by Koms Bomb/CVC.GA

本文的目的，就是想说明写病毒其实是多么的容易。
一，病毒神话
我们先看看让大家“兴奋”、“激动”的病毒技术。
1，CIH，简直成了神话，CIH的作者也成为无数人的偶像。这神话，是AVer吹出来的，这偶像，只是中国人盲目崇拜的延续，外国人没这臭毛病。看看这个病毒里究竟有什么？1K多点的代码，再厉害能有什么？我觉得这个病毒唯一比较好的地方就是它的非常优化。这种优化，其实说白了也不难，只要稍微有些汇编编程经验，再加上一部指令手册（至少要有指令长度），再有足够的耐心，都可以做到。其它还有什么？进入Ring 0？早已有之，再说稍微懂些保护模式的人都知道利用GDT/IDT/LDT是可以进行特权转换的，常识问题。感染后文件大小不变？稍微了解PE格式的人都知道PE里有多少空地。使用VxD技术？Flash BIOS？只要能找到这些资料，有什么难的？VxD无非就是玩一些int 20h，Flash BIOS无非是写一些端口。调用中断，写端口，谁不会？但怎么调中断，写哪些端口，则需要知道相关的资料。我就写不出VxD为基础的病毒，我也不会Flash BIOS，因为我没有这方面的资料。
再看看时下“热门”的病毒技术。
2，跨平台病毒。跨Windows和Linux，同样是X86指令，有什么特殊的吗？基本上这种跨平台病毒，公用一部分变形之类的和OS无关的代码，而和OS有关的则是分开的。比如在Windows上就调用API，而在Linux上则用int 80h（没搞错中断号吧，我对Linux没什么研究）。其实就相当于两个病毒的合并。只要有了相关系统调用的资料，这种病毒显然很容易。其实写出针对不同CPU的病毒也不难，只要针对不同的文件感染不同的代码，然后把另外OS或CPU的代码做为数据不执行就行。顺便说一句，跨平台有什么用？有几个Linux机器上有PE文件的？又有几个Windows上有ELF文件的？
3，.net病毒。有什么新鲜吗？Java不是也有病毒吗？只要掌握MSIL汇编，写一个真正的.net病毒并不难。值得一提的是前一阵炒得火热的两个.net病毒其实根本难登大雅之堂。29A的那个是用X86汇编写的，稍微有点头脑的都知道，.net是架构在MSIL上的，是一种中间语言，X86汇编根本就和.net无关。我没仔细看这个病毒的代码，但我估计无非是对EPE格式有一些不同于PE的操作，总体来说，还是PE病毒。那个“17岁天才少女”的C#病毒，算是.net病毒吧，但值得一吹吗？你，说的就是你，去看看C#语法，再略微看一些.net framework，相信你也可以用C#写出一个可以把自己通过邮件发出去的程序，这就是时髦的.net病毒。
4，metamorphism。简直被AVer吹上天了。这东西说白了其实就是对自身代码进行重新编码。过程是，反汇编自己的代码，重新改写（比如mov eax,esi可以写成push esi;pop eax等等），插入垃圾代码。当然最好还要在下一代中删除垃圾代码。怎样判断垃圾代码？显然看到一条指令的目的操作数在以后没有被当作源操作数，就可以认为是垃圾。这东西玩弄的是机器代码技巧，只要在手边摆一部Intel的指令手册，再加上足够的耐心，想对代码重新编码，不难。但写这东西确实很繁琐，可以说是非常繁琐，写出的代码也很大，没有实用价值。以后有空我可能会重新考虑一个semi-metamorphism，也不难，但力求小，如果engine超过8K，我将放弃。

