本文章翻译自Robet Kuster的Three Ways to Inject Your Code into Another Process一文，原版地址见下面。本文章版权归原作者所有。www.farproc.com
原版地址：http://www.codeproject.com/threads/winspy.asp?df=100&forumid=16291&select=1025152&msg=1025152
下载整个压缩包 下载WinSpy
作者：Robert Kusterwww.farproc.com hyzs@sina.com
目录：
导言：www.codeproject.com
一般来说，这个问题有三种可能的解决方案：
Ⅰ. Windows 钩子
示例程序：HookSpy 和 HookInjEx
Windows钩子的主要作用就是监视某个线程的消息流动。一般可分为：
如果被挂钩（监视）的线程属于别的进程（情况2a和2b），你的钩子过程（hook procedure）必须放在一个动态连接库（DLL）中。系统把这包含了钩子过程的DLL映射到被挂钩的线程的地址空间。Windows会映射整个DLL而不仅仅是你的钩子过程。这就是为什么windows钩子可以用来向其他线程的地址空间注入代码的原因了。
在这里我不想深入讨论钩子的问题（请看MSDN中对SetWindowsHookEx的说明），让我再告诉你两个文档中找不到的诀窍，可能会有用：
同理，调用UnhookWindowsHookEx之后，只有特定的事件发生后DLL才真正地从被挂钩线程卸载。
2． 当你安装了钩子后，系统的性能会受到影响（特别是系统级的钩子）。然而如果你只是使用的特定线程的钩子来映射DLL而且不截获如何消息的话，这个缺陷也可以轻易地避免。看一下下面的代码片段：
// 安全卸载钩子
我们来看一下。首先，我们用钩子映射这个DLL到远程线程，然后，在DLL被真正映射进去后，我们立即卸载挂钩（unhook）。一般来说当第一个消息到达被挂钩线程后，这DLL会被卸载，然而我们通过LoadLibrary来增加这个DLL的引用次数，避免了DLL被卸载。
剩下的问题是：使用完毕后如何卸载这个DLL？UnhookWindowsHookEx不行了，因为我们已经对那个线程取消挂钩（unhook）了。你可以这么做：
但是，我们应该在何种情况下使用该技巧呢？通常是在DLL需要在远程进程中驻留较长时间（比如你要子类[subclass]另一个进程中的控件）并且你不想过于干涉目的进程时比较适合使用这种技巧。我在HookSpy中并没有使用它，因为那个DLL只是短暂地注入一段时间――只要能取得密码就足够了。我在另一个例子HookInjEx中演示了这种方法。HookInjEx把一个DLL映射进“explorer.exe”（当然，最后又从其中卸载），子类了其中的开始按钮，更确切地说我是把开始按钮的鼠标左右键点击事件颠倒了一下。
你可以在本文章的开头部分找到HookSpy和HookInjEx及其源代码的下载包链接。
Ⅱ. CreateRemoteThread 和 LoadLibrary 技术
HINSTANCE LoadLibrary(
BOOL FreeLibrary(
再和CreateRemoteThread的线程过程（thread procedure）ThreadProc比较一下：
你会发现所有的函数都有同样的调用约定（calling convention）、都接受一个32位的参数并且返回值类型的大小也一样。也就是说，我们可以把LoadLibrary/FreeLibrary的指针作为参数传递给CrateRemoteThread。
然而，还有两个问题（参考下面对CreateRemoteThread的说明）
1． 传递给ThreadProc的lpStartAddress 参数必须为远程进程中的线程过程的起始地址。
第一个问题其实已经迎刃而解了，因为LoadLibrary和FreeLibrary都是存在于kernel32.dll中的函数，而kernel32可以保证任何“正常”进程中都存在，且其加载地址都是一样的。（参看附录A）于是LoadLibrary/FreeLibrary在任何进程中的地址都是一样的，这就保证了传递给远程进程的指针是个有效的指针。
第二个问题也很简单：把DLL的文件名（LodLibrary的参数）用WriteProcessMemory复制到远程进程。
所以，使用CreateRemoteThread和LoadLibrary技术的步骤如下：
同时，别忘了在最后关闭所有的句柄：第4、8步得到的线程句柄，第1步得到的远程进程句柄。
现在我们看看LibSpy的部分代码，分析一下以上的步骤是任何实现的。为了简单起见，没有包含错误处理和支持Unicode的代码。
//初始化 szLibPath
// 1. 在远程进程中为szLibPath 分配内存
// 加载 “LibSpy.dll” 到远程进程
//取得DLL的基地址
//扫尾工作
我们放在DllMain中的真正要注入的代码（比如为SendMessage）现在已经被执行了（由于DLL_PROCESS_ATTACH），所以现在可以把DLL从目的进程中卸载了。
// 从目标进程卸载LibSpu.dll
// 扫尾工作
进程间通讯
幸运的是，这个问题有很多种解决方案：文件映射（Mapping），WM_COPYDATA，剪贴板等。还有一种非常便利的方法#pragma data_seg。这里我不想深入讨论因为它们在MSDN（看一下Interprocess Communications部分）或其他资料中都有很好的说明。我在LibSpy中使用的是#pragma data_seg。
你可以在本文章的开头找到LibSpy及源代码的下载链接。
Ⅲ.CreateRemoteThread和WriteProcessMemory技术
另一种注入代码到其他进程地址空间的方法是使用WriteProcessMemory API。这次你不用编写一个独立的DLL而是直接复制你的代码到远程进程（WriteProcessMemory）并用CreateRemoteThread执行之。
让我们看一下CreateRemoteThread的声明：
和CreateThread相比，有一下不同：
●增加了hProcess参数。这是要在其中创建线程的进程的句柄。
现在，我们总结一下使用该技术的步骤：
1． 得到远程进程的HANDLE（OpenProcess）。
另外，编写ThreadFunc时必须遵守以下规则：
switch( expression ) {
如果你不按照这些游戏规则玩的话，你注定会使目的进程挂掉！记住，不要妄想远程进程中的任何数据会和你本地进程中的数据存放在相同内存地址！（参看附录F）
GetWindowTextRemote(A/W)
所有取得远程edit中文本的工作都被封装进这个函数：GetWindowTextRemote(A/W)：
参数：
返回值：
让我们看以下它的部分代码，特别是注入的数据和代码。为了简单起见，没有包含支持Unicode的代码。
INJDATA
typedef LRESULT (WINAPI *SENDMESSAGE)(HWND,UINT,WPARAM,LPARAM);
typedef struct {
char psText[128]; // buffer that is to receive the password
INJDATA是要注入远程进程的数据。在把它的地址传递给SendMessageA之前，我们要先对它进行初始化。幸运的是unse32.dll在所有的进程中（如果被映射）总是被映射到相同的地址，所以SendMessageA的地址也总是相同的，这也保证了传递给远程进程的地址是有效的。
ThreadFunc
static DWORD WINAPI ThreadFunc (INJDATA *pData)
// This function marks the memory address after ThreadFunc.
ThreadFunc是远程线程实际执行的代码。
如何用该技术子类（subclass）一个远程控件
让我们来讨论一个更复杂的问题：如何子类属于其他进程的一个控件？
首先，要完成这个任务，你必须复制两个函数到远程进程：
然而，最主要的问题是如何传递数据到远程的NewProc。因为NewProc是一个回调（callback）函数，它必须符合特定的要求（译者注：这里指的主要是参数个数和类型），我们不能再简单地传递一个INJDATA的指针作为它的参数。幸运的我已经找到解决这个问题的方法，而且是两个，但是都要借助于汇编语言。我一直都努力避免使用汇编，但是这一次，我们逃不掉了，没有汇编不行的。
解决方案1
不知道你是否注意到了，INJDATA紧挨着NewProc放在NewProc的前面？这样的话在编译期间NewProc就可以知道INJDATA的内存地址。更精确地说，它知道INJDATA相对于它自身地址的相对偏移，但是这并不是我们真正想要的。现在，NewProc看起来是这个样子：
//—————————–
//调用用来的的窗口过程;
然而，还有一个问题，看第一行：
pData被硬编码为我们进程中NewProc的地址，但这是不对的。因为NewProc会被复制到远程进程，那样的话，这个地址就错了。
用C/C++没有办法解决这个问题，可以用内联的汇编来解决。看修改后的NewProc：
static LRESULT CALLBACK NewProc(
//—————————–
// 调用原来的窗口过程
