代写CISC221、Java/Python设计编程代做

日期：2024-03-12 08:49

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