Lab 2: Defusing a Binary Bomb¹

• Assigned: Wednesday, April 20
• Check-in Post: Before 9pm Monday, April 25 (check-in forum)
• Due: 9pm Friday, April 29
• Collaboration: This is an individual assignment
• Handout:
• Submit: Upload descriptions.txt to Lab 2 (if applicable, see Step 2: Defuse Your Bomb)
• References:
  • 208 Reference Sheet
  • Introduction to Assembly
  • Assembly and Arithmetic
  • Assembly and Conditionals
  • Assembly and Loops
  • Assembly and Arrays
  • gdb Tutorial
  • Introductory Video (from University of Washington)
  • gdb Cheat Sheet

Introduction

The nefarious Mr. Dr. The Professor has planted a slew of binary bombs on our class server. A binary bomb is a program that consists of a sequence of phases. Each phase expects you to input a particular string. If you type the correct string, then the phase is defused and the bomb proceeds to the next phase. Otherwise, the bomb explodes by printing "BOOM!!!" and then terminating. The bomb is defused when every phase has been defused.

There are too many bombs for us to deal with, so we are giving each student a bomb to defuse. Your mission, which you have no choice but to accept, is to defuse your bomb before the due date. Good luck, and welcome to the bomb squad!

Step 1: Get Your Bomb

You can obtain your bomb by pointing your web browser at:

    http://awb66333.mathcs.carleton.edu:15213

The web page will display a binary bomb request form for you to fill in. Enter your Carleton user name and email address and hit the Submit button. The server will build your bomb and return it to your browser in a tar file called bombK.tar, where K is the unique number of your bomb.

Save the bombK.tar file. If you are working on mantis, connect via VS Code, open a folder, and drag the file over to the list of files to upload it. Then run the terminal command: tar -xvf bombK.tar from the directory containing the tar file. This will create a directory called bombK with the following files:

• README: Identifies the bomb and its owner.
• bomb: The executable binary bomb. You must be connected to the internet to run this bomb. It will automatically submit your progress.
• bomb-quiet: An offline version of the executable binary bomb. You can work on this one without an internet connection. You just need to run bomb once while connected to have your progress recorded.
• bomb.c: Source file with the bomb’s main routine and a friendly greeting from Mr. Dr. The Professor.
• descriptions.txt: File in which you describe the x86 assembly code
• defuse.txt: File in which you record defusing inputs, one line per phase

If for some reason you request multiple bombs, this is not a problem. Choose one bomb to work on and delete the rest.

Step 2: Defuse Your Bomb

Your job for this lab is to defuse your bomb.

You must do the assignment on Linux. There is a rumor that Mr. Dr. The Professor really is evil, and has built tamper-proofing devices into the bomb.

You can use many tools to help you defuse your bomb. Please look at the Advice section for some tips and ideas. The best way is to use a debugger to step through the disassembled binary.

The first three phases are worth 13 points each. The next three are worth 6 points each. The check-in post is worth 3 points, as usual, for a maximum score of 60 points. You can also earn points by writing descriptions of what the assembly code is doing for phases beyond phase 1. Specifically, in the provided descriptions.txt file, write a succinct paragraph or two for each phase, describing:

• What the phase is computing with your input at a high level of abstraction.
• Some key features of the assembly code that correspond to the high-level computation.

Describe at a high level as if you are summarizing whatever C code compiled to this assembly/machine code. (Feel free to write C to describe what is computed.) Do mention a couple assembly details that were particular aha! moments or critical aspects that alerted you to this high-level structure, but do not give a line-by-line run-down of the assembly code. Keep notes along the way so you do not need to repeat the reverse engineering process to remember how it worked!

Each description you submit can earn up to 6 points. This means you can earn the full 60 points for the lab by defusing the first four phases and writing good descriptions of two of them (again, not including phase 1). There are essentially two approaches to the lab (you can go with either one, or something in between):

• For each phase, concentrate on deciphering just enough of what’s going to provide a defusing input, and then move on. You will improve your ability to pinpoint what code actually matters and what code you can ignore in addition to your understanding of assembly. Your goal is to defuse all the phases.
• Work through each phase carefully to fully understand what is going on, and write a description of your findings. You will greatly improve your understanding of assembly. Your goal is to defuse the first four phases and thoroughly describe two of them.

Although phases get progressively harder to defuse, the expertise you gain as you move from phase to phase should offset this difficulty. However, the later phases will likely take some time to work through, so please don’t wait until the last minute to start.

    ./bomb defuse.txt

then it will read the input lines from defuse.txt until it reaches EOF (end of file), and then switch over to reading from the command line. In a moment of weakness, Mr. Dr. The Professor added this feature so you don’t have to keep retyping the solutions to 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. This is a crucial skill that will pay big dividends dealing with buggy software in the future.

Advice

There are many ways of defusing your bomb. You can examine it in great detail without ever running the program, and figure out exactly what it does. This is a useful technique, but it not always easy to do. You can also run it under a debugger, watch what it does step by step, and use this information to defuse it. This is probably the fastest way of defusing it.

Some general advice:

• Mr. Dr. The Professor may be evil, but he isn’t cruel. You may assume that functions do what their name implies (phase_1() is most likely the first phase. printf() is just printf(). A function called strings_not_equal probably takes two strings and returns whether they are not equal. If there is an explode_bomb() function, it would probably help to set a breakpoint there!)
• Most cryptic function calls you’ll see (e.g. callq ... <_exit@plt> and callq ... <__isoc99_sscanf@plt> would be calls to exit() and sscanf(), respectively) are calls to C library functions. (You can safely ignore the @plt as that refers to dynamic linking.)
• Most phases use the C library function sscanf to parse the input string, so you will want to understand how this function works.
• Avoid going through the assembly for C library functions—looking up online documentation will be much easier path to understanding them!

There are many tools which are designed to help you figure out both how programs work, and what is wrong when they don’t work. Here is a list of some of the tools you may find useful in analyzing your bomb, and hints on how to use them.

gdb

The GNU debugger, this is a command line debugger tool available on virtually every Linux 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.

The course web page has a handy list of resources that you can use as a reference. The list of References at the top this writeup links to many of these as well.

objdump

objdump -t bomb will print out the bomb’s symbol table. The symbol table 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!

Use objdump -d bomb to disassemble all of the code in the bomb. You can also just look at individual functions using gdb: gdb -batch bomb -ex 'disas FUNCTION_NAME'. Reading the assembler code can tell you how the bomb works.

strings

strings bomb will display the printable strings in your bomb.

What to Turn In

The bomb automatically sends in your progress as you work on it (as long as you are connected to the Internet). This means you will need to run your bomb with the defusing inputs you discover at least once. It’s perfectly fine to work on the lab offline (bomb-quiet is provided to enable this), you just need to defuse the bomb once where it can connect in order to have your solutions recorded. You can keep track of how you are doing by looking at the class progress board here:

    http://awb66333.mathcs.carleton.edu:15213/progress

This web page is updated continuously to show the progress for each bomb.

If you wish to submit descriptions of phases you have solved, upload your descriptions.txt to the Lab 2 assignment on Moodle. Otherwise, there is nothing you need to manually submit.