95_bomb_diffuse_94747/auto-lab3.docx
CSCI 2467, Fall 2021
, The Bomb Lab: Defusing a Binary Bomb Due: Friday October 29, 11:59PM (CDT)
The website is autolab.cs.uno.edu
Username is [email protected]
Password is Joycjackson55*
Introduction
The nefarious Dr. Evil 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 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!
Step 1: Get Your Bomb
You can obtain your bomb from AutoLab using the “download handout” link as you did for previous lab tar files):
This will display a binary bomb request form for you to fill in. Enter your 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. Note: When you click “submit”, the server may take a few seconds to prepare your bomb. Please wait, don’t click submit repeatedly.
Save the bombk.tar file to your home directory on systems-lab.cs.uno.edu where you will do your work. Then give the command: tar -xvf bombk.tar. This will create a directory called ./bombk with the following files:
README: Identifies the bomb and its owner.
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, 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 the class server, using a terminal in Math 209, the systems-lab-web interface, or an ssh client to connect to systems-lab.cs.uno.edu. 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 tamperproofing 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. The best way is to use the gdb debugger to step through the disassembled binary.
Gaining and losing points
Each time your bomb explodes it notifies the bomblab server, and you lose 1/2 point (up to a max of 20 points) in the final score for the lab. So there are real consequences to exploding the bomb. You must be careful!
The first two phases are worth 5 points each. Phases 3, 4, and 5 are worth 10 points each. If you defuse phases 1 through 5, you will have your full 40 points for the lab. Phase 6 is worth an additional 10 points, meaning you could get 50 out of 40 points by defusing phase 6.
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 strongest students!
Phase
Point value
1
5
2
5
3
10
4
10
5
10
Total
40
6
10 (extra credit)
Figure 1: Summary of bomb lab phases
How to “run” the bomb
Warning: Running the bomb program without using gdb could result in an explosion. We recommend always using gdb with breakpoints.
You can load your bomb into gdb with this command:
$ gdb ./bomb
The bomb ignores blank input lines. If you run your bomb with a command line argument (such as solution.txt) then it will read the input lines from solution.txt until it reaches EOF (end of file), and then switch 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. Of course, you wouldn’t run to run the bomb without breakpoints, so within GDB/GEF you would run the program with a command line argument like this:
gef ➤ run solution.txt
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 for you in the future.
Handin
This is an individual project! Please work only on your own bomb. Each bomb is unique, so you will need to find your own solutions.
There is no explicit handin. The bomb will notify AutoLab automatically about your progress as you work on it. You can keep track of how you are doing by looking at the class scoreboard on AutoLab.
This web page is updated continuously to show the progress for each bomb. Updates may take up to 30 seconds to appear.
Hints (Please read this!)
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.
We do make one request, please do not use brute force! You could write a program that will try every possible key to find the right one. But this is no good for several reasons:
You lose 1/2 point (up to a max of 20 points) every time you guess incorrectly and the bomb explodes.
We haven’t told you how long the strings are, nor have we told you what characters are in them. Even if you made the (incorrect) assumptions that they all are less than 80 characters long and only contain letters, then you will have 2680 guesses for each phase. This will take a very long time to run, and you will not get the answer before the assignment is due.
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. On the next page we provide 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 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 CS:APP web site (http://csapp.cs.cmu.edu/public/students.html) has a very handy single-page gdb summary that you can print out and use as a reference. (Also Figure 3.39 on page 280 of CS:APP3e has a nice summary)
VERY important advice: To keep the bomb from blowing up every time you type in a wrong input, you’ll need to learn how to set breakpoints. Do this before you do anything else.
gef: GDB enhanced features
gef (pronounced like “Jeff”) adds some features to gdb to aid in reverse engineering. It also adds a colorful “context” screen showing registers, assembly code, stack memory, and other things. You will still need to dig deeper using gdb commands, but students in previous semesters found gef useful, so we have enabled it by default on systems-lab.
objdump -t bomb
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!
objdump -d bomb -M intel
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 -d gives you a lot of information, it doesn’t tell you the whole story. You will need to use gdb, which actually runs the program, to learn more.
A note on assembly formats: objdump, like most tools on Linux, uses AT&T syntax for assembly instructions by default. If you took CSCI 2450 at UNO, you are probably accustomed to Intel syntax. (The Aside on p. 177 of CS:APP3e discusses these “flavors” and their differences.) That’s why the -M intel option is given above. Without it, the AT&T format is used, which is equivalent but difficult to use for people used to Intel. We recommend you stick with whatever format you are used to.
strings
This utility will display the printable (ASCII) null-terminated strings in your bomb.
Looking for a more details about a particular tool? Manual pages (the man command) are a good reference for the command-line tools. Also man ascii might come in useful when looking at ASCII text.
If you get stumped, please come to course help hours for assistance. Don’t stay stuck!
95_bomb_diffuse_94747/README.txt
This directory contains the files that you will use to build and run
the CS:APP Bomb Lab. The Bomb Lab teaches students principles of
machine-level programs, as well as general debugger and reverse
engineering skills.
***********
1. Overview
***********
----
1.1. Binary Bombs
----
A "binary bomb" is a Linux executable C program that consists of six
"phases." Each phase expects the student to enter a particular string
on stdin. If the student enters the expected string, then that phase
is "defused." Otherwise the bomb "explodes" by printing "BOOM!!!".
The goal for the students is to defuse as many phases as possible.
----
1.2. Solving Binary Bombs
----
In order to defuse the bomb, students must use a debugger, typically
gdb or ddd, to disassemble the binary and single-step through the
machine code in each phase. The idea is to understand what each
assembly statement does, and then use this knowledge to infer the
defusing string. Students earn points for defusing phases, and they
lose points (configurable by the instructor, but typically 1/2 point)
for each explosion. Thus, they quickly learn to set breakpoints before
each phase and the function that explodes the bomb. It's a great
lesson and forces them to learn to use a debugger.
----
1.3. Autograding Service
----
We have created a stand-alone user-level autograding service that
handles all aspects of the Bomb Lab for you: Students download their
bombs from a server. As the students work on their bombs, each
explosion and defusion is streamed back to the server, where the
current results for each bomb are displayed on a Web "scoreboard."
There are no explicit handins and the lab is self-grading.
The autograding service consists of four user-level programs that run
in the main ./bomblab directory:
- Request Server (bomblab-requestd.pl). Students download their bombs
and display the scoreboard by pointing a browser at a simple HTTP
server called the "request server." The request server builds the
bomb, archives it in a tar file, and then uploads the resulting tar
file back to the browser, where it can be saved on disk and
untarred. The request server also creates a copy of the bomb and its
solution for the instructor.
- Result Server (bomblab-resultd.pl). Each time a student defuses a
bomb phase or causes an explosion, the bomb sends a short HTTP
message, called an "autoresult string," to an HTTP "result server,"
which simply appends the autoresult string to a "scoreboard log file."
- Report Daemon (bomblab-reportd.pl). The "report daemon" periodically
scans the scoreboard log file. The report daemon finds the most recent
defusing string submitted by each student for each phase, and
validates these strings by applying them to a local copy of the
student's bomb. It then updates the HTML scoreboard that summarizes
the current number of explosions and defusions for each bomb, rank
ordered by the total number of accrued points.
- Main daemon (bomblab.pl). The "main daemon" starts and nannies the
request server, result server, and report deamon, ensuring that
exactly one of these processes (and itself) is running at any point in
time. If one of these processes dies for some reason, the main daemon
detects this and automatically restarts it. The main daemon is the
only program you actually need to run.
********
2. Files
********
The ./bomblab directory contains the following files:
Makefile - For starting/stopping the lab and cleaning files
bomblab.pl* - Main daemon that nannies the other servers & daemons
Bomblab.pm - Bomblab configuration file
bomblab-reportd.pl* - Report daemon that continuously updates scoreboard
bomblab-requestd.pl* - Request server that serves bombs to students
bomblab-resultd.pl* - Result server that gets autoresult strings from bombs
bomblab-scoreboard.html - Real-time Web scoreboard
bomblab-update.pl* - Helper to bomblab-reportd.pl that updates scoreboard
bombs/ - Contains the bombs sent to each student
log-status.txt - Status log with msgs from various servers and daemons
log.txt - Scoreboard log of autoresults received from bombs
makebomb.pl* - Helper script that builds a bomb
scores.txt - Summarizes current scoreboard scores for each student
src/ - The bomb source files
writeup/ - Sample Latex Bomb Lab writeup
*******************
3. Bomb Terminology
*******************
LabID: Each instance (offering) of the lab is identified by a unique
name, e.g., "f12" or "s13", that the instructor chooses. Explosion and
diffusions from bombs whose LabIDs are different from the current
LabID are ignored. The LabID must not have any spaces.
BombID: Each bomb in a given instance of the lab has a unique
non-negative integer called the "bombID."
Notifying Bomb: A bomb can be compiled with a NOTIFY option that
causes the bomb to send a message each time the student explodes or
defuses a phase. Such bombs are called "notifying bombs."
Quiet Bomb: If compiled with the NONOTIFY option, then the bomb
doesn't send any messages when it explodes or is defused. Such bombs
are called "quiet bombs."
We will also find it helpful to distinguish between custom and
generic bombs:
Custom Bomb: A "custom bomb" has a BombID > 0, is associated with a
particular student, and can be either notifying or quiet. Custom
notifying bombs are constrained to run on a specific set of Linux
hosts determined by the instructor. On the other hand, custom quiet
bombs can run on any Linux host.
Generic Bomb: A "generic bomb" has a BombID = 0, isn't associated with
any particular student, is quiet, and hence can run on any host.
************************
4. Offering the Bomb Lab
************************
There are two basic flavors of Bomb Lab: In the "online" version, the
instructor uses the autograding service to handout a custom notifying
bomb to each student on demand, and to automatically track their
progress on the realtime scoreboard. In the "offline" version, the
instructor builds, hands out, and grades the student bombs manually,
without using the autograding service.
While both version give the students a rich experience, we recommend
the online version. It is clearly the most compelling and fun for the
students, and the easiest for the instructor to grade. However, it
requires that you keep the autograding service running non-stop,
because handouts, grading, and reporting occur continuously for the
duration of the lab. We've made it very easy to run the service, but
some instructors may be uncomfortable with this requirement and will
opt instead for the offline version.
Here are the directions for offering both versions of the lab.
---
4.1. Create a Bomb Lab Directory
---
Identify the generic Linux machine ($SERVER_NAME) where you will
create the Bomb Lab directory (./bomblab) and, if you are offering the
online version, run the autograding service. You'll only need to have
a user account on this machine. You don't need root access.
Each offering of the Bomb Lab starts with a clean new ./bomblab
directory on $SERVER_NAME. For example:
linux> tar xvf bomblab.tar
linux> cd bomblab
linux> make cleanallfiles
---
4.2 Configure the Bomb Lab
---
Configure the Bomb Lab by editing the following file:
./Bomblab.pm - This is the main configuration file. You will only need
to modify or inspect a few variables in Section 1 of this file. Each
variable is preceded by a descriptive comment. If you are offering the
offline version, you can ignore most of these settings.
If you are offering the online version, you will also need to edit the
following file:
./src/config.h - This file lists the domain names of the hosts that
notifying bombs are allowed to run on. Make sure you update this
correctly, else you and your students won't be able to run your bombs.
----
4.3. Update the Lab Writeup
---
Once you have updated the configuration files, modify the Latex lab
writeup in ./writeup/bomblab.tex for your environment. Then type the
following in the ./writeup directory:
unix> make clean
unix> make
This will create ps and pdf versions of the writeup
---
4.4. Running the Online Bomb Lab
---
------
4.4.1. Short Version
------
From the ./bomblab directory:
(1) Reset the Bomb Lab from scratch by typing
linux> make cleanallfiles
(2) Start the autograding service by typing
linux> make start
(3) Stop the autograding service by typing
linux> make stop
You can start and stop the autograding service as often as you like
without losing any information. When in doubt "make stop; make start"
will get everything in a stable state.
However, resetting the lab deletes all old bombs, status logs, and the
scoreboard log. Do this only during debugging, or the very first time
you start the lab for your students.
Students request bombs by pointing their browsers at
http://$SERVER_NAME:$REQUESTD_PORT/
Students view the scoreboard by pointing their browsers at
http://$SERVER_NAME:$REQUESTD_PORT/scoreboard
------
4.4.2. Long Version
------
(1) Resetting the Bomb Lab. "make stop" ensures that there are no
servers running. "make cleanallfiles" resets the lab from scratch,
deleting all data specific to a particular instance of the lab, such
as the status log, all bombs created by the request server, and the
scoreboard log. Do this when you're ready for the lab to go "live" to
the students.
Resetting is also useful while you're preparing the lab. Before the
lab goes live, you'll want to request a few bombs for yourself, run
them, defuse a few phases, explode a few phases, and make sure that
the results are displayed properly on the scoreboard. If there is a
problem (say because you forgot to update the list of machines the
bombs are allowed to run in src/config.h) you can fix the
configuration, reset the lab, and then request and run more test
bombs.
CAUTION: If you reset the lab after it's live, you'll lose all your
records of the students bombs and their solutions. You won't be able
to validate the students handins. And your students will have to get
new bombs and start over.
(2) Starting the Bomb Lab. "make start" runs bomblab.pl, the main
daemon that starts and nannies the other programs in the service,
checking their status every few seconds and restarting them if
necessary:
(3) Stopping the Bomb Lab. "make stop" kills all of the running
servers. You can start and stop the autograding service as often as
you like without losing any information. When in doubt "make stop;
make start" will get everything in a stable state.
Request Server: The request server is a simple special-purpose HTTP
server that (1) builds and delivers custom bombs to student browsers
on demand, and (2) displays the current state of the real-time
scoreboard.
A student requests a bomb from the request daemon in two
steps: First, the student points their favorite browser at
http://$SERVER_NAME:$REQUESTD_PORT/
For example, http://foo.cs.cmu.edu:15213/. The request server
responds by sending an HTML form back to the browser. Next, the
student fills in this form with their user name and email address, and
then submits the form. The request server parses the form, builds and
tars up a notifying custom bomb with bombID=n, and delivers the tar
file to the browser. The student then saves the tar file to disk. When
the student untars this file, it creates a directory (./bomb
) with
the following four files:
bomb* Notifying custom bomb executable
bomb.c Source code for the main bomb routine
ID Identifies the student associated with this bomb
README Lists bomb number, student, and email address
The request server also creates a directory (bomblab/bombs/bomb)
that contains the following files:
bomb* Custom bomb executable
bomb.c Source code for main routine
bomb-quiet* A quiet version of bomb used for autograding
ID Identifies the user name assigned to this bomb
phases.c C source code for the bomb phases
README Lists bombID, user name, and email address
solution.txt The solution for this bomb
Result Server: Each time a student defuses a phase or explodes their
bomb, the bomb sends an HTTP message (called an autoresult string) to
the result server, which then appends the message to the scoreboard
log. Each message contains a BombID, a phase, and an indication of the
event that occurred. If the event was a defusion, the message also
contains the "defusing string" that the student typed to defuse the
phase.
Report Daemon: The report daemon periodically scans the scoreboard log
and updates the Web scoreboard. For each bomb, it tallies the number
of explosions, the last defused phase, validates each last defused
phase using a quiet copy of the bomb, and computes a score for each
student in a tab delimited text file called "scores.txt." The update
frequency is a configuration variable in Bomblab.pm.
Instructors and students view the scoreboard by pointing their
browsers at:
http://$SERVER_NAME:$REQUESTD_PORT/scoreboard
------
4.4.3. Grading the Online Bomb Lab
------
The online Bomb Lab is self-grading. At any point in time, the
tab-delimited file (./bomblab/scores.txt) contains the most recent
scores for each student. This file is created by the report daemon
each time it generates a new scoreboard.
------
4.4.4. Additional Notes on the Online Bomb Lab
------
* Since the request server and report daemon both need to execute
bombs, you must include $SERVER_NAME in the list of legal machines in
your bomblab/src/config.h file.
* All of the servers and daemons are stateless, so you can stop ("make
stop") and start ("make start") the lab as many times as you like
without any ill effects. If you accidentally kill one of the daemons,
or you modify a daemon, or the daemon dies for some reason, then use
"make stop" to clean up, and then restart with "make start". If your
Linux box crashes or reboots, simply restart the daemons with "make
start".
* Information and error messages from the servers are appended to the
"status log" in bomblab/log-status.txt. Servers run quietly, so they
can be started from initrc scripts at boot time.
* See src/README for more information about the anatomy of bombs and
how they are constructed. You don't need to understand any of this to
offer the lab. It's provided only for completeness.
* Before going live with the students, we like to check everything out
by running some tests. We do this by typing
linux> make cleanallfiles
linux> make start
Then we request a bomb for ourselves by pointing a Web browser at
http://$SERVER_NAME:$REQUESTD_PORT
After saving our bomb to disk, we untar it, copy it to a host in the
approved list in src/config.h, and then explode and defuse it a couple
of times to make sure that the explosions and diffusion are properly
recorded on the scoreboard, which we check at
http://$SERVER_NAME:$REQUESTD_PORT/scoreboard
Once we're satisfied that everything is OK, we stop the lab
linux> make stop
and then go live:
linux> make cleanallfiles
linux> make start
Once we go live, we type "make stop" and "make start" as often as we
need to, but we are careful never to type "make cleanallfiles" again.
----
4.5. Running the Offline Bomb Lab
----
In this version of the lab, you build your own quiet bombs manually
and then hand them out to the students. The students work on defusing
their bombs offline (i.e., independently of any autograding service)
and then handin their solution files to you, each of which you grade
manually.
You can use the makebomb.pl script to build your own bombs
manually. The makebomb.pl script also generates the bomb's solution.
Type "./makebomb.pl -h" to see its arguments.
Option 1: The simplest approach for offering the offline Bomb Lab is
to build a single generic bomb that every student attempts to defuse:
linux> ./makebomb.pl -s ./src -b ./bombs
This will create a generic bomb and some other files in ./bombs/bomb0:
bomb* Generic bomb executable (handout to students)
bomb.c Source code for main routine (handout to students)
bomb-quiet* Ignore this
ID Ignore this
phases.c C source code for the bomb phases
README Ignore this
solution.txt The solution for this bomb
You will handout only two of these files to the students: ./bomb and ./bomb.c
The students will handin their solution files, which you can validate
by feeding to the bomb:
linux> cd bombs/bomb0
linux> ./bomb < student_solution.txt
This option is easy for the instructor, but we don't recommend it
because it is too easy for the students to cheat.
Option 2. The other option for offering an offline lab is to use the
makebomb.pl script to build a unique quiet custom bomb for each
student:
linux> ./makebomb.pl -i -s ./src -b ./bombs -l bomblab -u -v
This will create a quiet custom bomb in ./bombs/bomb for the
student whose email address is and whose user name is :
bomb* Custom bomb executable (handout to student)
bomb.c Source code for main routine (handout to student)
bomb-quiet* Ignore this
ID Identifies the student associated with this bomb
phases.c C source code for the bomb phases
README Lists bomb number, student, and email address
solution.txt The solution for this bomb
You will handout four of these files to the student: bomb, bomb.c, ID,
and README.
Each student will hand in their solution file, which you can validate
by hand by running their custom bomb against their solution:
linux> cd ./bombs/bomb
linux> ./bomb < student_n_solution.txt
The source code for the different phase variants is in ./src/phases/.
95_bomb_diffuse_94747/bomblab.pdf
15-213 Fall 20xx
Lab Assignment L2: Defusing a Binary Bomb
Assigned: Sept. 13, Due: Friday Sept. 22
Harry Bovik ([email protected]) is the lead person for this lab.
1 Introduction
The nefarious Dr. Evil has planted a slew of “binary bombs” on our class 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!
Step 1: Get Your Bomb
You can obtain your bomb by pointing your Web browser at:
http://$Bomblab::SERVER_NAME:$Bomblab::REQUESTD_PORT/
This will display a binary bomb request form for you to fill in. Enter your 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 to a (protected) directory in which you plan to do your work. Then give the
command: 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.
1
• bomb.c: Source file with the bomb’s main routine and a friendly greeting from Dr. Evil.
• writeup.{pdf,ps}: The lab writeup.
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 one of the class machines. 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. The best way is to use your favorite debugger to step through the disassembled binary.
Each time your bomb explodes it notifies the bomblab server, and you lose 1/2 point (up to a max of 20
points) in the final score for the lab. So there are consequences to exploding the bomb. You must be careful!
The first four phases are worth 10 points each. Phases 5 and 6 are a little more difficult, so they are worth
15 points each. So the maximum score you can get is 70 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. If you run your bomb with a command line argument, for example,
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. 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.
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 the rest of your career.
Logistics
This is an individual project. All handins are electronic. Clarifications and corrections will be posted on the
course message board.
2
Handin
There is no explicit handin. The bomb will notify your instructor 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:
http://$Bomblab::SERVER_NAME:$Bomblab::REQUESTD_PORT/scoreboard
This web page is updated continuously to show the progress for each bomb.
Hints (Please read this!)
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.
We do make one request, please do not use brute force! You could write a program that will try every
possible key to find the right one. But this is no good for several reasons:
• You lose 1/2 point (up to a max of 20 points) every time you guess incorrectly and the bomb explodes.
• Every time you guess wrong, a message is sent to the bomblab server. You could very quickly saturate
the network with these messages, and cause the system administrators to revoke your computer access.
• We haven’t told you how long the strings are, nor have we told you what characters are in them. Even
if you made the (incorrect) assumptions that they all are less than 80 characters long and only contain
letters, then you will have 2680 guesses for each phase. This will take a very long time to run, and
you will not get the answer before the assignment is due.
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 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 CS:APP web site
http://csapp.cs.cmu.edu/public/students.html
has a very handy single-page gdb summary that you can print out and use as a reference. Here are
some other tips for using gdb.
3
– To keep the bomb from blowing up every time you type in a wrong input, you’ll want to learn
how to set breakpoints.
– For online 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 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!
• objdump -d
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 -d gives you a 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:
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.
• strings
This utility will display the printable strings in your bomb.
Looking for a particular tool? How about documentation? Don’t forget, 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, the web may also be a treasure trove
of information. If you get stumped, feel free to ask your instructor for help.
4
95_bomb_diffuse_94747/bomb/README.md
This is an x86-64 bomb for self-study students.
References:
https://yieldnull.com/blog/ed9209f92effdad6f9fe997fdfc120ecc89ea212/
http://www.chenzhikai.com/2018/02/21/bomb/
https://blackdragonf.github.io/2017/04/18/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%B3%BB%E7%BB%9FBombLab%E5%AE%9E%E9%AA%8C%E6%8A%A5%E5%91%8A/
Result:
```sh
$ ./bomb psol.txt
Welcome to my fiendish little bomb. You have 6 phases with
which to blow yourself up. Have a nice day!
Phase 1 defused. How about the next one?
That's number 2. Keep going!
Halfway there!
So you got that one. Try this one.
Good work! On to the next...
Congratulations! You've defused the bomb!
```
95_bomb_diffuse_94747/bomb/bomb
95_bomb_diffuse_94747/bomb/bomb.asm
bomb: file format elf64-x86-64
Disassembly of section .init:
0000000000400ac0 <_init>:
400ac0: 48 83 ec 08 sub $0x8,%rsp
400ac4: e8 f3 01 00 00 callq 400cbc
400ac9: 48 83 c4 08 add $0x8,%rsp
400acd: c3 retq
Disassembly of section .plt:
0000000000400ad0 <.plt>:
400ad0: ff 35 1a 25 20 00 pushq 0x20251a(%rip) # 602ff0 <_GLOBAL_OFFSET_TABLE_+0x8>
400ad6: ff 25 1c 25 20 00 jmpq *0x20251c(%rip) # 602ff8 <_GLOBAL_OFFSET_TABLE_+0x10>
400adc: 0f 1f 40 00 nopl 0x0(%rax)
0000000000400ae0 :
400ae0: ff 25 1a 25 20 00 jmpq *0x20251a(%rip) # 603000
400ae6: 68 00 00 00 00 pushq $0x0
400aeb: e9 e0 ff ff ff jmpq 400ad0 <.plt>
0000000000400af0 <__errno_location@plt>:
400af0: ff 25 12 25 20 00 jmpq *0x202512(%rip) # 603008 <__errno_location@GLIBC_2.2.5>
400af6: 68 01 00 00 00 pushq $0x1
400afb: e9 d0 ff ff ff jmpq 400ad0 <.plt>
0000000000400b00 :
400b00: ff 25 0a 25 20 00 jmpq *0x20250a(%rip) # 603010
400b06: 68 02 00 00 00 pushq $0x2
400b0b: e9 c0 ff ff ff jmpq 400ad0 <.plt>
0000000000400b10 :
400b10: ff 25 02 25 20 00 jmpq *0x202502(%rip) # 603018
400b16: 68 03 00 00 00 pushq $0x3
400b1b: e9 b0 ff ff ff jmpq 400ad0 <.plt>
0000000000400b20 :
400b20: ff 25 fa 24 20 00 jmpq *0x2024fa(%rip) # 603020
400b26: 68 04 00 00 00 pushq $0x4
400b2b: e9 a0 ff ff ff jmpq 400ad0 <.plt>
0000000000400b30 <__stack_chk_fail@plt>:
400b30: ff 25 f2 24 20 00 jmpq *0x2024f2(%rip) # 603028 <__stack_chk_fail@GLIBC_2.4>
400b36: 68 05 00 00 00 pushq $0x5
400b3b: e9 90 ff ff ff jmpq 400ad0 <.plt>
0000000000400b40 :
400b40: ff 25 ea 24 20 00 jmpq *0x2024ea(%rip) # 603030
400b46: 68 06 00 00 00 pushq $0x6
400b4b: e9 80 ff ff ff jmpq 400ad0 <.plt>
0000000000400b50 :
400b50: ff 25 e2 24 20 00 jmpq *0x2024e2(%rip) # 603038
400b56: 68 07 00 00 00 pushq $0x7
400b5b: e9 70 ff ff ff jmpq 400ad0 <.plt>
0000000000400b60 :
400b60: ff 25 da 24 20 00 jmpq *0x2024da(%rip) # 603040
400b66: 68 08 00 00 00 pushq $0x8
400b6b: e9 60 ff ff ff jmpq 400ad0 <.plt>
0000000000400b70 <__libc_start_main@plt>:
400b70: ff 25 d2 24 20 00 jmpq *0x2024d2(%rip) # 603048 <__libc_start_main@GLIBC_2.2.5>
400b76: 68 09 00 00 00 pushq $0x9
400b7b: e9 50 ff ff ff jmpq 400ad0 <.plt>
0000000000400b80 :
400b80: ff 25 ca 24 20 00 jmpq *0x2024ca(%rip) # 603050
400b86: 68 0a 00 00 00 pushq $0xa
400b8b: e9 40 ff ff ff jmpq 400ad0 <.plt>
0000000000400b90 :
400b90: ff 25 c2 24 20 00 jmpq *0x2024c2(%rip) # 603058
400b96: 68 0b 00 00 00 pushq $0xb
400b9b: e9 30 ff ff ff jmpq 400ad0 <.plt>
0000000000400ba0 :
400ba0: ff 25 ba 24 20 00 jmpq *0x2024ba(%rip) # 603060
400ba6: 68 0c 00 00 00 pushq $0xc
400bab: e9 20 ff ff ff jmpq 400ad0 <.plt>
0000000000400bb0...