Detailed explanation of buffer overflow attacks on Windows platform (this time, Windows is really a bully)

I tried bufbomb exercises in Linux yesterday. The result was finally given to ExecShield in Linux. It is precisely because of ExecShield that the traditional buffer overflow has completely failed on the Linux platform.

Today, let's try the Windows platform. Yesterday's log was the note I left during my practice, so it was messy and I did not understand it in many places. This is the preparation after completing the exercises. I will try my best to introduce the steps clearly.

First, in order to compile this code on the Windows platform, we need to introduce a malloc. h header file. Let's take a look at the most importantCodeFragment.

 
/* $ Begin getbuf-C */
 

IntGetbuf ()
 

 
{
 

CharBuf [12];
 

 
Getxs (BUF );
 

Return1;
 

 
}
 

 
VoidTest ()
 

{
 

 
IntVal;
 

Printf ("Type hex string :");
 

 
Val = getbuf ();
 

Printf ("Getbuf returned 0x % x \ n", Val );
 

 
}
 

The getbuf function returns 1 directly. Then, in the test function, the returned Number 1 is placed in the Val variable and output in hexadecimal format. ApparentlyProgramNormally, the output is 0x1. The requirement of the question is to let this program output 0 xdeadbeef. The getbuf function does not check the user input length. By inputting specially constructed strings, you can change the program running process and run arbitrary code.

We add a breakpoint to the getbuf function to disconnect the program. Let's take a look at the production assembly code and the situation in the program stack. Netbeans 7.0.1 + GCC 4.6.1 is used as the development and debugging environment.

After the program is disconnected, you can see the assembly code of the current function as shown in.

You have to open the memory and registers (that is, the registration in the figure) window. (No shortcut keys are available, and only one memory window exists. .) Then we can see the compiled code.

The Code lea-0x14 (% EBP) pointed to by the current row. % eax means to get the start address of the Buf. Let's take a look at the content in the register.

In this case, the EBP value is 0x28ef98, so the start address of the Buf is 0x28ef98-0x14 = 0x28ef84. The string entered by the user is stored in the memory from this place. That is, let the program jump to this address and execute the code we specially constructed.

Now the question is, how can I redirect the program to the address where the buff is located? Let's take a look at the assembly code above. RET is a jump, and the jump address is saved in the stack. In addition, the jump address is larger than the start address of the buff. Therefore, if the data in the buff overflows, the address can be completely overwritten. That is, when this function ends, any code can be executed anywhere.

Now we use the situation in the stack to verify the above statement. The value of the Register shows that the top stack address is 0x28ef70. This is the memory. As shown in.

Each line contains 16 bytes. The red box is the top of the stack, the green box is the bottom of the stack, and the blue box is the memory of the buff. The Green Box is the EBP value stored at the beginning of the function. 0x401476 is the return address of the function. The value of EIP storage in is 0x40144d, which is the address of the current command. It's very close. That's right. The code is already in the same place. The original return address will also be used later. Note it down first.

The buff size is 12 bytes, 16 bytes away from the return address of the function. Therefore, a total of 28 bytes are required. The part of the Green Box is the EBP value, which is used by the function to return, so it must be retained. The return address is changed to the start address of the buff.

So the last 8 bytes of the data we constructed should be: C8 EF 28 00 84 EF 28 00

Now let's write the assembly code and modify the return value of this function. From the compilation code of getbuf, we can see that the return value of the function is stored in eax. So our assembly code should be.

Movl $0 xdeadbeef, % eax

JMP 0 XXXXXXXXX

The first line is well understood. The second line aims to directly jump to the place where getbuf should have returned. This address is 0x401476, but JMP uses a relative offset. These two parameters occupy 10 bytes, so the address of the next instruction is the starting address of the buff plus 10. That is, 0x28ef84 + 0xa = 0x28ef8e.

Therefore, the offset is 0x401476-0x28ef8e = 0x1724e8. So the complete code is

Movl $0 xdeadbeef, % eax

JMP 0x1724e8

Put the two lines of code in a file, such as bomb. s, and then run GCC and objdump as shown to obtain the hexadecimal machine code.

The generated B. S file is as follows.

Disassembly of section. Text:

00000000 <. Text>:

0: B8 EF be Ad de mov $0 xdeadbeef, % eax

5: E9 EE 24 17 00 JMP 1724f8 <. Text + 0x1724f8>

A: 90 NOP

B: 90 NOP

We can see the binary representation of the above two compilations, namely, B8 EF be Ad de E9 EE 24 17 00. This is the first 10 bytes of the buff. Task completed! We have the first 10 and the last 8 bytes, which requires a total of 28 bytes. The 10 bytes in the middle are free.

Therefore, the final attack string we can obtain is:

B8 EF be Ad de E9 EE 24 17 00 00 00 00 00 00 00 00 00 00 00 C8 EF 28 00 84 EF 28 00

Let's run it.

For comparison, the normal execution result should be:

This is the second time to do this, so there is no process like the first one-step tracking. If you are interested, you can add a breakpoint and try again. The above results may not be effective on your machine. If you want to reproduce them, it is likely to be done from the beginning.

Windows 7 + GCC 4.6.1 Environment attack successful. Yesterday, the Ubuntu 11.04 + GCC 4.5.2 attack failed. As early as, Linux used the ExecShield mechanism to launch the original buffer overflow attack. It may be a configuration problem, but it is not reliable to attack successfully by default.