二，病毒的本质
大家之所以觉得病毒神秘，其实主要是因为大家没有对病毒没有了解，AVer又在大肆鼓吹（这种现象在中国尤为严重）。病毒到底是什么？
病毒是一段程序，它与普通程序的不同是它会复制自己，这是最主要的不同。复制有很多方法，直接copy，通过网络，插入别的可执行文件内部，等等，但这些方法的实现也是一段程序，并无特殊之处。
其实写病毒和写普通程序一样，不需要太高的智商。我为什么这么说？编程只是技术，这种技术所需要的基础知识是很浅的，可以说是非常浅，而且没有阶梯性。如果你要做物理学家，则一定要先学会中学物理，否则你就学不会大学物理。但如果你要做汇编程序员（听起来很高深的样子），你不必先学Basic，再学Pascal和C，最后学汇编，你完全可以从一开始就学汇编，完全没有问题。很多人以自己了解系统核心而自称高手，但这哪里高了？可能他花了三个月发现的一个系统核心的秘密，只是M$的一个程序员用一个小时写出来的。这一点也造就了很多“天才少年/少女”的神话，十几岁的小孩可以写出很好的程序或者病毒，让大家觉得真是天才。其实我敢肯定一个10岁的小孩对编程知识的理解能力不会比我差，甚至可能因为年龄小记忆力好而比我强，大家认为我智商有问题？也许吧，但小孩一样比你强。中国人对电脑界的“天才少年”总是津津乐道，其实只是愚蠢无知的表现。编程不需要智商，但需要资料，如果你不掌握一定数量的Win32 API，你很难写出像样的Win32程序。其实程序这东西还和物质力量有关，为什么外国有很多编程方面的“天才少年”？因为他们智商高？显然不是，中国人的智商至少不输于西洋人。主要是因为他们比较富裕，可以很早就接触电脑，并且有钱上网，上网当然可以获得许多有用的资料。靠，说到这里我不得不发牢骚，我正式开始能够经常接触电脑还是在2000年大学毕业以后。我在十几岁的时候，买本书都没钱，更别提电脑了，现在平时在家还是拿猫上网。
我说了这么多，其实一个结论就是，写病毒和写普通程序一样，不需要智商（当然智商也不能太低，如果智商低于80，除非真的是另类天才，否则还是别玩程序的好），但需要资料，这间接的需要物质力量。
所以说，病毒并不神秘，一点都不神秘，而且不难，可以说是相当简单，因为他们通常很小，最大也就几十K。我现在逐渐明白，哪怕是用Delphi这样易用的工具，开发大型程序，也是比较复杂比较困难的事，要有完善的设想，科学的模块划分，等等。
病毒虽然简单，但也有很好玩的地方，因为它的本质就是复制隐藏自己。如何更快的复制传播自己，如何隐蔽自己使得用户不容易发现病毒的踪影，是我的主要研究目标。这种目标显然违背了某些卫道士的“XX精神”（他们鼓吹的是黑客精神，但我不会黑，只会毒，是毒客而不是黑客），但这正是病毒的本质，如果脱离这些本质，那病毒也就不称之为病毒，而且也没必要研究病毒，有那精力不如做点应用软件。这种卫道士，鼓吹的是那种研究“新”、“高深”技术来写病毒的人，这样的病毒也就是AVer说的“学术病毒”、“概念病毒”。但这种病毒有什么用？除了给AVer吹牛的机会以外，没什么用。除了CIH以外，我上面说的基本都是这种病毒。大家可以看看，哪里有新技术？哪里有高深技术？
值得注意的是网上颇为流行江海客的那篇老文章“后英雄时代的AVER与VXER”，而且许多人都认为“受益菲浅”，为了不误导大家，我还是说两句。这篇文章总体来说就是在胡说八道。“AV企业的一般工程师，玩起softice的手法，远没有cracker熟练”？我确实不知道AVer是不是熟悉SI，但这句话有两个大问题，1），玩SI熟练就能代表水平？那好，我从现在开始天天玩SI，一个月后精通SI的各个功能，那我是不是成大师了？这简直是不合人类逻辑。 2），研究病毒一定要用SI？我调试病毒主要用VC，SI只是辅助，非常方便。“想象反病毒公司那些呆头呆脑的样本分析工程师，“**，原来病毒也可以这样编” 的惊呼，然后心情紧张的把样本交给公司中的前辈高人寻求指点他们已经心满意足。”更是胡说八道，有谁相信Symantec的在Nimda，Klez，BugBear爆发几个小时内就拿出解决方案的工程师是呆头呆脑的？”而是用了类似社交工程或者心理学一类的方法“，”当然，那些资深的VXER对此是不耻的，他们从不以自己的病毒传播如何广泛为荣誉，这些人的品性有些类似老牌黑客的绅士风范，这些人中确实也有我很欣赏的“，不是每个人都能做出成功的social engine的，好的S/E会得到全世界人的赞叹（套用卫道士的话，全世界人惊呼，”**，这他都能想得到“），一个人只要有耐心，可以对系统核心钻研很深，这没什么神秘，但好的S/E却需要灵光闪现。不能广泛传播的病毒显然不是好的病毒，无论它的技术如何高超（而且基本如我所说，并没有什么高超的技术），而且病毒和黑客不一样，黑客黑网站，真正有道德的不应该搞破坏，但他有能力可以破上10000个网站。有道德的病毒也不应该搞破坏，但有能力的病毒可以感染1000万台机器，这没什么不对，这是病毒应该做的，当然有能力感染不一定真的感染，不一定真的释放出去，但验证感染能力通常需要实战。还有就是他也是我说的那种卫道士，鼓吹那种黑客精神，其实如果大家都遵循他那种精神，那么结局就是大家整天都在研究不切实际的技术，根本就没有实用品出来。总体说，一个不懂得病毒本质，对病毒没有很深了解，没有写过病毒的人，不配写这种文章。
我一直对知道现在还在奉CIH和其它病毒为神明的无知之人感到气愤，在中国这种人太多了，所以就写了这篇文章，因为气愤，所以言语有不当之处，还望大家见谅，如果你对我感到气愤，可以理论，但不要骂人。

