Cholesterol medicines are no longer the top-selling drugs in the U.S.

Apple Inc. CEO Steve Jobs still expects to return from his medical leave at the end of June. That's according to an Apple director who responded to an investor at the company's annual shareholder meeting Wednesday.

The investor had pressed for details about when the board of directors knew Jobs planned to step away from his daily duties. Apple (nasdaq: AAPL - news - people ) director Arthur Levinson responded only by saying that since Jobs announced Jan. 14 that he needed to go on leave, "nothing has changed."

Jobs, who turned 54 on Tuesday, was not at the meeting.

A survivor of pancreatic cancer who looked very thin last year, Jobs said Jan. 5 that he had a treatable hormone imbalance and would continue to run Apple. But the following week he went on leave to treat medical issues that were "more complex" than he had believed.

Copyright 2008 Associated Press. All rights reserved. This material may not be published broadcast, rewritten, or redistributed

Intro to Reverse Engineering - No Assembly Required

Last time we went over the C programming language in an introductory article specifically focusing on getting the security professional on the road to coding (or at least the road to understanding). This time around we extend the series of coding articles for non-programmers with an area of high interest in the infosec community, reverse engineering.

This paper is intended as an introduction to reverse engineering for someone who has no experience whatsoever on the subject. You should have some basic knowledge of C programming, and access to a Windows or Linux box (preferably both) using the x86 architecture (i.e., your average computer). No knowledge of assembly code, registers, or the like is assumed, although it helps. The "Introduction" section of the paper is intended for the newcomer who has little or no understanding of what reverse engineering is and may be skipped by those looking for more technical details.

del.icio.us

Discuss in Forums (14)

Table of Contents

1) Introduction
    An introduction to reverse engineering and some basic RE concepts.

2) Assembly Basics
    Introduction to assembly programming language and process memory.

3) The Stack In Detail
    Detailed workings of stack operations.

4) Reverse Engineering a Program 
    Disassemble and reverse engineer two programs; one with the source code, one without.

 Introduction

What is Reverse Code Engineering?
"Reverse engineering (RE) is the process of discovering the technological principles of a mechanical application through analysis of its structure, function and operation"(Wikipedia).  Basically, Reverse Code Engineering (RCE) is the application of the reverse engineering process to software - in other words, analyzing a program in order to understand how it works. Because reverse engineering is most commonly used to analyze closed-source programs, it is largely focused on the Windows platform; however, reversing under Linux is also popular for inspecting buffer overflows, closed-source Linux applications, and hostile Windows programs (without the risk of running them).

Why Reverse Engineer?
There are many reasons to reverse engineer a program.  Have you ever wished that your favorite Windows program had xyz functionality? Want to dissect malware or viruses? Look for and analyze a buffer overflow? Figure out how that hardware driver works so you can write one for Linux? Maybe you're just curious how a particular program works, but you don't have access to the source code? All of these are common reasons for reverse engineering an application, and as such, there are many varied facets of RCE that one may choose to focus on, each of which can take a substantial amount of knowledge and experience to become an expert in. This paper will give you with the basic knowledge to get started in RCE, providing a base to launch into which ever specialties you prefer.

How Does It Work?
This all sounds great, but how do we analyze a program for which we have no code?  There are many ways to observe how a program interacts with the rest of your system, such as  file and registry access (which can be helpful when reverse engineering), but these techniques still leave you with a black box - you don't know what is going on under the hood. In order to understand how we can analyze the internal workings of a program, some understanding of the compilation process is needed. When you compile your source code, there are three major steps that occur: translation of the source code into assembly code, assembly, and linking.

First, the source code is translated into assembly code by the compiler. Assembly is a very low-level programming language; it is composed of many simple instructions which deal directly with memory addresses and CPU registers. For instance, if you assign the number 1 to an integer variable in your source code, the resulting assembly code may look something like:  

Normally, there is no need to fear RE-restrictive laws, unless you plan to publicize your work. One exception would be cracking, or using reverse engineering to circumvent an application's registration scheme, which is very illegal. All programs we will be working with in this paper are original, so there is no question of legality; however, it is very important to keep this in mind if you begin work on someone else's programs.

What Do I Need? 

In short, tools and knowledge. Obviously, you must be able to read assembly code, however, it is not enough to just understand assembly instructions. You must also know how assembly instructions interact with areas of memory (particularly the stack), and what the CPU registers are used for. Knowledge of the high-level programming language that the application was written in can be very helpful, although it is not necessary. You should also understand specific system functions for the OS platform you are dealing with (such as Linux syscalls or the Windows API).

There are many tools available to the reverse engineer, much of them designed for specific purposes. However, there are two indispensable tools: the disassembler and the debugger. As its name implies, a disassembler disassembles a program's binary 1s and 0s into readable assembly code. A debugger can disassemble the binary instructions as well, but also allows you to run the code inside of the debugger; this gives you the distinct advantage of being able to observe the effect each instruction in real time, and allows you to better understand the program flow. The most popular debugger for Linux is the GNU debugger (gdb), which is also available for Windows; however, there are other very powerful debuggers for the Windows platform as well, such as SoftIce and OllyDbg. We will be using gdb in both Linux and Windows later in this paper.

Assembly Basics

