Defusing Your Bomb

Your job for this lab is to defuse your bomb. You must do the assignment on wilkes.cs.hmc.edu. In fact, there is a rumor that Dr. Evil really is evil, and the bomb will always blow up if run elsewhere. There are several other tamper-proofing devices built into the bomb as well, or so we hear.

You can use many tools to help you defuse your bomb: Check out the Hints section below for suggestions about tools and tips on defusing the bombs.

We strongly recommend that you create a file containing the disassembled code (you can use either gdb or objdump to do so) and then, as you figure out what the code is doing, add comments to each line of that file. The annotated code will save you from having to repeatedly try to understand the same code.

The best way to figure out how the bomb code works is a combination of studying it and understanding what the instructions do and using gdb to step through the disassembled binary.

Exploring

• Each bomb has six phases. For each phase you need to figure out the correct input to “defuse” the bomb and proceed to the next level.

• The bomb ignores blank input lines.

• When run with no argument, the bomb will expect input from stdin.

• You can supply the name of a file containing the solutions to previous phases; for example,

  ./bomb psol.txt
  

  will cause the bomb program to read from psol.txt until it reaches EOF (end of file), and then switch over to reading from stdin. (In a moment of weakness, Dr. Evil added this feature so you don't have to keep retyping the solutions to the phases you have already defused.)

• To avoid accidentally detonating the bomb, you will need to learn how to single-step through the assembly code and how to set breakpoints.

  You will also need to learn how to inspect both the registers and the memory states.

  One of the nice side-effects of doing the lab is that you will get very good at using a debugger—a crucial skill that will (probably) pay big dividends the rest of your career.

Scoring

The first four phases are worth 10 points each; the last two are 15 points each. Although each phase gets progressively harder to defuse, the expertise you gain as you move from phase to phase should offset the increase in difficulty.

Note: The last phase is very challenging, so please don't wait until the last minute to start.

Explosions and Consequences

Each time your bomb explodes it notifies the bomblab server, and you lose \( 1/32 \) point (up to a maximum of 2 points) in the final score for the lab. So there are minimal consequences to exploding the bomb—experiment!

Hints (Please Read!)

There are many ways of defusing your bomb.

Theoretically, you can just examine the code and binary in great detail without ever running the program, and figure out exactly what it does and what you need to do to defuse it. While that's a great technique, it's usually pretty difficult to make it work in practice.

A more practical (and faster) approach is to run the bomb in a debugger, watch what it does at each step, and use what you learn to get the texts you need to defuse each stage.

You could (in theory) write a program that will try every possible key to find the one that works for each phase. But this approach has several drawbacks:

• You do lose that \( 1/32 \) point (up to 2 points maximum) each time you guess incorrectly and the bomb explodes.

• Every single time you guess wrong, a message is sent to the bomblab server. A brute-force attack could very quickly saturate the network with these messages, and cause the system administrators to come find you. No one wants that.

• More practically, you don't know how long the strings are or even what characters are in them. Even if you make the (incorrect) assumptions that each key string is less than 80 characters long and only contains ASCII letters, you will have \( 26^{80} \) guesses for each phase! Your brute-force approach will take a very long time to run, and you will not get the answer before the assignment is due—or even before the universe ends.

Functions

The bombs have many functions with descriptive names, such as read_six_numbers. All functions do what their names say they do; it turns out that Dr. Evil isn't that evil.

Keep in mind that you do not need to use the debugger on every function. In particular, do not attempt to analyze the scanf function from the C library—it would take you months to work through, and, hey, isn't typing man scanf a lot easier?

Here are some comments on specific functions in the bombs:

main

Dr. E gave you have the source code! Don't try to reverse-engineer it!

phasen

These functions are where you should spend most of your time.

strings_not_equal

It does what it says. You'll have to figure out the details, though.

string_length

It does what it says. You'll have to figure out the details, though.

read_six_numbers

It does what it says. You'll have to figure out the details, though.

sscanf

This is a hugely complicated function. There is equally complicated documentation available by typing man scanf, and you should read at least some it, including the “RETURN VALUE” section.

Helpful Hint

Type a slash (/) to search and Q to quit the manual reader.

? should show you all the other commands.

Most of what you need to know is that if scanf is given an argument containing "%d" it will parse a number and store it somewhere; similarly, "%c" will store a single character. There's a bit more to it than that, so you'll still need to look at the documentation, but %d and %c are what you should concentrate on.

Anything Else?

You probably don't need to understand how it works. If it has an obvious name (like explode_bomb) then that's what it does. Ask for help if you're not sure; don't waste huge amounts of time trying to figure out something that doesn't matter!

Tools

There are many tools designed to help you figure out both how programs work, and what's gone wrong if they don't work. The following list has some of the tools you may find useful in analyzing your bomb, and hints on how to use them:

gdb

The GNU debugger is a command-line tool available on virtually every platform. You can trace through a program line by line, examine memory and registers, look at both the source code and assembly code (we are not giving you the source code for most of your bomb), set breakpoints, set memory watch points, and write scripts. Here are some tips for using gdb.

• To keep the bomb from blowing up every time you type in a wrong input, you'll want to learn how to set breakpoints.

• The CS:APP Student Site has a very handy single-page gdb summary that you can print out and use as a reference.

• Look back to the debugging lab for more gdb tips and tricks, including links to the full documentation.

• Some people like to use gdb in Emacs with its gdb-mode. There are other frontends for gdb available as well; search for “frontend for gdb” for various possibilities. But don't get too caught up with trying to find the coolest/best frontend; you can do everything you need to do with the command line gdb.

objdump

objdump -t

Prints out the bomb's symbol table, which includes the names of all functions and global variables in the bomb, the names of all the functions the bomb calls, and their addresses. You may learn something by looking at the function names!

objdump -d

Disassembles all of the code in the bomb. You can also just look at individual functions. Reading the assembler code can tell you how the bomb works.

Although objdump -d gives you a lot of information, it doesn't tell you the whole story. Calls to system-level functions are displayed in a cryptic form. For example, a call to sscanf might appear as

8048c36:  e8 99 fc ff ff  call   80488d4 <_init+0x1a0>

To determine that the call was to sscanf, you would need to disassemble within gdb (possibly after partially running the program).

strings

strings displays the printable strings in your bomb.

More General Help

Looking for a particular tool? How about documentation? Don't forget, the commands apropos (or man -k), man, and info are your friends.

In particular, man ascii might come in useful….

info gas will give you more than you ever wanted to know about the GNU Assembler. (info will let you read documentation for many GNU programs (including Emacs!), which is most of the “userland” for Linux systems.)

The Internet, and So On

Be very careful about searching on the internet, as there may be solutions for this lab out there. You may not use posted solutions to help you complete this lab.

Help at Mudd

Remember that there's a whole page on Getting Help on this website.

You can also ask for help on Piazza, or ask your professor or a grutor for help.

(When logged in, completion status appears here.)

Previous Page Go to Parent Page