CSCI 2330
Introduction to Systems

Bowdoin College
Spring 2017
Instructor: Sean Barker

Project 3 - BitBombs

This project should be completed individually.

This project will give you experience with x86-64 machine code, program reverse-engineering, and more experience with debuggers. You will do this by defusing a BitBomb planted on the class server!

Start by reading through the entire project description!

Project Dates

AssignedSunday, March 5.
Checkpoint 1Friday, March 10. Phase 1 should be defused by this checkpoint.
Checkpoint 2Friday, March 31. Phases 2 and 3 should be defused by this checkpoint.
Checkpoint 3Tuesday, April 4. Phase 4 should be defused by this checkpoint.
DueSunday, April 9. All phases are due.

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 six phases, each of which is wired to explode and wreak havoc on our bits. The bitbombs are on timers and are set to detonate at midnight on April 6. Luckily, the bitbombs contain a failsafe mechanism - each phase of a bitbomb can be defused if a bomb and phase-specific defusal code is entered. However, if an incorrect defusal 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 your bitbomb before the detonation date. Good luck - our bits are counting on you!

BitBomb Files

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

BitBomb Handling & Safety

warningSafety Notice: You should ONLY execute the bitbomb on the class server. Attempting to execute your bitbomb on any other machine will detonate it immediately!

To attempt to defuse 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 that pressing enter without typing anything still constitutes submitting a defusal code!

warningSafety Notice: Our server has been outfitted with a bitbomb alarm system, which will automatically alert the instructor of bitbomb explosions. Practice safe bitbomb handling and don't blindly execute your bitbomb!

The bitbomb will start from phase 1 each time you execute it. To avoid having to re-enter defusal 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 manual defusal codes as normal.

To discover the defusal codes and avoid accidentally setting off the bitbomb, you will need to use a debugger to set breakpoints, step through the bitbomb, and inspect its state. However, this will be substantially more challenging than in previous projects, because you will (mostly) not have any source code to reference! Instead, you will need to reverse-engineer your bitbomb by inspecting its assembly instructions.

To run the bitbomb using the debugger gdb and pass it a codes file, you can run the following:

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

To run your bitbomb in gdb without passing it any initial codes, you can simply type run at the initial gdb prompt.

See the tools and advice sections below for more tips on defusing your bitbomb.


You are responsible for two tasks:

  1. Determining the correct defusal codes and entering them into codes.txt.
  2. 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.

The objective of your descriptions should not be a line-by-line explanation of what each individual assembly command is doing (though you'll largely need to understand that regardless), but rather to show that you understand how the entire phase fits together at a higher level. Ideally, your documentation should describe the behavior of the phase at the level of comments you might write for a regular C program. You may not understand every aspect of what each phase is doing (and that's okay) but your descriptions should explain what insights you've learned and how they led you to discovering your defusal codes.

Defusal Toolkit

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, a brute force approach is likely to result in repeatedly detonating your bitbomb!

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:

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

The following pieces of advice are well worth heeding as you tackle your bitbomb:


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

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):

warningSafety Notice: Repeated detonations of your bitbomb may have a negative impact on your score (as well as our bits)!

Partial credit is possible on unsolved phases for clear documentation that demonstrates effort and some understanding of the phase. Full credit requires both correct defusal codes and high-quality descriptions!

Disarmanent Status Report

To assist us in tracking the server-wide defusal effort, we have created an online Disarmament Status Report page. You may view your progress towards defusing your bomb, as well as the progress on defusing the other bombs, on this page. You can also see your total number of bitbomb explosions on this page.

Nothing is necessary to submit to the online scoreboard - your phase defusals (and explosions) are automatically reported to the scoreboard when you execute your bitbomb.

BitBomb Disarmament Status Report