旧文重贴，悼念我的第一个电子邮箱：在同一个进程空间运行两个程序

前天偶然点开了我的网摘（以前一直不知道CSDN这个网摘是怎么回事），竟然发现里面保存了我在2001年写的这篇文章。于是翻了一遍，不想看到了后面留的email地址，勾起了我的伤感回忆。

[email protected]，这是我在互联网上申请的第一个email地址，那还是在1996年的时候，在学校的开放实验室里。记得Forest还拿这个名字打趣过我，说你怎么起了这么个名字，好歹也得叫个dollar什么的呀（fenny和penny发音相近）。记得这篇文章出来后，蒋涛先生还给我发了个email，说想在《程序员》杂志上发表。不幸的是之后不久，由于某种不可知的原因，我的这第一个email地址，就莫名其妙的没了。给163官方发信如石沉大海，当时悲愤之余甚至还想去黑了它的邮件系统。发表之事由于邮箱丢失，失去联系，也就不了了之。旧文重贴，特此悼念我的互联网上第一个电子邮箱。

注：这篇文章发表时Windows XP还没发布，因此运行环境里没写支持Windows XP，答案当然是肯定的。文章最后提到的几个问题，如.tls section的处理，运行三个甚至更多程序，后来都已解决。

再次提醒，想跟我联系的话千万不要再给文章最后的email地址写信。
更新：Remote Run Library的最新代码可以在这里下载。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－  
  运行环境：Windows   NT4.0/Windows   2000  
  关键字：进程隐藏，API截获，映像加载  
  众所周知，bo2k可以在一个指定的进程空间(比如explorer.exe进程)做为一个线程运行。本文试图找出一种方法，使得任意exe都可以在其他进程中以线程运行(当然，这里说的"任意"是有条件的，下面会讲到)。  
  为行文简单起见，我把先加载的exe称为宿主，后加载的exe称为客户。对于上面的例子，explorer.exe为宿主，bo2k.exe为客户。  
  基本知识  
  每一个exe都有一个缺省加载基址，一般都是0x400000。如果实际加载基址和缺省基址相同，程序中的重定位表就不需要修正(fixup),否则，就必须修正重定位表；  
  如果一个程序没有重定位表，而且如果程序不能在缺省基址处加载，那么程序将不能运行。举个例子，Windows95的最低加载基址是0x400000，你在  
  Windows   NT上开发了一个exe，指定其加载基址为0x10000，如果连接时让连接器剥离重定位表，那么他将无法在Windows95下运行。  
  bo2k为了避免和普通程序冲突，选了一个极其特殊的基址：0x03140000，这个地址一般不会有程序用到。这样bo2k启动后，用WriteProcessMemory将自身复制到宿主进程的  
  0x03140000地址处，再用CreateRemoteThread远程启动一个线程，从入口点开始执行。  
  bo2k能够在其他进程空间正常运行，关键有两点：  
  1)实际加载基址和缺省基址相同，这样就无需修正重定位表。  
  2)与bo2k隐性联接(implicitly   link)的动态联接库在目标进程中的加载基址和bo2k启动时的加载基址一致，这样就无需修改导入函数表。除非只用到ntdll.dll和kernel32.dll两个dll，  
  否则这点很难保证。bo2k的解决办法是，远程运行的代码不用隐性调用，所有用到API都在远程代码运行后再动态确定(用LoadLibrary和GetProcAddress)  
  我的目标是让"所有"的程序都能在其他进程空间跑。在这里，"所有"的含义是所有那些"重定位表没有被剥离"的32位pe格式的可执行程序。  
  对于Visual   C++，这包括所有Debug版程序和以"/FIXED:NO"选项链接的Release版程序。  
  对于一般的程序，上面两点都很难满足：  
  1)绝大多数程序的加载基址都是0x400000，这样，客户exe就很难保证加载到其缺省基址。解决办法只能是修正重定位表。如果，很不幸，这个exe的重定位表被剥离，这个exe就没法在其他进程空间跑。  
  对于Visual   C++，剥离重定位表是Release版exe的缺省设置。可以在工程文件的连接选项中加入"/FIXED:NO"来防止连接器剥离重定位表。  
  2)很多程序都用隐性联接调用Windows   API，而只用到kernel32.dll导出API的程序很少，因此这一点也很难保证。解决办法是重填导入表(import   table)。  
  另外，对于有界面的程序，光修正重定位表和导入表还不够。因为他们都会直接或间接用到GetModuleHandle和LoadResource这些函数。  
  GetModuleHandle有个特点，如果传递给他的ModuleName为NULL，则返回宿主exe的模块句柄。LoadResource也类似，如果传递给他的模块句柄为NULL，则认为是宿主exe模块，类似的API还有一些，不一一列举。  
  客户exe调用这些API显然会得到错误的结果。因此必须截获这些API做特殊处理。  
  综合上面分析，要让两个程序共享一份进程空间，要做的工作有：  
  1)打开进程边界：用WriteProcessMemory向宿主进程注入代码，用CreateRemoteThread启动远程代码；  
  2)在远程代码中，加载客户exe，必要时修正重定位表和填充dll导入表。  
  3)截获GetModuleHandle，LoadResource等API，在客户exe以缺省参数调用时返回客户exe的模块句柄，而不是宿主句柄。  
  根据以上思路，我写了remote.dll，导出三个函数：RemoteRunA，RemoteRunW，和RemoteCall。  
  原型分别为：  

BOOL   WINAPI   RemoteRunA(   DWORD   processId,   LPCSTR   lpszAppPath,   LPCSTR   lpszCmdLine,    int    nCmdShow   );  
BOOL   WINAPI   RemoteRunW(   DWORD   processId,   LPCWSTR   lpszAppPath,   LPCWSTR   lpszCmdLine,    int    nCmdShow   );  
BOOL   WINAPI   RemoteCall(DWORD   processId,PVOID   pfnAddr,PVOID   pParam,DWORD   cbParamSize,   BOOL   fSyncronize   );  

  RemoteRunA用于在宿主进程中加载执行客户exe；  
  RemoteRunW是RemoteRunA的unicode版本；  
  RemoteCall实现远程注入并运行代码。  
  调用例子：  
  假如宿主exe为Depends.exe(我经常使用的宿主进程)，pid为136。客户exe为"C:/WINNT/system32/CALC.EXE"，  

RemoteRunA(    136 ,    " C:/WINNT/system32/CALC.EXE " ,   NULL,   SW_SHOW   );  

   或,  

RemoteRunW(    136 ,   L " C:/WINNT/system32/CALC.EXE "