4 ms·
If you're ever wondering what the load address of a piece of code is, my favourite trick is to: 1) identify relative addresses of all C-style strings from the
by mmastrac 5y ago
If you're ever wondering what the load address of a piece of code is, my favourite trick is to:
1) identify relative addresses of all C-style strings from the start of the binary
2) identify all absolute read addresses
3) find the load address where the most read addresses correspond to the most strings
This solves the problem for me in the vast majority of cases. If you don't have strings, function prologues work as well.
I don't think there's any tooling for this yet. I've had to write the same algorithm over and over. It works regardless of any header information at the start of the binary, though it will fail if there is data between chunks (but you may see multiple valid alignments that can hint to something like this happening)
- CaciaraAsAServi 5y agoYep! But before doing all of this, check if any .so/.dll for emulating the raw piece of code you are studying is available, so you can do this: 1. check if in the .so/.dll you can spot any function referring to any recognizable (occurring only once) kind of binary blob - like images, or strings too 2. find the same function in the raw image, Ghidra's decompiler helps so much in this 3. find the address supposed to be pointing to the same binary blob (assuming that this blob is the same in the emulated and the real version) 4. scan the raw image for that same blob you have in the emulated version 5. do the maths to find the base address of the raw image. Obviously all of this works if the raw binary image you have all refers to the same flat memory space and there's no partial relocation by the bootloader/program accepting this image going on. Don't ask me about that time I painfully spent so much time without knowing I had one file with the odd name of "emulator.dll" staring at me all that time...