**Assignment 04: Binary Bombs** The nefarious *Dr. Evil* has planted a slew of "binary bombs" on our course VM. A binary bomb is a program comprising a sequence of phases, where each phase expects you to type a particular string into `stdin`. If you type the correct string, then the phase is *defused* and the bomb proceeds to the next phase. Incorrect inputs cause the bomb to *explode* by printing `"BOOM!!!"` and terminating. The bomb is defused when every phase has been defused. There are too many bombs for a single person to handle, so each of you will receive a pair of bombs 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! # Learning Goals - Learn how to reverse engineer a binary - Gain experience reading binary and assembly - Learn more about data representation # Grading Walk-Throughs This assignment will be graded as "Nailed It" / "Not Yet" by a TA. To pass ("Nailed It") the assignment, you must 1. Complete the assignment and submit your work to gradescope. + You should start this assignment in class on the day shown on the calendar. + *Complete the assignment as early as possible*. 1. Schedule a time to meet with a TA. You can meet with them after the submission deadline. + You must book a time to meet with a TA + Sign-up on the Google Sheet *with at least 36 hours of notice*. + Contact your TA on Slack after signing up. + All partners must meet with the TA. If you cannot all make it at the same time, then each of you needs to schedule a time to meet with the TAs. 1. Walk the TA through your solutions prior to the deadline. + Walk-throughs should take no more than 20 minutes. + You should be well prepared to walk a TA through your answers. + You may not make any significant corrections during the walk-through. You should plan on making corrections afterward and scheduling a new walk-through time. Mistakes are expected---nobody is perfect. + You must be prepared to explain your answers and justify your assumptions. TAs do not need to lead you to the correct answer during a walk-through---this is best left to a mentor session. 1. The TA will then either + mark your assignment as "Nailed It" on gradescope, or + mark your assignment as "Not Yet" and inform you that you have some corrections to make. 1. If corrections are needed, then you will need to complete them and then schedule a new time to meet with the TA. + You will ideally complete any needed revisions by the end of the day the following Monday. If you have concerns about the grading walk-through, you can meet with me after you have first met with a TA. # Overview You will 1. find a partner to work with, 2. request a bomb from the server, and then 3. defuse several bomb phases using reverse engineering. The bomb will notify me automatically about your progress as you work on it. You can keep track of your progress by looking at the class scoreboard at (the scoreboard is anonymous unless you share your bomb number with others). http://itbdcv-lnx04p.campus.pomona.edu:10501/scoreboard This web page is updated every 30 seconds to show the progress for each bomb. You must be connected to campus Internet to view the website. # Quick Start Video **Read the entire assignment description prior to watching this video.** Also, keep [this gdb reference card handy](../A03-DebuggingLabyrinth/gdb-refcard.pdf); it should help explain some of the commands I type in the video.

