Recreating an Ubuntu instalation to run an unknown binary

Question

I have access to a Ubuntu 16.04 installation, that is able to run a certain binary (it is some version of LPMud compiled with unknown parameters), but I am not able to run the same binary on a different Ubuntu 16.04 installation - on the second system the binary fails with a segmentation fault.

I am not really interested in making an exact copy of the first system - I would like to know, what exactly is needed for the binary to run, so I can create a minimal installation of Ubuntu, that can run the binary.

What would be the best approach? I was thinking of extracting a list of installed packages (using apt list --installed) and the /etc directory, reinstalling the packages in the second system and copying the /etc directory.

I am aware, that there are many reasons, why a binary file can segfault on a different system, but I would like try some less data-intensive approaches before trying to narrow the enviroment down from a bit-for-bit copy.

Is this a reasonable approach? Does anyone have an idea, how to improve the chances of success?

Edit - more information on about the binary:

$ file driver
driver: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped

$ ldd driver
       statically linked

$ gdb driver
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/mud/bin/driver": not in executable format: File format not recognized

Trying to debug with a 32bit version of gdb brings similar results:

$ gdb driver
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
"/mud/bin/driver": not in executable format: File format not recognized
(gdb) show configuration
This GDB was configured as follows:
   configure --host=i686-linux-gnu --target=i686-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/lib/gdb (relocatable)
             --without-libunwind-ia64
             --with-lzma
             --with-python=/usr (relocatable)
             --without-guile
             --with-separate-debug-dir=/usr/lib/debug (relocatable)
             --with-system-gdbinit=/etc/gdb/gdbinit
             --with-babeltrace

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)
(gdb)

$ strace -o ./log ./driver ; cat ./log
execve("./driver", ["./driver"], [/* 9 vars */]) = 0
brk(NULL)                               = 0x8952000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f89000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
set_thread_area({entry_number:-1, base_addr:0xf7f89a80, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 (entry_number:12)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x4} ---
+++ killed by SIGSEGV (core dumped) +++

You can try gdb to debug why does it segfaults, the file is 32 bit and statically linked, do you have 32 bit libs installed on the other system or is it a 32 bit system? — mestia, Feb 04 '21 at 20:50
Ok, the system is obviously 64 bit, do you have 386 architecture enabled? you can do so with dpkg --add-architecture i386, once enabled install 32 bit libs: apt-get install libc6:i386 libstdc++6:i386 — mestia, Feb 04 '21 at 20:54
Thanks for the response! After enabling i368 architecture and installing the libc packages, gdb still says "not in executable format: File format not recognized" — jenda, Feb 04 '21 at 21:04
I guess you need to install 32 bit gdb to debug this issue, apt install gdb:i386 — mestia, Feb 04 '21 at 21:10
Tried it, but it is unfortunately still unable to recognize the file format. I have edited the question and added the full gdb output, including `show configuration` to check that the gdb is truly a 32 bit version. — jenda, Feb 04 '21 at 21:18
Ok, just as a wild guess, can you run strace on the system where it is working? like strace -o /tmp/log ./driver — mestia, Feb 04 '21 at 21:21
I have added the log from strace to the question, from my googling the ld.so.nohwcap and ld.so.preload warnings should not be an issue, but I am not sure. — jenda, Feb 04 '21 at 21:25
it is more interesting to see the strace output on the system where the binary is working. — mestia, Feb 04 '21 at 21:31
Also please check that the file isn't corrupted, like if the size or md5sum is the same — mestia, Feb 04 '21 at 21:35
Ok, this is embarrassing. The file was corrupted. After copying it again and confirming the hashes are identical, i can run the binary. :) Thank you very much for your help and patience. — jenda, Feb 04 '21 at 23:05

score 0 · Accepted Answer · answered Feb 05 '21 at 09:15

After comparing hashes of the binary on the first and the second system (using md5sum), I have found out, the binary on the second system was corrupted. Copying the binary again (and verifying that the hashes are identical) solved the issue.

Thank you to mestia who helped in the comments.

Recreating an Ubuntu instalation to run an unknown binary

1 Answers1