Project 2 - Bowdoin BitBombs

This project should be completed individually.

This project will give you experience with x86-64 machine code, application reverse-engineering, and the use of a low-level debugger (gdb). You will do this by defusing a BitBomb planted on the class server!

Start by reading through the entire project description!

Project Overview

Agents of the nefarious organization BitBombs Inc. have infiltrated the CSCI 2330 server and planted a set of BitBombs on our machine. A BitBomb is a compiled executable program that consists of a sequence of phases, each of which is wired to explode and wreak havoc on our bits. Luckily, each bitbomb contains a failsafe mechanism - if a particular code is entered for each phase of the bitbomb, the bitbomb will be harmlessly defused. However, if an incorrect code is entered for any phase, the bitbomb will immediately explode.

There are too many bitbombs for your instructor to handle, so each of you will be provided a bitbomb to defuse. Your task is to defuse the bitbomb before the due date (at which point all remaining bitbombs will explode). Good luck - we are counting on you!

BitBomb Files

Each of you have a set of files pertaining to your bitbomb that have been checked into your SVN directory under proj2. First, run svn update within your directory to download these files. Within the proj2 directory, there are several key files:

• bitbomb: Your personal bitbomb executable.
• bitbomb.c: A source file that BitBombs Inc. forgot to delete.
• codes.txt: File in which you will write your defusing codes.
• descriptions.txt: File in which you will describe your defusing solutions.
• README: File containing your unique BitBomb ID.

BitBomb Handling

Note: You can execute the bitbomb ONLY on the class server. Attempting to execute it elsewhere will immediately detonate the bitbomb!

To run the bitbomb, you can execute it directly:

$ ./bitbomb

When run, the bitbomb will wait for you to enter a defusal code, which will be passed to the current phase. If the code is correct, the phase will be defused and you will be prompted to enter the code for the next phase. If the code is incorrect, the bitbomb will explode. Note: Rumor has it that your instructor will be automatically notified of bitbomb explosions. Don't blindly execute your bitbomb!

Once you have determined one or more defusal codes, to avoid having to re-enter the codes each time you run the bitbomb, you should enter your codes in codes.txt, one phase per line. Then, you can pass this file to your bitbomb when you execute it to automatically feed it your codes:

$ ./bitbomb codes.txt

Once all the codes from codes.txt have been given to the bitbomb, it will switch over to prompting for defusal codes as normal.

To avoid accidentally setting off the bitbomb, you will need to learn how to step through the assembly code, examine the state of the program, and set breakpoints using a debugger. Learning to use a debugger will be an extremely useful skill both in defusing your bitbomb and beyond!

To run the bitbomb using the debugger gdb, you can do the following:

$ gdb bitbomb
... startup messages from gdb ...
(gdb) run codes.txt

See the tools and advice section below for more tips on defusing your bitbomb and using gdb.

Logistics

You are responsible for two tasks:

• Determining the correct defusal codes and entering them into codes.txt
• Documenting your methods and insights during reverse engineering in descriptions.txt

You should organize your descriptions by phase (i.e., each phase should have a code and a corresponding description). Each description should be a short paragraph or two describing what the phase is doing with your input (to the best of your understanding), and how you determined the correct input. While your description should be detailed enough to convey your understanding, you should not go as far as giving a line-by-line explanation of the assembly commands.

As usual, your final submission will consist of your committed files at the time of the due date, as well as the automatically submitted results of executing your bitbomb.

Evaluation

You will be evaluated both on determining the correct defusal codes for each phase, as well as clearly documenting your methods and insights during reverse-engineering in descriptions.txt. Points for each phase are described below (of which roughly half will be from your solution and half from your description):

• Phase 1: 10 points
• Phase 10: 20 points
• Phase 11: 20 points
• Phase 100: 20 points
• Phase 101: 20 points
• Phase 110: 10 points

Partial credit is possible on unsolved phases for clear documentation that demonstrates effort and some understanding of the phase. However, repeated detonations of your bitbomb may have a negative impact on your total score.

Lastly, unconfirmed rumors report that each bitbomb may have a secret phase 111...

Tools

There are many approaches you can take to defusing your bitbomb. You can examine your bitbomb in great detail without ever executing it to figure out how it works. While useful, this is not always straightforward. You can also execute the bitbomb using a debugger to run it step by step and examine the state of the machine along the way (while also giving you a chance to bail out before it explodes!). A mix of these two approaches is probably most efficient.

First, you should not use brute force to defuse your bitbomb! While you could theoretically write a program to try many defusal codes on your bitbomb, this is a bad idea for several reasons. One, the number of possibilities is so large that you are unlucky to solve your bitbomb using this approach. Two, a brute force approach will not allow you to write a very good description of your reverse engineering approach. Three, exploding your bitbomb repeatedly is hazardous to your score (as well as our bits)!

There are many tools that are designed to help you figure out how programs work and what is wrong when they do not work. You are likely to find the following tools helpful in particular:

• gdb (the GNU debugger) is a command-line debugger tool available on virtually every system. You can use gdb to trace through a program line by line, examine the contents of memory and registers, look at the assembly code (and the source code if available...which isn't the case here), set breakpoints, and more. A cheat sheet of common GDB commands is available here.
• objdump is a program that can output various types of information about compiled (object) files. The two uses of objdump that you will likely find most useful are objdump -t bitbomb and objdump -d bitbomb. The former (-t) will print out the bitbomb's symbol table, which includes the names of all functions and global variables in the program, as well as their addresses. These names may be useful! The latter (-d) will dump a complete assembly instruction listing of the program (i.e., it will disassemble the program). You may note, however, that certain things in this assembly instruction listing are cryptic, particularly the names of system library functions that are called. Some of this information is presented more usefully when the code is disassembled from within gdb (i.e., while the program is running) - the reason for this has to do with linking and loading, some of which happens at runtime.
• strings is a utility that will output all the printable strings contained in the bitbomb. A useful way to run it is strings -t x bitbomb, which will output all the strings and their hex offsets in the program.
• You may wish to save the output of running objdump or strings for later reference. You can easily do this using output redirection, like so:

  myprogram somearg > output.txt

  The above will run myprogram somearg and dump the output into a file called output.txt (of course, substitute whatever program, argument(s), and filename you would prefer).

If you encounter x86-64 assembly instructions with which you are not familiar, you can consult the textbook, Google, or go right to the source and check the the official Intel architecture manuals. Remember when consulting references that we're using x86-64, not the 32-bit x86 (aka IA32).

Tips and Advice

• Start early! (remember project 1?)
• The phases are progressively more difficult. Think of phase 1 like the reverse-engineering equivalent of writing 'Hello World' and plan accordingly!
• Don't let your bitbomb explode! The most reliable way to do this is to set breakpoints within gdb such that the bitbomb will be interrupted just before it explodes, giving you a chance to exit out and try again if you enter a wrong code. Make a habit of setting this breakpoint to give yourself an insurance policy!
• Remember that you can type Control-C to interrupt execution of a program that you're executing directly (i.e., outside of gdb). BitBombs Inc. was rumored to be working on a mechanism to defeat attempts to stop the bitbomb, so let's hope that feature doesn't work yet...
• Take notes liberally while reverse engineering (that is, beyond your 'polished' notes which should be entered in descriptions.txt). You will be looking at a lot of instructions, register names, symbols, and memory addresses, and keeping everything in your head is likely to be difficult. Jot down notes along the way so you don't have to do the process all over again to remember how it worked!
• Start early! (yep, still true)