Assembly language is specific to a processor's architecture - for example, a SPARC processor will use a different set of assembly instructions than a CPU using the x86 architecture, which will differ from the assembly instructions used when programming a PIC microcontroller. Since the most common architecture is x86, that is the instruction set we will be dealing with here. Before delving into the actual assembly instructions however, let's take a look at the CPU registers and process memory.

CPU Registers

A processor takes data and instructions that are stored in memory and performs whatever calculations are required, then writes the output back into memory as applicable. However, the CPU needs a place to store the data it retrieves from memory while it calculates; this is where the registers come in. Registers are small segments of memory inside the CPU that are used for temporarily storing data; some have specific functions, others are just used for general data storage. In a 32-bit processor, each register can hold 32 bits of data; in a 64-bit processor, the registers can hold 64 bits of data. This paper will assume the classic 32-bit registers are being used, but even if you have a 64-bit CPU, as long as it is backwards compatible with 32-bit applications, all of the following information is still applicable.

There are many registers used by a processor, but we are concerned primarily with a group of registers called the general purpose registers. The general purpose registers are composed of:

As you can see, there are three main sections of memory:

1. Stack Section - Where the stack is located, stores local variables and function arguments.

2. Data Section - Where the heap is located, stores static and dynamic variables.

3. Code Section - Where the actual program instructions are located.

The stack section starts at the high memory addresses and grows downwards, towards the lower memory addresses; conversely, the data section (heap) starts at the lower memory addresses and grows upwards, towards the high memory addresses. Therefore, the stack and the heap grow towards each other as more variables are placed in each of those sections.

Essential Assembly Instructions

Instruction	Example	Explanation
push	push eax	Pushes the value stored in EAX onto the stack
pop	pop eax	Pops a value off of the stack and stores it in EAX
call	call 0x08ffff01	Calls a function located at 0x08ffff01
mov	mov eax,0x1	Moves the value of 1 into the EAX register
sub	sub eax,0x1	Subtracts 1 from the value in the EAX register
add	add eax,0x1	Adds 1 to the value in the EAX register
inc	inc eax	Increases the value stored in EAX by one
dec	dec eax	Decreases the value stored in EAX by one
cmp	cmp eax,edx	Compare values in EAX and EDX; if equal set the zero flag* to 1
test	test eax,edx	Performs an AND operation on the values in EAX and EDX; if the result is zero, sets the zero flag to 1
jmp	jmp 0x08ffff01	Jump to the instruction located at 0x08ffff01
jnz	jnz 0x08ffff01	Jump if the zero flag is set to 1
jne	jne 0x08ffff01	Jump to 0x08ffff01 if a comparison is not equal
and	and eax,ebx	Performs a bitwise AND operation on the values stored in EAX and EBX; the result is saved in EAX
or	or eax,ebx	Performs a bitwise OR operation on the values stored in EAX and EBX; the result is saved in EAX
xor	xor eax,eax	Performs a bitwise XOR operation on the values stored in EAX and EBX; the result is saved in EAX
leave	leave	Remove data from the stack before returning
ret	ret	Return to a parent function
nop	nop	No operation (a 'do nothing' instruction)

*The zero flag (ZF) is a 1 bit indicator which records the result of a cmp or test instruction

Each instruction performs one specific task, and can deal directly with registers, memory addresses, and the contents thereof. It is easiest to understand exactly what these functions are used for when seen in the context of a simple hello world program, which we will do a little bit later.

Assembly syntax

There are two types of syntax used in assembly code: Intel and AT&T.  Each display thesame instructions, just a little bit differently (in the above examples I have used Intel syntax).  The primary difference is that the source and destination operands are flip-flopped. Look at the differences in how the syntaxes display the instruction to move the number 1 into the EAX register:

The Stack in Detail

The stack is a Last In, First Out (LIFO) data structure. Imagine that you are stacking plates; the first plate you put on the stack will be on the bottom; the second plate will be on top of the first plate, and the third plate will be on top of the second. When you start taking plates off of the stack, the third plate will come off first, then the second, and finally, the first. The stack section in memory operates the same way: data can be placed on the stack, but if you place three pieces of data on the stack, you will first have to remove the last two in order to access the first piece of data.

There are two types of stack operations: push and pop. When you want to place data onto the stack, you "push" it; when you want to remove data from the stack, you "pop" it. So, if you push the numbers 1, 2 and 3 in order onto the stack, when you pop the stack, you will get the number three; pop it again, and you will get the number two; pop it a third time and you will get the number one. To help visualize this, after pushing the numbers, the stack would look like:

-----------
|   1     |
-----------
|   2     |
-----------
|   3     |
----------- <---ESP

If we then pop the stack, it will look like:

-----------
|   1     |
-----------
|   2     |
----------- <---ESP

If we push the number 4 onto the top of the stack, it will look like:

-----------
|   1     |
-----------
|   2     |
-----------
|   4     |
----------- <---ESP

Don't be confused by the arrangement of the "top" and "bottom" of the stack; remember that the stack grows downwards, so data at the bottom of the stack (in this case, the number 1) is actually at the highest memory address, and the top of the stack (the number 4) is at a lower memory address. This is analogous to stacking plates on the ceiling.

