ARM/ELF issues

[radare]

This issue aims to track and describe a bunch of issues found in a small ELF file compiled with the NDK for Android.

libhello-jni.so.zip

• [ ] two relocs pointing to the same import
• [ ] reloc resolution

By setting asm.emu=1 and emu.write=1 i see that r6 points to 0 by doing the esil emulation of this function.

The reason why r6 points to 0 is because its a reloc, and this is set by the system linker at runtime, but we should be able to identify the address which matches witht he info from rabin2, but for some reason that i didnt checked yet, the flag is pointing somewhere else, thats why there's no name in the resolution as a comment next the the blx lines.

by looking at the output of ir* i find out the problem... this bin have 2 relocs to the same strtok import (WTF). thats why the 2nd reloc overwrites the first flag.

[0x00000c9c]> ir*~strtok f reloc.strtok @ 0x00003f6c f reloc.strtok @ 0x00003fdc

relocs virtual values can be set with io.cache, but that can result in some unexpected and complicated results, so thats why the .dynamic section is empty.

[radare]

The 2nd, "reloc resolution" one. Is related to the fact that this code does like this:

ldr r1, [0xdd0] ; 
add r1, pc // strtok
add r4, pc // another import
ldr r6, [r1]  // load reloc runtime address which is 0 in  r2land
blx r6    // call strtok reloc // actually calls to  0, beacuse r2 didnt "resolved" this reloc in  memory

we need the io.cache magic here and set false values in memory to trick the disassembler to output meaningful references here

[ret2libc]

With regard to "two relocs pointing to the same import":

Are you sure it is a bug? From readelf I can see two relocations, so I'm inclined to say we are doing the right thing.

Relocation section '.rel.dyn' at offset 0x93c contains 25 entries
...
00003f6c  00002015 R_ARM_GLOB_DAT    00000000   strtok@LIBC
...

Relocation section '.rel.plt' at offset 0xa04 contains 18 entries:
...
00003fdc  00002016 R_ARM_JUMP_SLOT   00000000   strtok@LIBC
...

[ret2libc]

@radare could you please explain exactly what is the issue with precise "Steps to reproduce"/"Expected output"/"Actual output"? I have an hard time understanding what is the second issue you are mentioning. Also, I fail to understand how all this is related to RBin (it seems more like an ESIL issue for what I got so far).

[radare]

yeah not all is depending on bin here, i will have a look when i get some time

[ret2libc]

This can't be solved if we don't get a better description of the issue, as already asked in https://github.com/radare/radare2/issues/12206#issuecomment-469758419

[radare]

i will describe in detail when i get some spare time. focus on the other elf issue for now