注入托管代码

前言：

本文的重点不在于介绍如何注入托管代码，而是侧重于介绍我的研究过程，这里面有很多曲折，可能会使你感到琐屑，但正所谓“授人以鱼，不如授人以渔”，了解了这个过程，会使你理解得更深刻。

正文：

网上关于dll注入的文章实在太多，但基本上都是针对Win32 dll的，而很少涉及到托管dll。
首先让我们来看看Win32 dll是如何注入的，通常有两种方法：钩子和远程线程。而远程线程更灵活，所以本文主要讨论远程线程的方法，为了便于交流，先明确以下概念：
1. 主程序：用于将dll注入到其它进程的exe
2. dll：被注入其它进程的dll
3. 宿主：dll将被注入的其它程序
前两个程序都是我们自己写的，而第3个是原来就有的。

远程注入的基本步骤为：主程序通过CreateRemoteThread函数迫使宿主调用LoadLibrary函数加载dll，从而执行dll的入口函数DllMain，只要我们把代码放到DllMain里，就可以被调用了。

现在我们来看托管dll的注入：

用C#或VB.NET写的dll没有DllMain函数，我们自然想到了功能强大的C++。通常，我们把用C#或VB.NET写的dll，或者用C++写的，但编译为/clr:pure的dll称为托管dll
而把用C++编写的，但编译为/clr的dll称为混合dll。
混合dll也可以调用托管代码，所以也可以将其称为托管dll，本文所说的托管dll注入，实际上是混合dll的注入。


我们首先想到的是用常规方法来注入混合dll，结果会发现：只要在DllMain函数里调用了托管代码，程序就会崩溃。
也许你还会想到下面的方法：
定义一个类，在其构造函数里调用托管代码，然后在全局域里定义这个类的一个变量，当我们这样做了后会发现，注入后，什么也没有执行。
查阅MSDN，我们找到了答案：
DllMain不能直接或间接地调用托管代码，并且全局变量不会进行初始化。
这样的结果让人非常沮丧！

难道真的就没有办法了吗？
一个解决方案：
写一个混合dll，在其中定义一个导出函数，在这个导出函数里可以调用托管代码。
然后写一个非托管dll（也就是Win32 dll），在其DllMain函数里调用前面那个混合dll的导出函数。

这个方案能够解决问题，并且我在一段时间里，也一直使用这个方法。但总觉得不完美：必须使用两个dll。

有没有办法用一个dll就解决问题呢？答案是肯定的。

我在一次偶然的机会中，发现了一个现象：
如里用钩子来实现注入，则全局变量会得到初始化。这个发现让我非常困惑：为什么远程线程注入就不会初始化呢？
我考虑这两种方法的区别：钩子注入时，宿主会调用dll中的钩子回调函数。

于是我大胆设想，只要宿主调用了dll中的任意一个函数，全局变量就会得到初始化。
于是我在dll中定义了一个空实现的函数（因为我的目地是迫使全局变量初始化，而不是去执行这个函数）

结果正如我所料，全局变量被初始化了，其构造函数中的托管代码被调用了！

这里其实已经实现了托管代码的注入，当然，还远远不够完善。

这时候，我又觉得全局变量是多余的了：既然我能够使宿主调用dll中的一个特定函数，为什么不直接把托管代码放到这个函数中呢？
我马上进行了测试，也成功了。

之前我是这样实现让宿主调用dll中的一个特定函数的：
在dll被注入之后，我在DllMain函数里将这个特定函数的地址写到共享内存中（这时DllMain里没有调用托管代码，所以可以执行），然后主程序读取共享内存中的值，再通过远程线程迫使宿主调用这个特定函数。

于是我又想，既然可以在主程序中用远程线程迫使宿主调用dll中的特定函数，为什么不直接在dll中用相同的方法去调用呢？
我还没有来得及验证，马上又想到：dll跟宿主是一个进程，即使用远程线程，传给CreateRomoteThread函数的第一个参数也是-1（GetCurrentProcess()返回-1），为什么不直接用“近程”线程CreateThread呢？

需要着重强调地是：我当时用CreateThread的目的只是让它调用一个特定函数，而不是要去创建一个线程，虽然最终的确创建了一个线程，不过对于此目的，貌似只是一个副作用。

我非常兴奋，马上进行了验证，成功了！