Recall that the ESP register always points to the top of the stack. This means that whenever you push data onto the stack, the address stored in ESP is decremented by the number of bytes placed onto the stack; when you pop the stack, ESP is incremented by the number of bytes removed from the stack.

Function Arguments and Local Variables 

The stack is used to store a function's arguments and local variables; to understand how assembly instructions reference these variables, let's see how that data is arranged on the stack. Take a look at the following function and what the resulting stack layout would be:

int myFunction(int var1, int var2, int var3)
{
    char buffer1;
    char buffer2;
    char buffer3;
}

----------------------- <-----Bottom of the stack (top of memory)
|    var3             |
|---------------------|
|    var2             |
|---------------------|
|    var1             |
|---------------------|
|    Return Address   |
|---------------------|
|    Saved EBP Value  |
|---------------------| <----EBP Points here
|    buffer1          |
|---------------------|
|    buffer2          |
|---------------------|
|    buffer3          |
----------------------- <----ESP (top of the stack,                               low memory addresses)

For the moment, we will ignore the return address and saved EBP value, and concentrate on how the arguments and variables get placed onto the stack. Before a function is called, all of its arguments must first be placed on the stack. These arguments are pushed onto the stack in reverse order; that is, in our example, var3 would be pushed first, var2 second, and finally var1:

push var3
push var2
push var1
call myFunction

The call instruction will automatically place the return value onto the stack, and the saved EBP value is pushed immediately afterwards by myFunction (again, we are ignoring these values for now - more on them later). Then, the local variables are pushed onto the stack in the order which they are declared;  first buffer1, then buffer2, and lastly buffer3. When you look at the assembly code of a disassembled program however, you won't have nice names for variables like var1 or buffer1; instead they will be indicated by memory addresses, or as offsets from EBP (recall that the purpose of EBP is to reference variables on the stack). Since the function arguments are located at higher memory addresses than the address pointed to by EBP, they will be referenced as positive offsets from EBP (example: 'ebp+8'); local variables, being located at lower memory addresses, will be referenced as negative offsets from EBP (example: 'ebp-4'). So, whenever you see something referenced as an offset from EBP, you know that you are dealing with a local variable.

Return Addresses and the Prologue

Besides storing data and function arguments, the stack is also used for storing critical values when calling functions. Recall that the EIP always points to the next instruction to be executed; however, the EIP has no way of storing old instruction addresses, so when a function returns, the EIP needs a way to determine where to return to. Whenever a function is called, the memory address of the next instruction in the calling function is pushed onto the stack. When the called function finishes, this address is popped off the stack and placed into the EIP register so that the CPU can return to the next instruction in the calling function. Take the following pseudocode as an example: 

functiona()
    var x = 1
    call functionb()
    x=0
return

When functiona calls functionb, the memory address that contains the 'x=0' assignment is pushed onto the stack. When functionb finishes, that address is popped off the stack and placed into the EIP, so the processor then knows that the next instruction it has to perform is to set the variable x equal to zero.

In addition, the value of the EBP register needs to be saved and appropriately changed when a new function is called, such as in our above example. By now you may be wondering why the EBP is used at all; why not just reference variables from the stack pointer? The base pointer is used because as data is added to and removed from the stack, the position of the stack pointer (ESP) will be constantly changing, making it difficult to use it as a reference point for locating stack variables. However, it is impractical to use the same EBP value for every function, especially in more complex programs where you have functions inside of functions inside of functions, ad infinitum. But, just like the EIP, when a function finishes and returns control to its parent function, that parent function will need to have its original EBP value restored into the EBP register so that it can continue to reference its own variables and arguments. And, just like the EIP value, the calling function's EBP value is also placed on the stack.

However, the EBP value is not pushed onto the stack automatically; this job is up to the child function, and the process of doing so is called the prologue. Basically what the prologue does is save the parent function's EBP value onto the stack, then gives the child function its own EBP value.  Finally, the prologue allocates enough room on the stack to hold all of the local variables. The resulting  assembly code looks like this:

push ebp
mov ebp, esp
sub esp, 0x24

Let's take this one line at a time, shall we. The first instruction is very simple; it pushes the value in EBP (i.e., the EBP value of the calling function) onto the stack. The second instruction copies the value in ESP into the EBP register (thus giving the child function its own EBP value). Finally, the third instruction decrements the stack pointer by 36 bytes (0x24 in hexadecimal); the actual value that is subtracted from ESP will of course depend on the size and number of local variables present in the function. But what is the second instruction really doing? Why copy the stack pointer value into EBP?  To see why, look again at our sample stack layout; note the steps that have been added, and which parts of the stack are affected by them. Make particular note of where the EBP value is pointing to as well:

        ----------------------- <--Bottom of the stack (top of memory)
        |        var3         |
        |---------------------|
        |        var2         | Step 1: Arguments pushed onto the stack.
        |---------------------|
        |        var1         |
        |---------------------|
        |    Return Address   | Step 2 The call instruction pushes the return address onto the stack.
        |---------------------| 
        | Saved EBP Value     | Step 3: The prologue saves the EBP value onto the stack.
EBP --> |---------------------| 
        |        buffer1      | Step 4: The prologue allocates space on the stack for local variables by decrementing the value of ESP.
        |---------------------|
        |        buffer2      | 
        |---------------------|
        |        buffer3      |
        ----------------------- <----ESP (top of the low memory addresses)

