Six important experimental lab3 of Csapp

Csapp && LAB3

Level2 & Leve3 not finished, to be updated! : )

In this lab, you'll gain firsthand experience with one of the methods commonly used to exploit security weaknesses in op Erating systems and network servers. Our purpose are to help you learn about the runtime operation of programs and to understand the nature of this form of SECU Rity weakness So, can avoid it when you write system code. We don't condone the use of these or any other form of attack to gain unauthorized access to any system resources. There is criminal statutes governing such activities.

Experimental instructions:

http://download.csdn.net/detail/u011368821/7920313

Experimental materials:

http://download.csdn.net/detail/u011368821/7920335

The Exploits

There is three functions that the must exploit for this lab. The exploits increase in difficulty. For those of your looking for a challenge, there are a fourth function you can exploit for extra credits.

Level 0:candle

When Getbuf () executes it return statement, the program ordinarily resumes execution within function test (). Within the file Bufbomb, there is a function smoke ():

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 () while GETBUF () executes its return statement, rather than R Eturning to test ().You can do this by supplying a exploit string that overwrites the stored return pointer in the stack frame for getbuf () W ith the address of the first instruction in smoke. Note that your exploit string could also corrupt other parts of the stack state, but this would not cause a problem, because Smoke () causes the program to exit directly.

Advice:

• All the information-need to devise your exploit string for this level can be determined by examining a disassembled ve Rsion 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's doing the R Ight thing.

• The placement of buf within the stack frame for getbuf () depends on which version of GCC were used to compile bufbomb. You'll 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.

• Check the line endings if your smoke.txt with Hexdump-c smoke.txt.

I got a big X, tuned for a few days to figure out how to use "Overflow buffer attack"

Use to construct an input text to record the character (overflow) of the data

I'm here.

Exploit.txt

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A. 10 40 00 00 00 00 00 (C0), Geneva, XX

There must be no line break symbol (if there is no problem, go to the generated file, use Vim to open the editor and then remove it)

Here altogether 0x30byte+8byte+8byte = = 0x40byte

The first 0x30byte is due to the 64bits of machine byte alignment resulting in an array of 36byte being extended to 0x30byte!

The latter 8byte is the value of the previous push%RBP register

The final 8byte is the return address, where we want to "attack"!

Consider the size end of the machine.

The address of smoke is

xx, XX, XX, C0

The writing should be

C0 10 40 00 00 00 00 00

This is where the generated data is recorded in the Exploit.byte.

Then the file as input is the ~:)

Level 1:sparkler

Problem Solving Basics:

/* $begin fizz-c */void Fizz (int arg1, char arg2, long arg3, char* Arg4, short arg5, short arg6, unsigned long long Val) { C0/>entry_check (1);  /* Make sure entered this function properly *  /if (val = = cookie) {printf ("fizz!: You called Fizz (0X%LLX) \ n", Val); Val Idate (1);  } else {printf ("misfire:you called Fizz (0X%LLX) \ n", Val);  }  Exit (0);} /* $end Fizz-c */

Similar to Level 0, your task was to get Bufbomb to execute the code for fizz () rather than returning to test. In this case, however, the must make it appear to fizz as if you have passed your cookies as its argument. You can do this by encoding your cookies in the appropriate place within your exploit string.

Advice:

note in X86--64, the first six arguments is passed into registers an D Additional arguments is passed through  the stack. Your exploit code needs to write to the appropriate place within the stack.

you can use GDB-get the information you need to construct your exploit string. Set a breakpoint within getbuf () and  run to this breakpoint. Determine parameters such as the address of Global_value and the location of the buffer.

After breaking the original test () Call GETBUF push return address, jump to fizz, at this time see the title request is to put the cookie as fizz parameter input, according to the disassembly information, we can see here

CMP 0x201296 (%rip)%rsi

If equal, it jumps to 0x40109f and then exits smoothly.

Since the value of the previous RSP register has not been compromised, we push back if the value of "attack RSP" causes 0x10 (%RSP) to point to the cookie

Then you can get out of it!

Since the last Leaveq will be saved%RBP re-assigned value to%RSP, so

We can instead attack the saved%RBP to realize the indirect change%RSP

CMP 0x201296 (%rip)%rsi

Hold on to this sentence, here it is 0x201296 (%rip) comparison of values at addresses and values of%rsi

0x201296 (%rip)

Is the address of the cookie, and here%rsi is the address of the parameter Val.

CMP put the value at the cookie address! Note is the value at the cookie address, and the%rsi comparison

If you want to wait to return correctly, you will always see missfire!.

Here's my solution.

First look at the value at the cookie address and enter

Exploit_for_level1.txt

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The xx----------------XX----------------XX, XX, XX, 39

The attentive person will find that I have filled out more than 8byte of space on the return address before filling in our answers.

This is because there is something on the return addres that I do not know here, but what I do here is tested and calculated based on the results of the disassembly.

We can discuss the changes in the register before jumping to fizz:) [email protected]

