radare2
radare2 copied to clipboard
radareorg
Unable to find string xrefs for shared libraries
Short version of this bug: take a shared library not compiled for x86_64 and radare2 is unable to find references to strings.
Long version: Take this piece of c code:
#include <stdio.h>
void test()
{
printf("Hello World!\n");
}
Name the file as test.c and compile it as following:
gcc -shared -fPIC test.c -o libtest.so
Then open with radare:
r2 -AA -e io.cache=true libtest.so
> iz
vaddr=0x0000068d paddr=0x0000068d ordinal=000 sz=13 len=12 section=.rodata type=ascii string=Hello World!
> axt 0x68d
...
data 0x674 lea rdi, qword str.Hello_World_ in sym.test; const char * s
>[email protected]
/ (fcn) sym.test 19
| sym.test ();
| ; UNKNOWN XREF from 0x00000340 (unk)
| ; UNKNOWN XREF from 0x00001590 (unk)
| 0x00000670 55 push rbp
| 0x00000671 4889e5 mov rbp, rsp
| 0x00000674 488d3d120000. lea rdi, qword str.Hello_World_ ; 0x68d ; rdi ; "Hello World!" @ 0x68d ; const char * s
| 0x0000067b e8d0feffff call sym.imp.puts ; int puts(const char *s);
| 0x00000680 90 nop
| 0x00000681 5d pop rbp
\ 0x00000682 c3 ret
Fine! But now try with:
gcc -shared -fPIC test.c -m32 -o libtest.so
What we got is:
r2 -AA -e io.cache=true libtest.so
...
[can't find function prototype for sym.__x86.get_pc_thunk.dxnctions (aan)
can't find function prototype for sym.__x86.get_pc_thunk.dx
can't find function prototype for entry0
can't find function prototype for sym.__x86.get_pc_thunk.dx
can't find function prototype for entry0
can't find function prototype for entry0
can't find function prototype for fcn.000003e8
can't find function prototype for sym.__x86.get_pc_thunk.ax
...
> iz
vaddr=0x00000564 paddr=0x00000564 ordinal=000 sz=13 len=12 section=.rodata type=ascii string=Hello World!
> axt 0x564
null 0x1114 add eax, 0 in unknown function
null 0x1924 add eax, 0x5640000 in unknown function
null 0x1928 add eax, 0xd0000 in unknown function
> pdf @sym.test
/ (fcn) sym.test 43
| sym.test ();
| ; var int local_4h @ ebp-0x4
| ; UNKNOWN XREF from 0x00000228 (unk)
| ; UNKNOWN XREF from 0x000013e4 (unk)
| 0x00000520 55 push ebp
| 0x00000521 89e5 mov ebp, esp
| 0x00000523 53 push ebx
| 0x00000524 83ec04 sub esp, 4
| 0x00000527 e81f000000 call sym.__x86.get_pc_thunk.ax
| 0x0000052c 05d41a0000 add eax, 0x1ad4
| 0x00000531 83ec0c sub esp, 0xc
| 0x00000534 8d9064e5ffff lea edx, dword [eax - 0x1a9c]
| 0x0000053a 52 push edx ; const char * s
| 0x0000053b 89c3 mov ebx, eax
| 0x0000053d e88efeffff call sym.imp.puts ; int puts(const char *s);
| 0x00000542 83c410 add esp, 0x10
| 0x00000545 90 nop
| 0x00000546 8b5dfc mov ebx, dword [ebp - local_4h]
| 0x00000549 c9 leave
\ 0x0000054a c3 ret
As you can see, the string reference is not found.
r2 -v radare2 1.1.0-git 13141 @ linux-x86-64 git.1.0.2-197-g0251197 commit: 025119779f90a9ac3b0235142b6a2bb0a3f07973 build: 2016-12-02
Because of the relocs?
On 4 Dec 2016, at 23:27, Maijin [email protected] wrote:
Here is the lib - libtest.zip
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
so looks like this compiler generates "call next;next:;pop eax" and then computes the relative pointer to the string from here. you can fix this with asm.emuwrite=true. but this can be dangerous in some situations. remember to run aeim first to initialize the stack.
the string itself is not recognized because it priorizes the section symbol in here. we can do better here with the new apis i added that are used in the disasm
This is very nice. However I am still having some troubles. This file contains a compiled lib from the source I posted. I am not able to obtain the same results with this library, even if everything seems to work flawlessly with the one given by @Maijin.
Here it is what I get using this lib:
I think we should allow asmemu to emulate part of the stack without requiring asm.emuwrite. That would be the best way to handle all those cases because compilers can get really funky here and identifying patterns to resolve references seems like a bad idea to me
On 12 Dec 2016, at 01:21, Edoardo Morandi [email protected] wrote:
This is very nice. However I am still having some troubles. This file contains a compiled lib from the source I posted. I am not able to obtain the same results with this library, even if everything seems to work flawlessly with the one given by @Maijin.
Here it is what I get using this lib:
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
thats the same, but calling a helper function to set eax=ret address
what about other archs? is this also an issue for arm or mips?
On 12 Dec 2016, at 01:21, Edoardo Morandi [email protected] wrote:
This is very nice. However I am still having some troubles. This file https://drive.google.com/file/d/0B88Q0Bv2HTxxSW9jWUQtNEZpd2c/view?usp=sharing contains a compiled lib from the source I posted. I am not able to obtain the same results with this library, even if everything seems to work flawlessly with the one given by @Maijin https://github.com/Maijin.
Here it is what I get using this lib: https://cloud.githubusercontent.com/assets/350168/21084773/e16405ae-c008-11e6-860b-380db0a85bfc.png — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6283#issuecomment-266319750, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lsLKLfL0kqXSd0vVEf-69IIEakXcks5rHJOmgaJpZM4LDuDB.
I am able to cross-compile for ARM, and things seem to work correctly. asm.emuwrite does not seem to be necessary, but I just tried to compile against armv7-a.
Unfortunately I do not have a gcc binary to compile against MIPS. Anyone can do this? Otherwise I will leave my laptop compile the mips64-elf-gcc overnight.
you can use the ndk.. well i could do this too but im a bit busy. just trying to get feedback and ideas for different problems that may affect this issue. thanks!
On 12 Dec 2016, at 14:29, Edoardo Morandi [email protected] wrote:
I am able to cross-compile for ARM, and things seem to work correctly. asm.emuwrite does not seem to be necessary, but I just tried to compile against armv7-a.
Unfortunately I do not have a gcc binary to compile against MIPS. Anyone can do this? Otherwise I will leave my laptop compile the mips64-elf-gcc overnight.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6283#issuecomment-266431015, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-ls8AibD4Rf2RDL6FrFiyhZOYmOqJks5rHUw6gaJpZM4LDuDB.
I performed some tests, and I am not completely sure of the results I get:
This is what I get if I compile the test lib with the ndk prebuilts. Specifically, the file has been built with the mipsel-linux-android-gcc 4.9.x (20150123), using arch mips32r6. It is my very first time I see a MIPS assembly, and it is almost obscure to me. However I can see that the str.Hello_World_ ref is seen used in the addition operation (but not sure if it is easy to detect that it will be passed to sym.imp.puts -- probably related to my ignorance ;-) ).
I also tried to use the x86 gcc compiler from ndk, and the issue seems to persist even with this old gcc version.
If you thing I can perform some other test, just let me know. I am happy if I am able to help you with this problem!
EDIT: fixed x86 screenshot
without aeim i dont think the emulation of mips will work at all also asm.emuwrite is needed
On 13 Dec 2016, at 12:34, Edoardo Morandi [email protected] wrote:
I performed some tests, and I am not completely sure of the results I get: https://cloud.githubusercontent.com/assets/350168/21138308/b80b6c1c-c12d-11e6-82c1-7286d897ae8f.png This is what I get if I compile the test lib with the ndk prebuilts. Specifically, the file has been built with the mipsel-linux-android-gcc 4.9.x (20150123), using arch mips32r6. It is my very first time I see a MIPS assembly, and it is almost obscure to me. However I can see that the str.Hello_World_ ref is seen used in the addition operation (but not sure if it is easy to detect that it will be passed to sym.imp.puts -- probably related to my ignorance ;-) ).
I also tried to use the x86 gcc compiler from ndk, and the issue seems to persist even with this old gcc version. https://cloud.githubusercontent.com/assets/350168/21138829/3177d4a8-c130-11e6-8b8d-80699bced315.png If you thing I can perform some other test, just let me know. I am happy if I am able to help you with this problem!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6283#issuecomment-266716126, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-luyDfHEFw2KfeT8JCkYnmH7-mhjKks5rHoLPgaJpZM4LDuDB.
Whoops, sorry! I just forgot to run aeim before making the screenshot for x86. I will edit the previous post in a couple of minutes. However the MIPS screenshot have been correctly taken, setting asm.emu, asm.emuwrite and running aaa. Maybe I am still missing something?
the string ref is fine in mips sorry :D
On 13 Dec 2016, at 12:37, [email protected] wrote:
without aeim i dont think the emulation of mips will work at all also asm.emuwrite is needed
On 13 Dec 2016, at 12:34, Edoardo Morandi <[email protected] mailto:[email protected]> wrote:
I performed some tests, and I am not completely sure of the results I get: https://cloud.githubusercontent.com/assets/350168/21138308/b80b6c1c-c12d-11e6-82c1-7286d897ae8f.png This is what I get if I compile the test lib with the ndk prebuilts. Specifically, the file has been built with the mipsel-linux-android-gcc 4.9.x (20150123), using arch mips32r6. It is my very first time I see a MIPS assembly, and it is almost obscure to me. However I can see that the str.Hello_World_ ref is seen used in the addition operation (but not sure if it is easy to detect that it will be passed to sym.imp.puts -- probably related to my ignorance ;-) ).
I also tried to use the x86 gcc compiler from ndk, and the issue seems to persist even with this old gcc version. https://cloud.githubusercontent.com/assets/350168/21138829/3177d4a8-c130-11e6-8b8d-80699bced315.png If you thing I can perform some other test, just let me know. I am happy if I am able to help you with this problem!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/6283#issuecomment-266716126, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-luyDfHEFw2KfeT8JCkYnmH7-mhjKks5rHoLPgaJpZM4LDuDB.