《Undocumented Windows 2000 Secrets》翻译 --- 第五章（3）

第五章  监控Native API调用

翻译：Kendiv( fcczj@263.net )

更新： Thursday, March 24, 2005

 

 

声明：转载请注明出处，并保证文章的完整性，本人保留译文的所有权利。

 

 

本书设计的hook机制的最大特色就是它是完全数据驱动的（data-driven）。只需简单的增加一个新的API符号表，该hook dispatcher就可适应Windows 2000的新版本。而且，通过向apdSdtFormats[]数组中加入新的API函数的格式化字符串就可在任何时候记录对这些附加的API函数的调用。这并不需要编写任何附加的代码---API Spy的动作可完全由一组字符串来确定！不过，在定义新的格式化字符串是必须要小心，因为w2k_spy.sys是运行于内核模式的驱动程序。因为在这一系统层次上，系统不能温和的处理发生错误。给Win32 API函数提供了一个无效的参数并不是问题-----你会收到一个错误提示窗口，同时程序会被系统自动终止。在内核模式下，一个微小的访问违规都会引发系统蓝屏。因此，一定要小心。在需要的地方如果没有出现一个正确的格式化控制ID或缺失了这一ID都会使你的系统彻底崩溃。即使一个简单的字符串有时都是致命的！

 

 

现在仅剩SpyHookInitializeEx()中的那一大块ASM代码还未讨论，这段代码由SpyHook2和SpyHook9标识。这段代码的一个有趣的特性是：在SpyHookInitializeEx()被调用的时候，它们从来都不会被执行。在进入SpyHookInitializeEx()后，函数代码将跳过这一整段代码，然后在SpyHook9标签处开始恢复执行，此处包含aSpyHooks[]数组的初始化代码。这一大块ASM代码只有通过aSpyHooks[]数组中的Handler成员才能进入。稍候，我将展示这些进入点是如何连接到SDT的。

 

 

在设计这段ASM代码时，我的重要目标之一就是使其是完全非侵入式的。截获操作系统调用非常危险，因为你从来不会知道被调用的代码是否会依赖调用上下文（calling context）的某些未知特性。理论上来说，这些ASM代码完全符合__stdcall约定，但仍存在出错的可能性。我不得不选择将原始的Native API处理例程放入几乎完全相同的环境中，这意味着这些原始函数将使用最初的参数堆栈并且可以访问所有的CPU寄存器，就像它们被正常调用一样。当然，必须接受由于插入hook所带来的最低限度的危险，否则，监控将不可能实现。在这里，有意义的改动就是维护堆栈中的返回地址。如果你翻回到图5-3，你会发现在进入函数时，调用者的返回地址并不位于堆栈的顶部。SpyHookInitializeEx()中的hook dispatcher占用了此地址，将它自己的SpyHook6标签的地址写在了这里。因此，原始Native API处理例程将被打断，然后进入SpyHook6中，这样hook dispatcher才能检查原始Native API处理例程的参数和它要返回的数据。

 

 

在调用原始处理例程之前，dispatcher将建立一个SPY_CALL（参见列表5-3）控制块，该控制块中包含它稍候将会用到的参数。其中的一些参数在正确记录API调用时会用到，另外一些则提供了有关调用者的信息，因此dispatcher可以在写完log后，把控制返回给调用者，就像什么都没有发生一样。Spy设备在它的全局数据块DEVICE_CONTEXT中维护着一个SPY_CALL结构的数组，可通过全局变量gpDeviceContext来访问。Hook Dispatcher通过检查SPY_CALL结构中的InUse成员来在数组中找到一个空的SPY_CALL。Hook Dispatcher使用CPU的XCHG指令来加载和设置该成员的值（译注：XCHG指令可以保证此操作为原子操作）。这一点非常重要，因为当代码运行于多线程环境中时，读写全局数据时必须采取保护措施以避免条件竞争。如果在数组中找到了一个空的SPY_CALL，dispatcher就会将调用者的线程ID（通过PsGetCurrentThreadId()获取）、与当前API函数相关的SPY_HOOK_ENTRY结构的地址以及整个参数堆栈保存到该SPY_CALL结构中。需要复制的参数的字节数取自KiArqumentTable数组，该数组保存在系统的SDT中。如果所有的SPY_CALL都被使用了，原始的API函数处理例程将被调用而不会产生任何日志记录。

 

 