欢迎转载，请注明 by Koms Bomb/CVC.GA。
又：我发现深圳之窗网站曾从CSDN转了我的一篇文章，但去掉了所有作者信息，我给他们发信叫他们改正，也没有回音。这种行为是极度卑鄙无耻的，如果引起众怒将会玩火自焚！

     本文章翻译自Robet Kuster的Three Ways to Inject Your Code into Another Process一文，原版地址见下面。本文章版权归原作者所有。
     如果转载该译文,请保证文章的完整性，并注明来自www.farproc.com
袁晓辉   
2005/5/20

原版地址：http://www.codeproject.com/threads/winspy.asp?df=100&forumid=16291&select=1025152&msg=1025152

下载整个压缩包
下载WinSpy

作者：Robert Kuster
翻译：袁晓辉 (www.farproc.com  hyzs@sina.com)
摘要：如何向其他线程的地址空间中注入代码并在这个线程的上下文中执行之。

目录：
●导言
●Windows 钩子（Hooks）
●CreateRemoteThread 和LoadLibrary 技术
○进程间通讯
●CreateRemoteThread 和 WriteProcessmemory 技术
○如何使用该技术子类（SubClass）其他进程中的控件
○什么情况下适合使用该技术
●写在最后的话
●附录
●参考
●文章历史

导言：
     我们在Code project（www.codeproject.com）上可以找到许多密码间谍程序（译者注：那些可以看到别的程序中密码框内容的软件），他们都依赖于Windows钩子技术。要实现这个还有其他的方法吗？有！但是，首先，让我们简单回顾一下我们要实现的目标，以便你能弄清楚我在说什么。
要读取一个控件的内容，不管它是否属于你自己的程序，一般来说需要发送 WM_GETTEXT 消息到那个控件。这对edit控件也有效，但是有一种情况例外。如果这个edit控件属于其他进程并且具有 ES_PASSWORD 风格的话，这种方法就不会成功。只有“拥有（OWNS）”这个密码控件的进程才可以用 WM_GETTEXT 取得它的内容。所以，我们的问题就是：如何让下面这句代码在其他进程的地址空间中运行起来：
::SendMessage( hPwdEdit, WM_GETTEXT, nMaxChars, psBuffer );

