search

rizinorg / rizin

UNIX-like reverse engineering framework and command-line toolset.
https://rizin.re
GNU Lesser General Public License v3.0
2.69k stars 360 forks source link

Stop Analyzing at Tailjump into a Reloc Target #1144

Open thestr4ng3r opened 3 years ago

thestr4ng3r commented 3 years ago

Since 58433a72accfee45dce6085f49d3f7b84a56aa05, relocs in ELF are patched by default without needing io.cache. This has brought some issues to light since now pretty much the entire test suite runs with reloc patching. In particular when there is a tailjmp to a reloc-ed imported function, the analysis thinks the stub reloc target constructed by the ELF loader in https://github.com/rizinorg/rizin/blob/c17a23a9139be19283d288b02cb328c6939fab6d/librz/bin/p/bin_elf.inc#L768 and used for targets in https://github.com/rizinorg/rizin/blob/c17a23a9139be19283d288b02cb328c6939fab6d/librz/bin/p/bin_elf.inc#L625 which just consists of 0s, is actual code and continues to analyze there.

See for example the function at 0x000071e0 after aaa in bins/elf/ls: Bildschirmfoto 2021-05-17 um 21 02 37

All blocks starting with 0x23de8 are garbage. Note how it even thinks this is a switch.

One way to tell the analysis to stop continuing there would be to have actual RzAnalysisFunctions at the reloc targets, marked specifically as stubs.

ret2libc commented 3 years ago

@thestr4ng3r when does this happen?

thestr4ng3r commented 3 years ago

What exactly do you mean? It seems like it happens in jumptable analysis.

ret2libc commented 3 years ago

What exactly do you mean? It seems like it happens in jumptable analysis.

Do you see this with any ELF? Just with .o files? Or with .so? Or even with executables?

thestr4ng3r commented 3 years ago

The example given in the description is 0x000071e0 in our bins/elf/ls, which is an elf executable. In theory it can happen with any ELF that has a tailjmp to an imported function without lazy binding.