拦截win32 API 调用(上)

拦截win32 API 调用(上)

原文出处： http://www.codeproject.com/system/hooksys.asp
     拦截win32 API 调用对于多数windows开发人员来说都一直是很有挑战性的课题，我承认，这也是我感兴趣的一个课题。钩子机制就是用一种底层技术控制特定代码段的执行，它同时提供了一种直观的方法，很容易就能改变操作系统的行为，而并不需要涉及到代码。这跟一些第三方产品类似。
     许多系统都通过拦截技术（spying techniques）利用现有windows应用程序。而拦截的一个重要目的，并不只是为应用程序提供更高级功能，而是为完成调试。
     与老式操作系统（如dos，win3.xx）不同，现有操作系统（如WINNT/2K和win9X）使用了成熟的机制来分隔各进程的地址空间。这种架构提供了真正的内存保护，因此任何应用程序都不能破坏属于其它进程的地址空间，更不可能破坏操作系统本身。这使得开发系统相关的钩子（system-aware hooks）变得十分困难。
     我写这篇文章就是要探讨一种简单实用的钩子机制，它提供了一个简单的接口，用来拦截不同的API调用。它也示范了一些技巧，可以帮助你开发出自己的api拦截程序（spying system）。同时它还提供了一系列在WIN2K/NT和WIN98/ME（下面简称9X）等windows上拦截WIN32 API 的方法。为了简化我的描述，我没有引入UNICODE的相关内容。但你只需对代码作一些微小改动就能支持UNICODE。

拦截应用程序（Spying of applications）有许多好处：
1．监视API函数
     有助于控制API调用，也让开发人员在API调用期间跟踪到应用程序特定的“不可见”动作。它有助于开发人员全面掌握程序的细节（comprehensive validation of parameters），也有助于发现潜在问题。例如，有时候，它能便于监视内存管理API引起的资源泄漏。
2．调试和逆向工程
     除了一般的调试方法，API钩子也是一种值得称道的非常流行的调试方式。许多开发人员用钩子来区分不同组件的执行以及它们之间的关联。因此它也用于获取二进制可执行文件的信息。
3．深入操作系统内部
     通常开发人员都热衷于深入了解操作系统并扮演着“调试者”的角色。钩子机制也是用于解码未公开的或不为人知的API的有力技术。
4．扩展已有功能
     可以向外部的windows应用程序嵌入自定义模块、增强原有函数的功能，这需要借助钩子来重定向原有代码的执行序列（让系统在执行原有代码过程中执行用户自定义代码），从而扩展现有模块的功能。例如，许多第三方软件产品并不遵循指定的安全规则而只满足用户特定的使用需求。拦截应用程序允许开发者在原有API执行之前或之后添加属于用户自己的代码。这有助于改变已经编译好的代码的行为。
对拦截系统的功能需求
     在实现任何形式的API拦截系统之前，都必须先做一些慎重考虑。首先，你要决定是开发对单个程序的钩子还是全局钩子。例如，假设你只希望拦截一个程序，就不必安装全局钩子了；但如果要监视一切对TerminateProcess() 和WriteProcessMemory()的调用，唯一的办法就是使用全局钩子。选用何种方法都取决于特定的环境和要解决的问题。

API拦截架构的概要设计
     通常拦截系统由至少两部分组成——一个钩子服务器（Hook Server）和一个驱动（Driver）。钩子服务器用于在合适时机把驱动注入目标进程，它也可以管理驱动，甚至可以通过注入点获取驱动的工作情况。这样的设计比较粗略，很明显它并未涉及所有可能的实现方式。但这已经能够描述API拦截的框架了。

     如果需要实现特定的钩子架构，应该慎重考虑下面几点：
     a 要拦截什么程序
     b 如何向目标进程注入DLL或者说应用何种注入技术
     c 使用何种拦截机制
     希望读者可以从以下章节找到答案。

