在某些特定场合，CDebugInjector合成了一小段代码根区来调用LoadLibrary。LoadLibrary的dll名字参数，指到要被注射的dll的名字。CDebugInjector写那个根区（和相关联的dll名字）到被调试者的地址空间。然后，调用SetThreadContext来改变被调试者的指令寄存器，运行LoadLibrary根区。所有的相关代码在CDebugInjector::PlaceInjectionStub过程中。

立刻的，根区中的LoadLibrary调用后，是一个断点(int 3)。这个暂停被调试者的运行，交回控制权给调试的进程。调试者用SetThreadContext，恢复指令寄存器和其他寄存器到原来的值。另一次调用ContinueDebugEvent，被调试者在dll注射的状态下，继续运行。没有人知道发生了什么事情。

如果你不想那么多，这个注射进程不会觉得太难，但是，一些有兴趣的东西，弄复杂了事情。例如，什么时候创建根区，改变运行代码，才是适当呢？你不能在CreateProcess后立刻做这个，因为，引入的dll还没有被映射到内存中，WIN32加载器还没有建立exe的IAT。相当于：太早了。

最后，我决定让被调试者运行，直到碰到了第一个断点。我在程序入口处，设置了一个自己的断点。当第2次中断被触发，CDebugInjector知道目的进程的DLL，都被初始化了（包括Kernel32.dll）。但是，在exe中，还没有代码运行。现在是时候注射DelayLoadProfileDLL.DLL了。

顺便说一下：断点从哪里来呢？通过定义，一个被调试的win32的进程，在运行之前，会调用DebugBreak（也是int3），在我早期的apispy32代码中，我选用了最初的DebugBreak来做注射。在win2k中，非常不幸，这个DebugBreak在Kernel32.dll初始化之前，被调用，那么，CDebugInjector设置它的断点到exe即将获得控制的地方，那么，kernel32.dll被初始化了。

在之前，我提到在LoadLibrary调用后，发生的一个断点。这是第3个CDebugInjector要处理的断点，所有的处理不同断点的技巧，可以参考CDebugInjector::HandleException。

另外一个关于注射dll的有兴趣的问题，就是在那里写LoadLibrary单元，在winnt4.0以后，你可以用VirtualAllocEx来为某个线程申请内存。我采用了这个方法

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!