However, when the second instruction (mov ebp, esp) is executed, only steps one through three have been performed - no space has been allocated on the stack for local variables yet. So when the ESP value is copied into the EBP register, the stack actually looks like this:

        ----------------------- <-----Bottom of the stack (top of memory)
        |        var3         |
        |---------------------|
        |        var2         |
        |---------------------|
        |        var1         |
        |---------------------|
        | Return Address      |
        |---------------------|
        | Saved EBP Value     |
        ----------------------- <----ESP (top of the stack, low memory addresses)

Note that ESP is pointing exactly where the EBP needs to be. This makes setting the new EBP value simple; before allocating space for the local variables (step four), simply copy the value of ESP into EBP.

Some Minor Details...

The above examples have been portrayed as layouts of the program's stack; in reality, they are really just sections of the stack known as stack frames. Since each function has its own arguments and variables, each function has its own frame. A function will clean up its frame before returning, but if you have functions called inside of other functions, you will have multiple frames on the stack. For instance, if functiona() calls functionb() which calls functionc(), an overall view of that program's stack would look like:

        ----------------------- <-----Bottom of the stack (top of memory)
        | functiona() Frame   |
        |---------------------|
        | functionb() Frame   |
        |---------------------|
        | functionc() Frame   |
        ----------------------- <----Top of the stack (low memory addresses)

 

Reverse Engineering a Program

In this last section, we will be writing a simple hello world program in C, compiling it, then analyzing the disassembled binary. The code will be compiled with gcc and disassembled using gdb; if you are using Windows, you can get Dev-C++ from bloodshed.net which is a nice IDE that comes with all the gcc utilities, including gdb. Bear in mind that if you compile the source code yourself, your assembly code may be slightly different from mine due to variations in the different versions of gcc (I am using gcc v3.3.5 on Linux and v3.4.2 on Windows - they both produce identical assembly instructions). Also, your memory addresses probably won't match mine, but this is normal as they will  be different when compiled on different systems. Finally, we will examine the disassembly of a slightly more complex program and walk through reverse engineering it.

Using GDB

As stated earlier, gdb is both a debugger and a disassembler. In the following examples, we will be using gdb as a disassembler to perform a static analysis of our code. Gdb has many commands, but for our purposes there are just a few we will be using:

Command	Example	Explanation
file	file helloworld	Open the specified program in gdb. The program name can also be specified on the command line when starting gdb ($gdb helloworld).
disassemble	disassemble main	Disassemble the specified function in the program.Gdb will display the function's assembly instructions on screen.
x	x/20s 0x80403001	Examine the contents of 20 addresses as strings starting at memory address 0x80403001. If you want to view the contents in hexadecimal, replace the 's' with an 'x'.

Hello World

We will first use gdb to analyze a binary compiled from the following source code:

int main(int argc, char *argv[])
{
printf("Hello World!\n");
return 0;
}

Save this program as helloworld.c and compile it with 'gcc -o helloworld helloworld.c'; run the resulting binary and it should print "Hello World!" on the screen and exit. So far so good, now let's take a look at the assembly code:

heff@TPad:~/Programming$ gdb helloworld
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) disassemble main
Dump of assembler code for function main:
0x08048384 <main+0>: push %ebp
0x08048385 <main+1>: mov %esp,%ebp
0x08048387 <main+3>: sub $0x8,%esp
0x0804838a <main+6>: and $0xfffffff0,%esp
0x0804838d <main+9>: mov $0x0,%eax
0x08048392 <main+14>: sub %eax,%esp
0x08048394 <main+16>: movl $0x80484c4,(%esp)
0x0804839b <main+23>: call 0x80482b0 <_init+56>
0x080483a0 <main+28>: mov $0x0,%eax
0x080483a5 <main+33>: leave
0x080483a6 <main+34>: ret
End of assembler dump.

Let's look at each instruction, keeping in mind that this disassembly is in the AT&T syntax (source on the left, destination on the right):

0x08048384 <main+0>: push %ebp
0x08048385 <main+1>: mov %esp,%ebp
0x08048387 <main+3>: sub $0x8,%esp

These three instructions should be familiar; they are the function's prologue. The ' push %ebp' instruction saves the current EBP value onto the stack; ' mov %esp,%ebp' creates the new EBP value by copying ESP into EBP; then eight bytes of space is created on the stack for local variables using the 'sub $0x8,%esp' instruction.

0x0804838a <main+6>: and $0xfffffff0,%esp
0x0804838d <main+9>: mov $0x0,%eax
0x08048392 <main+14>: sub %eax,%esp

These three instructions are used to clean up any stray bits and prepare ESP and the stack at the beginning of the program; they are present only in a program's main() function, but not any subsequent functions. The first command zeros out the last byte of the value in ESP; the next two commands put the value 0 into the EAX register, then subtracts the EAX register (aka, zero) from the stack pointer.

0x08048394 <main+16>: movl $0x80484c4,(%esp)

