The nefarious Dr. Evil has planted a slew of binary bombs on our virtual 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 is to defuse your bomb before the due date. Good luck, and welcome to the bomb squad!
You can obtain your bomb by logging into the console of your VM (via OpenStack or NoMachine), starting up firefox on your VM, and visiting this site: http://raphael.cs.uky.edu:16123/. This site displays a binary bomb request form for you to fill in. Enter your user name and email address and click the Submit button. The server then builds your bomb and returns it to your browser in a file called bombX.tar where X is the unique number of your bomb. Each person in the class receives a personal bomb to defuse.
Save the bombX.tar file to a directory on your VM. (X will be a small integer.) Then give the command:
tar -xvf bombX.tarThis command creates a directory called ./bombX with the following files:
If for some reason you request multiple bombs, don't panic. Choose one bomb to work on and delete the rest.
Your job for this project is to defuse your bomb.
You must do the assignment on your 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 of this page for some tips and ideas. The best idea is to use your favorite debugger to step through the disassembled binary.
Each time your bomb explodes, it notifies the bomb server, and you lose 1 point (up to a max of 50 points) in the final score for the project. So there are consequences to exploding the bomb. You must be careful!
The first four phases are worth 15 points each. Phases 5 and 6 are a little more difficult, so they are worth 20 points each. The total for all 6 phases is 100 points.
Although phases get progressively harder to defuse, the expertise you gain as you move from phase to phase should offset this difficulty. However, the last phase will challenge even the best students, so please don't wait until the last minute to start.
The bomb ignores blank input lines. It also has a helpful behavior to switch between input from a file and from standard input: If you run your bomb with a command-line argument, for example, ./bomb mysolution.txt, then it reads input lines from mysolution.txt until it reaches the end of that file, and then it switches over to stdin. In a moment of weakness, Dr. Evil added this feature so you don't have to keep retyping the solutions to phases you have already defused; you can put them in the file.
To avoid accidentally detonating the bomb, you need to learn how to single-step through the assembly code and how to set breakpoints. You also need to learn how to inspect both the registers and the memory states. One of the nice side-effects of doing the project is that you will get very good at using a debugger. This skill is crucial and will pay big dividends for the rest of your career.
You should certainly use a debugger to investigate your bomb, but your score depends on providing input to the program that defuses all the phases when the program is run without a debugger.
This project is to be done individually. All submittals are electronic (see What to submit below). We will send any project clarifications and corrections to the class email list.
The binary bomb project has been around for a few years at many schools. Please do not turn to the internet for hints on how to solve its phases. If we find you doing that, you get a 0 on the project and we report a cheating offense to the registrar.
There are many ways to defuse your bomb. You can examine the bomb in great detail without ever running the program and figure out exactly what it does. This technique is useful, but it is not always easy to accomplish. You can also run the program under a debugger, watch what it does step by step, and use this information to defuse it. This method is probably the fastest way to defuse it.
Don't try brute force to guess the answers. You could write a program that tries every possible key to find the right one, but this solution is not good for several reasons:
There are many tools 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.
set auto-load safe-path /
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.
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. The web is also be a treasure trove of information. If you get stumped, feel free to ask the instructor for help. But you must not use the web to search for methods to defuse the bombs in the bomblab. That's cheating. Dr. Evil is watching.
As you defuse the bomb, remember the input you typed so that you can submit a text file named DefuseCommands.txt containing the phrases you typed to defuse the bomb. Please put your name and the bomb number at the end of DefuseCommands.txt.
Once you create the text file, go to https://www.cs.uky.edu/csportal to upload DefuseCommands.txt. You may upload it as many times as you like. We'll only grade the last submission. The CSPortal timestamps every submission.