How to read Gary nebbet's classic self-deletion code

How to read Gary nebbet's classic self-deletion code

Liond8 essay 10415468-3-14 QQ:

The following is the classic source code of Gary nebbet.

# Include "windows. H"

Void main (INT argc, char * argv [])

{

Hmodule module = getmodulehandle (0 );

Char Buf [max_path];

Getmodulefilename (module, Buf, sizeof (BUF ));

Closehandle (handle) 4 );

_ ASM

{

Lea eax, Buf

Push 0

Push 0

Push eax

Push exitprocess

Push Module

Push deletefile

Push unmapviewoffile

RET

}

}

The first three lines of code are not mentioned. Start with closehandle (handle) 4.

I found a lot of information on the Internet and found that handle4 is the OS hard code. closehandle (handle) 4) is used to close the file handle.

To delete a file, you must delete the operator that opens the file. If the operator opens the file, the operation fails. It has been disabled.

The following describes the content in _ ASM.

After a series of pushes. The contents in the stack form this form.

The following are the test results under win2000 SP3 vc6.0.

Value stack address in the ESP Stack

0012fe28 0 0012fe28

0012fe24 0 0012fe24

0012fe20 0012fe78 0012fe20 file full path

0012fe1c 77e7cf5c 0012fe1c exitprocess entry

0012fe18 00040000 0012fe18 Module Value

0012fe14 77e6e3a6 0012fe14 deletefile entry

0012fe10 77e6d2bd 0012fe10 unmapviewoffile

Next we will know that RET is called when the function returns. Its function is to retrieve the return address of the function from the stack pointed to by the current ESP. For the above Code, the current ESP = 0012fe10, now retrieve the value of 77e6d2bd in the stack address 0012fe10, and then jump to 77e6d2bd, which goes to the function entry of unmapviewoffile. Why is deletefile behind 0012fe10? Why does the parameter module reach fe18.

Let's write a code first.

Void main ()

{

Unmapviewoffile (null );

}

Then, disassemble the Assembly command to see how it works. As follows:

6: unmapviewoffile (null );

00401028 mov ESI, ESP

0040102a push 0

0040102c call dword ptr [_ imp _ unmapviewoffile @ 4 (001_1ac)]

00401032 cmp esi, ESP

First, the parameter 0 is input to the stack, and then we catch [_ imp _ unmapviewoffile @ 4 (001_1ac)]

. Let's see what the current stack looks like. As follows:

Intra-stack address intra-stack Value

0012ff30 0 Parameter

0012ff2c 00401032 return address

00401032 is the call function system that helped us into the stack. We did not manually add it. However, when RET is transferred to the unmapviewoffile entry, there is no inbound stack with the returned address. That is to say, push deletefile becomes the return address of the unmapviewoffile function. The push module above is the parameter of unmapviewoffile. Think about it. Okay, when the unmapviewoffile function is called, The EIP has now reached the 77e6e3a6 and deletefile entries.

But where is ESP? The value in the 0012fe1c stack should be 77e7cf5c.

After deletefile is returned, the program should jump to 77e7cf5c, that is, the exitprocess entry.

Then (0012fe1c + 4) is the deletefile parameter. That is, 0012fe78. Push eax.

When deletefile is returned, the program jumps to the 77e7cf5c and exitprocess entries. The current ESP = 0012fe24. The same principle

Push 0. This is the exitprocess parameter.

Push 0. This is the return address of exitprocess.

Because exitprocess has not returned the process and ends, the return address of exitprocess is 0, and no memory error will occur.

References:

Gary nebbet's classic source code

The above is my personal opinion. I hope it will help you. If you have any comments, you are welcome to discuss them with me.

==================================

Www.rohu.com

Network security team of humeng