This instruction places the memory address 0x080484c4 onto the stack - the compiler just chose to use a different way of placing the memory address onto the stack than the standard push instruction. Note the parenthesis around %esp - this indicates a pointer. So, the mov command (AT&T syntax always uses 'movl' instead of 'mov', but they are the same instructions) is actually placing the memory address into the address pointed to by the ESP register, not directly into the ESP register itself. Perhaps you noticed that in the prologue, eight bytes were reserved on the stack for local variables, even though no variables are defined in our source code. That was necessary in order to place the memory address on the stack in this manner. If those eight bytes had not been allocated, ESP would still be pointing to the same place as EBP, and the saved EBP value would be been overwritten with the 0x080484c4 address (why the compiler uses this instead of a push instruction I don't know - that's up to the gcc developers  :).

0x0804839b <main+23>: call 0x80482b0 <_init+56>

This is a call to a function at the address 0x08482b0. Since we have only one function that is called from our code, this must be the call to printf(). There was a push instruction (or the equivalent thereof) immediately before calling printf(), so that push must have placed an argument for printf() onto the stack. Our call to printf() only has one argument: the string to print. This can be double checked by examining the contents of 0x080484c4 (the address pushed onto the stack) by issuing the command:

(gdb)x/s 0x08048384
0x8048384 <_IO_stdin_used+4>: "Hello World!\n"
(gdb)

So, this is indeed our call to printf(), and our single argument, the "Hello World!\n" string, wasappropriately placed on the stack just before it was called.

0x080483a0 <main+28>: mov $0x0,%eax

Remember that the EAX register holds any value that is returned by a function, and our main() function returns zero. So this instruction is placing the value 0 into EAX in preparation for a return.

0x080483a5 <main+33>: leave

The leave instruction cleans up the stack by removing all local variables from the stack and popping the saved EBP value off the stack into the EBP register, restoring it to its original value.

0x080483a6 <main+34>: ret

The ret instruction pops the top value off of the stack and places it into the EIP register. Since all data through he saved EBP value has been removed by the leave instruction, the top most piece of data on the stack is the saved EIP value; thus, the leave and ret instructions enable the function to properly return. Since these last three instructions (main+28 through main+34) prepare the function to return and clean up data placed on the stack by the prologue, they are known as the function's epilogue.

Here is the same disassembly, but this time printed in the Intel syntax, and commented for an easier feel of how the program flows:

0x8048384 push ebp <--- Save the EBP value on the stack
0x8048385 mov ebp,esp <--- Create a new EBP value for this function
0x8048387 sub esp,0x8 <---Allocate 8 bytes on the stack for local variables
0x804838a and esp,0xfffffff0 <---Clear the last byte of the ESP register
0x804838d mov eax,0x0 <---Place a zero in the EAX register
0x8048392 sub esp,eax <---Subtract EAX (0) from the value in ESP
0x8048394 mov DWORD PTR [esp],0x80484c4 <---Place our argument for the printf() (at address 0x08048384) onto the stack
0x804839b call 0x80482b0 <_init+56> <---Call printf()
0x80483a0 mov eax,0x0 <---Put our return value (0) into EAX
0x80483a5 leave <---Clean up the local variables and restore the EBP value
0x80483a6 ret <---Pop the saved EIP value back into the EIP register

As you can see, they are all the same instructions, just formatted a little differently; note also how the Intel syntax indicates a pointer reference as opposed to the AT&T syntax.

Disassembling Without The Source

Next, we will examine a program for which we have no source code, called helloworld2. We will attempt to reconstruct the original source code as closely as possible, and to understand how the program operates. Let's start out by running the program to see what it does:

$./helloworld2
Hello World!
$

So far, it appears no different than our first program. We know that it prints out a string to stdout, so it probably uses the printf() function. If we are disassembling this in Linux, we can use the strings command to look for the "Hello World!" string and anything else that may be interesting:

$strings helloworld2
/lib/ld-linux.so.2
_Jv_RegisterClasses
__gmon_start__
libc.so.6
printf
_IO_stdin_used
__libc_start_main
GLIBC_2.0
PTRh@
[^_]
Hello World!
Goodbye World!

We see our "Hello World!" string, but there is also a "printf" string (indicating that the program does indeed use printf), and another interesting string, "Goodbye World!". Now, let's look at the main() function in gdb:

(gdb) disassemble main
Dump of assembler code for function main:
0x080483af <main+0>: push %ebp
0x080483b0 <main+1>: mov %esp,%ebp
0x080483b2 <main+3>: sub $0x8,%esp
0x080483b5 <main+6>: and $0xfffffff0,%esp
0x080483b8 <main+9>: mov $0x0,%eax
0x080483bd <main+14>: sub %eax,%esp
0x080483bf <main+16>: movl $0x1,0x804961c
0x080483c9 <main+26>: call 0x8048384 <myprint>
0x080483ce <main+31>: mov $0x0,%eax
0x080483d3 <main+36>: leave
0x080483d4 <main+37>: ret

Here we see the same prologue as before between main+0 and main+14. However, at main+16 we see that the number 1 is being moved into the memory address at 0x0804961c. This memory address is referenced directly, not as an offset from EBP, indicating that it is a global, not local, variable. Since the number 1 is being moved into it, it is safe to assume that this is an integer variable as well; we will call it var1. Next is a call to a function named 'myprint', which takes no arguments. Immediately afterwards we see the epilogue where 0 is moved into EAX, and leave and ret are called. So we now know that the main function simply sets a global integer variable to 1, calls a second function, then returns zero. We can reconstruct the main() function's source code to read:

