利用DllMain来阻止注入的想法其实很早就有了,msdn上已经把fdwReason讲的很清楚了,所以这个用法其实也是很直接就能想到了

不过在"应用层反外挂技术实践"(http://bbs.pediy.com/showthread.php?t=174292)出来后,我才真正的尝试了一下这个想法.毕竟别人都把源代码丢这了,自然拿来玩玩呗

但是在载入了保护DLL并且杀掉了第一个创建的线程后,再次点击创建线程却什么都没有发生.很明显代码是有问题的,不过我自己也没有去研究这个的打算,毕竟也没有啥程序需要这样反注入的,也就放在那里了.

不过我现在在写的一个程序里,对一个dll有一个很具体的要求:在载入时加载另一个dll.另一个dll并不是确定的,需要读取环境变量来获得.很自然的想到了在DllMain里面LoadLibrary,不过以前记得在DllMain里面执行LoadLibrary和CreateThread都会导致死锁,想来只有研究一下到底能够在DllMain里面干什么了

Google后找到了这么一篇"Best Practices for Creating DLLs"(http://msdn.microsoft.com/en-us/windows/hardware/gg487379.aspx).我现在还只是看到个开头,但是这里面有这么一句引起了我的注意:

• Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.

按照这个文章的说法,系统在加载DLL的时候首先会获取一个进程全局可重入的锁(ReactOS是用一个临界区实现的),然后在加载完成后释放掉.由于除了互斥量以外的锁在线程意外中止的情况下均不会释放,ExitThread后会导致死锁也就十分理所当然:再次LoadLibrary时将会永久的等待这个锁.对于这一点大家可以自己在那个帖子里的例子里点击"加载保护DLL"自己测试

而如果这个只是导致进程之后不能加载DLL也就罢了,我们可以先把所有需要加载的dll都加载好.不过按照上面说的那个微软文档,通过CoInitializeEx初始化COM线程在特定情况下会使用LoadLibraryEx;CreateProcess也可能加载dll.而在ReactOS中各dll中调用LoadLibrary近160次,这意味着这些函数将统统不能使用.而你永远也不能确保一个Win32API会不会在以后突然就有了LoadLibrary的需求.

所以如果真的需要在Ring3层反注入的话,还是inline hook LoadLibrary最为稳妥

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课