Open ejm9 opened 1 year ago
This is a bug in the libc type library. The library name listed in the binary needs to match one of the alternate_names
in the type library. This binary however is linked against 'libc.so.0` and we don't have that one listed.
>>> bv.platform.type_libraries[0]
<typelib ‘libc_armv7.so.6’:armv7>
>>> bv.platform.type_libraries[0].alternate_names
[‘libc.so’, ‘libc.so.6’]
>>> bv.libraries
['libdl.so.0', 'libpthread.so.0', 'libcrypto.so.1.0.0', 'libc.so.0']
After introducing the fallback libc types, the snprintf
's type is correctly introduced into the binary view. However, this callsite(at 0xca8c
) still doesn't have parameters.
Seems like it's a problem during mapped_mlil_ssa
-> mlil
That's the same issue as https://github.com/Vector35/binaryninja-api/issues/4696
We have added fallback type libraries in 4.1, but the removal of the armv7 libraries that will allow those fallback to be automatically applied for armv7/thumb2 is coming on the 4.2 release or dev shortly after 4.1 ships.
I've looked at the examples that aren't showing arguments and haven't been able to determine why. The normal likely culprits are stack analysis failing causing #3927 but there could be other other issues.
Version and Platform (required):
Bug Description: at 0xca8c in hlil view it just has "snprintf()" with no arguments shown
Steps To Reproduce: open attached binary, change view to HLIL, go to address 0xca8c
Expected Behavior: expect to see correct arguments in snprintf, like: snprintf(buf, sz, format_str, arg1, arg2)
server_snprintf.zip