您现在的位置: 破洛洛 >> 服务器 >> Windows 2000 >> 正文

《Undocumented Windows 2000 Secrets》翻译 --- 第五章(3)

作者:佚名 来源:网络整理 更新时间:2008-7-27
分享到

第五章 监控 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_WA99v (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 )。更详细的信息请参考 列表

rong>4-22 和 列表 4-24 。另一种可能的替代方案是使用结构化异常( __try/__except )。

 
转载请注明:破洛洛(谢谢合作)
网友评论: