After the classic self-delete code of Gary Nebbet, the experience liond8 essay 2004-3-14 QQ: 10415468 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 3 rows of the code do not say. Start from CloseHandle ((Handle 4). Find a lot of information on the Internet to find that Handle4 is the hardcode of the OS, and CloseHandle ((Handle) is used to close the file sheder. To delete a file, you must delete the sheder of the file, if there is a file sheder to open will fail. It has been closed above. The following focus on the contents of __asm {}. After a series of PUSHs. The content inside the stack forms this form. The following is the test results under Win2000 SP3 VC6.0. 0012FE28 0 0012FE28 0012FE24 0 value in the value of the stack in the ESP stack address 0012FE24 0012FE20 0012FE78 0012FE20 full file path 0012FE1C 77E7CF5C 0012FE1C ExitProcess entrance 0012FE18 00040000 0012FE18 module of 0012FE14 77E6E3A6 0012FE14 DeleteFile entrance 0012FE10 77E6D2BD 0012FE10 UnmapViewOfFile we know next to RET RET is a function Call when returned. Its function is to remove the return address of the function from the current ESP pointed to by the current ESP. For the above code, the current ESP = 0012FE10 is now taken out of the value 77E6D2BD in the stack address 0012FE10, then jumps to 77E6D2BD, which is the function portal of UnmapViewOffile. Why is the DELETEFILE FE10 after 0012FE10? Why did you go to 0012FE18? We will be resolved immediately. Let's write a code void main () {unmapViewoffile (NULL); As follows: 6: UnmapViewOfFile (NULL); 00401028 mov esi, esp 0040102A push 0 0040102C call dword ptr [__imp__UnmapViewOfFile @ 4 (004241ac)] 00401032 cmp esi, esp first parameter 0 is pushed onto the stack, and then we catch [__imp__UnmapViewOfFile @ 4 ( 004241ac)]. See what the stack is now like. As follows: Stack address stack internal value 0012FF30 0 Parameters 0012FF2C 00401032 Return address 00401032 is a Call function system to help us into the stack. We don't have manually added. However, for Ret we have not returned the address when transferring to the unmapViewoffile entry, that is, the Push deletefile is a return address of the UNMAPVIEWOFFILE function. Then the Push Module is the parameter of UnmapViewOffile. There is a little cumbersome to think about it.
Ok, when our UnmapViewOffile function is called, now EIP has reached 77E6E3A6, and the deletefile entry. But where is ESP now? The value of 77E7CF5C should be in the 0012FE1C stack, the same reason is in the deletefile, the program should be jumped to 77E7CF5C is also the entrance of EXITPROCESS. So (0012FE1C 4) is the parameter of deletefile. That is, 0012FE78. Push eax. When our deletefile returns, the program jumps to the entrance of 77E7CF5C, EXITPROCESS. The current ESP = 0012FE24. The same truth push 0 This is the parameter of EXITPROCESS PUSH 0 This is the return address of EXITPROCESS. Because EXITPROCESS has not returned the process, the return address of EXITPROCESS is 0 or memory errors. Reference: The classic source code of Gary Nebbet is my personal interest to help you. If there is any opinion, a better insight is welcome to discuss it. ===================== www.rohu.com Tiger League Network Security Group