Then take the exploit_for_level1.byte as input.

Level 2:firecracker 

                a much more sophisticated fo RM of buffer attack involves supplying a string that encodes actual machine instructions. The exploit string then overwrites the return pointer with the starting address of these instructions. When the calling function (In this case GETBUF) executes it ret instruction, the program would start executing the in Structions on the stack rather than returning. With this form of attack, you can get the program to do almost anything. The code you place on the stack is called the exploit code. This style of attack are tricky, though, because you must get machine code onto the stack and set the Return pointer t o The start of this code.

For Level 2, you'll need to run your exploit within GDB for it to succeed. (Attu have special memory protection that prevents execution of memory locations in the stack. Since GDB works a little differently, it'll allow the exploit to succeed.)

Similar to levels 0 and 1, your task was to get Bufbomb to execute the code for Bang () rather than returning to test (). Before this, however, the must set global variable Global_value to your cookie. Your exploit code should set Global_value, push the address of Bang () on the stack, and then execute a RETQ instruction to Cause a jump to the code for Bang ().

Advice:
Determining the byte encoding of instruction sequences by hand are tedious and prone to errors. You can-do-it-all-of-the-writing an assembly code file containing the instructions and data-want to put On the stack. Assemble this file with the GCC and disassemble it with Objdump. You should is able to get the exact byte sequence so you'll type at the prompt. (A Brief example of how to does this are included in the generating Byte Codes section above.)

Keep in mind this your exploit string depends on your machine, your compiler, and even your cookie. Make sure your exploit string works on Attu or your VMS, and make sure your include your uwnetid on the command line to BUFB Omb.

Watch your use of the address modes when writing assembly code. Note that movq $0x4,%rax moves the value
0x0000000000000004 into register%rax; Whereas Movq 0x4,%rax moves the value at memory location
0x0000000000000004 into%rax. Because that memory location is usually undefined, the second instruction would
Cause a segmentation fault!

Do not attempt to use either a jmp or a call instruction to jump to the code for Bang (). These instructions use pc-relative addressing, which are very tricky to set up correctly. Instead, push an address in the stack and use the RETQ instruction.

Here I jump to the buffer address when there is a problem ... segment fault

My attempt:

The first observation is that the CMP is equal and will jump and end safely.

The two objects that are compared are the value that 0x602320 points to, and%rsi is global_value.

The value of the cookie is fixed when we enter it. What can be changed here is the value of the global_value (i.e. the 0x602308 place).

The common practice is uncertain.

You have to write an attack code for yourself here--the Assembly form

Then, in this code, the value of the cookie is assigned to Global_value, which is half done.

This code is then gcc-c compiled into obj. Then objdump to see the corresponding machine code.

mov 0x602330,%rax on the corresponding machine code is

8b 04 25 20 23 60

No explanation.

It is worth mentioning that there are

Pushq $0x401020

and RETQ operation (explanation of use later)

And write these machine codes into buffer!

Just imagine if the reture address I'm covering only wants the buffer header, then these instructions will be executed at the buffer.

And then when these instructions are executed to the end,

Pushq $0x401020

Retq

This step will jump to 0x401020 (Bang function header). Execute the Bang function, we have modified the Global_value in the attack code, then the structure of CMP is 0,je jump, the program security end.

This is only my theoretical analysis, I encountered the problem is here to jump to the buffer head will appear segment fault ...

Passing master can advise:)

Six important experimental lab3 of Csapp