I have a small (54k) linux binary that I need to gut
and figure out the inner workings of. The "file"
command tells me:
Linux/i386 demand-paged executable (ZMAGIC)
which tells me it is an a.out format binary, but
little else. I am interested in finding out what
the reference to ZMAGIC means, and getting my hands
on a Binary-to-Hex-to-Assembly disassembler (if one
has been written for linux yet).
Does anyone have any ideas?
Thanks,
R.
I don't know about a disassembler or decompiler, but the "strace"
command (especially with options) gives tons of information about what a
program actually *does*... since it shows the systems calls, it doesn't
show you internal data manipulations, but it does show you about
everything else... what's read, what memory is requested, what's
written, what ioctl's get issued, etc.
--
Chris Tyler <CTy...@Oxford.net>
Global Proximity Corporation (519) 421-3541 / fax (519) 421-2107
Internet and Computer Consulting
The command "objdump -d file" disassembles the file. If the binary has not
been stripped, objdump will show you where each function is in the listing.
If it's been stripped, you'll have one big dump of assembly, not too easy
to understand, but if you're determined enough you can figure it out. gcc
mixes string literals with machine code in its object files, so you'll see
some apparently meaningless sequences of instructinos that are actually
ASCII strings, not instructions.
"objdump -f" will tell you the start address, which will be some code that
does some libc init things, sets up the stack frame for main(), and calls
main. Once you get into main, you're on your own.
One easy landmark to look for is "int $0x80" which is the entry point
to all the Linux system calls. Whatever value is loaded into %eax
right before the int80, look that value up in /usr/include/sys/syscall.h
and you'll have the name of the syscall. Now you can easily locate
important functions like read() and write() and _exit() even if the program
is stripped.
BTW, objdump is part of GNU binutils, in case you don't have it already.
If the program is dynamically linked, you get the added fun of trying to
figure out where the libc functions are in the shared lib. For a.out shared
libs, run "nm -n" on the corresponding .sa file to get a list of shared lib
entry points. (I'm not sure if this will work if your .sa file isn't from
the same library version that the mystery program was linked with.) For ELF
shared libs, I don't know of any easy way to figure out where the library
functions will be relocated to. But there is one last weapon: gdb!
gdb can single-step by cpu instructions with the "stepi" and "nexti"
commands, and you can insert breakpoints at a particular instruction with
commands like "break *0x2000". You can print out register values with
"print $eax" or dump them all with "info reg", and you can even alter them
with "print $eax=0". Also read about the "x" command for examining data.
This post is far too long. Oh well.
$ man objdump
$ man strace
$ gdb
gdb> help disassemble
gdb> quit
$
--
James Youngman VG Gas Analysis Systems |The trouble with the rat-race
Before sending advertising material, read |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.