一般来说，这个问题有三种可能的解决方案：
1. 把你的代码放到一个DLL中；然后用 windows 钩子把它映射到远程进程。
2. 把你的代码放到一个DLL中；然后用 CreateRemoteThread 和 LoadLibrary 把它映射到远程进程。
3. 不用DLL，直接复制你的代码到远程进程（使用WriteProcessMemory）并且用CreateRemoteThread执行之。在这里有详细的说明：

Ⅰ. Windows 钩子

示例程序：HookSpy 和 HookInjEx

Windows钩子的主要作用就是监视某个线程的消息流动。一般可分为：
1． 局部钩子，只监视你自己进程中某个线程的消息流动。
2． 远程钩子，又可以分为：
a． 特定线程的，监视别的进程中某个线程的消息；
b． 系统级的，监视整个系统中正在运行的所有线程的消息。

     如果被挂钩（监视）的线程属于别的进程（情况2a和2b），你的钩子过程（hook procedure）必须放在一个动态连接库（DLL）中。系统把这包含了钩子过程的DLL映射到被挂钩的线程的地址空间。Windows会映射整个DLL而不仅仅是你的钩子过程。这就是为什么windows钩子可以用来向其他线程的地址空间注入代码的原因了。

     在这里我不想深入讨论钩子的问题（请看MSDN中对SetWindowsHookEx的说明），让我再告诉你两个文档中找不到的诀窍，可能会有用：
1． 当SetWindowHookEx调用成功后，系统会自动映射这个DLL到被挂钩的线程，但并不是立即映射。因为所有的Windows钩子都是基于消息的，直到一个适当的事件发生后这个DLL才被映射。比如：
如果你安装了一个监视所有未排队的（nonqueued）的消息的钩子（WH_CALLWNDPROC），只有一个消息发送到被挂钩线程（的某个窗口）后这个DLL才被映射。也就是说，如果在消息发送到被挂钩线程之前调用了UnhookWindowsHookEx那么这个DLL就永远不会被映射到该线程（虽然SetWindowsHookEx调用成功了）。为了强制映射，可以在调用SetWindowsHookEx后立即发送一个适当的消息到那个线程。

     同理，调用UnhookWindowsHookEx之后，只有特定的事件发生后DLL才真正地从被挂钩线程卸载。

2． 当你安装了钩子后，系统的性能会受到影响（特别是系统级的钩子）。然而如果你只是使用的特定线程的钩子来映射DLL而且不截获如何消息的话，这个缺陷也可以轻易地避免。看一下下面的代码片段：
BOOL APIENTRY DllMain( HANDLE hModule,
                        DWORD   ul_reason_for_call,
                        LPVOID lpReserved )
{
     if( ul_reason_for_call == DLL_PROCESS_ATTACH )
     {
         //用 LoadLibrary增加引用次数
         char lib_name[MAX_PATH];
         ::GetModuleFileName( hModule, lib_name, MAX_PATH );
         ::LoadLibrary( lib_name );

         // 安全卸载钩子
         ::UnhookWindowsHookEx( g_hHook );
     }    
     return TRUE;
}

     我们来看一下。首先，我们用钩子映射这个DLL到远程线程，然后，在DLL被真正映射进去后，我们立即卸载挂钩（unhook）。一般来说当第一个消息到达被挂钩线程后，这DLL会被卸载，然而我们通过LoadLibrary来增加这个DLL的引用次数，避免了DLL被卸载。

     剩下的问题是：使用完毕后如何卸载这个DLL？UnhookWindowsHookEx不行了，因为我们已经对那个线程取消挂钩（unhook）了。你可以这么做：