注入技术
1．注册表
如果要向加载了USER32.DLL的进程注入DLL，只需向如下注册表键写入DLL的名称：
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
     上述表键的值可包含单个或成组用逗号（,）或空格分隔的DLL名称。根据MSDN文档[参考7]，所有包含在上述键值内的DLL，都会被任何运行在当前用户登陆空间（current logon session）的windows应用程序所加载。有趣的是，实际上，这些DLL的加载过程其实是USER32初始化过程的一部分。USER32读取上述键值并为这些DLL的入口调用LoadLibrary()。但这种方法只适用于那些加载了USER32.DLL的程序。另外一种限制是，这种内置的机制只适用于windows2k/nt系统。这是一种安全的DLL注入方法，但有以下缺点：
     a． 激活或撤销进程注入必须重启windows
     b． 被注入的DLL只被映射到那些加载了USER32.DLL的进程，所以这种方法至少不能注入控制台程序，因为它们根本不必导入USER32的函数。
     c． 另外一方面，注入方不可能控制注入过程。就是说，DLL被注入了所有GUI程序，不管注入方是否有这样的需求。在只需要拦截少量程序的情况下，这样会显得多余。更多信息请参考[参考2]“利用注册表注入DLL”。

2．全局Windows钩子
     的确，另外一种很流行的DLL注入方法来自windows钩子。MSDN指出这种钩子是系统消息处理机制中添加的陷阱。应用程序可以通过安装钩子来监视系统中的消息流（message traffic），并在消息到达特定窗口过程之前处理它们。
     根据系统底层要求，这种全局钩子一般在DLL内实现。它的基本原理是，钩子回调过程在被拦截进程的地址空间内被调用。通过调用SetWindowHookEx()并加入合适的参数来安装一个钩子。一旦这种全局钩子安装好，操作系统就会把DLL映射到目标进程的地址空间。此时，DLL内的全局变量就变成局限于单个进程（per-process），不能被各目标进程共享。因此，所有需要共享的变量应该被放置在共享数据段。下图展示了一个例子：钩子服务器注册一个钩子并将其注入到名为“Application one”和“Application two”的进程的地址空间。

图1

     每当SetWindowsHookEx()执行，全局钩子就会被注册一次。一切正确时函数将返回该钩子的句柄。在用户自定义的钩子回调过程末尾调用CallNextHookEx()时将要用到上述句柄。成功调用SetWindowsHookEx()后，操作系统就会自动把这个DLL注入到符合要求的所有进程的地址空间，但并不一定是立即注入。下面具体来看过滤WH_GETMESSAGE消息的函数体：
//---------------------------------------------------------------------------
// GetMsgProc
//
// Filter function for the WH_GETMESSAGE - it's just a dummy function
//---------------------------------------------------------------------------
LRESULT CALLBACK GetMsgProc(
int code,        // hook code
WPARAM wParam,   // removal option
LPARAM lParam    // message
)
...{
// We must pass the all messages on to CallNextHookEx.
return ::CallNextHookEx(sg_hGetMsgHook, code, wParam, lParam);
}
      全局钩子被多个不共享相同地址空间的进程加载。例如，钩子句柄sg_hGetMsgHook会被SetWindowsHookEx()函数获取并作为参数用于CallNextHookEx()，它必须在各进程的地址空间中使用。就是说，该句柄的值必须被客户进程和拦截服务器共享。因此，钩子句柄应该放置在共享数据段中。
      以下例子调用了#pragma data_seg()编译预处理语句（使用共享数据段）。在此，我要提醒一下，共享数据段内的变量必须初始化，否则它们将会被放置在默认数据段，同时#pragma data_seg()语句也会失效。
//---------------------------------------------------------------------------
// Shared by all processes variables
//---------------------------------------------------------------------------
#pragma data_seg(".HKT")
HHOOK sg_hGetMsgHook        = NULL;
BOOL sg_bHookInstalled     = FALSE;
// We get this from the application who calls SetWindowsHookEx()'s wrapper
HWND sg_hwndServer         = NULL;
#pragma data_seg()

