Closed vanhauser-thc closed 4 years ago
Could it be that your binary is stripped? Finding function beginnings is currently not supported, so you need to supply a symtab using some other tool :/
it was stripped but with an unstripped one its similar:
# file unrar
unrar: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=026933b3a0c1610e6832db340cf30bb71cfd0422, for GNU/Linux 3.2.0, not stripped
is this normal ?->
(retro) # python3 -m librw.rw /prg/tests/qemu/unrar-x/unrar unrar.s
[*] Relocations for a section that's not loaded: .rela.dyn
[*] Relocations for a section that's not loaded: .rela.plt
[x] Could not replace value in .init_array
[x] Couldn't find valid section 63998
[x] Couldn't find valid section 63fc0
[x] Couldn't find valid section 63fc8
[x] Couldn't find valid section 63fd0
[x] Couldn't find valid section 63fd8
[x] Couldn't find valid section 63fe0
[x] Couldn't find valid section 63fe8
and then:
(retro) # g++ unrar.s -o unrar -lpthread -lm
/bin/ld: /tmp/cc6K20zl.o:(.data+0x20): undefined reference to `.LC0'
/bin/ld: /tmp/cc6K20zl.o:(.init_array+0x0): undefined reference to `.LC3d80'
/bin/ld: /tmp/cc6K20zl.o:(.data.rel.ro+0x378): undefined reference to `.LC10'
/bin/ld: /tmp/cc6K20zl.o:(.data.rel.ro+0x388): undefined reference to `.LC10'
/bin/ld: /tmp/cc6K20zl.o:(.data.rel.ro+0x398): undefined reference to `.LC10'
collect2: error: ld returned 1 exit status
I tried using gcc 7 and 9 (both for compiling unrar and recompiling unrar.s)
The output you see above is normal (for debug purposes). The real problem is, unrar is C++ compiled, and there are known issues with supporting C++ compiled binaries (the one that you mention above is one of them). Currently, only C compiled binaries have stable support in retrowrite. Sorry about that!
ah ok! I think you might get less issues reported if you put in a caveat section about "unstripped C programs only at the moment" :) EDIT: just saw you put "unstripped and position independant" in there ;) - still a caveat section would be nice, plus the C only code and maybe gcc versions verified to work? Or whatever other restrictions are currently there
OK, continuing trying to get this working. I am using tiff-4.0.4 thumbnail now, which is unstripped, C, and compiled with gcc 7:
thumbnail: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=97dff6aa6fe032ce92faaad7ed1cb1d75548f03b, for GNU/Linux 3.2.0, with debug_info, not stripped
converting to .s with the same debug output, and recompiling with gcc works! :)
gcc thumbnail.s -o thumbnail.bin -llzma -ljpeg -lz -lm
but - when running it it crashes:
gdb$ run -h
Starting program: /prg/tests/qemu/tiff-4.0.4/tools/thumbnail.bin -h
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
--------------------------------------------------------------------------[regs]
RAX: 0x0000000000000001 RBX: 0x00007FFFF7BABCE0 RBP: 0x0000000000000002 RSP: 0x00007FFFFFFFD340 odItsZaPc
RDI: 0x0000000000000002 RSI: 0x0000000000000000 RDX: 0x00000000004353E0 RCX: 0x0000000000000000 RIP: 0x00007FFFF7AD04C8
R8 : 0x0000000000000000 R9 : 0x0000000000000000 R10: 0x0000555555554E5F R11: 0x00007FFFF7AD0AC0 R12: 0x00007FFFFFFFDD98
R13: 0x00000000004353E0 R14: 0x0000000000000000 R15: 0x0000000000000001
CS: 0033 DS: 0000 ES: 0000 FS: 0000 GS: 0000 SS: 002B
--------------------------------------------------------------------------[code]
=> 0x7ffff7ad04c8 <_getopt_internal_r+88>: movzx eax,BYTE PTR [r13+0x0]
0x7ffff7ad04cd <_getopt_internal_r+93>: cmp al,0x2d
0x7ffff7ad04cf <_getopt_internal_r+95>: je 0x7ffff7ad05b8 <_getopt_internal_r+328>
0x7ffff7ad04d5 <_getopt_internal_r+101>: cmp al,0x2b
0x7ffff7ad04d7 <_getopt_internal_r+103>: je 0x7ffff7ad08d0 <_getopt_internal_r+1120>
0x7ffff7ad04dd <_getopt_internal_r+109>: mov ecx,DWORD PTR [rsp+0x78]
0x7ffff7ad04e1 <_getopt_internal_r+113>: xor edx,edx
0x7ffff7ad04e3 <_getopt_internal_r+115>: test ecx,ecx
--------------------------------------------------------------------------------
_getopt_initialize (argc=<optimized out>, argv=<optimized out>, posixly_correct=<optimized out>, d=<optimized out>, optstring=<optimized out>) at getopt.c:394
394 getopt.c: No such file or directory.
Thank you for trying again! :)
From your file output on thumbnail, it seems to me that it isn't compiled to be position-independent: as it says LSB executable
rather than LSB shared object
. Can you confirm that it is compiled to be position-independent?
If it is, and you're still having issues, please do link/attach the executable so that we may debug.
you are right! I had assumed it would be PIE just because everything compiled nowadays is ... but its an old version ...
I recompiled with -pie, and then it runs ...
thanks and sorry ;)
I'm also working on a set of demo binaries to help others get started. Thanks for providing feedback along the way! :)
I run it as in the example:
an ls.s file is created but it fails to compile:
and this happens with every binary I try, static compiled or dynamic. all 64 bit though