现在我来总结一下托管代码注入的过程：
首先定义一个线程回调函数，可以在其中调用托管代码：
DWORD CALLBACK ThreadProc(LPVOID lp)
{
//可以在此调用托管代码
return 0;
}
然后在dll的入口函数DllMain里调用CreateThread函数：
BOOL APIENTRY DllMain( HMODULE hModule,
  DWORD ul_reason_for_call,
  LPVOID lpReserved
)
{

switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
CreateThread(0,0,ThreadProc,0,0,0);
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
这样就实现了托管代码的注入。


深入话题：

通常我们会有这样的要求：在主程序中单击某个按扭，使宿主执行dll中的一段代码，多次单击就多次执行。

上面的代码无法实现这个目地，因为只有dll刚被注入到宿主时，DllMain中的DLL_PROCESS_ATTACH才会收到通知，我们自然想到：每次执行后，卸载掉dll，下次单击后，DLL_PROCESS_ATTACH又会收到通知；遗憾的是，目前我还没有办法卸载掉这个dll。

对于非托管dll，我们可以通过FreeLibrary来卸载（如果是在dll内部卸载，还必须借助FreeLibraryAndExitThread函数，关于dll的自卸载，由于没有在这个程序中使用，这里就不做介绍了）
而对于托管dll，查阅MSDN，我们得到的结论是：.Net不支持dll的卸掉，dll只能随着应用程序域的卸载而卸载。

对于混合dll，应该如何卸载呢？
我尝试用Win32 dll的方式卸载，结果也“真的”卸载了，这是因为：
1. DllMain中的DLL_PROCESS_DETACH收到了通知
2. 用模块查看工具去看，宿主中确实不存在注入的dll了
但事实上是失败了，至少有两个问题：
1. 关闭宿主时，会提示出错
2. 再次注入时，虽然DLL_PROCESS_ATTACH会收到通知，但用CreateThread创建的新线程并不被执行

既然MSDN上都说无法卸载托管dll，那这个问题就搁浅了吧。


虽然不能卸载这个dll，但并不是说就不能实现前面提到的问题。
实际上，每次主程序通过CreateRemoteThread函数在宿主创建线程时，DllMain中的DLL_THREAD_ATTACH和DLL_THREAD_DETACH也会收到通知，当然最好不要在这里直接调用CreateThread，这是因为：
1. 如果不做处理，直接在DLL_THREAD_ATTACH中调中CreateThread，显然会造成死循环：每产生一个线程，DLL_THREAD_ATTACH就会收到通知，然后又去创建线程，它又会得到通知……
2. 虽然多次单击按扭注入时，DLL_THREAD_ATTACH都会得到通知；但反过来，得到了通知，不意味着就是远程注入：一个最明显的情况是，对CreateThread的调用就会导致DLL_THREAD_ATTACH收到通知，但这并非远程注入

我的解决办法是：每次主程序调用CreateRemoteThread迫使宿主调用LoadLibrary加载dll的时候，都会使模块计数器加1，根据模块计数器的值的变化，就可以确定是否是远程注入了。

示例程序说明：

示例程序包括3个文件：
1. SuperSpy.exe 用C#写的主程序
2. Invoke.dll 用C++写的dll，也只能用C++来写
3. PropertyControl.dll 用VB.NET写的插件，它不是必需的
除了Invoke.dll必须用C++外，其余两个可以用任意语言写。

你也许会感到奇怪，为什么有两个dll？
其中PropertyControl.dll是一个插件，你完全可以把所有的代码都放到Invoke.dll中，之所以用插件的形式，只是为了方便大家编写自已的插件，插件的规范是，在任意一个类中实现以下成员（你可以用你习惯的语言来编写这个插件）：
public static void Inject();
public static string Description
{
get;
}
两个成员都必须是公共、静态的，其中Inject方法是注入后要调用的方法；Description属性是用于描述插件作用的。

我自已实现的插件的功能是：查询和编辑一个托管程序中所有窗口（包括控件）的属性，这是一个很强大的功能，我举两个例子：
1. 星号密码查看。由于已经注入，本来显示为星号的密码，可以直接通过Text属性获得
2. 灰色按扭突破。只需将窗口的Enabled属性设置成true即可

以往要实现这两个功能，都需要分别编写相关的程序，而现在仅仅是这个插件的一个简单应用。而且，你可以编写自己的插件，来实现自己的要求。