同时应该添加SECTIONS语句到DLL的DEF文件，如下所示：
SECTIONS
          .HKT    Read Write Shared
或使用
#pragma comment(linker, "/section:.HKT, rws")

     一旦钩子DLL被加载到目标进程的地址空间，要卸载该钩子的话除了拦截服务器调用UnhookWindowHookEx()函数或客户进程退出就没有其他办法了。当拦截服务器调用UnhookWindowHookEx()函数时，操作系统就会扫描一个列表，这个列表包含了所有加载了钩子dll的进程。这时操作系统会（根据列表内进程数量）相应递减钩子DLL的锁定计数，当这个计数变为0，DLL就会从对应进程的地址空间删除。
      下面列举了上述方法的一些好处。
      a．这种机制都被WINNT/2K和9X系列的操作系统所支持，后继版本的windows系统也有望支持这种机制。
      b．跟注册表注入机制不同，当拦截服务器不再需要钩子DLL时，可以调用UnhookWindowsHookEx()卸载钩子。
      尽管我认为windows钩子方便实用，但它不可避免存在下列缺点：
      a．windows钩子会明显减低windows的性能，因为它增加了系统处理每个消息时所需开销。
      b．要调试全局钩子很麻烦。但如果你同时运行多于一个vc++实例，就会发现在复杂情况下这样调试反而简单些。
      c．最后一个不容忽视的问题，这种钩子会影响整个系统，在特定环境下（钩子中有bug），需要重启系统来恢复它。

3．用CreateRemoteThread()函数远程注入DLL
     这是我最喜欢的一种注入方式。不幸的是只有NT和2K系统支持。该函数的独特之处在于，它也可以在windows9x上被执行，但只返回NULL而不做任何操作。
     远程注入DLL是Jeffrey Ritcher发明的，并记录在他的文章[参考9] "Load Your 32-bit DLL into Another Process's Address Space Using INJLIB"中。
     基本原理简单且巧妙。任何进程都可以调用LoadLibrary()来动态加载DLL。问题是当我们缺乏对目标（外部）进程子线程的访问权限时，如何根据自己的意愿强制外部进程调用这个函数？这里要用到CreateRemoteThread()函数了，它可以远程产生线程。这里有个窍门——且看线程体函数的原型，它的指针（类型为LPTHREAD_START_ROUTINE）被作为参数传递给了CreateRemoteThread()：
DWORD WINAPI ThreadProc(LPVOID lpParameter);
     下面是LoadLibrary()的原型：
HMODULE WINAPI LoadLibrary(LPCTSTR lpFileName);

     它们都有相似之处。它们都使用相同的WINAPI调用约定，它们都接受一个参数，且返回值的长度也是一样的。上面的比较告诉我们，可以把LoadLibrary()作为线程体，这样它就可以在远程线程产生后被执行。接下来看下面的示例代码：
