进程间通讯
到目前为止，我们仅仅讨论了任何向远程进程注入DLL，然而，在多数情况下被注入的DLL需要和你的程序以某种方式通讯（记住，那个DLL是被映射到远程进程中的，而不是在你的本地程序中！）。以密码间谍为例：那个DLL需要知道包含了密码的的控件的句柄。很明显，这个句柄是不能在编译期间硬编码（hardcoded）进去的。同样，当DLL得到密码后，它也需要把密码发回我们的程序。
幸运的是，这个问题有很多种解决方案：文件映射（Mapping），WM_COPYDATA，剪贴板等。还有一种非常便利的方法#pragma data_seg。这里我不想深入讨论因为它们在MSDN（看一下Interprocess Communications部分）或其他资料中都有很好的说明。我在LibSpy中使用的是#pragma data_seg。
你可以在本文章的开头找到LibSpy及源代码的下载链接。
Ⅲ.CreateRemoteThread和WriteProcessMemory技术
示例程序：WinSpy
另一种注入代码到其他进程地址空间的方法是使用WriteProcessMemory API。这次你不用编写一个独立的DLL而是直接复制你的代码到远程进程（WriteProcessMemory）并用CreateRemoteThread执行之。
让我们看一下CreateRemoteThread的声明：
CODE:HANDLE CreateRemoteThread(
HANDLE hProcess, // handle to process to create thread in
LPSECURITY_ATTRIBUTES lpThreadAttributes, // pointer to security
// attributes
DWORD dwStackSize, // initial thread stack size, in bytes
LPTHREAD_START_ROUTINE lpStartAddress, // pointer to thread
// function
LPVOID lpParameter, // argument for new thread
DWORD dwCreationFlags, // creation flags
LPDWORD lpThreadId // pointer to returned thread identifier
);
和CreateThread相比，有一下不同：
●增加了hProcess参数。这是要在其中创建线程的进程的句柄。
●CreateRemoteThread的lpStartAddress参数必须指向远程进程的地址空间中的函数。这个函数必须存在于远程进程中，所以我们不能简单地传递一个本地ThreadFucn的地址，我们必须把代码复制到远程进程。
●同样，lpParameter参数指向的数据也必须存在于远程进程中，我们也必须复制它。
现在，我们总结一下使用该技术的步骤：
1． 得到远程进程的HANDLE（OpenProcess）。
2． 在远程进程中为要注入的数据分配内存（VirtualAllocEx）、
3． 把初始化后的INJDATA结构复制到分配的内存中（WriteProcessMemory）。
4． 在远程进程中为要注入的数据分配内存（VirtualAllocEx）。
5． 把ThreadFunc复制到分配的内存中（WriteProcessMemory）。
6． 用CreateRemoteThread启动远程的ThreadFunc。
7． 等待远程线程的结束（WaitForSingleObject）。
8． 从远程进程取回指执行结果（ReadProcessMemory 或 GetExitCodeThread）。
9． 释放第2、4步分配的内存（VirtualFreeEx）。
10． 关闭第6、1步打开打开的句柄。
另外，编写ThreadFunc时必须遵守以下规则：
1． ThreadFunc不能调用除kernel32.dll和user32.dll之外动态库中的API函数。只有kernel32.dll和user32.dll（如果被加载）可以保证在本地和目的进程中的加载地址是一样的。（注意：user32并不一定被所有的Win32进程加载！）参考附录A。如果你需要调用其他库中的函数，在注入的代码中使用LoadLibrary和GetProcessAddress强制加载。如果由于某种原因，你需要的动态库已经被映射进了目的进程，你也可以使用GetMoudleHandle代替LoadLibrary。同样，如果你想在ThreadFunc中调用你自己的函数，那么就分别复制这些函数到远程进程并通过INJDATA把地址提供给ThreadFunc。
2． 不要使用static字符串。把所有的字符串提供INJDATA传递。为什么？编译器会把所有的静态字符串放在可执行文件的“.data”段，而仅仅在代码中保留它们的引用（即指针）。这样，远程进程中的ThreadFunc就会执行不存在的内存数据（至少没有在它自己的内存空间中）。
3． 去掉编译器的/GZ编译选项。这个选项是默认的（看附录B）。
4． 要么把ThreadFunc和AfterThreadFunc声明为static，要么关闭编译器的“增量连接（incremental linking）”（看附录C）。
5． ThreadFunc中的局部变量总大小必须小于4k字节（看附录D）。注意，当degug编译时，这4k中大约有10个字节会被事先占用。
6． 如果有多于3个switch分支的case语句，必须像下面这样分割开，或用if-else if代替：
CODE:switch( expression ) {
case constant1: statement1; goto END;
case constant2: statement2; goto END;
case constant3: statement2; goto END;
}
switch( expression ) {
case constant4: statement4; goto END;
case constant5: statement5; goto END;
case constant6: statement6; goto END;
}
END:
（参考附录E）
如果你不按照这些游戏规则玩的话，你注定会使目的进程挂掉！记住，不要妄想远程进程中的任何数据会和你本地进程中的数据存放在相同内存地址！（参看附录F）
（原话如此：You will almost certainly crash the target process if you don't play by those rules. Just remember: Don't assume anything in the target process is at the same address as it is in your process.）
GetWindowTextRemote(A/W)
所有取得远程edit中文本的工作都被封装进这个函数：GetWindowTextRemote(A/W)：
int GetWindowTextRemoteA( HANDLE hProcess, HWND hWnd, LPSTR lpString );
int GetWindowTextRemoteW( HANDLE hProcess, HWND hWnd, LPWSTR lpString );
参数：
hProcess
目的edit所在的进程句柄
hWnd
目的edit的句柄
lpString
接收字符串的缓冲
返回值：
成功复制的字符数。
让我们看以下它的部分代码，特别是注入的数据和代码。为了简单起见，没有包含支持Unicode的代码。
CODE:INJDATA
typedef LRESULT (WINAPI *SENDMESSAGE)(HWND,UINT,WPARAM,LPARAM);
typedef struct {
HWND hwnd; // handle to edit control
SENDMESSAGE fnSendMessage; // pointer to user32!SendMessageA
char psText[128]; // buffer that is to receive the password
} INJDATA;
INJDATA是要注入远程进程的数据。在把它的地址传递给SendMessageA之前，我们要先对它进行初始化。幸运的是unse32.dll在所有的进程中（如果被映射）总是被映射到相同的地址，所以SendMessageA的地址也总是相同的，这也保证了传递给远程进程的地址是有效的。
CODE:ThreadFunc
static DWORD WINAPI ThreadFunc (INJDATA *pData)
{
pData->fnSendMessage( pData->hwnd, WM_GETTEXT, // 得到密码
sizeof(pData->psText),
(LPARAM)pData->psText );
return 0;
}
// This function marks the memory address after ThreadFunc.
// int cbCodeSize = (PBYTE) AfterThreadFunc - (PBYTE) ThreadFunc.
static void AfterThreadFunc (void)
{
}
ThreadFunc是远程线程实际执行的代码。
●注意AfterThreadFunc是如何计算ThreadFunc的代码大小的。一般地，这不是最好的办法，因为编译器会改变你的函数中代码的顺序（比如它会把ThreadFunc放在AfterThreadFunc之后）。然而，你至少可以确定在同一个工程中，比如在我们的WinSpy工程中，你函数的顺序是固定的。如果有必要，你可以使用/ORDER连接选项，或者，用反汇编工具确定ThreadFunc的大小，这个也许会更好。
如何用该技术子类（subclass）一个远程控件
示例程序：InjectEx
让我们来讨论一个更复杂的问题：如何子类属于其他进程的一个控件？
首先，要完成这个任务，你必须复制两个函数到远程进程：
1． ThreadFunc，这个函数通过调用SetWindowLong API来子类远程进程中的控件，
2． NewProc， 那个控件的新窗口过程（Window Procedure）。
然而，最主要的问题是如何传递数据到远程的NewProc。因为NewProc是一个回调（callback）函数，它必须符合特定的要求（译者注：这里指的主要是参数个数和类型），我们不能再简单地传递一个INJDATA的指针作为它的参数。幸运的我已经找到解决这个问题的方法，而且是两个，但是都要借助于汇编语言。我一直都努力避免使用汇编，但是这一次，我们逃不掉了，没有汇编不行的。
解决方案1
看下面的图片：
图片附件: winspy2.gif (2006-8-8 09:11, 8.98 K)
不知道你是否注意到了，INJDATA紧挨着NewProc放在NewProc的前面？这样的话在编译期间NewProc就可以知道INJDATA的内存地址。更精确地说，它知道INJDATA相对于它自身地址的相对偏移，但是这并不是我们真正想要的。现在，NewProc看起来是这个样子：
CODE:static LRESULT CALLBACK NewProc(
HWND hwnd, // handle to window
UINT uMsg, // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam ) // second message parameter
{
INJDATA* pData = (INJDATA*) NewProc; // pData 指向
// NewProc;
pData--; // 现在pData指向INJDATA;
// 记住，INJDATA 在远程进程中刚好位于
// NewProc的紧前面;
//-----------------------------
// 子类代码
// ........
//-----------------------------
//调用用来的的窗口过程;
// fnOldProc (由SetWindowLong返回) 是被ThreadFunc（远程进程中的）初始化
// 并且存储在远程进程中的INJDATA里的;
return pData->fnCallWindowProc( pData->fnOldProc,
hwnd,uMsg,wParam,lParam );
}
然而，还有一个问题，看第一行：
INJDATA* pData = (INJDATA*) NewProc;
pData被硬编码为我们进程中NewProc的地址，但这是不对的。因为NewProc会被复制到远程进程，那样的话，这个地址就错了。
用C/C++没有办法解决这个问题，可以用内联的汇编来解决。看修改后的NewProc：
责任编辑：瞳瞳
进入论坛参与针对本文章的讨论