The names all the functions the bomb calls

The nefarious Dr. Evil has planted a slew of "binary bombs" on our machines. 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 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!

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

This will display a binary bomb request form for you to fill in. Enter your user name and GMU 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.

Important Notes:

Step 2: Defuse Your Bomb

You must do the assignment only on zeus (specifically, zeus-1; not any other machine or zeus-2!). 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.

linux> ./bomb psol.txt

then it will read the input lines from psol.txt until it reaches EOF (end of file), and then switch over to stdin. We added this feature so you don't have to keep retyping the solutions to phases you have already defused.

Hand-In

There is no explicit hand-in. The bomb will notify your instructor automatically after you have successfully defused it on zeus. You can keep track of how you are doing by looking at:

•You lose 1/2 point (up to a max of 10 points) every time you guess incorrectly and the bomb explodes.

•Every time you guess wrong, a message is sent to the bomb server. You could very quickly saturate the network with these messages, and cause the system administrators to revoke your computer access.

oFor other documentation, type help at the gdb command prompt, or type man gdb, or info gdb at a Unix prompt. Some people also like to run gdb under gdb-mode in emacs.

• objdump -t This will print out the bomb's symbol table. The symbol table includes the names of all

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:

can use this to look up information on system functions that the binary executable might use. In particular, man

asciimight come in useful.

• As you will notice from examining bomb.c, the user input is sent into the phase as a single string. One of the

first things the phase will do is try to 'parse' it into the form it is expecting.

what the function does, use man to investigate the parameters and return information. Then examine the

parameters that are sent and the return value. Examples would be like <sscanf@plt> for sscanf.

waste your time trying to reverse engineer functions like read_six_numbers or strings_not_equal.

• Understanding parameter passing is critical to this assignment. Whenever you see a reference to %rsp in the

being met. You can also set a breakpoint atexplode_bombto ensure you don’t accidently execute it.

• Breakpoint guards are crucially important to success in this project. If I put a breakpoint at the start of the explode_bomb function, I can ensure that I always give myself the option not to explode. Always use breakpoint guards before attempting to run any code, even if you think you are only performing “safe” operations.

This layout mode will display the assembly source code on the screen with a border around it. Sometimes this border may look garbled, but it is trying the best it can to serve everyone up a nice pretty display. If the screen looks too garbled, you can issue a refresh command in gdb to redraw the screen.

refresh

Warnings on GDB layout modes: There have been past reports of crashing gdb (and setting off bombs) when using layout modes and resizing the window (eg. expanding to full-screen while running gdb, or shrinking/growing the font while in gdb). While everything looks like it’s running well, you should take care by getting a good size for you window before running gdb.

Tips on GDB layout modes: Previous students reported that setting your breakpoints and start running the program before running the layout commands worked more reliably than setting layouts before beginning to run the code.

The CS 367 GTAs and UTAs can help you with the use of tools such as gdb and objdump. You are encouraged to use the Piazza forum for your questions. However, please do not post long Assembly code sections from your binary bomb to Piazza and ask what the “logic” of that code is – it is your responsibility to figure out that logic. But of course, questions about the semantics of individual assembly instructions and the use of specific tools (e.g., gdb) are welcome.

Good luck and have fun defusing your binary bomb!