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 的地址;
// 在远程进程中，INJDATA刚好在
//NewProc的前面;
INJDATA* pData;
_asm {
call dummy
dummy:
pop ecx // <- ECX 中存放当前的EIP
sub ecx, 9 // <- ECX 中存放NewProc的地址
mov pData, ecx
}
pData--;
//-----------------------------
// 子类代码
// ........
//-----------------------------
// 调用原来的窗口过程
return pData->fnCallWindowProc( pData->fnOldProc,
hwnd,uMsg,wParam,lParam );
}
这是什么意思？每个进程都有一个特殊的寄存器，这个寄存器指向下一条要执行的指令的内存地址，即32位Intel和AMD处理器上所谓的EIP寄存器。因为EIP是个特殊的寄存器，所以你不能像访问通用寄存器（EAX，EBX等）那样来访问它。换句话说，你找不到一个可以用来寻址EIP并且对它进行读写的操作码（OpCode）。然而，EIP同样可以被JMP，CALL，RET等指令隐含地改变（事实上它一直都在改变）。让我们举例说明32位的Intel和AMD处理器上CALL/RET是如何工作的吧：
当我们用CALL调用一个子程序时，这个子程序的地址被加载进EIP。同时，在EIP被改变之前，它以前的值会被自动压栈（在后来被用作返回指令指针[return instruction-pointer]）。在子程序的最后RET指令自动把这个值从栈中弹出到EIP。
现在我们知道了如何通过CALL和RET来修改EIP的值了，但是如何得到他的当前值？
还记得CALL把EIP的值压栈了吗？所以为了得到EIP的值我们调用了一个“假（dummy）函数”然后弹出栈顶值。看一下编译过的NewProc：
CODE:Address OpCode/Params Decoded instruction
--------------------------------------------------
:00401000 55 push ebp ; entry point of
; NewProc
:00401001 8BEC mov ebp, esp
:00401003 51 push ecx
:00401004 E800000000 call 00401009 ; *a* call dummy
:00401009 59 pop ecx ; *b*
:0040100A 83E909 sub ecx, 00000009 ; *c*
:0040100D 894DFC mov [ebp-04], ecx ; mov pData, ECX
:00401010 8B45FC mov eax, [ebp-04]
:00401013 83E814 sub eax, 00000014 ; pData--;
.....
.....
:0040102D 8BE5 mov esp, ebp
:0040102F 5D pop ebp
:00401030 C21000 ret 0010
a． 一个假的函数调用；仅仅跳到下一条指令并且（译者注：更重要的是）把EIP压栈。
b． 弹出栈顶值到ECX。ECX就保存的EIP的值；这也就是那条“pop ECX”指令的地址。
c． 注意从NewProc的入口点到“pop ECX”指令的“距离”为9字节；因此把ECX减去9就得到的NewProc的地址了。
这样一来，不管被复制到什么地方，NewProc总能正确计算自身的地址了！然而，要注意从NewProc的入口点到“pop ECX”的距离可能会因为你的编译器/链接选项的不同而不同，而且在Release和Degub版本中也是不一样的。但是，不管怎样，你仍然可以在编译期知道这个距离的具体值。
1． 首先，编译你的函数。
2． 在反汇编器（disassembler）中查出正确的距离值。
3． 最后，使用正确的距离值重新编译你的程序。
这也是InjectEx中使用的解决方案。InjectEx和HookInjEx类似，交换开始按钮上的鼠标左右键点击事件。
解决方案2
在远程进程中把INJDATA放在NewProc的前面并不是唯一的解决方案。看一下下面的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 = 0xA0B0C0D0; // 一个假值
//-----------------------------
// 子类代码
// ........
//-----------------------------
// 调用以前的窗口过程
return pData->fnCallWindowProc( pData->fnOldProc,
hwnd,uMsg,wParam,lParam );
}
这里，0XA0B0C0D0仅仅是INJDATA在远程进程中的地址的占位符（placeholder）。你无法在编译期得到这个值，然而你在调用VirtualAllocEx（为INJDATA分配内存时）后确实知道INJDATA的地址！（译者注：就是VirtualAllocEx的返回值）
我们的NewProc编译后大概是这个样子：
CODE:Address OpCode/Params Decoded instruction
--------------------------------------------------
:00401000 55 push ebp
:00401001 8BEC mov ebp, esp
:00401003 C745FCD0C0B0A0 mov [ebp-04], A0B0C0D0
:0040100A ...
....
....
:0040102D 8BE5 mov esp, ebp
:0040102F 5D pop ebp
:00401030 C21000 ret 0010
编译后的机器码应该为：558BECC745FCD0C0B0A0......8BE55DC21000。
现在，你这么做：
1． 把INJDATA，ThreadFunc和NewFunc复制到目的进程。
2． 改变NewPoc的机器码，让pData指向INJDATA的真实地址。
比如，假设INJDATA的的真实地址（VirtualAllocEx的返回值）为0x008a0000，你把NewProc的机器码改为：
558BECC745FCD0C0B0A0......8BE55DC21000 <- 修改前的 NewProc 1
558BECC745FC00008A00......8BE55DC21000 <- 修改后的 NewProc
也就是说，你把假值 A0B0C0D0改为INJDATA的真实地址2
3． 开始指向远程的ThreadFunc，它子类了远程进程中的控件。
¹ 你可能会问，为什么A0B0C0D0和008a0000在编译后的机器码中为逆序的。这时因为Intel和AMD处理器使用littl-endian标记法（little-endian notation）来表示它们的（多字节）数据。换句话说：一个数的低字节（low-order byte）在内存中被存放在最低位，高字节（high-order byte）存放在最高位。
想像一下，存放在四个字节中的单词“UNIX”，在big-endia系统中被存储为“UNIX”，在little-endian系统中被存储为“XINU”。
² 一些蹩脚的破解者用类似的方法来修改可执行文件的机器码，但是一个程序一旦载入内存，就不能再更改自身的机器码（一个可执行文件的.text段是写保护的）。我们能修改远程进程中的NewProc是因为它所处的那块内存在分配时给予了PAGE_EXECUTE_READWRITE属性。
何时使用CreateRemoteThread和WriteProcessMemory技术
通过CreateRemoteThread和WriteProcessMemory来注入代码的技术，和其他两种方法相比，不需要一个额外的DLL文件，因此更灵活，但也更复杂更危险。一旦你的ThreadFunc中有错误，远程线程会立即崩溃（看附录F）。调试一个远程的ThreadFunc也是场恶梦，所以你应该在仅仅注入若干条指令时才使用这个方法。要注入大量的代码还是使用另外两种方法吧。
再说一次，你可以在文章的开头部分下载到WinSpy，InjectEx和它们的源代码。
写在最后的话
最后，我们总结一些目前还没有提到的东西：
方法 适用的操作系统 可操作的进程进程
I. Windows钩子 Win9x 和WinNT 仅限链接了USER32.DLL的进程1
II. CreateRemoteThread & LoadLibrary 仅WinNT2 所有进程3，包括系统服务4
III. CreateRemoteThread & WriteProcessMemory 近WinNT 所有进程，包括系统服务
1． 很明显，你不能给一个没有消息队列的线程挂钩。同样SetWindowsHookEx也对系统服务不起作用（就算它们连接了USER32）。
2． 在Win9x下没有CreateRemoteThread和VirtualAllocEx（事实上可以在9x上模拟它们，但是到目前为止还只是个神话）
3． 所有进程 ＝ 所有的Win32进程 ＋ csrss.exe
本地程序（native application）比如smss.exe, os2ss.exe, autochk.exe，不使用Win32 APIs，也没有连接到kernel32.dll。唯一的例外是csrss.exe，win32子系统自身。它是一个本地程序，但是它的一些库（比如winsrv.dll）需要Win32 DLL包括kernel32.dll.
4.如果你向注入代码到系统服务或csrss.exe，在打开远程进程的句柄（OpenProcess）之前把你的进程的优先级调整为“SeDebugprovilege”(AdjustTokenPrivileges)。
大概就这些了吧。还有一点你需要牢记在心：你注入的代码（特别是存在错误时）很容易就会把目的进程拖垮。记住：责任随权利而来（Power comes with responsibility）！
这篇文章中的很多例子都和密码有关，看过这篇文章后你可能也会对Zhefu Zhang（译者注：大概是一位中国人，张哲夫??）写的Supper Password Spy++感兴趣。他讲解了如何从IE的密码框中得到密码，也说了如何保护你的密码不被这种攻击。
最后一点：读者的反馈是文章作者的唯一报酬，所以如果你认为这篇文章有作用，请留下你的评论或给它投票。更重要的是，如果你发现有错误或bug；或你认为什么地方做得还不够好，有需要改进的地方；或有不清楚的地方也都请告诉我。
感谢
首先，我要感谢我在CodeGuru（这篇文章最早是在那儿发表的）的读者，正是由于你们的鼓励和支持这篇文章才得以从最初的1200单词发展到今天这样6000单词的“庞然大物”。如果说有一个人我要特别感谢的话，他就是Rado Picha。这篇文章的一部分很大程度上得益于他对我的建议和帮助。最后，但也不能算是最后，感谢Susan Moore，他帮助我跨越了那个叫做“英语”的雷区，让这篇文章更加通顺达意。
――――――――――――――――――――――――――――――――――――
附录
A) 为什么kernel32.dll和user32.dll中是被映射到相同的内存地址？
我的假定：以为微软的程序员认为这么做可以优化速度。让我们来解释一下这是为什么。
一般来说，一个可执行文件包含几个段，其中一个为“.reloc”段。
当链接器生成EXE或DLL时，它假定这个文件会被加载到一个特定的地址，也就是所谓的假定/首选加载/基地址（assumed/preferred load/base address）。内存映像（image）中的所有绝对地址都时基于该“链接器假定加载地址”的。如果由于某些原因，映像没有加载到这个地址，那么PE加载器（PE loader）就不得不修正该映像中的所有绝对地址。这就是“.reloc”段存在的原因：它包含了一个该映像中所有的“链接器假定地址”与真正加载到的地址之间的差异的列表（注意：编译器产生的大部分指令都使用一种相对寻址模式，所以，真正需要重定位[relocation]的地方并没有你想像的那么多）。如果，从另一方面说，加载器可以把映像加载到链接器首选地址，那么“.reloc”段就会被彻底忽略。
但是，因为每一个Win32程序都需要kernel32.dll，大部分需要user32.dll，所以如果总是把它们两个映射到其首选地址，那么加载器就不用修正kernel32.dll和user32.dll中的任何（绝对）地址，加载时间就可以缩短。
让我们用下面的例子来结束这个讨论：
把一个APP.exe的加载地址改为kernel32的（/base:"0x77e80000"）或user32的（/base:"0x77e10000"）首选地址。如果App.exe没有引入UESE32，就强制LoadLibrary。然后编译App.exe，并运行它。你会得到一个错误框（“非法的系统DLL重定位”），App.exe无法被加载。
为什么？当一个进程被创建时，Win2000和WinXP的加载器会检查kernel32.dll和user32.dll是否被映射到它们的首选地址（它们的名称是被硬编码进加载器的），如果没有，就会报错。在WinNT4 中ole32.dll也会被检查。在WinNT3.51或更低版本中，则不会有任何检查，kernel32.dll和user32.dll可以被加载到任何地方。唯一一个总是被加载到首选地址的模块是ntdll.dll，加载器并不检查它，但是如果它不在它的首选地址，进程根本无法创建。
总结一下：在WinNT4或更高版本的操作系统中：
●总被加载到它们的首选地址的DLL有：kernel32.dll，user32.dll和ntdll.dll。
●Win32程序（连同csrss.exe）中一定存在的DLL：kernel32.dll和ntdll.dll。
●所有进程中都存在的dll：ntdll.dll。
B) /GZ编译开关
在Debug时，/GZ开关默认是打开的。它可以帮你捕捉一些错误（详细内容参考文档）。但是它对我们的可执行文件有什么影响呢？
当/GZ被使用时，编译器会在每个函数，包含函数调用中添加额外的代码（添加到每个函数的最后面）来检查ESP栈指针是否被我们的函数更改过。但是，等等，ThreadFunc中被添加了一个函数调用？这就是通往灾难的道路。因为，被复制到远程进程中的ThreadFunc将调用一个在远程进程中不存在的函数。
C) static函数和增量连接（Incremental linking）
增量连接可以缩短连接的时间，在增量编译时，每个函数调用都是通过一个额外的JMP指令来实现的（一个例外就是被声明为static的函数！）这些JMP允许连接器移动函数在内存中的位置而不用更新调用该函数的CALL。但是就是这个JMP给我们带来了麻烦：现在ThreadFunc和AfterThreadFunc将指向JMP指令而不是它们的真实代码。所以，当计算ThreadFunc的大小时：
const int cbCodeSize = ((LPBYTE) AfterThreadFunc - (LPBYTE) ThreadFunc);
你实际得到的将是指向ThreadFunc和AfterThreadFunc的JMP指令之间的“距离”。现在假设我们的ThreadFunc在004014C0，和其对应的JMP指令在00401020
责任编辑：瞳瞳
进入论坛参与针对本文章的讨论