Program self-deleting method big summary procedure's self-deduplication is no longer something more easily, but it is more easier for prawns, but I think it is necessary to think about it. The various methods you know have summed up, I hope to help the newcomers. The program's self-deduplication is widely used in the final self-deletion of the reverse installer (environmental!), Of course, more common in Trojans, the first installation of the virus is installed ^ * ^, as for what use, look at yourself! Classic self-deleting said self-deletion of the program can not say the code written by prawn such as Gary Nebbett! The code is embedded in the C language. Asm: Under Win9X, you can remove the exe image in memory by executing the exe itself handle, then you can delete your own files by calling deletefile. The code under Win9x is as follows [Selfkill-9x.c]: # include "windows.h" int main (int Argc, char * argv []) {charf [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;
In Winnt / 2K, you need to call CloseHandle to close the EXE file itself corresponding image handle Handle [hardcoded to 4], then call unmapViewoffile to release another handle, and release the program itself in memory mapping object, Finally, you can use Deletefile to delete itself! (Note: This method does not apply to WinXP!)
The code under winnt / 2k is as follows [Selfkill-NT.c]: # include "windows.h" int main (int argc, char * argv []) {charf [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;}
Integrate the code under Win9X and Winnt / 2k, that is, all the API code used by the two platforms is all over again. Although there may be several APIs fail to run on a platform, there are several APIs to run. Success, but the final result of the EXE program file deleted itself before withdrawing!
The code under Win9x and Winnt / 2k is as follows [Selfkill-9x NT.c]: # include "windows.h" int main (int Argc, char * argv []) {charf [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;} because I own compilation [MASM32] in learning Win32, so re-written in assembler again, but only to find that each time failed , Showing an error as shown in Figure 1
=========== In this insert map one ==============
By disassembly comparison discovery found that due to the MASM32 compiler to the coding and C compiler of the API, causing the version of the codefile when using the freeibrary or unmapViewoffile to release the code [JMP deletefile] , Causing read memory execution errors. Error Analysis When a normal program is used, the compiler compiles an API call statement into several parameter stack instructions followed by an indirect call statement (this refers to the Microsoft compiler, the Borland compiler uses JMP DWORD PTR [xxxxxxxh]) as follows:
PUSH ARG1PUSH ARG2 ... CALL DWORD PTR [xxxxxxxh] address xxxxxxxh In the import section of the program image, when the program is loaded, the loader is responsible for adding the address of the API function to the inside;
I: Programs compiled with MASM32 The API function call format is: Call Capi; ................ CAPI: JMP DWORD PTR [xxxxxxxx]; XXXXXXXX is stored in the called API function real address
The JMP DWORD PTR [xxxxxxx] instruction is the advantage of using the "compiler" in the process of automatically plus the process of all code, and can reduce the code volume when calling the same API multiple times,
Second: Programs compiled with C The API function call format is: Call Dword PTR [xxxxxxxx]; XXXXXXXX address is stored in the called API function real address
It is because the above API function call format is different, resulting in a program compiled with MASM32, because the JMP DWORD PTR [xxxxxxxx] instruction of the code segment is turned into unreadable, after the code section of the code segment is not readable, after the coded DWORD PTR [xxxxxxxx] instruction is turned into unreadable, after the DELETEFILE The execution of the API will fail, the program is wrong! So if we compile this self-delete program with MASM32, we should change the Push Deletefile command to:
MOV EAX, Deletefile; Take the JMP DWORD PTR [xxxxxxx] instruction address, machine code FF25XXXXXXXXINC EAXINC EaxMov Eax, DWORD PTR [EAX] Push DWORD PTR [EAX] puts the real address of DeleteFile into the stack, of course, use dynamically acquired API Also, but it is better to have less code. Below is the MASM32 code I have changed [Selfkill9x-nt.asm]:
.386.Model flat, StdCallOption Casemap: NONE
include windows.incinclude kernel32.incincludelib kernel32.lib.codestart: mov ebp, espinvoke GetModuleHandle, NULL; obtaining module handle itself mov ebx, eaxinvoke GetModuleFileName, ebx, ebp, MAX_PATH; obtaining the own path invoke CloseHandle, 4; corresponding to close the file itself exe the IMAGE handle [hardcoded 4] push 0; ExitProcess parameters push 0push ebp; DeleteFile parameter mov eax, ExitProcessinc eaxinc eaxmov eax, dword ptr [eax] push dword ptr [eax]; pushExitProcesspush ebx; UnmapViewOfFile parameters mov eax, DeleteFileinc eaxinc eaxmov eax, dword ptr [eax] push dword ptr [eax]; pushDeleteFilepush ebx; FreeLibrary parameters mov eax, UnmapViewOfFileinc eaxinc eaxmov eax, dword ptr [eax] push dword ptr [eax]; pushUnmapViewOfFilepush FreeLibrary; FreeLibrary not Change because the code section of calling it can also read RETENDSTART
Remote threads Insert self-delete remote threads Inserts are now widely used in the self-protection and conceal of Trojans and viruses, and we can also use it in the program's self-deletion.
The code in which the deleted itself is as follows: kremote_code_start equ this bytecall @f @@: pop ebxsub ebx, offset @B; thread code relocation PUSH 500CALL [EBX _LPselfkillsleep]; Sleep 0.5 second Lea Eax, [EBX offset _selfkillselfname] Push EaxCall [EBX _LPSELFKILDELETEFILE]; Delete Program File Ret
_lpselfkillsleep DD ?; hardcoded address _lpselfkillDeletefile dd ?; deletefile's hardcoded address _SelfkillSelfName:; program own file name, main program generation write
KREMOTE_CODE_END EQU THIS BYTEKREMOTE_CODE_LENGTH EQU Offset Kremote_code_end - Offset Kremote_code_Start
Use getProcAddress in the main program to get the hard-encoded address of the Sleep and DeleteFile, and get it with GetModuleFileName to get the _selfkillselFname with getModuleFileName to use it for remote threads.
Establishing a remote thread under Win9x KERNEL32.DLL code as follows: 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; get the address CreateKernelThread; _findProcess is a name lookup process PID function according to the process, detailed code, see [selfkill-R9x.asm] invoke _findProcess, offset Kernel32; Find KERNEL32.DLL process .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; create KERNEL32.DLL threads .endifinvokeCloseHandle, hProcess.endifret_RemoteCode9Xendp function call format is: push KREMOTE_CODE_LENGTH MAX_PATH; the code length push offset rEMOTE_CODE; code address call _RemoteCode9X [Note: Do not use invoke _RemoteCode9X here, offset rEMOTE_CODE, KREMOTE_CODE_LENGTH MAX_PATH to call a function, because it was discovered invoke my test calls will KREMOT E_CODE_LENGTH MAX_PATH value is bigger! Maybe a bug of the compiler? ] In _Remotecode9x first using getProcAddress to get CreatekernetThread this API address for establishing remote threads in kernel32.dll [CreatekernetThread's parameters, but there is a point different for the lpstartaddress parameter (address started by thread) is in Kernel32.dll in progress! ], Then call the _FindProcess process to find the PID of the kernel32.dll process, then open this process with all permissions, and write the code into the space starting in the Kernel32.dll process 80001100h [所 8 80001100h is because The large section may not be used in memory 00h, so you don't have to enter the 0 ring like Chinese hackers! ], Final call CREATEKERNELTHREAD to create a kernel32.dll thread to delete itself! (Remote thread under Win9X insert self-delete full code see Selfkill-r9x.asm!)
For at Win2K / XP establish remote thread code is as follows:; szDesktopClassdb'Progman thread for insertion in the remote process explorer.exe ', 0szDesktopWindowdb'Program Manager', 0_RemoteCode2KXPproc @_RmCodeStart, @ _ RmCodeLenlocal @hRmCodeMemorylocal @hselfkillProcessIDlocal @hselfkillProcess; Find a file manager window and get the process ID, and then open the process 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; in the process allocation of space and writes remote code, to establish a remote thread 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 function call format and _Remotecode9x are the same!
The above function _RemoteCode2KXP first call FindWindow and GetWindowThreadProcessId to get PID explorer.exe process, and then use OpenProcess to allow write access to its memory and open the process to establish a remote thread, subsequent calls VirtualAllocEx, WriteProcessMemory in explorer.exe application code is written to memory Finally, establish a remote thread using CreateRemTethread and run. (Remote Threads under Win2K / XP Insert Self-Delete Complete Code See Selfkill-Rnt.asm!) Batch File Delete We know that you can use% X in the batch file to get the parameters passing to batch, and% 0 It is the path to itself, and you can delete the self-deletion of the batch file with Del% 0. We can use this tip to use in our own procedure, and the program is called batch file to delete itself, reach the purpose of self-deletion. The generated corresponding batch files are as follows: @echo off: selfkillattrib -A -R -H "C: /selfkill-bat.exe" del "c: /selfkill-bat.exe" if exist "C: / Selfkill -bat.exe "goto selfkildel% 0" I have modified it, first use @echo off to turn the output information, so that the DOS window after running the batch file is automatically turned off, then use Attrib to modify the file attribute to prevent itself When it is read-only, hidden, system properties, cannot be used to delete, and the program name is caused by double quotes, preventing space in the path. [See the batch file "C: /autoExce.bat" generated in the fixed location with batch file deletion program, not in the current directory, is to prevent itself from in the directory path Contains spaces, causing batch failure, generating batch, using Winexec hidden operation, does not display DOS window. Self-deleting this method under the DOS virtual machine is provided by the "Depressant Angel" (thanks!), The code is as follows: #include
Through its disassembly analysis, combined testing, this self-deleted reason should be the program under DOS under Windows [Win2000 is 16-bit MS-DOS Subsystem (NTVDM CPU) NTVDM.EXE, WIN98 It should be WinOa386.MOD], and when the DOS program is executed under the virtual machine, since the virtual machine is read into memory, it is also equivalent to explaining the execution (the execution of the script), so when the DOS program is loaded, the system is not Protect it, so you can be deleted in the execution, you can use the following method to verify! Use Debug to create a COM program under a dead cycle, command as follows: Debug-a0b22: 0100 JMP 1000B22: 0102-R CXCX 0000: 02-n DOS16.COM-wwriting 00002 BYTES-Q running generation DOS16.COM, Produce a DOS window, you remove DOS16.COM, is it successful? ^ * ^ The program generated above is too big, it is used up, give you a compilation, the same use Debug generation: -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: 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- Qi
The above code is to call the DOS Interrupt INT 21 function to delete itself. As for how the application under Windows use this method to remove its own full code to see [Selfkill-dos.asm] file, and the use of batch is hidden Run mode call! The script self-deleting the flooding of the joyful time, it is necessary to have a lot of people to know about the VBS script, because the script is explained, so can be deleted at runtime, that is, the script file does not affect the following code execution. We do an experiment, save the following script to selfkill.vbs or selfkill.vbe: Set fso = CreateObject ( "Scripting.FileSystemObject") f = fso.DeleteFile (WScript.ScriptName) WScript.Echo (WScript.ScriptName) then Run it, is it a magical disappearance of Selfkill.vbs? The following dialogs are normally displayed. ^ * ^ The script calls the FSO control, use the WSRIPT object in WSH to get the scriptname property, get the script itself, and call the fso deletefile method to delete itself! Remote it: On Error ResMe next 'prevents error SET FSO = CREATEOBJECT ("scripting.filesystemObject") WScript.sleep 1000' Prying the script 1 second fso.deletefile (wscript.scriptname) 'Delete script itself IF Fso.fileexists ("c: /selfkill.exe") The fso.deletefile ("c: /selfkill.exe") 'Delete program program can dynamically generate VBS self-delete scripts, and call it to delete itself, method is also The self-deletion of the batch file is similar! It should be noted that due to the abuse of the virus and worms, the script may be mistaken when the script is deleted! [Remove JS Scripts: Try {fso = New ActiveXObject ("scripting.filesystemObject"); wscript.sleep (1000); // Sleep 1 second fso.deletefile (wscript.scriptname); // Delete script itself fso.deletefile ("c: / scrollkill.exe"); // Delete Program} Catch (e) {}] Of course, there is a WSF script file, and the above is basically the same! Special way to open the file Self-delete this method I only delete it when the win2000 is in the FAT32 (FAT) format, which is not successfully deleted under the NTFS partition. I don't know why, so this method may use the value very low. But since writing a summary, just mention it.
Code as follows: [Delete from .asm] .386.model flat, stdcalloption casemap: noneinclude windows.incinclude user32.incincludelib user32.libinclude kernel32.incincludelib kernel32.lib.coderdb "selfkill.exe", 0main :; opened in 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; run 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 'self-delete .exe', 0start: invokeSleep, 1500invokeDeleteFile, offset delexeinvokeMessageBox, NULL, offset delexe, offset delexe, MB_OKinvokeExitProcess, NULLendstart
First open the Selfkill.exe file using createfile using cretefile_dlete_on_close (automatically removed immediately after being turned off) in "Self-deleted .asm", then run Selfkill.exe, shut down the file after dormancy for 0.5 seconds (that is, delete selfkill.exe ), First sleep in "Selfkill.asm", then delete "self-delete .exe". After the file is compiled, "self-delete .exe" is run in the FAT partition in Win2000, you will find that both files are automatically deleted, but the dialog is still displayed normally! After the restart system, the method described above is to delete the program directly, do not need to restart the system, the program self-deletion also has several methods after the system is removed. I: Wininit.ini self-removing some of the features of Wininit.ini, there is a section in the wininit.ini file [Rename], as long as the write to "NUL = to delete file", then the next system restarted When this file will be automatically deleted, WininIt.ini is automatically deleted when each command is performed each time it is performed. The following is a WinInit.ini example: [Rename] NUL = C: /selfkill.exe Using this feature, we can use WritePrivateProfileString to operate this INI file in the program, and remove itself after restarting. 2: File movement self-deletion Under NT, the file mobile API function movefileex, when the mobile flag is specified as the parameter movefile_delay_until_reboot, the target file is empty, the next start system will delete the specified file! Code is as follows: .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; deleted next time you start INVOKE MOVEFILEX, ADDR Selfname, Null, MoveFile_DELAY_UNTIL_REBOOTINVOKE EXITPROCESS, NULLEENDSTART
By monitoring, found that when operating in MoveFileEx MOVEFILE_DELAY_UNTIL_REBOOT manner, the following will be created in the registry key: HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control / Session Manager "PendingFileRenameOperations" = hex (7): 5c, 00,3f, 00,3f 00, 5C, 00, 43, 100, 3A, 00, 5C, 00, / 73, 100, 65, 100, 69, 66, 100, 6B, 00, 69, 100, 6C, 00, 6C, 00, 2e, 00, 65, 3, 78, 100, 65, 00, / 00, 00 ,00 ,00% the type of REG_MULTI_SZ, displayed in the registry editor, displayed as: / ?? / C: /selfkill.exe, is a Unicode encoding format. Directly read and write hard drives Self-deletion We know that the delete file is only changed to the name of the file in the file allocation table, and the DIR (Directory Root Directory Area) DIR is recorded after the second FAT table. The starting unit of each file (directory), the properties of the file, etc. When positioning the file location, the operating system can know the specific location and size of the file in the hard disk according to the starting unit in the DIR. Under NT and 2000, the drive, readfile, writefile you need to read and write via CREATEFILE, to perform disk read and write. Createfile (".// A:", generic_read, file_share_read | file_share_write, null, open_existing, 0, null; well known Windows has FAT12, FAT16, FAT32, NTFS and other file formats, while FAT12, FAT16, FAT32 file format can be seen as One class, referred to as the FAT format, and NTFS file format can be seen as a class '//./vwin32''//./physicaldrive0'