int var1; /* The global integer variable */

int main()
{
    var1 = 1;
    myprint();
    return 0;
}

Next, let's examine the myprint() function:

(gdb) disassemble myprint
Dump of assembler code for function myprint:
0x08048384 <myprint+0>: push %ebp
0x08048385 <myprint+1>: mov %esp,%ebp
0x08048387 <myprint+3>: sub $0x8,%esp
0x0804838a <myprint+6>: cmpl $0x1,0x804961c
0x08048391 <myprint+13>:jne 0x80483a1 <myprint+29>
0x08048393 <myprint+15>:movl $0x80484f4,(%esp)
0x0804839a <myprint+22>:call 0x80482b0 <_init+56>
0x0804839f <myprint+27>:jmp 0x80483ad <myprint+41>
0x080483a1 <myprint+29>:movl $0x8048502,(%esp)
0x080483a8 <myprint+36>:call 0x80482b0 <_init+56>
0x080483ad <myprint+41>:leave
0x080483ae <myprint+42>:ret

We see that after the prologue, at myprint+6, there is a comparison operation. It is comparing the value stored in 0x0804961c (var1, the global variable we saw in the main() function) with the number 1. Immediately afterwards is a jne instruction. So, if var1 is not equal to 1, the the program will jump down to myprint+29, but if it is equal to 1 (which we know it is, because it was set to 1 in the main() function), it will execute the next instruction at myprint+15. Since we know that the jump will not be taken, let's look at what happens at myprint+15.

Myprint+15 pushes the memory address of 0x080484f4 onto the stack (again, using the mov instruction instead of push, but achieving the same end result), then calls a function that is located at 0x080482b0. This means that the function at 0x080482b0 is passed one argument; let's take a look at what that argument is by examining what is stored at the address 0x080484f4:

(gdb)x/s 0x080484f4
0x80484f4 <_IO_stdin_used+4>: "Hello World!\n"

This is our "Hello World!" string, and since we know that printf() is being used to print it to stdout, then the function at 0x080482b0 must be printf(). After the call to printf(), the program jumps down to myprint+41, which begins the function's epilogue. Since no value is placed in EAX before returning, and we know that the main() function does not examine EAX or place it anywhere in memory after calling the myprint() function, we can surmise that this function doesn't return a value.

But let's now look at what would happen if var1, for some reason, did not equal one. The jne instruction specifies that the program would jump down to myprint+29, which places a memory address (0x08048502) onto the stack in the same manner as before, then calls a function at 0x080482b0 - the printf() function. This means that either way printf() is called, it is just provided with a different argument. Taking a look at the contents of 0x08048502, we see that this alternate argument is the "Goodbye World!" string that we saw with the strings command earlier:

(gdb)x/s 0x08048502
0x08048502 <_IO_stdin_used+18>:"Goodbye World!\n"

We now know enough about the myprint() function to reconstruct its original source code as well:

void myprint()
{
    if(var1 == 1){
        printf("Hello World!\n");
    } else {
        printf("Goodbye World!\n");
    }
}

While there is no real purpose of the if-else statement (since var1 will always be equal to zero), I wanted to include it in order to show what a conditional statement looked like in assembly code. It is very important that you are able to recognize and understand conditional statements in assembly, as more complex comparisons (such as long case/switch statements) will be more difficult to follow.

Conclusion

This paper covered necessary background information and provided some simplistic examples in order to introduce the basic concepts of RCE. You should now have a good grasp of how to read and interpret disassembled code, identify variables and functions, and translate the assembly code back into a high-level language. In most cases however, you will be working with larger programs that are muchmore difficult to analyze; you may also be only interested in a particular part of the program, or you may want to examine all instances of a specific function. In the next paper, we will introduce some new tools and debugging techniques, as well as cover some more advanced RCE methods in order to deal with such situations.

References

Wikipedia: http://en.wikipedia.org/wiki/Reverse_engineering

Exploiting Software: http://www.informit.com/articles/article.asp?p=353553&seqNum=2&rl=1

AT&T vs Intel - http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html

Dev-C++ - http://bloodshed.net/devcpp.html

According to the White House plan to aid General Motors and Chrysler with money drawn from the $700 billion fund voted by Congress, Treasury Secretary Henry Paulson will temporarily oversee loans to the two ailing auto giants.

After Jan. 20, President-elect Obama will need to choose his own more permanent overseer. This person, identified as "the president's designee" in the failed Auto Industry Financing and Restructuring Act, is now widely referred to as the "car czar."
 

The imagery and reality of a car czar is fraught with problems. First of all, under what authority will this person be able to orchestrate sacrifices required by the carmakers, United Auto Workers, bond holders, and suppliers to make the loan recipients economically viable and competitive by March 31? It is by no means clear what power, apart from personal suasion, such a person would have to resolve disputes and align interests among key stakeholders during the coming months.

Furthermore, arriving at a plan for economically viability by March 31, as stipulated by the White House, will not save loan recipients from bankruptcy unless the financial community judges the carmakers' debt to be commercially bankable. This final and most important judgment is not for the car czar, the White House or even Congress to make.

