10

As you might imagine, source code is not available. The executable was written using C/C++ and compiled using gcc.

This is what file has to say about the file

ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, not stripped

According to ldd, these are the libraries that the program uses:

    libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xf7700000)
    libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xf7554000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7528000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf737e000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7363000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7359000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7270000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf726b000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7252000)
    /lib/ld-linux.so.2 (0xf7789000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7234000)

All these libraries are also available in 64bit version.

The Questions:

  1. Is it possible to reassemble the application as 64bit application ?
  2. What tools exists to aid with such a thing ? (if possible)
Improve this question

2 Answers 2

Reset to default
5

Even if it's not in the question, as it would be quite hard to actually reassemble, I hope you can try something else than reassembling, or that it's at least a small and non-obfuscated file.

low level

Reassembling would be very difficult:

Tools: I can't think of a specific tool to help, beyond IDA and normal reverse engineering methods (I get similar request to port DOS/NE files to PE)

Calling conventions: Porting from 32b to 64b will be difficult as calling conventions are different, so they'll need to be rewritten at assembly level. At least, ELF structures are very similar.

high level

Your best bet is to try and decompile via Hex-Rays Decompiler to save the hassle, but it will still require a lot of tedious work before the decompiled code can work as expected.

Improve this answer
8
  • What do you mean 'calling conventions are different'. I thought this was ultimately at the behest of the operating system / executable format?
    – zetavolt
    Commented Apr 10, 2013 at 16:27
  • passing function parameters in registers and not on the stack
    – Ange
    Commented Apr 10, 2013 at 16:34
  • I see, for certain exe's, isn't it still the same? I believe two items are generally passed in registers and the rest on the stack in Windows's "standard" calling convention? Why (besides register size) are these calling conventions distinct?
    – zetavolt
    Commented Apr 10, 2013 at 16:38
  • (exe as in PE, right?) I wrote this as a reminder for PE calling conventions.
    – Ange
    Commented Apr 10, 2013 at 16:43
  • I see, I thought Microsoft called it "Standard", now I know it's called FastCall -- You and corkami are flipping awesome by the way. I tell everyone I meet who will listen about you guys.
    – zetavolt
    Commented Apr 10, 2013 at 16:44
5

The question here is what do you need? Do you need to be able to run this thing on 64bit and interact with it or is the objective to actually port it?

Run it

If you only needed to run it and we can assume the compatibility libraries (those allowing to run 32bit programs on 64bit) as a given, you could probably intercept all kinds of functionality using the standard ld.so methods (LD_PRELOAD and friends) as also outlined in answers to How do I add functionality to an existing binary executable? Going from there you'd be able to interface with the existing and unchanged 32bit program by means of memory mapped files or sockets or really any kind of IPC mechanism that you deem suitable for the purpose.

Quite frankly this is likely the best method with the least effort to put in.

On Debian 5 the compatibility layer is in the following two packages:

libc6-dev-i386 - Embedded GNU C Library: 32-bit development libraries for AMD64
libc6-i386 - Embedded GNU C Library: 32-bit shared libraries for AMD64

The same name is used on Ubuntu 10.04 through 12.04. These are the only versions I could check at the moment, but I'm aware of similar stuff in RHEL/CentOS/ScientificLinux.

Port it

Otherwise you'd run into a whole plethora of problems, the biggest of which were already outlined by ange albertini here.

In general, if you are lucky and it looks like that, the debug information (not stripped it says) will allow you to sort out names of source files, so you may be able to put puzzle pieces like libraries together and can then concentrate on the "actual" code. This may not be a big advantage, but for the reverse engineer every little straw helps.

Decompilers like the Hex-Rays plugin or the one that comes with Hopper could be a good way of getting a more high-level idea of the code. Still this will be a lot of work unless you focus on the functional parts that you need - which is why I (being lazy and all) would always go with the option above, i.e. running it in compatibility mode.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.