必须采用SPY_CALL数组是因为Windows 2000的多线程本性。当Native API函数被暂停（suspended）时，这种情况就会经常出现----此时，另一个线程将获得控制权，然后在它自己的时间片（time slice）内调用另一个Native API函数。这意味着Spy设备的Hook Dispatcher必须允许在任何时间和任何执行点上的重进入（reenter）。如果Hook Dispatcher有单一的全局SPY_CALL存储区域，它就可能在处于等待状态的线程使用完之前被当前运行的线程覆写（overwritten）。而这种情况正是蓝屏的最佳候选人。为了进一步了解Native API的嵌套，我在Spy的DEVICE_CONTEXT结构中增加了dLevel和dMisses成员。无论何时只要重进入hook dispatcher（如，向SPY_CALL数组中增加一个新的SPY_CALL）dLevel都不会累加一个1。如果超过了最大嵌套层数（如，SPY_CALL数组已满），dMisses就会累加一个1，来标识丢失了一个日志记录。根据我的观察，在实际环境下，可以很容易的发现嵌套层达到4。这表示即时在高负载（heavy-load）的情况下，Native API也会被重进入，因此，我将嵌套层数的上限设为256。

 

 

在调用原始的API处理例程之前，Hook Dispatcher会保存所有的CPU寄存器（包括EFLAGS），随后执行路径将导向函数的进入点。这会在列表5-3中的SpyHook5标签之前立即完成。此时，SpyHook6将位于栈顶，仅随其后的是调用者的参数。一旦API处理例程推出了，控制将被传回到hook dispatcher的SpyHook6标签。从此处开始执行的代码也被设计为非入侵的。此时，主要目标是允许调用者可以看到调用上下文，这和原始API函数建立的上下文几乎完全一致。Dispatcher的主要问题是要能立即找到保存有当前API调用信息的SPY_CALL结构。唯一可以依赖的就是调用者的线程ID，该ID保存在SPY_CALL结构的hThread成员中。因此，Dispatcher循环遍历整个SPY_CALL数组以寻找匹配的线程ID。注意，代码不会关心fmuse标志的值；这并不是必须的，因为数组中所有未使用的SPY_CALL结构的hThread都被设为了0，这是系统空闲线程的ID。循环会在到达数组结尾时终止。否则的话（译注：即没有找到匹配的线程ID），Dispatcher不会将控制返回给调用者，因为这样做将是致命的。在这种情况下，代码的选择余地很小，因此，它会进入KeBugCheck()，这样做的结果当然是使系统以受控的方式终止。不过这种情况应该从来不会发生，但如果它发生了，那表示系统必然出现了很严重的错误，因此，使系统终止是最佳解决方案。

 

 

如果发现了匹配的SPY_CALL，Hook Dispatcher将结束它的工作。最后的动作是调用日志记录函数SpyHookProtocol()，需要给该函数传入一个指向SPY_CALL结构的指针。日志记录所需的信息都保存在该结构中。当SpyHookProtocol()返回后，Dispatcher就释放它刚才使用的SPY_CALL，恢复所有的CPU寄存器，然后返回到调用者。

 

 

 

 

API HOOK协议

一个好的API Spy应该可以在原始函数被调用后还能察看它使用的参数，因为函数可能会通过传入的缓冲区返回附加的数据。因此，日志函数SpyHookProtocol()在hook例程结束时将被调用，而此时API函数还未返回到调用者。在讨论它的实现秘诀之前，请先看看下面给出的两个示例性的协议（Protocol），它们会为你提供一个大概的方向。图5-6是在命令行下执行dir c:/时产生的日志文件的快照。

 

 

