Part1 Buffer Overflows
池是内核模式内存，用作驱动程序的存储空间。
池的组织方式与在从演讲或书中记笔记时使用记事本的方式类似。 有些笔记可能是1行，其他笔记可能是多行。 许多不同的注释都在同一页面上。内存也被组织成页，通常一页内存为4KB。 Windows内存管理器将这个4KB的页面分成更小的块。 一个块可能小到8个字节或可能更大。 这些块中的每一个与其他块并排存在。
！pool命令可用于查看存储在页面中的池块。
1 | kd> !pool fffffa8003f42000 |
由于许多池分配存储在同一页面中，因此每个驱动程序仅使用已分配的空间至关重要。如果DriverA使用的空间比分配的空间多，则会写入下一个驱动程序的空间（DriverB）并损坏DriverB的数据。将这种覆盖到下一个驱动程序的空间的情况称为缓冲区溢出。接着，内存管理器或DriverB将尝试使用此损坏的内存，并将遇到意外的信息。这种意外信息通常会导致蓝屏（BSOD）。
通常，池损坏显示为终止码 0x19 BAD_POOL_HEADER或终止码 0xC2 BAD_POOL_CALLER。 这些终止码可以轻松确定崩溃中涉及池损坏。 但是，访问意外内存的结果可能会有很大差异，因此池损坏会导致许多不同类型的错误检查。
与任何蓝屏转储分析一样，最好的起点是！analyze -v。 此命令将显示终止码和参数，并对崩溃进行一些基本解释。
1 | kd> !analyze -v |
在上述例子中，错误检查是一个终止码 0x3B SYSTEM_SERVICE_EXCEPTION。 此终止码的第一个参数是c0000005，它是访问冲突的状态代码。 访问冲突是尝试访问无效内存（此错误与权限无关）。 可以在WDK头ntstatus.h中查找状态代码。
！analyze -v命令还提供了一个有用的捷径来进入失败的上下文。
1 | CONTEXT: fffff88004763560 -- (.cxr 0xfffff88004763560;r) |
运行此命令会向我们显示崩溃时的寄存器值。
1 | kd> .cxr 0xfffff88004763560 |
从上面的输出我们可以看到崩溃发生在ExAllocatePoolWithTag中，这很好地表明崩溃是由于池损坏造成的。 通常情况下，看着dump的工程师会在此时停止并得出结论认为崩溃是由池损坏引起的，但我们可以更进一步。
执行失败的指令是解引用rax + 8。 rax寄存器包含4f4f4f4f4f4f4f4f，它不具有x64系统上指针所需的规范形式。 这说明因为rax中的数据应该是一个指针，但很明显他不是，导致系统崩溃了。
要确定rax不包含预期数据的原因，我们必须在失败之前检查指令。
1 | kd> ub . |
汇编代码中显示rax来自r8所指向数据。查找前面寄存器的值，看到r8值为fffffa8001a1b820，查看内存，可以看到与rax中数据一致，由此可以断定，是此处内存出现问题。
1 | kd> dq fffffa8001a1b820 l1 |
要确定此意外数据是否是由池损坏引起的，我们可以使用！pool命令。
1 | kd> !pool fffffa8001a1b820 |
fffffa8001a1b810看起来不像是一个有效的小池分配，检查整个页面是否实际上是大页面分配的一部分……
1 | kd> !pool fffffa8001a1b820 |
上面的输出看起来不像我们之前使用的！pool命令。 此输出显示池标头的损坏，这会阻止命令走分配链。
上面的输出显示在大小为810的fffffa8001a1b000上有一处分配。如果我们查看这个内存，我们应该看到一个池头。 但是，我们看到的是4f4f4f4f`4f4f4f4f的样子。
1 | kd> dq fffffa8001a1b000 + 810 |
此时，我们可以确定系统因池损坏而崩溃。
因为损坏发生在之前，并且转储是系统当前状态的快照，所以没有具体证据表明内存是如何被破坏的。 在损坏之前立即分配池块的驱动程序可能是写入错误位置并导致此损坏的驱动程序。 此池块标有“None”标记，我们可以在内存中搜索此标记以确定哪些驱动程序使用它。
1 | kd> !for_each_module s -a @#Base @#End "None" |
文件Pooltag.txt列出了由Windows提供的内核模式组件和驱动程序，相关文件或组件（如果已知）以及组件名称用于池分配的池标记。 Pooltag.txt随Windows调试工具（在triage文件夹中）和Windows WDK（在\ tools \ other \ platform \ poolmon中）一起安装。 Pooltag.txt显示以下标记：
1 | None - <unknown> - call to ExAllocatePool |
不幸的是，我们发现当驱动程序调用ExAllocatePool（未指定标记）时会使用此标记。 这不允许我们确定在损坏之前分配块的驱动程序。 即使我们可以将标记绑定回驱动程序，也可能不足以断定使用此标记的驱动程序是破坏内存的驱动程序。
下一步应该是启用特殊池并希望在行为中捕获损坏者。
Part2 Special Pool for Buffer Overruns
在本节中，我们将讨论特殊池如何帮助识别向缓冲区写入太多数据的驱动程序。
池通常被组织为允许多个驱动程序将数据存储在同一内存页中，如图1所示。
图1 未损坏池
通过允许多个驱动程序共享同一页面，池可以有效地使用可用的内核内存空间。 但是，这种共享要求每个驱动程序都要小心使用池，使用池的任何错误都可能破坏其他驱动程序池并导致崩溃。
图二 损坏池
如图2所示池，如果DriverA分配100个字节但写入120个字节，它将覆盖由DriverB存储的池头和数据。 在第1部分中，我们演示了这种类型的缓冲区溢出，但我们无法识别哪些代码导致损坏池。
为了捕获损坏池的驱动程序，我们可以使用特殊池。 特殊池更改池的组织方式，使得每个驱动程序的分配位于单独的内存页中。 这有助于防止驱动程序意外写入另一个驱动程序的内存。 特殊池也在页末尾进行驱动程序的分配，通过将下一个虚拟页面标记为无效将其设置为保护页面。写入超过分配的结尾，会导致保护页面进行立即错误检查。
特殊池还用重复模式填充页面的未使用部分，称为“slop bytes”。 如果在模式中发现任何错误，在释放页面时将检查这些slop字节，生成错误检查以指示内存已损坏。 这种类型的损坏不是缓冲区溢出，它可能是下溢或其他形式的损坏。
图3 特殊池
由于特殊池将每个池分配存储在其自己的4KB页面中，因此会导致内存使用量增加。启用特殊池时，内存管理器将配置可在系统上分配特殊池的限制，当达到此限制时，将使用常规池。对于比64位系统具有更少内核空间的32位系统，这种限制尤其明显。
解释了特殊池的工作原理，现在来用它。
有两种方法可以启用特殊池。驱动验证程序允许在特定驱动程序上启用特殊池。 KB188831中描述的PoolTag注册表值允许为特定池标记启用特殊池。从Windows Vista和Windows Server 2008开始，驱动验证程序捕获特殊池分配的其他信息，因此这通常是推荐的方法。
要使用驱动程序验证程序启用特殊池，请使用以下命令行，或从验证程序GUI中选择该选项。使用/ driver标志指定要验证的驱动程序，这是列出您怀疑是问题原因的驱动程序的位置。您可能需要验证已编写并希望测试的驱动程序或最近在系统上更新的驱动程序。在下面的命令行中，我只验证myfault.sys。需要重新启动才能启用特殊池。
1 | verifier /flags 1 /driver myfault.sys |
启用验证程序并重新启动系统后，重复导致崩溃的活动。 对于某些问题，活动可能只是等待一段时间。 对于我们的演示，我们运行NotMyFault（有关详细信息，请参阅第1部分）。
特殊池中缓冲区溢出导致的崩溃将是一个终止码0xD6，DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION。
1 | kd> !analyze -v |
我们可以调试此崩溃并确定notmyfault.sys写入池缓冲区之外。
调用堆栈显示myfault.sys访问了无效内存，这会生成页面错误。
1 | kd> k |
！pool命令显示myfault.sys引用的地址是特殊池。
1 | kd> !pool fffff9800b5ff000 |
页表条目显示该地址无效。 这是特殊池用于捕获溢出的防护页面。
1 | kd> !pte fffff9800b5ff000 |
此内存之前的分配是一个800字节的非分页池标记为“Wrap”。 “Wrap”是验证程序在没有标记的情况下分配池时使用的标记，它相当于我们在第1部分中看到的“None”标记。
1 | kd> !pool fffff9800b5ff000-1000 |
特殊池是跟踪缓冲区溢出池损坏的有效机制。 它还可以用于捕获其他类型的池损坏，我们将在以后的文章中讨论。
Part3 Special Pool for Double Frees
在本系列的第1部分和第2部分中，我们讨论了池损坏以及如何使用特殊池来确定此类损坏的原因。 在这一部分中，我们将使用特殊池来捕获一个双重释放池内存。
双重释放池将导致系统显示蓝屏，但是由此导致的崩溃可能会有所不同。 在最明显的情况下，两次释放池分配的驱动程序将导致系统立即崩溃，终止码为C2 BAD_POOL_CALLER，第一个参数将为7，表示“尝试释放已释放的池”。 如果您遇到此类崩溃，则应在故障排除步骤列表中启用特殊池。
1 | BAD_POOL_CALLER (c2) |
一个不太明显的崩溃是池已被重新申请。正如第二部分所示，池的结构使得多个驱动程序共享一个页面。当DriverA调用ExFreePool释放其池块时，该块可供其他驱动程序使用。 如果内存管理器将此内存提供给DriverF，然后DriverA再次释放它，则当池分配不再包含预期数据时，DriverF中可能会发生崩溃。 对于没有特殊池的DriverF的开发者来说，这样的问题可能是困难的。
特殊池将每个驱动程序的分配放在一个单独的内存页中（如第2部分所述）。 当驱动程序释放特殊池中的池块时，将释放整个页面，并且对任意页面的任何访问都将导致立即错误检查。 此外，特殊池将此页面放在要再次使用的页面列表的尾部。 这增加了页面在第二次释放时仍然可用的可能性，降低了上面显示的DriverA / DriverF场景的可能性。
为了验证这种失败，我们将再次使用Sysinternals工具NotMyFault。 选择“Double free”选项，然后单击“Crash”。 很可能你会得到上面提到的停止C2错误检查。 启用特殊池并重新启动以获得更多信息错误。
1 | verifier /flags 1 /driver myfault.sys |
选择启用特殊池的“双重免费”选项会导致以下崩溃。 错误检查代码PAGE_FAULT_IN_NONPAGED_AREA表示某些驱动程序试图访问无效的内存。 此无效内存是已释放的特殊池页面。
1 | PAGE_FAULT_IN_NONPAGED_AREA (50) |
查看调用堆栈，我们可以看到myfault.sys正在释放池，ExFreePoolSanityChecks发生了导致崩溃的页面错误。
1 | kd> kn |
使用错误检查代码中的地址，我们可以看到内存实际上是无效的：
1 | kd> dd fffff9800a7fe7f0 |
到目前为止，我们有足够的证据证明myfault.sys释放了无效的内存，但是我们怎么知道这个内存被释放了两次呢？ 如果有双重释放，我们需要确定对ExFreePool的第一次或第二次调用是否不正确。 为此我们需要确定哪些代码首先释放了内存。
Driver Verifier特殊池跟踪最后的0x10000调用以分配和释放池。 您可以使用！verifier 80命令转储此数据库。 要限制数据输出，您还可以将此命令传递给您怀疑被双重释放的内存地址。
不要假设错误检查代码中的地址是被释放的地址，请从调用VerifierExFreePoolWithTag的函数中获取地址。
在上面的调用堆栈中，VerifierExFreePoolWithTag下面的调用是第9帧（从0开始计数，或者使用kn）。
1 | kd> .frame /r 9 |
在x64系统上，第一个参数在rcx中传递。 下面的程序集显示rcx源自rbx。
1 | kd> ub fffff880`04c9b5d9 |
运行！verifier 80：rbx中的地址
1 | kd> !verifier 80 fffff9800a7fe800 |
最近内核池分配和自由操作的日志：
日志中最多有0x10000个条目。
解析0x0000000000010000个日志条目，搜索地址0xfffff9800a7fe800。
1 | ====================================================================== |
上面的输出显示由myfault.sys分配的池块，然后由myfault.sys释放。 如果我们将这些信息与调用堆栈结合起来导致我们的错误检查，我们可以得出结论，池在MyfaultDeviceControl中在偏移量0x2f2处被释放一次，然后在偏移量为0x2fd的MyfaultDeviceControl中再次释放。
现在我们知道哪个驱动程序导致了问题，如果这是我们的驱动程序，我们就知道要调查的代码区域。
原文链接：
- Understanding Pool Corruption Part 1 – Buffer Overflows
- Understanding Pool Corruption Part 2 – Special Pool for Buffer Overruns
- Understanding Pool Corruption Part 3 – Special Pool for Double Frees
共勉。