# Get Your Bomb Each group will attempt to defuse their own personalized bomb. Each bomb is a Linux binary executable file that has been compiled from a C program. To obtain your group's bomb, one (and only one) of the group members should 1. navigate to http://itbdcv-lnx04p.campus.pomona.edu:10501/, 2. fill in the form - enter the partner names (without spaces), - enter one partner's email address, 3. download your bomb to your local computer, and then 4. upload your bomb back to the server. 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. Copy the `bombk.tar` file to somewhere in the home directory of one of your partners. You should be able to use something like the following command (assuming your bomb file was downloaded to your `~/Downloads` directory): ~~~bash scp ~/Downloads/bombk.tar USERNAME@itbdcv-lnx04p.campus.pomona.edu:~/cs105/assignments ~~~ Login to the server and unpack your bomb: ~~~bash cd ~/cs105/assignments tar xvf bombk.tar mv bombk A04-BinaryBomb ~~~ This will result in a directory called `A04-BinaryBomb` with the following files: - `README`: Identifies the bomb and its owners. - `bomb`: The executable binary bomb. - `bomb.c`: Source file with the bomb's main routine and a friendly greeting from Dr. Evil. If for some reason you request multiple bombs, just choose one bomb to work on and delete the others. # Defuse Your Bomb Your job for this assignment is to defuse your bomb. To have your assignment marked as a "Nailed-It" you must demonstrate to your TA that you have defused **phases one through four.** If your group is ambitious, you all should attempt to defuse bombs five and six (and any other you may find). You must complete the assignment using the course VM. 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, or so we hear. You can use many tools to help you defuse your bomb. Please look at the Hints section for some tips and ideas. Along the way, you should jot down your notes, because these are what you will submit to gradescope. For example, jot down any shell or GDB commands that you found useful, or any methods for viewing the files. I will be notified each time your bomb explodes, and I will publicly ridicule you for this (OK, maybe not). It is possible to complete the assignment without your bomb exploding, but don't worry if it does explode. # Hints ## solution.txt The bomb takes an optional program argument in the form of a text file with your solutions to the different bomb phases. To begin with, you will not know any solutions, but after you defuse the first bomb, you can run the program with a file that let's you skip . For example: ~~~bash # Assume that solution.txt has answers to phases 1 and 2 gdb bomb (gdb) b phase_3 # SOME GDB OUTPUT (gdb) r solution.txt # SOME GDB OUTPUT ~~~ The bomb ignores blank input lines, will read the input lines from `solution.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 do not have to keep retyping the solutions to phases you have already defused. Please take advantage of this vulnerability by creating a file named `solution.txt` and recording your solutions in this file. ## GDB 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 not always easy, and I don't particularly recommend it. 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. To avoid accidentally detonating the bomb, you will need to learn how to single-step through the **assembly** code (`si` and `ni`) and how to set breakpoints (`b`). You will also need to learn how to inspect both the registers (`i r`) and the memory states (using `p`rint or e`x`amine). One nice side-effect of the assignment is that you will get very good at using a debugger. This is a crucial skill that will pay big dividends the rest of your career. ## Tools There are many tools which are designed to help you figure out both how programs work, and what is wrong when they do not 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` As you saw in the Debugger lab, 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. You'll find the `disassemble` command very useful (e.g., `disassemble phase_1`). As I mentioned in class, I prefer to view x86-64 assembly in Intel syntax, which is not the default. You can tell GDB to use Intel syntax with this command: ~~~bash echo "set disassembly-flavor intel" >> ~/.gdbinit ~~~ - `objdump --syms` This 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! ~~~bash objdump --syms bomb | grep text | awk '{print $NF}' | grep -v "^[\._]" | sort ~~~ (See [this webpage](https://explainshell.com/explain?cmd=objdump+--syms+bomb+%7C+grep+text+%7C+awk+%27%7Bprint+%24NF%7D%27+%7C+grep+-v+%22%5E%5B%5C._%5D%22+%7C+sort) for an explanation of that command.) - `objdump --disassemble` Use this to disassemble all of the code in the bomb. You can also just look at individual functions. Reading just the assembly code is technically enough to show you how the bomb works. Although `objdump --disassemble` gives you a lot of information, it does not 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). I prefer to view the output with syntax highlighting using Intel syntax. Here is my preferred method: ~~~bash objdump --disassemble --disassembler-options=intel bomb > bomb.s vim bomb.s ~~~ - `strings --data` This utility will display the printable strings that appear in the data section of your bomb. Looking for a particular tool? How about documentation? The commands `tldr`, `apropos`, `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. Also, keep in mind that you may not look for solutions on the web. And remember that the mentors (and I) are here to help you! One other useful fact: you will find that the bomb has many functions with descriptive names. All functions do what their names say. Also remember that some functions (like `sscanf`) are library function. Do not try to reverse-engineer it unless you have several months to spend; instead read the `man`ual page. ## Reverse Engineering [Radare2](https://www.radare.org/n/radare2.html) is a reverse engineering tool. You can use it to extract useful information about your program. For example, it will - display branching (if-statements) - display loops - display function calls - give human-readable names to function arguments - and much much more Here is a quick animation show it at work. If you do not see an animation above this line (or if you see the animation but you don't see the progress bar), you will need to refresh the page (sometimes more than once). Or you can go directly to the player: https://asciinema.org/a/524154 Here are the commands I used: ~~~bash # Starting r2 and analyze the binary r2 -A bomb # List all symbols afl # Seek to the sym.phase_4 function s sym.phase_4 # Enable minimap view (a control flow graph) VV # Press 'q' twice to return to the prompt # Press and enter 'q' to quite r2 when at the prompt ~~~ Check this out for more information: [Visual Graphs · Radare2 Explorations](https://monosource.gitbooks.io/radare2-explorations/content/intro/visual_graphs.html). # Submitting Your Assignment You will submit your responses on gradescope. **Only one partner should submit.** The submitter will add the other partner through the gradescope interface. - [Submitting an Assignment](https://help.gradescope.com/article/ccbpppziu9-student-submit-work) - [Adding Group Members](https://help.gradescope.com/article/m5qz2xsnjy-student-add-group-members) - [gradescope Student Help Center](https://help.gradescope.com/category/cyk4ij2dwi-student-workflow)