请对比图5-6中列出的日志项和列表5-6给出的协议格式化字符串。在示列5-1中，NtOpenFile()和NtClose()的格式化字符串分别对应图5-6中的第一行和第四行。它们有着惊人的相似处；每一个格式化控制ID都紧随在一个%号后（参考表5-2），与其相关的参数项将包含在协议中。不过，协议还包含一些附加的信息，这些信息明显不属于格式字符串。稍后我将解释这种差异的原因。

 

 

示例5-2给出了一个协议项的一般格式。每一项包含相同个数的域，这些域采用分隔符隔开。这样分隔可以使程序很容易的解析它。这些域按照如下的一组简单的基本规则来构建：

l         所有的数字都已十六进制表示，没有0前缀或常见的前缀“0x”

l         函数的多个参数由逗号隔开

l         字符串参数将位于一对双引号中

l         结构体成员的值由“.”符号隔开

 

 

图5-6.  命令dir c:/的示列协议

 

 

"%s=NtOpenFile(%+,%n,%o,%i,%n, %n) "

18:sO=NtOpenFile(+46C.18,nl00001,o"/??/C:/",i0.1,n3,n4021)lBFEE5AE05B6710,278,2

 

 

"%s=NtClose(%-l)"

lB:sO=NtClose(-46C.18="/??/C:/")lBFEE5AE05B6710,278,l

示列5-1.  比较格式化字符串和协议项

 

 

<#> : <status>=<function> (<arguments>) <time> , <thread>, <handles>

示列5-2.  协议项的一般格式

 

 

l         与句柄相关的对象名称和句柄的值采用“=”进行分割。

l         日期/时间的stamp为1601-01-01至今逝去的毫秒数，其格式依赖Windows 2000的基本时间格式，精度可达到1/10毫秒。

l         线程ID是调用API函数的线程的唯一数字标识。

l         句柄计数的状态表示当前注册到Spy设备句柄列表中的句柄的数量。协议函数使用该列表查找与对象名称相关的句柄。

 

 

图5-7.  命令type c:/boot.ini的示列协议

 

 

图5-7是在控制台中执行：type c:/boot.ini命令产生的API Spy协议结果。下面给出日志项中的某些列的含义：

l         在0x31行，调用了NtCreateFile()来打开/??/c:/boot.ini文件。（o”/??/c:/boot.ini”）该函数返回的NTSTATUS的值为0（s0），即STATUS_SUCCESS，并分配了一个新的文件句柄，其值为0小8，该句柄属于进程0x46c（+46C.18）。因此，句柄计数从1增加到2。

l         在0x36行，type命令将文件/??/c:/boot.ini的前512个字节（n200）读入位于线性地址0x0012F5B4处的缓冲区中，并把从NtCreateFile()获取的句柄解析给NtReadFile()函数。系统成功的返回512字节（io.200）。

l         在0x39行，将处理另一块512个字节的文件块。这一次，将到达文件的末尾，因此NtReadFile()仅返回了75个字节（io.4B）。显然，我的boot.ini文件的大小为：512+75=587字节。

l         在0x3C行，NtClose()成功的释放了指向/??/c:/boot.ini的文件句柄（-46.18=”/??/c:/boot.ini”），因此，句柄计数将从2减少为1。

 

 

现在，你应该已经明白Spy协议的API是如何构建的了，这会帮助你掌握协议生成机制的细节，接下来我们将讨论这一机制。在前面我曾提及过，用于日志记录的主要API函数是SpyHookProtocol()。列表5-7给出了该函数，它将使用SPY_CALL结构中的数据来为每个API函数生成一个协议记录并将其写入一个环形缓冲区中，这里的SPY_CALL结构由Hook Dispatcher传入。一个Spy设备的客户端可以通过IOCTL调用来读去这一协议。每个记录项都是一行文本，每行都由单个行结束符（即C语言中的”/n”）表示行的结束。通过使用内核的Mutext KMUTEX kmProtcol来实现串行读去协议缓冲区，kmProtocol位于Spy设备的全局结构DEVICE_CONTEXT中。列表5-7中的SpyHookWait()和SpyHookRelease()函数用于请求和释放此Mutext对象。所有对协议缓冲区的访问都必须由SpyHookWait()预处理并在结束时由SpyHookRelease()处理，SpyHookProtocol()函数展示了这种行为。

 

 

