utds3lab / multiverse

A static binary rewriter that does not use heuristics
GNU Lesser General Public License v3.0
298 stars 33 forks source link

Binary execution goes wrong #6

Open ckxckx opened 5 years ago

ckxckx commented 5 years ago

When the warning "WARNING elfmanip._update_phdr_entry :: problem finding LOAD segment containing new phdr location" happens in the rewriting procedure, the rewrited binary will not work well.

drjantz commented 4 years ago

I just want to add to this issue. We receive a similar error when using multiverse with the SPEC CPU 2006 benchmarks. We do not see the error with the simplest example that comes with multiverse.

Specifically, we get the bug when we run multiverse with bzip2 from SPEC CPU 2006.

If we do:

python icount.py ./bzip2

It does produce a bzip2-r executable file, but the last line of output states:

WARNING elfmanip._update_phdr_entry :: problem finding LOAD segment containing new phdr location

If we run the bzip2-r executable under gdb and watch the global counter that was inserted by icount.py, we can see it reach instructions that increment the counter exactly 11 times. Then, the program reaches an uninstrumented version of the main routine, and executes the remainder of the program without instrumentation.

Any help would be greatly appreciated. Thanks.

utds3lab commented 4 years ago

Could you run the file command on your version of bzip2 and share the output? It will help to know whether it is 32-bit or 64-bit and whether it is a position-independent executable.

drjantz commented 4 years ago

This is a 64-bit binary. We have tried compiling with a 32-bit binary, but we had some other issues with the 32-bit binary. Here's the output of file:

$ file bzip2 $ bzip2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=880bca2d84e71df63b534d06486dff74e22d3baa, not stripped

drjantz commented 4 years ago

FYI, this morning I tried with a statically linked binary (i.e., compiled with -static), and received some additional warnings along with the same warning from earlier. Here's the output of file on the static binary:

$ file bzip2 $ bzip2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=7b706cefab8733d23fff6e93b89bd9790530af7f, not stripped

And from icount.py:

$ python icount.py bzip2 ... WARNING elfmanip._update_phdr_entry :: problem finding LOAD segment containing new phdr location

utds3lab commented 4 years ago

My 64-bit binary for spec's bzip2 works fine for me. It shows that about 983 thousand instructions executed when running bzip2 with no arguments and about 377 billion instructions executed when I ran bzip2 with icount.py as the file to compress.

My compiled version of bzip2 appears to use an older Linux ABI version:

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=acba1409b496f99cdde7fe99811ed4e49ce0a91c, not stripped

Besides that, I can't be sure what might be causing the problem without more information. Perhaps try compiling a version of bzip2 that isn't from the spec benchmark. If that version doesn't work, upload the original and rewritten binaries from that version somewhere and I can try to take a look.

drjantz commented 4 years ago

Could you send me the exact Linux distribution and kernel version you are using? Thanks!

rlt3 commented 4 years ago

Could you also share which version of Pwntools you are using?

utds3lab commented 4 years ago

The Linux distribution is Ubuntu 14.04.1, kernel version 4.4.0, pwntools version 2.2. All fairly old versions since this was developed a few years ago.

rlt3 commented 4 years ago

I've got multiverse working properly now inside a VM with those specific versions of everything. Appreciate the help!