**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 that consists of a sequence of phases. Each phase expects you to type a particular string on `stdin`. 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 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 pair 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! # Learning Goals - Learn how to reverse engineer a binary - Gain experience reading binary - Learn more about data representation # Grading Walk-Throughs This assignment will be graded as pass/needs-revisions by a TA. To pass 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**. 2. Schedule a time to meet with a TA prior to the 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 can't all make it at the same time, then each of you needs to schedule a time to meet with the TAs. 3. 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. 4. The TA will then either - mark your assignment as "pass" on gradescope, or - mark your assignment as "needs-revisions" and inform you that you have some corrections to make. 5. 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've first met with a TA. # Overview You will 1. find a partner to work with (two to three to a group), 1. request a bomb from the server, and then 2. defuse several bomb phases using reverse engineering techniques. The bomb will notify me automatically about your progress as you work on it. You can keep track of how you are doing 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:15213/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. # 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:15213/, 2. fill in the form - enter the partner names (without spaces), - enter a partners email address, 3. download your bomb, 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 on the server of one of your partners. You should be able to use something like (assuming your bomb file is number 1 and it was downloaded to your `~/Downloads` directory): ~~~bash scp ~/Downloads/bombk.tar username@itbdcv-lnx04p.campus.pomona.edu:~/ ~~~ Login to the server and give the command: ~~~bash tar xvf bombk.tar ~~~ This will create a directory called `bombk` 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 "pass" 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 do the assignment on 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 as well, 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 about it 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 it. 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, the GNU debugger is a command line debugger 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. 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 the assembler code can tell 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 `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 manual page. # Submitting Your Assignment You will submit your code and/or responses on gradescope. **Only one partner should submit.** The submitter will add the other partner through the gradescope interface. To pass the autograder (if one exists for this assignment), your output must exactly match the expected output. Your program output should be similar to the example execution above, and the autograder on gradescope will show you the correct output if yours is not formatted properly. You can use [text-compare](https://text-compare.com/) to compare your output to the expected output and that should give you an idea if you have a misspelled word or extra space (or if I do). Additional details for using gradescope can be found here: - [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)