HexHive / retrowrite

RetroWrite -- Retrofitting compiler passes through binary rewriting
Other
655 stars 78 forks source link

Could not find valid section ... #7

Closed vanhauser-thc closed 4 years ago

vanhauser-thc commented 4 years ago

I run it as in the example:

(retro) # python3 -m librw.rw /bin/ls ./ls.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 21398
[x] Couldn't find valid section 21fc8
[x] Couldn't find valid section 21fd0
[x] Couldn't find valid section 21fd8
[x] Couldn't find valid section 21fe0
[x] Couldn't find valid section 21fe8
[x] Couldn't find valid section 21ff0
[x] Couldn't find valid section 21ff8

an ls.s file is created but it fails to compile:

# gcc ls.s -o ls.bin
/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x20): undefined reference to `main'
/bin/ld: /tmp/cc071IcM.o: in function `_obstack_newchunk':
(.text+0x7f): undefined reference to `.L160e0'
/bin/ld: (.text+0x111): undefined reference to `.L16100'
/bin/ld: /tmp/cc071IcM.o: in function `_obstack_free':
(.text+0x178): undefined reference to `.L16100'
/bin/ld: /tmp/cc071IcM.o: in function `_obstack_begin':
(.text+0xd): undefined reference to `.L16120'
/bin/ld: /tmp/cc071IcM.o: in function `_obstack_begin_1':
(.text+0x22): undefined reference to `.L16120'
/bin/ld: /tmp/cc071IcM.o: in function `_obstack_free':
(.text+0x18d): undefined reference to `.L4722'
/bin/ld: /tmp/cc071IcM.o:(.data+0x1f0): undefined reference to `.LCcc60'
/bin/ld: /tmp/cc071IcM.o:(.data+0x260): undefined reference to `.LC160a0'
/bin/ld: /tmp/cc071IcM.o:(.data.rel.ro+0x0): undefined reference to `.LC6ce0'
/bin/ld: /tmp/cc071IcM.o:(.data.rel.ro+0x8): undefined reference to `.LC7200'
[...]

and this happens with every binary I try, static compiled or dynamic. all 64 bit though

gannimo commented 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 :/

vanhauser-thc commented 4 years ago

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)

sushant94 commented 4 years ago

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!

vanhauser-thc commented 4 years ago

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

vanhauser-thc commented 4 years ago

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.
sushant94 commented 4 years ago

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.

vanhauser-thc commented 4 years ago

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 ;)

gannimo commented 4 years ago

I'm also working on a set of demo binaries to help others get started. Thanks for providing feedback along the way! :)