辅导 CISC221、Java/Python设计编程讲解
CISC221: The Bomb Lab
This lab serves as a newly added experiential learning module within CISC221, offering
hands-on exposure to binary files and assembly code debugging at the instruction set
level of the x86 processor. Understanding debugging at this level is crucial for grasping
computer architecture and gaining reverse engineering proficiency. Such skills are vital
to fields like code optimization, embedded systems, and cybersecurity. Furthermore, it
fosters essential debugging skills applicable across diverse programming domains. By
emphasizing the lab's hands-on approach, its challenging yet rewarding nature, and the
career prospects it offers, students are motivated to engage actively, deepening their
comprehension of low-level computing and laying a foundation for advanced learning in
related subjects.
Good luck, and welcome to the bomb squad!
I. Description
This lab is for a digital binary bomb, with the schematic shown below.
2
As illustrated in the diagram, the binary bomb is composed of four distinct phases, each
requiring a specific input string, set of numbers, or combination thereof for successful
defusal. Correctly entering the required input disarms the phase, allowing the bomb to
advance to the next stage. Failure to provide accurate input triggers an explosion,
signaled by the display of "BOOM!!!" before termination. The entire bomb is considered
defused only when all four phases have been disarmed. Each student will receive their
own bomb to defuse as part of this mini-project. Your objective is to successfully
disarm your assigned bomb before the designated due date.
The executable binary file is the bomb is called “bomb_lab” and is located at the
CASLAB machines in the following directory linux>cas/course/cisc221. To access the
bomb_lab file, you should first go up to root directory by typing (cd ..) twice, then
navigate to the following folder linux>cas/course/cisc221 as shown below
You can then run the bomb by (./bomb_lab) or debug the bomb by (gdb bomb_lab).
II. Overview
The Bomb consists of four phases (sub-problems):
1) Phase 1: Requires a textual input, for example, "Hello world."
2) Phase 2: Requires an array of six numbers, for example, 12 34 81 23 10 22.
3) Phase 3: Requires three inputs in the order of integer, character, and integer, with
the first integer falling within the range of 0 to 7, for example, 3 Z 1.
4) Phase 4: Requires a textual input, for example, "Goodbye!"
You should work on the gdb debugger to trace clues, disassemble functions, investigate
the contents of the registers/stack to find the defusal passcodes for each phase. The
most important registers that you should keep track of their content are
• %rax: return value
• %rsp: stack pointer
• %rdi: 1st argument
• %rsi: 2nd argument
• %rdx: 3rd argument
• %rbp: base pointer
3
Please note that registers are typed in the gdb debugger preceded by a dollar sign
($rax) not a percentage sign. For instance to check the data in %rax, you type (info
registers $rax)
To help you find some clues, Table 1 highlights the most important labels for each phase
and Table 2 lists all the debugging commands that you will need to defuse your bomb
Table 1. most important labels
Table 2. gdb common commands
command desc example
run runs the loaded executable program run
break
[func_name]
breaks once you call a specific function break phase_1
break *
mem_loc
breaks when you execute the instruction at
a certain address
break * 0x0000555555555ef9
info
breakpoints
displays information about all breakpoints
currently set
info breakpoints
deletel
breakpoints
delete a specific breakpoint delete breakpoints 10 //delete
breakpoint number 10
continue continue to the next breakpoint continue
stepi steps through a single x86 instruction.
Steps into calls.
stepi
nexti steps through a single x86 instruction.
Steps over calls.
nexti
Phase Important functions/labels
Phase_1 ● strings_not_equal
● string_length
Phase_2 ● generatedValues
Phase_3 -
Phase_4 ● generateRandomChars
● validateOccurrence
4
disassemble views assembly code while debugging disassemble or disassemble
“label”
info registers prints the names and values of all
registers
info registers
info register
$reg
prints the name and value for specific
register
info register $rax
set $reg = val assign value to a certain register set $rdi = 0x80
x command prints values stored in a certain address
with a specific format
1) x/s 140737488227040
#display values in string format
2) x/d 140737488341111
#display values in decimal
format
III. Goal & Guidelines
The ultimate goal for each phase is to determine the registers containing the correct
input by navigating through “stepi” or over “nexti” the assembly code, inspecting the
values of the registers using "info register $reg" and then updating the registers that
hold your input with the correct value through "set $reg = val" to defuse the phase.
There are several tips for deactivating the bomb:
● Once on the correct directory (cas/course/cisc221), you can begin debugging
by using the gdb command: gdb bomb_lab.
● Set breakpoints on all phases, i.e., break phase_1, break phase_2, break
phase_3, and break phase_4., you can also add more breakpoints on crucial
parts.
5
● Start the bomb program by prompting the run command and enter you student
ID.
Phase#1
Desc: The input text will be compared against a predefined string.
● The program anticipates a string input for the first phase. It is advisable to
employ a concise and memorable text, e.g., test, similar to the example below.
● It should hit the phase_1 breakpoint (added previously), disassemble
command can be utilized to show the assembly code for the current block. The
small arrow in the left of the screen (see below) indicates the command at which
the program is executing next.
6
● If you defuse phase_1 successfully, you will get “Phase 1 defused. How about
the next one?”
● Otherwise, the bomb will explode and return
Phase#2
Desc: The input is an array of six numbers with a space separator, for example, 12 34
81 23 10 22, that will be compared against a predefined array.
● The program anticipates an input of 6 numbers for the second phase. It is
advisable to employ concise and memorable integers, similar to the example
below.
● If you defuse phase_2 successfully, you will get “Halfway there!”
● Otherwise, the bomb will explode and return
Phase#3
Desc: The input is three values in the following order, separated by spaces: an integer
(should be within the range of 0 to 7), a character, and another integer, e.g., 3 z 44.
● The program anticipates an input of three values for the third phase. It is
advisable to employ concise and memorable values, similar to the example
below.
● If you defuse phase_3 successfully, you will get “That's number 3. Keep
going!”
● Otherwise, the bomb will explode and return
Phase#4
Desc: In the final phase, an input of text is anticipated, and the provided text should
satisfy the occurrence of some random characters.
7
For instance, If the last phase generates random characters such as {l:3, x: 0, d: 1},
your input string should resemble something like "Hello world!"
Considering that the phase 4 characters are limited to only three random characters.
● The program anticipates an input of textual form (e.g., Have a Nice Day!). It is
advisable to employ concise and memorable text, similar to the example below.
● If you defuse phase_4 successfully, you will get “Congratulations! You've
defused the bomb!”
● Otherwise, the bomb will explode and return
IV. Hints
1. The input for each phase is entirely deterministic for every student, based on
the ID
2. Ensure constant attention and focus on the segment of code preceding the
explode_bomb function. In case you miss the correct input for any phase, you
can bypass the explosion by manipulating the flags register
https://en.wikipedia.org/wiki/FLAGS_register and setting or resetting the zero flag
based on the phase condition. It implies that there is consistently a condition or
validation check before the execution of the explode_bomb function.
E.g.,
The cmp instruction subtracts the value in the %edx register from the value in
the %eax register, but it doesn't store the result. It only updates the flags
register based on the outcome of the subtraction.
If the values in %eax and %edx are equal, It will result in zero, setting the Zero
Flag (ZF) in the flags register. In this case, the je instruction will jump to the
specified label or location. But, If the values in %eax and %edx are not equal,
resulting in ZF being set to zero, then the explode_bomb will be called.
3. To inspect the content stored at a particular memory location, you can employ the
x command, such as x/s for strings or x/d for integers,
8
E.g., cmpl $0x5,-0x30(%rbp)
This command compares the immediate value 5 with the value stored in memory
at an address calculated as 0x30 bytes before the address stored in the base
pointer %rbp. So, to get the value stored in this location:
I. gets $rbp value through info register command
II. subtracts 0x30 from 0x7fffb96afc90 = 0x7fffb96afc60. (you can also type
the address directly as 0x7fffb96afc90-0x30 and let the computer do the
computation for you)
III. checks memory location “0x7fffb96afc60” value via x/d as it translates it to
integers
V. Deliverables
Upload only your answers “correct inputs” for all defused phases. It is recommended to
use computer-based tools like “MS Word” instead of handwritten notes to minimize
readability mistakes.
VI. Acknowledgement
Special thanks for Hesham Elabd for importing and customizing this lab to CISC221 and
for Doug Martin for assistance in implementing and hosting the lab on Caslab machines.
Good luck