hThread = ::CreateRemoteThread(
           hProcessForHooking,
           NULL,
           0,
           pfnLoadLibrary,
           "C:HookTool.dll",
           0,
           NULL);
          
     调用GetProcAddress()可以获取LoadLibrary()的地址。很巧妙的一点是，KERNEL32.DLL总是被映射到进程地址空间的相同位置，因此在每个进程中，LoadLibrary()的地址总是相同的。这就保证了CreateRemoteThread()接收到的参数总是一个有效指针。
     我们用DLL的绝对路径作为线程体函数的实参，并转换成LPVOID类型。远程线程运行时，它会把DLL的路径传递给线程体函数（LoadLibrary）。上述就是用远程线程注入dll的全部窍门。
     在此需要慎重考虑的是，是否使用CreateRemoteThread()实现远程注入。每当注入程序访问目标进程的虚拟地址空间之前都要调用CreateRemoteThread()，它首先会用OpenProcess()打开目标进程，并传递PROCESS_ALL_ACCESS标志作为实参，这样对目标进程会有最高访问权限。这种情况下，OpenProcess()对于某些低ID(low ID)进程会返回NULL。这是因为，尽管使用合法的进程ID，但注入程序的上下文所具有的权限还不足以访问目标进程。稍思考片刻，你立即会发现这其实很必要。所有被严格限制访问的进程都是操作系统的一部分，因此普通进程不应该访问它们。如果一些存在bug的进程突然试图终止一个操作系统的进程会发生什么事情呢？为了避免操作系统上发生这些问题，应用程序需要具备足够的特权才能调用那些改变操作系统行为的API，要通过OpenProcess()访问操作系统资源（例如smss.exe，winlogon.exe，services.exe等），你必须具有调试特权级（debug privilege）。这是一种非常强大的功能，它提供一种访问操作系统资源的途径，这通常是被限制的。调整进程特权级的过程比较麻烦，可以描述如下：
     a．用目标特权级所需访问许可打开进程记号(processs token)
     b．为了指定特权级名称“SeDebugPrivilege”，必须定位它的本地LUID映射。各个特权级都被冠以名称并可以在平台SDK的winnt.h中找到。
     c．调用AdjustTokenProvileges()函数以调整进程记号（token），这样就使得“SeDebugPrivilege”特权生效。
     d. 关闭通过OpenProcessToken()函数获得的进程记号句柄。
     关于改变特权级的更多信息可以参考[参考10]“using privilege”。

4．通过BHO插件注入
     有时候我们只想把自定义代码注入Inernet Explorer。幸运的是，微软公司为这样的需求提供了一种简单且有详细文档记录的解决方法——浏览器辅助对象（BHO）。BHO用COM DLL实现，而且一旦正确注册，以后每当IE加载，所有实现了IobjectWithSite接口的COM组件都会随之一起加载。

5．微软Office插件
     与BHO插件类似，如果要向微软office系列应用程序注入用户自定义代码，只需借助微软提供的高级机制来实现office插件，以达到上述目的。很多现成代码展示了如何实现这类插件。
拦截机制
     向外部进程注入DLL是拦截系统的关键环节。它提供了控制外部线程活动的极好机会。尽管如此，这样还不足以拦截API调用。
     本部分将会对现实世界中的API拦截方法作一个概述，并着眼于每种方法的要点，同时揭示它们各自的优点和缺点。
     根据所使用钩子的层次，可以把拦截API的钩子机制分为两种——内核级和用户级。要更好的理解这两种层次，就必须掌握win32子系统API和内部API（Native API）之间的关系。下图解释了不同层次的钩子所在的位置，并说明了在Windows 2k系统上，各个模块的关系以及它们的依赖性。

图2

     在实现上主要的不同点在于内核级拦截引擎用内核模式驱动程序实现，而用户级钩子通常以用户模式DLL实现。

1．NT内核级钩子

     在内核模式中有几种方法拦截NT系统服务。最流行的方法在Mark Russinovich和Bryce Cogswell的文章[参考3]"Windows NT System-Call Hooking"中有详细描述。其基本思想是，在用户模式下实现监视NT系统调用的拦截机制。这种技术非常强大，它提供了一种灵活的方法，在系统内核处理用户线程请求前将其拦截下来。
     你可以在 "Undocumented Windows 2000 Secrets" 中找到上述机制的极好设计和实现。在这本书中，Sven Schreiber 解释了如何从零开始建立一个内核级钩子框架[参考5]。
     另外一个全面分析和高明的实现来自Prasad Dabak所著的[参考17]"Undocumented Windows NT"。尽管如此，所有上述的拦截策略都超出了本文的讨论范围。
2．Win32用户级钩子
A. 窗口子类
     这种方法适用于那些会根据不同窗口过程的实现而具有不同行为的应用程序。要完成上述工作（通过更改窗口过程来执行用户自定义代码），只需对该特定窗口简单调用SetWindowLongPtr()，传递GWLP_WNDPROC和用户自定义窗口过程的指针作为实参即可。一旦建立好用户自定义窗口过程，以后windows每次分发消息到目标窗口时，都会调用用户自定义的窗口过程了。
     这种机制的缺点是，子类只在指定进程（当前进程）边界范围内（the boundaries of a specific process）有效。就是说，应用程序不能为其它进程创建的窗口建立窗口子类。
     通常，这种方法适用于通过插件拦截应用程序，这样就能够取得要替换窗口过程的窗口的句柄了。
     例如，以前我写过一个简单的IE插件（BHO），它通过窗口子类把IE的浮动菜单替换掉。
B. 代理DLL（DLL木马）
     拦截API的另一种简单方法是，用具有相同名称、相同导出符号的DLL替换掉应用程序原来的DLL。借助函数导出节（function forwarders）实现这种技术会很容易。从根本上说，函数导出节就是DLL入口处的导出节，它代表本模块与其它DLL的函数调用关系。
     你可以简单使用#pragma comment完成以上工作：
       #pragma comment(linker, "/export:DoSomething=DllImpl.ActuallyDoSomething")
     如果你决定使用这种方法，你应该自行处理库新旧版本之间的兼容性问题。更多信息请参考[参考13a]“Export forwarding”和[参考2]“Function Forwarders”。

C. 代码重写（Code Overwriting）
     很多函数拦截的方法都基于代码重写。其中一种通过改变call指令的目标地址实现代码重写。这种方法使用困难，而且容易出错。基本思想是，拦截内存中所有的call指令并以用户提供的地址替换其原来的函数地址。
     代码重写的另一种方法实现起来更复杂。简单说，基本思想就是先定位原有API函数地址，然后通过jmp指令改变函数体前几个字节来重定向到用户自定义的API函数去执行。这种方法需要极强技巧性，并涉及到对每个call调用的一系列恢复和拦截操作。要指出的一点是，如果函数处于未被拦截的状态（unhooked mode）并且该函数正被调用，则将不能拦截到对该函数的下一次调用。
     上述方法的主要问题是，它跟多线程环境中的线程规则相冲突。
     尽管如此，还是有巧妙解决方法的，它解决了一些问题并提供了可以基本实现API拦截的成熟的方法。如果对上述问题有兴趣，可以查看[参考12]的Detours解决方案。

D．通过调试器拦截api调用
     另一个替代的方法是在目标函数内插入断点。但这种方法也有些缺点。主要问题是抛出调试异常时（debugging exceptions）会挂起当前应用程序所有子线程的执行。还需要一个调试线程处理这个异常。另一个问题是，当调试过程（debugger）完成时，windows就会把调试器关闭。
E．通过改变导入地址表拦截api调用
     这种技术最初由 Matt Pietrek 公布，后来由 Jeffrey Ritcher （[参考2] “通过操作模块的导入节实现API拦截”）和 John Robbins （[参考4]“拦截导入函数”）加以详细描述。这是种强大简单而且容易实现的方法，也满足在winNT/2k和9x上运行拦截系统的大部分需求。这种技术基于windows的可执行文件结构。要理解这种方法的工作过程，必须熟悉PE文件结构，它是通用文件对象格式（COFF）的扩展。Matt Pietrek 在[参考6]“深入PE格式”以及[参考13a/b]“win32PE格式深度透视”中详述了PE格式的相关细节。我将给出PE格式的概述，旨在让读者明白通过操作导入表实现api拦截的思想。
     通常来说，一个PE二进制文件的格式是经过组织的，因此它具有代码节（code sections）和数据节（data sections），这与可执行文件在内存中的格式是一致的。PE文件格式在逻辑上由几个节组成，每个节维护特定的数据，并符合操作系统程序加载器的特定要求。
     请注意 .idata节，它包含导入地址表的信息。这部分信息对于一个更改IAT拦截api调用的系统相当重要。
     符合PE格式的可执行文件都具有下图所述的结构：