○在你想要卸载这个DLL之前再安装一个钩子；
○发送一个“特殊”的消息到远程线程；
○在你的新钩子的钩子过程（hook procedure）中截获该消息，调用FreeLibrary 和 （译者注：对新钩子调用）UnhookwindowsHookEx。
现在，钩子只在映射DLL到远程进程和从远程进程卸载DLL时使用，对被挂钩线程的性能没有影响。也就是说，我们找到了一种（相比第二部分讨论的LoadLibrary技术）WinNT和Win9x下都可以使用的，不影响目的进程性能的DLL映射机制。

     但是，我们应该在何种情况下使用该技巧呢？通常是在DLL需要在远程进程中驻留较长时间（比如你要子类[subclass]另一个进程中的控件）并且你不想过于干涉目的进程时比较适合使用这种技巧。我在HookSpy中并没有使用它，因为那个DLL只是短暂地注入一段时间――只要能取得密码就足够了。我在另一个例子HookInjEx中演示了这种方法。HookInjEx把一个DLL映射进“explorer.exe”（当然，最后又从其中卸载），子类了其中的开始按钮，更确切地说我是把开始按钮的鼠标左右键点击事件颠倒了一下。

     你可以在本文章的开头部分找到HookSpy和HookInjEx及其源代码的下载包链接。

Ⅱ. CreateRemoteThread 和 LoadLibrary 技术
示例程序：LibSpy
     通常，任何进程都可以通过LoadLibrary动态地加载DLL，但是我们如何强制一个外部进程调用该函数呢？答案是CreateRemoteThread。
让我们先来看看LoadLibrary和FreeLibrary的函数声明：

HINSTANCE LoadLibrary(
   LPCTSTR lpLibFileName    // address of filename of library module
);

BOOL FreeLibrary(
   HMODULE hLibModule       // handle to loaded library module
);

再和CreateRemoteThread的线程过程（thread procedure）ThreadProc比较一下：
DWORD WINAPI ThreadProc(
   LPVOID lpParameter    // thread data
);

     你会发现所有的函数都有同样的调用约定（calling convention）、都接受一个32位的参数并且返回值类型的大小也一样。也就是说，我们可以把LoadLibrary/FreeLibrary的指针作为参数传递给CrateRemoteThread。

     然而，还有两个问题（参考下面对CreateRemoteThread的说明）

     1． 传递给ThreadProc的lpStartAddress 参数必须为远程进程中的线程过程的起始地址。
     2． 如果把ThreadProc的lpParameter参数当做一个普通的32位整数（FreeLibrary把它当做HMODULE）那么没有如何问题，但是如果把它当做一个指针（LoadLibrary把它当做一个char*），它就必须指向远程进程中的内存数据。

     第一个问题其实已经迎刃而解了，因为LoadLibrary和FreeLibrary都是存在于kernel32.dll中的函数，而kernel32可以保证任何“正常”进程中都存在，且其加载地址都是一样的。（参看附录A）于是LoadLibrary/FreeLibrary在任何进程中的地址都是一样的，这就保证了传递给远程进程的指针是个有效的指针。

     第二个问题也很简单：把DLL的文件名（LodLibrary的参数）用WriteProcessMemory复制到远程进程。

     所以，使用CreateRemoteThread和LoadLibrary技术的步骤如下：
     1． 得到远程进程的HANDLE（使用OpenProcess）。
     2． 在远程进程中为DLL文件名分配内存（VirtualAllocEx）。
     3． 把DLL的文件名（全路径）写到分配的内存中（WriteProcessMemory）
     4． 使用CreateRemoteThread和LoadLibrary把你的DLL映射近远程进程。
     5． 等待远程线程结束（WaitForSingleObject），即等待LoadLibrary返回。也就是说当我们的DllMain（是以DLL_PROCESS_ATTACH为参数调用的）返回时远程线程也就立即结束了。
     6． 取回远程线程的结束码（GetExitCodeThtread），即LoadLibrary的返回值――我们DLL加载后的基地址（HMODULE）。
     7． 释放第2步分配的内存（VirtualFreeEx）。
     8． 用CreateRemoteThread和FreeLibrary把DLL从远程进程中卸载。调用时传递第6步取得的HMODULE给FreeLibrary（通过CreateRemoteThread的lpParameter参数）。
     9． 等待线程的结束（WaitSingleObject）。

     同时，别忘了在最后关闭所有的句柄：第4、8步得到的线程句柄，第1步得到的远程进程句柄。

     现在我们看看LibSpy的部分代码，分析一下以上的步骤是任何实现的。为了简单起见，没有包含错误处理和支持Unicode的代码。
