程序的自删除早已经不是什么新鲜的话题了，对于各位大虾来说是更是比较容易的事情，但想想自己刚学时遇到的种种错误，我觉得有必要把自己所知道的各种方法总结一下，希望对新手的学习能够有所帮助。程序的自删除广泛用于反安装程序最后的自删除（环保呀！），当然更多见于木马、病毒首次安装的自动销毁^*^，至于用于何种用途就看你自己啦！经典自删除说到程序的自删除就不能不说由 Gary Nebbett 等大虾所写的代码，经典之作呀！代码采用C语言内嵌汇编asm:在Win9x下只要先对exe本身句柄执行FreeLibrary操作即可解除exe IMAGE在内存的映射，随后就可以通过调用DeleteFile来删除自身文件。Win9x下的代码如下[selfkill-9x.c]：#include "windows.h"int main(int argc, char *argv[]){char buf[MAX_PATH];HMODULE module;module = GetModuleHandle(0);GetModuleFileName(module, buf, MAX_PATH);__asm {lea eax, bufpush 0push 0push eaxpush ExitProcesspush modulepush DeleteFilepush FreeLibraryret}return 0;}
在WinNT/2K下则需要先调用CloseHandle关闭exe文件本身对应的IMAGE的句柄HANDLE[硬编码为4]，然后调用UnmapViewOfFile解除了另外一个对应IMAGE的HANDLE,并且解除了程序本身在内存的映射对象，最后就可以用DeleteFile删除自身啦！（注意：本方法不适用于WinXP!）
WinNT/2K下的代码如下[selfkill-nt.c]：#include "windows.h"int main(int argc, char *argv[]){char buf[MAX_PATH];HMODULE module;module = GetModuleHandle(0);GetModuleFileName(module, buf, MAX_PATH);CloseHandle((HANDLE)4);__asm {lea eax, bufpush 0push 0push eaxpush ExitProcesspush modulepush DeleteFilepush UnmapViewOfFileret}return 0;}
把上面用于Win9x及WinNT/2K下的代码综合起来，即把两种平台用到的API代码全部执行一遍，虽然在一种平台上可能会有几个API运行失败,有几个API会运行成功，但最后的结果exe程序文件在退出前就删除了自身！
Win9x和WinNT/2K下的代码如下[selfkill-9x+nt.c]：#include "windows.h"int main(int argc, char *argv[]){char buf[MAX_PATH];HMODULE module;module = GetModuleHandle(0);GetModuleFileName(module, buf, MAX_PATH);CloseHandle((HANDLE)4);
__asm {lea eax, bufpush 0push 0push eaxpush ExitProcesspush modulepush DeleteFilepush modulepush UnmapViewOfFilepush FreeLibraryret}return 0;}
因为我自己在学习Win32下的汇编[MASM32]，所以重新用汇编写了一遍，但结果却发现每次都执行失败，显示如图一的错误，
＝＝＝＝＝＝＝＝＝＝＝ 在此插入图一 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝
通过反汇编比较发现原来由于MASM32编译器对API调用的编码和C编译器的不同，导致使用FreeLibrary或UnmapViewOfFile解除程序在内存的映射后，调用DeleteFile时又引用IMAGE映射地址内的代码[JMP DeleteFile]，导致读内存执行错误。错误分析普通程序进行API调用时，编译器会将一个API调用语句编译为几个参数压栈指令后跟一条间接调用语句（这是指Microsoft编译器，Borland编译器使用JMP DWORD PTR [XXXXXXXXh]）形式如下：
push arg1push arg2……call dword ptr[XXXXXXXXh]地址XXXXXXXXh在程序映像的导入（Import Section）段中，当程序被加载运行时，由装入器负责向里面添入API函数的地址；
一：用MASM32编译的程序其API函数调用格式为：Call capi;………………capi:jmp dword ptr[XXXXXXXX];XXXXXXXX中存放着所调用的API函数真正地址
其中jmp dword ptr[XXXXXXXX]指令是由“编译器”在程序所有代码的后面自动加上的这样调用的好处是当多次调用同一API时可以减少代码体积,〈呵呵:)个人观点!〉
二：用C编译的程序其API函数调用格式为:Call dword ptr [XXXXXXXX];XXXXXXXX地址中存放着所调用的API函数真正地址
正是由于上面API函数调用格式不同导致用MASM32编译的程序自删除失败，因为当调用UnmapViewOfFile后其中代码段的jmp dword ptr[XXXXXXXX]指令所处的代码节变成了不可读，后面的DeleteFile这个API的执行就会失败，程序出错！所以我们如果用MASM32编译这种自删除程序时，应该把push DeleteFile指令改为：
mov eax,DeleteFile;取jmp dword ptr[XXXXXXXX]指令地址，机器码FF25XXXXXXXXinc eaxinc eaxmov eax,dword ptr[eax]push dword ptr[eax]这样才是把DeleteFile的真正地址放入堆栈，当然用动态获取API也行，但不如这样代码少，下面是我改好的MASM32代码[selfkill9x-nt.asm]：
.386.model flat, stdcalloption casemap :none
include windows.incinclude kernel32.incincludelib kernel32.lib.codestart:mov ebp, espinvoke GetModuleHandle,NULL ;获取自身模块句柄mov ebx,eaxinvoke GetModuleFileName,ebx,ebp,MAX_PATH ;获取自身路径invoke CloseHandle,4 ;关闭exe文件本身对应的IMAGE的句柄[硬编码为4]push 0;ExitProcess的参数push 0push ebp;DeleteFile的参数mov eax,ExitProcessinc eaxinc eaxmov eax,dword ptr[eax]push dword ptr[eax];pushExitProcess
push ebx;UnmapViewOfFile的参数mov eax,DeleteFileinc eaxinc eaxmov eax,dword ptr[eax]push dword ptr[eax];pushDeleteFilepush ebx;FreeLibrary的参数mov eax,UnmapViewOfFileinc eaxinc eaxmov eax,dword ptr[eax]push dword ptr[eax];pushUnmapViewOfFilepush FreeLibrary;FreeLibrary不用改因为调用它时代码节还可以读retendstart
远程线程插入自删除远程线程插入如今广泛用于木马和病毒的自我保护及隐蔽自身，同样我们也可以把它用在程序的自删除。
其中所插入的删除自身的远程线程的代码如下:KREMOTE_CODE_START equ this bytecall @F@@:pop ebxsub ebx,offset @B ;线程代码重定位push 500call [ebx+_lpselfkillSleep] ;休眠0.5秒lea eax,[ebx+offset _selfkillselfname]push eaxcall [ebx+_lpselfkillDeleteFile] ;删除程序文件ret
_lpselfkillSleep dd?; Sleep的硬编码地址_lpselfkillDeleteFile dd?; DeleteFile的硬编码地址_selfkillselfname: ; 程序自身文件名，主程序内生成写入
KREMOTE_CODE_END equ this byteKREMOTE_CODE_LENGTH equ offset KREMOTE_CODE_END - offset KREMOTE_CODE_START
主程序中使用GetProcAddress来获取Sleep和DeleteFile的硬编码地址后写入上面，并用GetModuleFileName获取自身路径存入_selfkillselfname处，供远程线程使用。
Win9x下的用于在KERNEL32.DLL中建立远程线程代码如下：Kernel32 db"KERNEL32.DLL",0SzCreateKernelThread db 'CreateKernelThread',0_RemoteCode9Xproc@_RmCodeStart,@_RmCodeLenlocal lpThreadIDlocal lpCreateKernelThreadlocal hProcessinvoke GetModuleHandle,addr Kernel32mov ebx,eaxinvoke GetProcAddress,ebx,offset szCreateKernelThreadmov lpCreateKernelThread,eax ;取得CreateKernelThread的地址; _findProcess是一个根据名称查找进程PID的函数过程，详细代码见[selfkill-R9x.asm]invoke _findProcess,offset Kernel32 ;查找KERNEL32.DLL进程.if eaxinvoke OpenProcess,PROCESS_ALL_ACCESS,TRUE,eaxmov hProcess,eaxinvoke WriteProcessMemory,eax,80001100h,@_RmCodeStart,@_RmCodeLen,NULL.if eaxxor eax,eaxlea ecx,lpThreadIDpush ecxpush eaxpush eaxpush 80001100hpush eaxpush eaxcall lpCreateKernelThread ;创建KERNEL32.DLL线程.endifinvokeCloseHandle,hProcess.endifret_RemoteCode9Xendp函数的调用格式为：push KREMOTE_CODE_LENGTH+MAX_PATH ;代码长度push offset REMOTE_CODE ;代码地址call _RemoteCode9X[注意：这里不使用invoke _RemoteCode9X，offset REMOTE_CODE，KREMOTE_CODE_LENGTH+MAX_PATH来调用函数，因为我测试时发现invoke调用会使KREMOTE_CODE_LENGTH+MAX_PATH的值变大！也许是编译器的一个BUG？]
在_RemoteCode9X中首先使用GetProcAddress获得CreateKernelThread这个用于在KERNEL32.DLL中建立远程线程的API地址[CreateKernelThread的参数和CreateThread类似，但有一点不同为lpStartAddress参数（线程开始执行的地址）处于KERNEL32.DLL进程中！]，然后调用_findProcess过程查找KERNEL32.DLL进程的PID，随后以全部的权限打开此进程，并用WriteProcessMemory把代码写入到KERNEL32.DLL进程80001100h开始的空间内[之所以选择80001100h是因为此处有大段可能未使用得内存00h，这样就不用像中国黑客那样进入0环啦！]，最后调用CreateKernelThread创建KERNEL32.DLL线程来删除自身！（Win9x下的远程线程插入自删除完整代码见selfkill-R9x.asm!）
Win2K/XP下的用于建立远程线程的代码如下：;用于在explorer.exe进程中插入远程线程szDesktopClassdb'Progman',0szDesktopWindowdb'Program Manager',0_RemoteCode2KXPproc @_RmCodeStart,@_RmCodeLenlocal @hRmCodeMemorylocal @hselfkillProcessIDlocal @hselfkillProcess;查找文件管理器窗口并获取进程ID，然后打开进程invoke FindWindow,addr szDesktopClass , addr szDesktopWindowlea ecx , @hselfkillProcessIDinvoke GetWindowThreadProcessId , eax,ecxinvoke OpenProcess, PROCESS_CREATE_THREAD or PROCESS_VM_OPERATION or PROCESS_VM_WRITE , FALSE , @hselfkillProcessIDmov @hselfkillProcess , eax;在进程中分配空间并将写入远程代码，建立远程线程invoke VirtualAllocEx , @hselfkillProcess , NULL , @_RmCodeLen , MEM_COMMIT , PAGE_EXECUTE_READWRITE.ifeaxmov@hRmCodeMemory,eaxinvoke WriteProcessMemory,@hselfkillProcess,eax,@_RmCodeStart,@_RmCodeLen,NULLxor eax,eaxinvokeCreateRemoteThread,@hselfkillProcess,eax,eax,@hRmCodeMemory,eax,eax,eaxinvokeCloseHandle,eax.endifinvokeCloseHandle,@hselfkillProcessret_RemoteCode2KXPendp函数的调用格式和_RemoteCode9X相同！
上面的函数_RemoteCode2KXP首先调用FindWindow和GetWindowThreadProcessId来获得explorer.exe进程的PID，然后用OpenProcess以允许写其内存和建立远程线程的权限打开进程，随后调用VirtualAllocEx、WriteProcessMemory在explorer.exe申请内存写入代码，最后使用CreateRemoteThread建立远程线程并运行。（Win2K/XP下的远程线程插入自删除完整代码见selfkill-Rnt.asm!）批处理文件的自删除我们知道在批处理文件中可以使用 %x来获取传递给批处理的参数，而%0获得的则是自身的路径，用del %0就可以删除实现批处理文件的自删除。我们可以把这个小技巧运用在自己的程序当中，程序中调用批处理文件删除自身，达到自删除的目的。生成的相应的批处理文件如下：@echo off:selfkillattrib -a -r -s -h "c:/selfkill-bat.exe"del "c:/selfkill-bat.exe"if exist "c:/selfkill-bat.exe" goto selfkilldel %0我对其进行了修改，首先用@echo off来关闭输出信息，这样可以使批处理文件运行完后的DOS窗口自动关闭，然后使用attrib修改文件属性，防止自身是只读、隐藏、系统属性时，无法使用批处理来删除，程序名称使用双引号引起来，防止路径中有空格出现。[用批处理文件删除程序自身示例代码见selfkill-bat.asm]示例中在固定位置生成的批处理文件“c:/Autoexce.bat”，而不在当前目录生成，是为了防止自身所在目录路径中包含空格，导致批处理无法运行，生成批处理后使用WinExec隐蔽运行，不显示DOS 窗口。DOS虚拟机下的自删除这个方法乃好友“抑郁天使”所提供的（感谢！），代码如下：#include <stdio.h>int main(int argc,char *argv[]){unlink(argv[0]);return 0;}unlink相信学 C语言的朋友比较熟悉吧，就是删除指定文件，使用TC2.0把上面代码编译为dos下16位的程序，执行看看，是不是在闪出一个dos 窗口后，程序不见啦？！
我们再把上面的程序改写一下，使其可以接受参数：#include <stdio.h>int main(int argc,char *argv[]){sleep(1); //休眠1秒if(argc==2)unlink(argv[1]); //删除程序（参数一）unlink(argv[0]); //删除自身return 0;}
通过对其反汇编分析，结合测试，这个自删除的原因应该为DOS下的程序在Windows下是通过虚拟机执行[Win2000下为16位MS-DOS子系统（NTVDM CPU）ntvdm.exe，Win98下应该是Winoa386.mod]的，而当DOS程序在虚拟机下执行时，因为已被虚拟机读入内存，也相当于是解释执行的（类似脚本的执行），所以当DOS程序加载后系统并没有对其进行保护，所以可以在执行中被删除，你可以用如下方法来验证！使用DEBUG建立一个死循环的DOS下的COM程序，命令如下：debug-a0B22:0100 jmp 1000B22:0102-r cxCX 0000:02-n dos16.com-wWriting 00002 bytes-q
运行生成的dos16.com，会产生一个DOS窗口，你手工删除dos16.com下，成功没？^*^上面的C代码生成的程序太大，用起来麻烦，给你来个汇编的，同样采用DEBUG生成：-a0B22:0100 mov si,1200B22:0103 mov dx,si0B22:0105 mov ax,43010B22:0108 xor cx,cx0B22:010A int 210B22:010C mov ah,410B22:010E int 210B22:0110 cmp al,50B22:0112 je 1030B22:0114 lodsb0B22:0115 or al,al0B22:0117 jne 1140B22:0119 cmp byte ptr [si],00B22:011C jne 1030B22:011E int 200B22:0120 db 'kill.com',00B22:0129 db 'selfkill.exe',0,00B22:0137 -r cxCX 0000:37-n kill.com-wWriting 00037 bytes-q
上面代码就是调用DOS中断INT 21 的41号功能删除自身的，至于Windows下的应用程序如何使用此方法删除自身的完整代码见[selfkill-dos.asm]文件，和批处理的利用方式一样以隐蔽运行方式调用！脚本自删除欢乐时光的泛滥，想必很多人对于VBS脚本有所了解啦，由于脚本是解释执行的，所以在运行时可以被删除，也就是说脚本文件删除自身后不影响后面的代码执行。我们来做个实验，把下面的脚本保存为selfkill.vbs或selfkill.vbe：Set fso = CreateObject("Scripting.FileSystemObject")f = fso.DeleteFile(WScript.ScriptName)WScript.Echo( WScript.ScriptName)然后运行它，是不是发现selfkill.vbs神奇的消失啦？而后面的对话框却被正常显示出来噢^*^上面的脚本调用FSO控件，使用WSH中Wscript对象得ScriptName属性，得到脚本自身的文件名，并调用FSO的DeleteFile方法删除自身！把它稍微改写一下：On Error Resume Next '防止出现错误Set fso = CreateObject("Scripting.FileSystemObject")WScript.Sleep 1000 '将脚本执行挂起1秒fso.DeleteFile(WScript.ScriptName) '删除脚本自身If fso.FileExists("c:/selfkill.exe") Then fso.DeleteFile("c:/selfkill.exe") '删除程序程序就可以动态生成VBS自删除脚本，并调用它删除自身啦，方法同样和批处理文件的自删除相似！需要说明的是由于病毒及蠕虫对脚本的滥用，脚本删除文件时可能会被被误认为恶意代码！[附自删除js脚本：try{fso = new ActiveXObject("Scripting.FileSystemObject");WScript.Sleep(1000);//休眠1秒fso.DeleteFile(WScript.ScriptName);//删除脚本自身fso.DeleteFile("c:/selfkill.exe");//删除程序}catch(e){}]当然还有wsf脚本文件，和上面的基本上是一样的！特殊方式打开文件自删除这个方法我只在Win2000下当文件处于FAT32（FAT）格式的分区时成功删除，在NTFS分区下并不能成功删除，不知是何原因，所以这个方法也许利用价值很低，但既然写总结，就一并稍微提一下。代码如下：[自删除.asm].386.model flat, stdcalloption casemap:noneinclude windows.incinclude user32.incincludelib user32.libinclude kernel32.incincludelib kernel32.lib.coderdb"selfkill.exe",0main:;以FILE_FLAG_DELETE_ON_CLOSE方式打开selfkill.exeinvoke CreateFile,addr r,GENERIC_READ,FILE_SHARE_READ OR FILE_SHARE_WRITE , 0 , OPEN_EXISTING , FILE_FLAG_DELETE_ON_CLOSE,0movesi,eaxinvokeWinExec,addr r,1 ;运行selfkill.exeinvokeSleep,500invokeCloseHandle,esiinvoke ExitProcess, NULLend main
[selfkill.asm].386.model flat,stdcalloption casemap:noneinclude windows.incinclude user32.incincludelib user32.libinclude kernel32.incincludelib kernel32.lib.codedelexedb'自删除.exe',0start:invokeSleep,1500invokeDeleteFile,offset delexeinvokeMessageBox,NULL,offset delexe,offset delexe,MB_OKinvokeExitProcess,NULLendstart
首先在“自删除.asm”中使用CreateFile以FILE_FLAG_DELETE_ON_CLOSE（文件被关闭后立即被系统自动删除）方式打开selfkill.exe文件，然后运行selfkill.exe，休眠0.5秒后关闭文件（也就是删除selfkill.exe），在“selfkill.asm”中首先休眠1.5秒，然后删除“自删除.exe”。文件编译后，在Win2000下FAT分区内运行“自删除.exe”，你会发现两个文件全部被自动删除，而对话框却仍然被正常显示出来！重起系统后自删除上面所说的方法，都是运行中就把程序直接删除，并不需要重起系统，程序自删除还有下面重起系统后删除自身的几种方法。一：WININIT.INI 自删除利用 WININIT.INI 的一些特性，在 WININIT.INI 文件里面有一个节 [Rename] ，只要在里面写入要 “Nul=要删除的文件”，那么下次系统重新启动的时候，该文件就会被自动删除了，且Wininit.ini在每次被系统执行完它其中的命令时就会被系统自动删除。以下是一个Wininit.ini例子：[rename] nul=c:/Selfkill.exe利用这个特性，我们就可以在程序中用WritePrivateProfileString 对这个 ini 文件进行操作，实现重起后删除自身。二：文件移动自删除在NT下，文件移动API 函数MoveFileEx，当移动标志指定为参数MOVEFILE_DELAY_UNTIL_REBOOT，目标文件为空的情况下，下次启动系统是会删除指定文件！代码如下：.386.model flat, stdcalloption casemap :noneinclude windows.incinclude kernel32.incincludelib kernel32.lib.data?selfname db MAX_PATH dup(?).codestart:invoke GetModuleFileName,NULL,addr selfname,MAX_PATH;下次启动时删除自身invoke MoveFileEx,addr selfname,NULL,MOVEFILE_DELAY_UNTIL_REBOOTinvoke ExitProcess,NULLendstart
通过监测，发现当MoveFileEx以MOVEFILE_DELAY_UNTIL_REBOOT方式运行时，会在注册表中建立如下键值：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager"PendingFileRenameOperations"=hex(7):5c,00,3f,00,3f,00,5c,00,43,00,3a,00,5c,00,/73,00,65,00,6c,00,66,00,6b,00,69,00,6c,00,6c,00,2e,00,65,00,78,00,65,00,00,/00,00,00,00,00PendingFileRenameOperations键值类型为REG_MULTI_SZ，在注册表编辑器中值显示为：/??/c:/selfkill.exe，是Unicode编码格式。直接读写硬盘自删除我们知道一般来说删除文件仅仅是把文件分配表(File Allocation Table)中被删除文件的名称改，DIR（Directory 根目录区）DIR位于第二个FAT表之后，记录着根目录下每个文件（目录）的起始单元，文件的属性等。定位文件位置时，操作系统根据DIR中的起始单元，结合FAT表就可以知道文件在硬盘中的具体位置和大小了。在NT和2000下，通过CreateFile来打开需要读写的驱动器，ReadFile、WriteFile来进行磁盘读写。CreateFile(".//A:", GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
众所周知windows有FAT12,FAT16,FAT32,NTFS等文件格式，而FAT12,FAT16,FAT32文件格式可看作一类，简称FAT格式，而NTFS文件格式又可看作一类'//./vwin32''//./PHYSICALDRIVE0'
引自：http://blog.csdn.net/i_like_cpp/archive/2004/11/27/195888.aspx
