X86 AT&T Assembly Language Assignment Program 2

Learning GOALS

There are two main objectives of this project. The first is to quickly become familiar with x86 assembly language. The second relates to the first: to gain some familiarity with the tools that help with this process, namely objdump (the disassembler) and gdb (the debugger), which you've already used.

Binary BOMBS

In this assignment, you will be defusing four binary bombs. The idea is simple: each bomb is an executable program that prompts the user for five inputs via the stdin console, one at a time, in order to defuse the bomb. If you type in the right values, you successfully defuse the bomb. If not, the bomb explodes! (Don't worry, it just prints that the bomb explodes; no real harm is done to you or your computer)

Getting the Required Files

There should be 4 executable files namedb1, b2, b3, and b4.

Please copy your executable bombs to your own private directory, and work towards finding your solutions in your own directory. That way, you will have the original executables in your student directory if you accidentally overwrite an executable.

Defusing the Bombs

The challenge is to figure out the correct set of 5 inputs expected by each of the four bombs. You can run each bomb interactively, and type in your guesses, one at a time. This will be useful in defusing each bomb with a debugger, as described in the next section. Take a look at the sample run below:

(55)$ ls
b1* b2* b3* b4*
(56)$ ./b1
input 1 (of 5)? 951905
input 2 (of 5)? 1234
BOMB EXPLODED
(57)$ ./b1
input 1 (of 5)? 951905
input 2 (of 5)? 994563
input 3 (of 5)? 493693
input 4 (of 5)? 828695
input 5 (of 5)? 278566
success!
58)$

Your task is to figure out all the inputs and create four files,b1.solution,b2.solution,b3.solution and b4.solution, where each file contains the five lines of input demanded by its associated bomb. We will test your solution files as show below.

(70)$ ls
b1* b1.solution b2* b2.solution b3* b3.solution b4* b4.solution
(71)$ cat b1.solution
951905
994563
493693
828695
278566
(72)$ ./b1 < b1.solution
input 1 (of 5)? input 2 (of 5)? input 3 (of 5)? input 4 (of 5)? input 5 (of 5)? success!
(73)$

All 5 inputs need to be correct to defuse a bomb. As long as the bomb explodes, no points will be given no matter how many inputs were correct before the explosion.

Make sure you create this file with a text editor (vim/gedit/nano) on a Linux Machine. If you are using Windows or Mac, editing locally followed by uploading will fail for b2. Use remote accessing tools like ssh or MobaXterm instead. Make sure your solution file contains five non-empty lines. Remember to press enter or return after the last line in the solution file. The bomb will be trapped into an infinite loop if the solution file contains less than 5 lines. If that happens, press ctrl-c to break.

This testing also uses another shell skill that you have already used: IO redirection. In this case the contents of a file are redirected as stdin to the program.

TOOLS: Objdump and gdb

To figure out how to defuse your binary bombs, you will use two powerful tools: objdump and gdb. Both are critical in reverse engineering each binary bomb to understand what it does.

objdump

objdump is a command in linux to display information about object files. For our purposes the two important command line options are:

• -d which disassembles a binary
• -s which displays the full binary contents of the executable

For example, to see the assembly code of bomb b1, you might type:

objdump -d b1

This will show an assembly listing of each function in the bomb. Your first task then might be to look at main() and figure out what the code is doing.

The -s flag is also quite useful, as it shows the contents of each segment of the executable. This may be needed when looking for the initial value of a given variable.

By redirecting stdout, you can capture the output of objdump in a file, such that you can look at this output without having to regenerate it every time. And, you can use both command line options at the same time to create a full dump of the contents of the executable as well as the disassembled contents.

gdb

By now, you should have used the debugger, gdb, to help find segmentation faults, but it is an even more powerful ally in your search for clues to defuse each binary bomb. The following gdb commands in addition to the ones specified in p3 will be useful to defuse the bombs.

• finish: continue until the current function returns and prints the return value (if any)
• print: prints the contents of variable or memory location or register
• set var <variable_name>=<value>: changes the content of a variable to the given value
• info registers: shows you the contents of all of the registers of the system
• x/nfu <addr>: The examine command, which shows you the contents of memory. n, f, and u are all optional parameters that specify how much memory to display and how to format it. addr is the hexadecimal address you want to look at. So for instance “x/3ub 0x54320” is a request to display 3 bytes (b) of memory formatted as unsigned decimal integers (u) starting at the address 0x54320.

HINTS

• x86 cheat sheet
• Function strtol() corresponds to the use of atoi() in C source code.
• Every C program has a main() function. Figure out how to locate it.
• A loop in main() iterates five times. Remember that each bomb requires five inputs.
• On a wrong input, function bomb() is called. This results in an explosion.
• If all five inputs are correct, function success() is called.
• Function arguments are set up in the call stack just prior to the function call.
• The two parameters to strcmp() are addresses to 2 C strings.
• The return value of a function is stored in %eax.

REQUIREMENTS

We will test your solution files by running them as shown in the sample output. It is your responsibility to ensure that your solutions correctly defuse each of the four binary bombs on the Linux machines.