The BUFBOMB Program
The BUFBOMB program reads a string from standard input with a function getbuf having the following C code:
1 int getbuf()
2 {
3 char buf[12];
4 Gets(buf);
5 return 1;
6 }
The function Gets is similar to the standard library function gets—it reads a string from standard input (terminated by ‘\n’ or end-of-file) and stores it (along with a null terminator) at the specified destination. In this code, the destination is an array buf having sufficient space for 12 characters. Neither Gets nor gets has any way to determine whether there is enough space at the destination to storethe entire string. Instead, they simply copy the entire string, possibly overrunning the bounds of the storage allocated at the destination. If the string typed by the user to getbuf is no more than 11 characters long, it is clear that getbuf will return 1, as shown by the following execution example:
unix> ./bufbomb
Type string: howdy doody
Dud: getbuf returned 0x1
Typically an error occurs if we type a longer string:
unix> ./bufbomb
Type string: This string is too long
Ouch!: You caused a segmentation fault!
As the error message indicates, overrunning the buffer typically causes the program state to be corrupted, leading to a memory access error. Your task is to be more clever with the strings you feed BUFBOMB so that it does more interesting things. These are called exploit strings.
BUFBOMB takes several different command line arguments:
-t NAME: Operate the bomb for the indicated name. You should always provide this argument for several reasons:
� It is required to log your successful attacks.� BUFBOMB determines the cookie you will be using based on your name, just as does the program MAKECOOKIE. � We have built features into BUFBOMB so that some of the key stack addresses you will need to use depend on your cookie.
-h: Print list of possible command line arguments
-n: Operate in “Nitro” mode, as is used in Level 4 below.
Your exploit strings will typically contain byte values that do not correspond to the ASCII values for printing characters. The program SENDSTRING can help you generate theseraw strings. It takes as input a hexformatted string. In this format, each byte value is represented by two hex digits. For example, the string “012345” could be entered in hex format as “30 31 32 33 34 35.” (Recall that the ASCII code fordecimal digit is 0x3x). Non-hex digit characters are ignored, including the blanks in the example shown.If you generate a hex-formatted exploit string in the file exploit.txt, you can apply the raw string to BUFBOMB in several different ways:
1. You can set up a series of pipes to pass the string through SENDSTRING.
unix> cat exploit.txt | ./sendstring | ./bufbomb -t bovik
2. You can store the raw string in a file and use I/O redirection to supply it to BUFBOMB:
unix> ./sendstring < exploit.txt > exploit-raw.txt
unix> ./bufbomb -t bovik < exploit-raw.txt
This approach can also be used when running BUFBOMB from within GDB:
unix> gdb bufbomb
(gdb) run -t bovik < exploit-raw.txt
One important point: your exploit string must not contain byte value 0x0A at any intermediate position, since this is the ASCII code for newline (‘\n’). When Gets encounters this byte, it will assume you intended to terminate the string. SENDSTRING will warn you if it encounters this byte value.When you correctly solve one of the levels, BUFBOMB will automatically send an email notification to our grading server. The server will test your exploit string to make sure it really works, and it will update the lab web page indicating that your name (listed by cookie) has completed this level.Unlike the bomb lab, there is no penalty for making mistakes in this lab. Feel free to fire away at BUFBOMB with any string you like.
Level 0: Candle (10 pts)
The function getbuf is called within BUFBOMB by a function test having the following C code:
1 void test()
2 {
3 int val;
4 volatile int local = 0xdeadbeef;
5 entry_check(3); /* Make sure entered this function properly */
6 val = getbuf();
7 /* Check for corrupted stack */
8 if (local != 0xdeadbeef) {
9 printf("Sabotaged!: the stack has been corrupted\n");
10 }
11 else if (val == cookie) {
12 printf("Boom!: getbuf returned 0x%x\n", val);
13 validate(3);
14 }
15 else {
16 printf("Dud: getbuf returned 0x%x\n", val);
17 }
18 }
When getbuf executes its return statement (line 5 of getbuf), the program ordinarily resumes execution within function test (at line 8 of this function). Within the file bufbomb, there is a function smoke having the following C code:
void smoke()
{
entry_check(0); /* Make sure entered this function properly */
printf("Smoke!: You called smoke()\n");
validate(0);
exit(0);
}
Your task is to get BUFBOMB to execute the code for smoke when getbuf executes its return statement, rather than returning to test. You can do this by supplying an exploit string that overwrites the stored return pointer in the stack frame for getbuf with the address of the first instruction in smoke. Note that your exploit string may also corrupt other parts of the stack state, but this will not cause a problem, since smoke causes the program to exit directly.
Some Advice:
All the information you need to devise your exploit string for this level can be determined by examining a diassembled version of BUFBOMB.
Be careful about byte ordering.
You might want to use GDB to step the program through the last few instructions of getbuf to make sure it is doing the right thing.
The placement of buf within the stack frame for getbuf depends on which version of GCC was used to compile bufbomb. You will need to pad the beginning of your exploit string with the proper number of bytes to overwrite the return pointer. The values of these bytes can be arbitrary.
可以看到：Your task is to get BUFBOMB to execute the code for smoke when getbuf executes its return statement, rather than returning to test.
任务是把getbuf函数返回的地址改为smoke的地址。
getbuf函数的汇编代码：
0x08048ad0 <+0>: push