图3
     应用程序加载器负责把应用程序以及与它相链接的DLL加载到内存，由于这些DLL被加载到的内存地址是不可预料的，因此加载器不能断定各个导入函数的实际地址。加载器必须做一些额外工作来保证应用程序能成功调用每个导入函数。但是对于内存中的每个可执行文件映像，逐个修改它们的每个导入函数会花费大量的处理器时间并导致性能下降。那么，加载器是如何处理这个问题的呢？关键在于，对同一个导入函数的每次调用都指向相同地址，那就是函数代码驻留在内存的位置。实际上对导入函数的调用都是间接调用，即通过一条间接JMP指令并结合IAT实现寻址。这样的好处是加载器不需要扫描整个可执行映像。这种方法看上去很简单，它仅仅是改变IAT内导入函数的地址。这里是一个简单win32程序的PE结构的示例，并借助了[参考8]的PEView 工具。可以看到TestApp导入表包含了两个由GDI32.DLL导出的函数：TextOutA() 和 GetStockObject()。

图4
     实际上拦截一个导入函数并没有那么难。总之，一个通过修改IAT来拦截api的拦截系统需要找出IAT中存储的导入函数地址，并用自定义函数的地址覆盖它。这个用户自定义的函数必须和被替换函数的原形一致，这点很重要。下面是替换的步骤：
     1、对于目标进程以及它加载的每个DLL，都要通过IAT定位导入节的位置。
     2、找到导出目标函数的DLL的IMAGE_IMPORT_DESCRIPTOR 束。实际上，我们通过DLL的名称来找到这个入口。
     3、找到含有目标函数地址的IMAGE_THUNK_DATA 束。
     4、用自定义函数的地址替换原有地址。
     要改变IAT内导入函数的地址，我们必须保证所有对目标函数的调用都被重定向（re-routed）到钩子函数。
     还有一点是，需要改写的 .idata 节不一定都是可写的，这就要求我们保证 .idata 节可写。可以调用 VirtualProtect() 来实现。
     另一点值得注意的是，GetProcAddr() 函数在win9x系统上的行为。当一个程序在非调试模式调用这个API，它会返回目标函数的指针；但如果在调试时调用，它会返回一个与上述指针不同的地址。这是由于在调试的时候，GetProcAddr() 返回的是指向目标函数指针的指针。这个指针指向一条带有目标函数地址的PUSH指令。就是说，在win9x系统上迭代（IMAGE_THUNK_DATA）束时，我们必须检查这个函数指针是否带有PUSH指令（在x86平台上是0x86），并相应地获取函数的实际地址。
     Win9x并不支持写时拷贝，因此操作系统会尝试阻止调试器访问2GB边界以上的函数。这就是GetProcAddr() 返回调试指针（debug thunk）而不是实际地址的原因。John Robbins 在[参考4]“拦截导入函数”中讨论了这个问题。
