dELTA
March 14th, 2003, 08:33
There are several tricks for making programs that are in one way or another able to delete themselves, without leaving any traces in the system.
One of the most wide-spread techniques, and also the one which is supposed to be one of the most platform independent (between Windows versions) is the following:
1.
Start the program you want to delete (EXE1).
2.
From this program, drop a second exe file (EXE2).
3.
Open a file handle to EXE2 from EXE1, using CreateFile, with the flag "FILE_FLAG_DELETE_ON_CLOSE".
4.
Execute EXE2 from EXE1 (e.g. with CreateProcess), causing the operating system to open another file handle to EXE2.
5.
Let EXE1 exit and terminate (which will implicitly cause its filehandle to EXE2 to close, leaving only the operating system's filehandle to EXE2 left open).
6.
EXE2 waits for EXE1 to terminate, and as soon as it detects this, it deletes EXE1 from disk.
7.
After successfully deleting EXE1, the job of EXE2 is complete, and it exits and terminates, causing the operating system's filehandle to it to close.
8.
The general concept and idea is now that EXE2 should immediately be deleted upon this closing of the last open file handle to it. This is also a seemingly correct assumption, especially when you read the entry for the "FILE_FLAG_DELETE_ON_CLOSE" flag of the CreateFile API in the Win32API reference:
The problem is that on the contrary (according to my own experiments), the file deletion does only work if the last file handle to be closed is the one that was opened with the "FILE_FLAG_DELETE_ON_CLOSE" flag. If any file handle is left after this, nothing will happen when it is closed, and the file will hence not be deleted.
This will of course prevent the whole self-deleting exe technique to fail, since the operating systems handle of EXE2 always have to be closed after the handle that EXE1 opened (the one with the FILE_FLAG_DELETE_ON_CLOSE). This is because EXE2 will not succeed in deleting EXE1 before EXE1 is closed, and as soon as EXE1 is closed, its handle to EXE2 will be implicitly closed. And EXE2 will not terminate before it has successfully deleted EXE1, and hence, the operating system's handle to EXE2 will not close before EXE1 has terminated and (implicitly) closed its handle to EXE2.
There is even ready-made example code to be found on the web that is supposed to demonstrate this technique, and the people who provide it claim to have used it successfully. But I have tried this very code on both Win98, Win2000 and WinXP, and in all cases, the dropped exe fails to automatically delete when it terminates, hence being left on the disk.
This makes me wonder if this whole technique is just someone's drug induced fantasy, based on a mixture of the incorrect statements in the Win32 API reference and their own lazyness not to actually try the code themselves (and then obviously lying about having gotten it to work).
So, my question here:
Has anyone reading this post ever gotten this to work, or at least ever seen a program that succeeded in using this technique?
Also, I attach the very small source code of the example program that is supposed to accomplish this with this post. It would be very nice if people could compile it (it should compile right away in VS 6/NET, if inserted into a standard console application), and try it on their systems to see if it succeeds there.
It will simply print out the full path of the EXE2 it has created, and then use the procedure described above.
The desired result is that both the main exe (EXE1) and the created EXE2 should be deleted from the disk afterwards, but in my case EXE2 will always remain on the disk.
Thanks for any help or tips!
dELTA
One of the most wide-spread techniques, and also the one which is supposed to be one of the most platform independent (between Windows versions) is the following:
1.
Start the program you want to delete (EXE1).
2.
From this program, drop a second exe file (EXE2).
3.
Open a file handle to EXE2 from EXE1, using CreateFile, with the flag "FILE_FLAG_DELETE_ON_CLOSE".
4.
Execute EXE2 from EXE1 (e.g. with CreateProcess), causing the operating system to open another file handle to EXE2.
5.
Let EXE1 exit and terminate (which will implicitly cause its filehandle to EXE2 to close, leaving only the operating system's filehandle to EXE2 left open).
6.
EXE2 waits for EXE1 to terminate, and as soon as it detects this, it deletes EXE1 from disk.
7.
After successfully deleting EXE1, the job of EXE2 is complete, and it exits and terminates, causing the operating system's filehandle to it to close.
8.
The general concept and idea is now that EXE2 should immediately be deleted upon this closing of the last open file handle to it. This is also a seemingly correct assumption, especially when you read the entry for the "FILE_FLAG_DELETE_ON_CLOSE" flag of the CreateFile API in the Win32API reference:
Quote:
FILE_FLAG_DELETE_ON_CLOSE Indicates that the operating system is to delete the file immediately after all of its handles have been closed, not just the handle for which you specified FILE_FLAG_DELETE_ON_CLOSE. |
The problem is that on the contrary (according to my own experiments), the file deletion does only work if the last file handle to be closed is the one that was opened with the "FILE_FLAG_DELETE_ON_CLOSE" flag. If any file handle is left after this, nothing will happen when it is closed, and the file will hence not be deleted.
This will of course prevent the whole self-deleting exe technique to fail, since the operating systems handle of EXE2 always have to be closed after the handle that EXE1 opened (the one with the FILE_FLAG_DELETE_ON_CLOSE). This is because EXE2 will not succeed in deleting EXE1 before EXE1 is closed, and as soon as EXE1 is closed, its handle to EXE2 will be implicitly closed. And EXE2 will not terminate before it has successfully deleted EXE1, and hence, the operating system's handle to EXE2 will not close before EXE1 has terminated and (implicitly) closed its handle to EXE2.
There is even ready-made example code to be found on the web that is supposed to demonstrate this technique, and the people who provide it claim to have used it successfully. But I have tried this very code on both Win98, Win2000 and WinXP, and in all cases, the dropped exe fails to automatically delete when it terminates, hence being left on the disk.
This makes me wonder if this whole technique is just someone's drug induced fantasy, based on a mixture of the incorrect statements in the Win32 API reference and their own lazyness not to actually try the code themselves (and then obviously lying about having gotten it to work).
So, my question here:
Has anyone reading this post ever gotten this to work, or at least ever seen a program that succeeded in using this technique?
Also, I attach the very small source code of the example program that is supposed to accomplish this with this post. It would be very nice if people could compile it (it should compile right away in VS 6/NET, if inserted into a standard console application), and try it on their systems to see if it succeeds there.
It will simply print out the full path of the EXE2 it has created, and then use the procedure described above.
The desired result is that both the main exe (EXE1) and the created EXE2 should be deleted from the disk afterwards, but in my case EXE2 will always remain on the disk.
Thanks for any help or tips!
dELTA
Also, I cannot find any Pietrek article discussing the subject of self-deletion. 
).