可执行模块的自删除技术已经被讨论的很多, 有很多极富创意的思路和想法被提出, 但有些似是而非的方案往往使人误入歧途. 举个例子来说, 很多文章认为下面的一小段代码可以实现自删除:
void main(void)
{
TCHAR szCMD[NAME_LENGTH] = {0};
strcpy(szCMD, "cmd /c del ");
strcat(szCMD, ::GetProgramName());
::WinExec(szCMD, 0);
}
初看起来, 这段代码表面上没有什么问题, 运行测试发现很好很奏效, 又简单又明了, 难道存在隐藏的错误? 是的! 可以很肯定的告诉大家, 这段代码从原则上来说是错误的! 它的错误可以归结为一句话: 不能无条件地假设多个进程在特定时刻的运行顺序!
编写上面例子代码的时候, 不知不觉的陷入了一个假相陷阱: cmd进程会在当前程序退出后开始执行(假设了cmd进程与当前应用程序进程的执行顺序). 我们可以加入一条Sleep语句来验证这个假相陷阱, 代码如下:
void main(void)
{
TCHAR szCMD[NAME_LENGTH] = {0};
strcpy(szCMD, "cmd /c del ");
strcat(szCMD, ::GetProgramName());
::WinExec(szCMD, 0);
::Sleep(1000);
}
结果发现程序现在不能自删除了. 为什么? 就是因为cmd进程开始运行时, 当前应用程序进程仍然存在, 系统不能释放当前应用程序的可执行文件句柄, 导致文件不能被删除. 有些朋友会说: 没关系, 我在调用::WinExec(szCMD, 0);后什么也不做就退出, 这样不就OK啦? 真的这样就OK了? 实际上你无法保证在调用::WinExec(szCMD, 0);后进程立即退出且释放当前应用程序的可执行文件句柄. 因为在很多情况下, 应用程序的退出是一个相对缓慢的过程(像卸载大量的dll, 释放各种资源, C++全局对象的析构etc.)
现在给大家介绍几种简单可行的Windows可执行模块安全自删除技术
1) MoveFileEx() API, 在NT以后的Windows平台上被引入. 它的原型是
BOOL MoveFileEx(
LPCTSTR lpExistingFileName,
LPCTSTR lpNewFileName,
DWORD dwFlags
);
如果传NULL给lpNewFileName并置dwFlags为MOVEFILE_DELAY_UNTIL_REBOOT, 那么系统重启后lpExistingFileName所指定的文件就会被删除.
而在9x下, 需要修改win.ini, 给出类似 "filename= "这样的字段, 那么系统重启后"filename"所指定的文件会被删除.
它们的共同点就是Windows系统保证文件的正确删除, 非常简单, 而且对于一些系统级,驱动级文件来说是唯一可靠的方法, 缺点是要求系统重启才能真正删除指定的文件.
2) 利用文件的FILE_FLAG_DELETE_ON_CLOSE属性实现安全自删除
当创建文件时如果指定了FILE_FLAG_DELETE_ON_CLOSE属性, 系统会在该文件的所用句柄被关闭后立刻自动删除该文件.
步骤:
1) 使用CreateFile() API创建一个新文件, 指定FILE_FLAG_DELETE_ON_CLOSE属性.
2) 使用一个可执行文件映象填充这个新文件.
3) 使用CreateProcess() API启动新文件进程.
4) 借助任意的进程间通信机制保证新文件进程在当前程序退出后安全的删除可执行文件.
5) 新文件进程结束后系统将自动删除新文件, 至此, 自删除顺利完成.
很多我的朋友使用这种方式后, 感觉很简单明了也有很强的适应性. 他们写出了各式各样的应用方法, 实践证明这种方式是可靠安全的.
最后大家可以使用以上介绍的方法自己动手尝试, 就不再给出例子啦, 自己动手最可靠, 嘿嘿. 有任何问题, 错误请指出, 谢过先.
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