注入拦截DLL的时机
     在此前已经讨论过，选择的注入机制并不是操作系统本身的固有机制时开发人员所面临的困难。例如，当使用内置的windows钩子注入DLL时，注入机制就不是开发人员所要关心的问题。强制每个符合要求的进程加载DLL[参考18]，这是操作系统需要完成的工作。事实上，windows跟踪所有新建立的进程并强制它们加载钩子DLL。通过注册表来管理dll注入与windows 钩子类似。这些方法的最大的好处是它们本身就是操作系统的一部分。
     与上述注入机制不同的是，利用CreateRemoteThread() 的注入方法还要求维护当前运行的进程列表。如果没有及时注入，拦截系统将会丢失一些原本需要拦截的api调用。每当一个新进程开始或关闭时，钩子服务器（Hook Server）都要使用一种巧妙的方法来接收相关的通知，这很重要。其中一种方法，是通过拦截并监视CreateProcess() 系列的API函数的调用（来获得进程开启或关闭的通知）。这时当用户自定义函数被调用，它就可以通过添加Create_SUSPENDED标志调用原来的CreateProcess()。这意味着目标进程的主线程将被挂起，同时钩子服务器将有机会利用手写的机器码指令把DLL注入到目标进程，然后使用ResumeThread() 唤醒目标进程。细节可以参考[参考2]“利用CreateProcess()远程注入代码”。
     另一种检测进程执行的方法，是基于驱动程序的。值得关注的是它极高的灵活性。Windows nt/2k 提供了一个由NTOSKRNL导出的名为 PsSetCreateProcessNotifyRoutine() 的函数，这个函数允许增加一个回调函数，每当有进程产生或终止时这个回调函数都被调用。更多细节请参见[参考11]和[参考15]。
枚举进程和模块
     有时候我们希望利用CreateRemoteThread() API来注入DLL，特别是当拦截系统运行在windows NT/2K上。这种情况下，钩子服务器启动后都会枚举所有活动进程并把DLL注入它们的地址空间。Windows 9x和windows2k 都内置了这种进程枚举机制（Tool Help 库，辅助库）的实现（由Kernel32.dll实现）。另一方面，windowsNT使用PSAPI库达到相同目的。于是，我们需要一种能够令钩子服务器正确运行并动态决定当前可用“帮助库”的途径。因此，拦截系统被设计成可以判断当前操作系统支持何种帮助库，并相应采用合适的API。
     我将要展示一个以面向对象为基础的简单框架，它用于在windows9x以上操作系统枚举进程和模块。我的设计允许用户根据自己的需求来扩展框 架的功能。框架的实现也是相当简单明了的。
     CTaskManager类实现了整个枚举子系统的处理核心，它负责生成一个进程枚举库对象（例如CPsapiHandler 或 CToolhelpHandler）来调用正确的进程信息提供库（例如在9x和2k上分别是psapi和toolHelp32）。CTaskManager也负责产生和维护一个记录当前所有进程列表的容器对象。在CTaskManager实例化之后，拦截系统调用Populate()函数。这个函数强制性地枚举系统中所有进程和dll库并把它们的信息保存在CTaskManager的成员m_pProcesses中。
     下面的uml图展示了上述子系统各个类之间的关系：


图5

     此处要着重指出的一条是，事实上，windowsNT的Kernel32.dll并没有实现任何的ToolHelp32函数。因此我们必须使用运行时动态链接的方式额外链接这些函数。在windowsNT上如果使用静态链接，那么不论应用程序是否曾经试图调用任何ToolHelp32函数，代码都会运行失败。更多信息请参见我的文章“在windows9x/2k和windowsNT上枚举进程和模块的单一接口”。

建立钩子工具系统（Hook Tool System）的必要条件
     目前我已经对拦截过程中用到的各种原理概念作了简短介绍，现在是时候来确定建立一个拦截系统的必要条件，并研究其详细设计了。下面是有关这个系统的一些总结：
     1）提供用户级拦截系统，对通过名字导入的win32 api函数实施拦截
     2）提供一种方法，可以用windows钩子 或远程线程把拦截驱动注入到所有正在运行的进程。拦截系统应该提供ini文件来选择使用何种方式
     3）使用一种基于更改iat的拦截方法
     4）拦截系统的架构是基于面向对象技术的、可重用的、可扩展的和分层的
     5）用一种高效的可扩展的机制来拦截api函数
     6）（整个系统）能够达到预期的性能要求
     7）在拦截驱动和钩子服务器之间使用一种可靠的数据传输机制
     8）实现TextOutA()、TextOutW()以及ExitProcess()的拦截
     9）把拦截过程发生的事件都记录在日志中
     10）拦截系统可以运行在任何基于Intel x86架构的windows9x或以上的操作系统