HANDLE hThread;
char     szLibPath[_MAX_PATH];   // “LibSpy.dll”的文件名
                                // (包含全路径!);
void*    pLibRemote;              // szLibPath 将要复制到地址
DWORD    hLibModule;    //已加载的DLL的基地址（HMODULE）;
HMODULE hKernel32 = ::GetModuleHandle(“Kernel32”);

//初始化 szLibPath
//…

// 1. 在远程进程中为szLibPath 分配内存
// 2. 写szLibPath到分配的内存
pLibRemote = ::VirtualAllocEx( hProcess, NULL, sizeof(szLibPath),
                                MEM_COMMIT, PAGE_READWRITE );
::WriteProcessMemory( hProcess, pLibRemote, (void*)szLibPath,
                       sizeof(szLibPath), NULL );

// 加载 “LibSpy.dll” 到远程进程
// (通过 CreateRemoteThread & LoadLibrary)
hThread = ::CreateRemoteThread( hProcess, NULL, 0,
             (LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,
                                        “LoadLibraryA” ),
              pLibRemote, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );

//取得DLL的基地址
::GetExitCodeThread( hThread, &hLibModule );

//扫尾工作
::CloseHandle( hThread );
::VirtualFreeEx( hProcess, pLibRemote, sizeof(szLibPath), MEM_RELEASE );

我们放在DllMain中的真正要注入的代码（比如为SendMessage）现在已经被执行了（由于DLL_PROCESS_ATTACH），所以现在可以把DLL从目的进程中卸载了。

// 从目标进程卸载LibSpu.dll
// (通过 CreateRemoteThread & FreeLibrary)
hThread = ::CreateRemoteThread( hProcess, NULL, 0,
             (LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,
                                        “FreeLibrary” ),
             (void*)hLibModule, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );

// 扫尾工作
::CloseHandle( hThread );

进程间通讯
     到目前为止，我们仅仅讨论了任何向远程进程注入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的声明：
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代替：

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的代码。

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的地址也总是相同的，这也保证了传递给远程进程的地址是有效的。

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
看下面的图片：

不知道你是否注意到了，INJDATA紧挨着NewProc放在NewProc的前面？这样的话在编译期间NewProc就可以知道INJDATA的内存地址。更精确地说，它知道INJDATA相对于它自身地址的相对偏移，但是这并不是我们真正想要的。现在，NewProc看起来是这个样子：
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：

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：

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：
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编译后大概是这个样子：
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，它子类了远程进程中的控件。

     &sup1; 你可能会问，为什么A0B0C0D0和008a0000在编译后的机器码中为逆序的。这时因为Intel和AMD处理器使用littl-endian标记法（little-endian notation）来表示它们的（多字节）数据。换句话说：一个数的低字节（low-order byte）在内存中被存放在最低位，高字节（high-order byte）存放在最高位。
想像一下，存放在四个字节中的单词“UNIX”，在big-endia系统中被存储为“UNIX”，在little-endian系统中被存储为“XINU”。

     &sup2; 一些蹩脚的破解者用类似的方法来修改可执行文件的机器码，但是一个程序一旦载入内存，就不能再更改自身的机器码（一个可执行文件的.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
:00401020    jmp   004014C0
…
:004014C0    push EBP           ; ThreadFunc的真实地址
:004014C1    mov   EBP, ESP
…
然后，
WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);
将把“JMP 004014C0”和其后的cbCodeSize范围内的代码而不是ThreadFunc复制到远程进程。远程线程首先会执行“JMP 004010C0”，然后一直执行到这个进程代码的最后一条指令（译者注：这当然不是我们想要的结果）。