NTSTATUS SpyHookWait (void)

    {

    return MUTEX_WAIT (gpDeviceContext->kmProtocol);

    }

 

 

// -----------------------------------------------------------------

 

 

LONG SpyHookRelease (void)

    {

    return MUTEX_RELEASE (gpDeviceContext->kmProtocol);

    }

 

 

// -----------------------------------------------------------------

// <#>:<status>=<function>(<arguments>)<time>,<thread>,<handles>

 

 

void SpyHookProtocol (PSPY_CALL psc)

    {

    LARGE_INTEGER liTime;

    PSPY_PROTOCOL psp = &gpDeviceContext->SpyProtocol;

 

 

    KeQuerySystemTime (&liTime);

 

 

    SpyHookWait ();

 

 

    if (SpyWriteFilter (psp, psc->pshe->pbFormat,

                             psc->adParameters,

                             psc->dParameters))

        {

        SpyWriteNumber (psp, 0, ++(psp->sh.dCalls));   // <#>:

        SpyWriteChar   (psp, 0, ':');

                                                  // <status>=

        SpyWriteFormat (psp, psc->pshe->pbFormat, //  <function>

                             psc->adParameters);  //   (<arguments>)

 

 

        SpyWriteLarge  (psp, 0, &liTime);              // <time>,

        SpyWriteChar   (psp, 0, ',');

 

 

        SpyWriteNumber (psp, 0, (DWORD) psc->hThread); // <thread>,

        SpyWriteChar   (psp, 0, ',');

 

 

        SpyWriteNumber (psp, 0, psp->sh.dHandles);     // <handles>

        SpyWriteChar   (psp, 0, '/n');

        }

    SpyHookRelease ();

    return;

    }

列表5-7.  主要的Hook协议函数SpyHookProtocol()

 

 

如果你比较一下列表5-7给出的SpyHookProtocol()函数的主要部分和示列5-2给出的协议项的一般格式，将很容易找出那个语句生成了协议项中的哪一个域（field）。这样一来一切就很清楚了为什么列表5-6中的协议字符串没有说明整个数据项---有些独立于功能的数据将由SpyHookProtocol()添加，而这将不需要格式字符串的帮助。SpyHookProtocl()的核心调用是SpyWriteFormat()，该函数生成<status>=<function>[<arguments>]部分，这依赖于与要记录的当前API函数相关的格式字符串。请参考位于随书光盘的/src/w2k_spy目录下的源文件w2k_spy.c和w2k_spy.h，以获取Spy设备驱动程序中使用的SpyWrite*()函数的更多实现信息。

 

 

请注意，这些代码稍微有些危险。这些代码编写与1997年是针对Windows NT 4.0的。在移植到Windows 2000之后，当hook工作一段较长时间后会偶尔引发蓝屏。更糟糕的是，有些特殊的操作将立即引发蓝屏，例如，在My Favoriter文本编辑器的File/Open对话框中打开我的电脑时。在分析过多过crash dump后，我发现是由于将NULL指针传递给了某些函数从而导致了系统崩溃。一但Spy设备试图使用这些指针中的某个来记录该指针引用的数据时，系统就会崩溃。典型的就是，指向IO_STATUS_BLOCK结构的指针，在UNICODE_STRING和OBJECT_ATTRIBUTES结构中存在无效的字符串指针。我还发现某些有Buffer成员的UNICODE_STRING结构没有/0结束符。因此，我再次强调你不应该假定所有的UNICODE_STRING结构都以/0结束。在不能确定时，请使用Length成员，它总能正确地告诉你在Buffer中存放的有效的字节数。

 

 

为了修正这一问题，我为所有使用客户指针的日志函数增加了指针有效性检查。在结束时，我使用第四章讨论过的SpyMemoryTestAddress()函数来检验一个线性地址指针是否指向一个有效的页表项（PTE）。更详细的信息请参考列表4-22和列表4-24。另一种可能的替代方案是使用结构化异常（__try/__except）。

 

 

…………….待续………………