So, with little formal authority to force changes in a 50-year-old business model and an extremely limited role in certifying the economic viability of business plans submitted by loan recipients, how can the car czar truly be a czar?

What's even more problematic is that the concept of a bridge-loan program with or without a car czar has a dream-like quality in the absence of an economic stimulus program that gets fast traction and an immediate increase in the availability of consumer credit.

Unless the volume of car and truck sales recovers to the industry's current break-even point of 14.5 to 15 million units per year from its current run rate of around 11 million units, the Big Three cannot remain solvent--czar or no czar. There is no near-term financial problem facing General Motors (nyse: GM - news - people ), or any other automaker, that a surge in volume wouldn't cure.

(CNN) -- There's no indication when -- or if -- the White House and congressional leaders will reach agreement on the Democrats' proposal to give troubled U.S. automakers a financial lifeline.

General Motors Corp. and Chrysler could get $15 billion in federal loans as soon as December 15, according to a working Democratic draft of proposed legislation and a senior Democratic congressional aide.

Meanwhile, one key GM official already is talking about the need for more help from the government -- even before this package's approval.

In an interview Tuesday on CNN's "American Morning," Bob Lutz, GM vice chairman of global product development, told anchor John Roberts that he expects the industry to go back to Washington next year for more money.

John Roberts: A lot of taxpayers are asking if you get this $15 billion collectively, what will you do to make sure your company won't fail?

Bob Lutz: Well, first of all, GM will only get a portion of that money and ... this is simply a bridge loan which will get us into the next administration, where we hope we can do something more fundamental. Because the main problem is the lack of liquidity and the lack of revenue flowing in as we're facing absolutely the lowest, lowest car market in history, and it's not just the domestics, the Japanese are all down 30 percent and 40 percent. Their inventories are piling up. You know, this isn't a question of Detroit is in trouble; the whole automobile industry is going to be in trouble

Roberts: You don't see Toyota and Honda coming to the government for a handout. But based on what you said there -- that this is just the beginning -- you're going to need more money next year?

Lutz: I think that's a reasonable assumption.

Roberts: How much more?

Lutz: At this point, you know, that's going to have to be discussed with Congress. We'll have to see. But this is definitely a bridge loan that will solve the immediate liquidity problem

Roberts: When you come to Congress next year and say, OK, you gave us $15 billion in December, now we need X amount of money, how difficult a sales job will that be?

Lutz: You know, I don't think anybody in Congress or the president-elect assumes that this is all the money that is going to be required to bridge this liquidity crisis that the American automobile industry is facing, and, again, it all depends on how fast we have an economic recovery. Again, let me restate this. At 10.8 or 10.5 million total market, we do not have a viable automobile industry in this country for anybody.
iReport.com: How is the automaker crisis affecting you? Should there be a bailout?

Roberts: Yesterday, you took out a full page ad in the Automotive News Journal; it was a big mea culpa. I guess on GM'S part. You said in part we acknowledge we disappointed you. We violated your trust by letting our quality fall and our designs become lackluster. You also laid out a GM commitment to the American people. First thing, you said specifically we're committed to producing automobiles you want to buy and are excited to own. There are many people who might think that's just a fundamental tenet of free enterprise, and why should that be revolutionary?

Lutz: It isn't. I think people were expecting this sort of message. What we're trying to do with an ad like that is live down this legacy of the '80s. Everybody agrees that American cars of the '80s were not very good and were not competitive with the Japanese. But that was a long time ago.

We've now equaled the Japanese in productivity and quality, and speaking for General Motors we got Car of the Year with the Saturn Aura, Car of the Year for Chevy Malibu, Truck of the Year with the Silverado, Green car of the Year with the Silverado hybrid, and on and and on. Car of the Year with the Cadillac CTS.

Roberts: One more question, Bob, certainly, as a condition of this bridge loan, the government is going to appoint a car czar to oversee what you do with it. They will talk about what kind of models you should build, fuel efficiency you should get. There will be a government approval of any vehicles you make. Who would you like to see as the car czar?

Lutz: Wait a minute. We don't know if it will be a czar or overseer. I doubt whether this person would dictate the product policy.

Roberts: Certainly an idea they are talking about. Who would you be comfortable with as car czar?

Lutz: I wouldn't even -- other than myself? Unfortunately I'm not available because I'm still gainfully employed.

Roberts: Some people [are] floating the idea maybe [that former Massachusetts Gov.] Mitt Romney would be a good car czar. He comes down hard on you guys. His father [George Romney] ran American Motors for a time.

Lutz: Well, I hardly think that the automobile business is a genetic trait, but he would probably be satisfactory as would many other people.

MOSCOW, Nov 22 (Reuters) - Russia's gas firm Gazprom wwould like to avoid supply cuts to Ukraine in 2009 but will not continue deliveries without a new contract, Gazprom's spokesman Sergei Kupriyanov said on Saturday.

Russia has often threatened to cut gas supplies during pricing disputes with Ukraine and has fulfilled the threat in early 2006, briefly halting supplies to Europe, 80 percent of which go via Ukrainian territory.