然而，如果一个函数被声明为static，就算使用增量连接，也不会被替换为JMP指令。这就是为什么我在规则#4中说把ThreadFunc和AfterThreadFunc声明为static或禁止增量连接的原因了。（关于增量连接的其他方面请参看Matt Pietrek写的“Remove Fatty Deposits from Your Applications Using Our 32-bit Liposuction Tools”）

D) 为什么ThreadFunc只能有4K的局部变量？
局部变量总是保存在栈上的。假设一个函数有256字节的局部变量，当进入该函数时（更确切地说是在functions prologue中），栈指针会被减去256。像下面的函数：
void Dummy(void) {
     BYTE var[256];
     var[0] = 0;
     var[1] = 1;
     var[255] = 255;
}
会被编译为类似下面的指令：
:00401000    push ebp
:00401001    mov   ebp, esp
:00401003    sub   esp, 00000100            ; change ESP as storage for
                                          ; local variables is needed
:00401006    mov   byte ptr [esp], 00       ; var[0] = 0;
:0040100A    mov   byte ptr [esp+01], 01    ; var[1] = 1;
:0040100F    mov   byte ptr [esp+FF], FF    ; var[255] = 255;
:00401017    mov   esp, ebp                 ; restore stack pointer
:00401019    pop   ebp
:0040101A    ret

请注意在上面的例子中ESP（栈指针）是如何被改变的。但是如果一个函数有多于4K的局部变量该怎么办？这种情况下，栈指针不会被直接改变，而是通过一个函数调用来正确实现ESP的改变。但是就是这个“函数调用”导致了ThreadFunc的崩溃，因为它在远程进程中的拷贝将会调用一个不存在的函数。

让我们来看看文档关于栈探针（stack probes）和/Gs编译选项的说明：
“/Gssize选项是一个允许你控制栈探针的高级特性。栈探针是编译器插入到每个函数调用中的一系列代码。当被激活时，栈探针将温和地按照存储函数局部变量所需要的空间大小来移动

如果一个函数需要大于size指定的局部变量空间，它的栈探针将被激活。默认的size为一个页的大小（在80×86上为4k）。这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互，在运行期间向程序栈增加已提交的内存总数。

我能确定你们对上面的叙述（“栈探针将温和地按照存储函数局部变量所需要的空间大小来移动”）感到奇怪。这些编译选项（他们的描述！）有时候真的让人很恼火，特别是当你想真的了解它们是怎么工作的时候。打个比方，如果一个函数需要12kb的空间来存放局部变量，栈上的内存是这样“分配”的
sub     esp, 0x1000     ; 先“分配”4 Kb
test   [esp], eax       ; touches memory in order to commit a
                       ; new page (if not already committed)
sub     esp, 0x1000     ; “分配”第二个 4 Kb
test   [esp], eax       ; …
sub     esp, 0x1000
test   [esp], eax

注意栈指针是如何以4Kb为单位移动的，更重要的是每移动一步后使用test对栈底的处理（more importantly, how the bottom of the stack is “touched” after each step）。这可以确保了在“分配”下一个页之前，包含栈底的页已经被提交。

继续阅读文档的说明：
“每一个新的线程会拥有（receives）自己的栈空间，这包括已经提交的内存和保留的内存。默认情况下每个线程使用1MB的保留内存和一个页大小的以提交内存。如果有必要，系统将从保留内存中提交一个页。”（看MSDN中GreateThread > dwStackSize   > “Thread Stack Size”）

..现在为什么文档中说“这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互”也很清楚了。

E) 为什么我要把多于3个case分支的swith分割开来呢？
同样，用例子来说明会简单些：
int Dummy( int arg1 )
{
     int ret =0;

     switch( arg1 ) {
     case 1: ret = 1; break;
     case 2: ret = 2; break;
     case 3: ret = 3; break;
     case 4: ret = 0xA0B0; break;
     }
     return ret;
}
将会被编译为类似下面的代码：
Address    OpCode/Params     Decoded instruction
————————————————–
                                              ; arg1 -> ECX
