THE ANATOMY OF A COMPUTER PROGRAM

As anyone who has written a script or program knows , the user never actually creates the binary themselves . They create a program in some higher-level language (C, C#, Java, etc.) and then use a compiler or interpreter to actually convert the code into the lower-level instruction set.

 Hello World in C #include<stdio.h> main() {      printf("hello\n"). } Hello World in Assembly (x86) txt     db      "hello world!", 0Dh,0Ah, 24h lea      dx, txt mov      ah, 09h int     21h mov     ah, 0 

This instruction set can be one of two things: either the native ISA (Instruction Set Architecture) of the platform the program is intended to run on or an instruction set that is used by a virtual machine to execute (think C# and Java). The ISA instructions are then encoded into a binary number, and all the instructions are appended together to create the binary file. From a reverse engineering standpoint, it is important to discover how the binary was compiled and the platform it was intended to run on so you don't waste a lot of time chasing your tail.

Determining a Binary File Type

GNU has a utility named file which can be useful in determining the makeup of a binary executable. File looks at the header of the file, and from the signature of that header (the so-called "magic" number) it determines whether the file is a natively compiled executable, a byte-code compilation, or just static nonexecutable binary data. Let's take a look at what a typical file command looks like:

 $ file backdoor        backdoor:  ELF 32-bit LSB executable, Intel 80386, version 1        (SYSV), dynamically linked (uses shared libs), stripped 

As you can see, when we run the file utility on the executable backdoor, we are given lots of useful information, albeit somewhat cryptic at first glance. Breaking the results down: ELF 32-bit LSB executable tells us this is a Linux ELF binary, compiled for the x86 platform. Dynamically linked is important to us because that means the executable relies on other files besides itself to run. If you are trying to track down all the files that have been placed on your computer, you can look to see if the executable uses any nonstandard libraries and where they are stored on the file system for an idea of where else to look for root kit remnants. The last detail, stripped , is the most important one if you are going to actually reverse engineer the binary. When a program is compiled, you have the option of including the source code for ease of debugging. If you have ever written a program and used a debugger such as GDB or the one in Visual Studio, you have worked with the code embedded within the executable. A hacker can remove the source code (also known as the symbols ) either at compile time by using a flag to the compiler or after creation by using the GNU utility strip. If you are lucky enough to be working with a binary that has all symbols included, you can use the debugger to re-create the symbols. If not, your best course of action will be to try to determine as much as you can without looking at the binary programmatically.



Anti-Hacker Tool Kit
Anti-Hacker Tool Kit, Third Edition
ISBN: 0072262877
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net