Gazprom said on Thursday Ukraine must repay a $2.4 billion gas debt before new supply contracts are signed, raising fears the two sides face another battle in their gas war.

"We would like to avoid such a scenario (this time). We have time to reach an agreement before the new year but as you understand we cannot supply gas without a contract," Kupriyanov told Vesti 24 television channel.

Ukraine's state energy firm Naftogaz said its debt to RosUkrEnergo, a Russian-Ukraine intermediary gas trader, co-owned by Gazprom, amounts to only $1.27 billion.

Kupriyanov said the Ukrainian side counted only Sept-Oct debt while Gazprom included November debt as well as penalties. He denied there were major differences in the overall debt estimates.

"Everybody understands pretty well who owes to whom and how much," Kupriyanov said.

Ukraine and Russia are engaged in talks on a 2009 price for gas, currently set at $179.50 per 1,000 cubic metres. Kupriyanov said a market price for 2009 gas deliveries was $400 per 1,000 cubic metres.

GAS BURNING IN FURNACES

A memorandum signed in October by Prime Ministers Vladimir Putin and Yulia Tymoshenko sees a gradual transition to market pricing and direct supplies without intermediaries such as RosUkrEnergo.

Kupriyanov said direct supplies as well as lower gas prices for Ukraine in 2009 were only possible if other conditions set out in the memorandum, such as debt redemption in full, were met. He said Russia would not discount for the global crisis.

"If Ukraine's consumption drops, our deliveries will fall as well but it is not happening. Gas is burning in furnaces of Ukraine's economy as it had been before, therefore the crisis has nothing to do with it," Kupriyanov said.

Gazprom supplies a quarter of Europe's gas needs and sends one fifth of its total exports via Belarus with the rest going via Ukraine, giving both countries extra leverage over the firm in pricing disputes.

Kupriyanov said Gazprom's financial standing was sound, debt portfolio "healthy" with the share of short term loans only 14 percent, while a revision of the capital investment plan will not concern priority projects such as the Nord Stream pipeline. "We can talk about not receiving some of expected profit (from domestic operations). The demand is falling, warm weather in November has also played a role," Kupriyanov said.

He said the firm was in intense talks with Belarus and Moldova to switch to rouble payments. Gazprom supplied 15.32 bcm of gas to Belarus at $128 per tcm in Jan-Sept 2008 and 1.9 bcm to Moldova.

With the Russian rouble under depreciation pressure as a result of falling prices for oil, Russia's main export commodity, Russia is seeking to boost international demand for roubles from its ex-Soviet neighbours.

"The rouble is the most reliable currency. Our expenditure is also in roubles. Matching our revenues and expenses is a reasonable thing," Kupriyanov said.

He added that the transition will require changes to contracts with Belarus and Moldova. He said Russia was not yet talking about switching to roubles with Ukraine but it was "theoretically possible". (Reporting by Gleb Bryanski, Editing by Peter Blackburn)

Japan - world's No. 2 economy - in recession

TOKYO (CNN) -- Japan, the world's second-largest economy, is in a recession, government officials announced Monday.

Japan's Cabinet Office confirmed that its economy fell another 0.1% in its third quarter, following a 0.3% drop in the second quarter.

The country's gross domestic product - second to that of the United States - has fallen by 0.4% this year.

Stocks on the Nikkei were trading about 1% higher in Monday morning trading.

Major indexes around the globe have plummeted over the last two months. The Russian stock market has lost 65.5% of its value since the start of the year. Stocks in Japan and the United States have been equally hard hit, falling 42% and 33%, respectively.

In Europe, the pain has been particularly acute. The European Union on Friday officially declared that the 15-nation group had entered into a recession, with its gross domestic product declining 0.2% for the second straight quarter.

Japan's recession announcement was not unexpected. Part of the problem is the strong yen, which skyrocketed in recent weeks as turmoil in the world's financial markets and concerns about a global recession drove investors away from high-yielding currencies such as the euro and the pound. As a result, lower-yielding currencies like the dollar and the yen surged in value because they are considered by many investors to be a safe-haven.

Since Japan is such a big exporter of goods, a more robust yen hurts profits for Japanese firms as sales from abroad get translated back into yen. The more that the yen has climbed, the worse Japan's stock market has performed, which has resulted in a ripple effect on European and U.S. exchanges.

 

The good news for a struggling Starbucks: The recent economic slump hasn't quashed Americans' tastes for gourmet coffee.

From Pete's Coffee to McDonald's (nyse: MCD - news - people ) to Dunkin' Donuts, the market's awash in successful imitators, despite the downturn. Grocery store sales of premium coffee beans are growing at double-digit rates annually.

"No one wants Folgers," says industry analyst Steve West of Stifel, Nicholas, citing an entire young generation of professionals for whom upscale coffee has become the standard.

The bad news: Fewer people want it from Starbucks (nasdaq: SBUX - news - people ). The company announced Monday that fourth-quarter profit plummeted to a penny a share from 21 cents a year earlier, with same-store sales slipping 8% in the U.S. Aside from costs associated with store closings, profit was 10 cents a share, below estimates and less than half of last year's result.

The announcement came just hours after

Is McCain Coming Back?

Does recent polling suggest a McCain comeback at the right time or something else? Photo by Ricky Carioti -- The Washington Post