:00401000   8B4C2404          mov ecx, dword ptr [esp+04]
:00401004   33C0              xor eax, eax      ; EAX = 0
:00401006   49                dec ecx           ; ECX —
:00401007   83F903            cmp ecx, 00000003
:0040100A   771E              ja 0040102A

; JMP to one of the addresses in table ***
; note that ECX contains the offset
:0040100C   FF248D2C104000    jmp dword ptr [4*ecx+0040102C]

:00401013   B801000000        mov eax, 00000001    ; case 1: eax = 1;
:00401018   C3                 ret
:00401019   B802000000        mov eax, 00000002    ; case 2: eax = 2;
:0040101E   C3                 ret
:0040101F   B803000000        mov eax, 00000003    ; case 3: eax = 3;
:00401024   C3                 ret
:00401025   B8B0A00000        mov eax, 0000A0B0    ; case 4: eax = 0xA0B0;
:0040102A   C3                 ret
:0040102B   90                 nop

; 地址表 ***
:0040102C   13104000          DWORD 00401013    ; jump to case 1
:00401030   19104000          DWORD 00401019    ; jump to case 2
:00401034   1F104000          DWORD 0040101F    ; jump to case 3
:00401038   25104000          DWORD 00401025    ; jump to case 4

看到switch-case是如何实现的了吗？
它没有去测试每个case分支，而是创建了一个地址表（address table）。我们简单地计算出在地址表中偏移就可以跳到正确的case分支。想想吧，这真是一个进步，假设你有一个50个分支的switch语句，假如没有这个技巧，你不的不执行50次CMP和JMP才能到达最后一个case，而使用地址表，你可以通过一次查表即跳到正确的case。使用算法的时间复杂度来衡量：我们把O（2n）的算法替换成了O(5)的算法，其中：
1． O代表最坏情况下的时间复杂度。
2． 我们假设计算偏移（即查表）并跳到正确的地址需要5个指令。

现在，你可能认为上面的情况仅仅是因为case常量选择得比较好，（1，2，3，4，5）。幸运的是，现实生活中的大多数例子都可以应用这个方案，只是偏移的计算复杂了一点而已。但是，有两个例外：
●如果少于3个case分支，或
●如果case常量是完全相互无关的。（比如 1， 13， 50， 1000）。
最终的结果和你使用普通的if-else if是一样的。

有趣的地方：如果你曾经为case后面只能跟常量而迷惑的话，现在你应该知道为什么了吧。这个值必须在编译期间就确定下来，这样才能创建地址表。

回到我们的问题！
注意到0040100C处的JMP指令了吗？我们来看看Intel的文档对十六进制操作码FF的说明：
Opcode    Instruction   Description
FF /4     JMP r/m32    Jump near, absolute indirect, address given in r/m32

JMP使用了绝对地址！也就是说，它的其中一个操作数（在这里是0040102C）代表一个绝对地址。还用多说吗？现在远程的ThreadFunc会盲目第在地址表中004101C然后跳到这个错误的地方，马上使远程进程挂掉了。

F) 到底是什么原因使远程进程崩溃了？
如果你的远程进程崩溃了，原因可能为下列之一：
1． 你引用了ThreadFunc中一个不存在的字符串。
2． ThreadFunc中一个或多个指令使用了绝对寻址（看附录E中的例子）
3． ThreadFunc调用了一个不存在的函数（这个函数调用可能是编译器或连接器添加的）。这时候你需要在反汇编器中寻找类似下面的代码：
:004014C0     push EBP          ; entry point of ThreadFunc
:004014C1     mov EBP, ESP
…
:004014C5     call 0041550      ; 在这里崩溃了
                               ; remote process
…
:00401502     ret
如果这个有争议的CALL是编译器添加的（因为一些不该打开的编译开关比如/GZ打开了），它要么在ThreadFunc的开头要么在ThreadFunc接近结尾的地方

不管在什么情况下，你使用CreateRemoteThread & WriteProcessMemory技术时必须万分的小心，特别是编译器/连接器的设置，它们很可能会给你的ThreadFunc添加一些带来麻烦的东西。

参考（省略）
文章历史（省略）

<结束>