-
I have two linux arm64 binaries: one is libc and one has a statically linked libc. ioctl in libc gets lifted as: ioctl when statically linked gets lifted as: I think the problem with the statically linked one is the lack the correct platform being associated with this... binary view? function? So, I have a few questions, all related:
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
There's a default platform for a Function is a parameter of function creation (can't be changed after the fact; functions in a bndb are identified by a tuple of Was the statically linked file also an elf/mach-o or was it a raw file? My suspicion would be that the type library with syscall information hasn't been loaded for that file. |
Beta Was this translation helpful? Give feedback.
-
This was the thing that was biting me -- when I originally opened this binary I was testing lifter improvements before #2035 was fixed, so there was no platform for the initial analysis pass. Subsequently when I swapped out my arm64 architecture dll, it didn't fix things because the functions were already identified with no platform. In this case, if I wanted to reset the platform on everything it would be:
Or something similar? |
Beta Was this translation helpful? Give feedback.
There's a default platform for a
BinaryView
, but eachFunction
has its own reference to a platform object.Function.platfom
andBinaryView.platform
will show you what's in use for each.Function is a parameter of function creation (can't be changed after the fact; functions in a bndb are identified by a tuple of
(platform, address)
).Was the statically linked file also an elf/mach-o or was it a raw file? My suspicion would be that the type library with syscall information hasn't been loaded for that file.