前面的文章主要记录 SnowSword 在进程、驱动和内存视角上的检测实践。这次把测试重点放到 SnowWall 对恶意行为链的检测：使用 SnowSword 在授权的隔离实验机中对 Windows 计算器进程执行 DLL 远程注入，然后观察 SnowWall 如何记录、关联并阻断这一串操作。

本文只讨论防御性检测和实验现象。远程线程注入也可能出现在调试、兼容性工具和安全软件中，因此“命中行为链”是需要进一步复核的高风险信号，而不是脱离上下文的恶意归因。

2. 实验环境与对照条件

实验对象是 Windows 11 中的 CalculatorApp.exe，日志记录的目标 PID 为 4236。发起方是桌面目录下未签名的 SnowSword.exe，PID 为 7108，父进程为 explorer.exe。

实验采用两组对照：

两组截图的窗口布局基本一致，区别主要在 SnowWall 是否仍处于监控状态以及注入结果提示。这里的“成功/失败”只表示本次测试程序报告的结果，最终判断仍以日志和目标进程状态为准。

3. 注入代码的行为拆解

RemoteInjectDll 的核心流程可以抽象为：

1
2
3
4
5
6
7
8

OpenProcess(PROCESS_ALL_ACCESS)
        ↓
VirtualAllocEx  分配目标进程内存
        ↓
WriteProcessMemory  写入 DLL 路径
        ↓
ZwCreateThreadEx  在目标进程创建线程
                  └─ 线程入口 = LoadLibraryW

代码首先通过 OpenProcess(PROCESS_ALL_ACCESS, ...) 获取目标进程句柄。随后按 DLL 路径长度调用 VirtualAllocEx，再用 WriteProcessMemory 把路径写入目标地址空间，并通过 ReadProcessMemory 做一次写入验证。

在 64 位分支中，由于 64 位 Windows 的 kernel32.dll 在系统范围内按相同基址加载，远程线程入口可以直接使用本进程解析到的 LoadLibraryW 地址，参数是目标进程中的路径地址。在 32 位分支中，代码额外获取目标进程中的函数地址，构造一段调用 LoadLibraryW 的 x86 shellcode，分配可执行内存后再通过 ZwCreateThreadEx 执行。两条分支的实现细节不同，但从防御侧看都形成了相同的高风险序列：跨进程分配、跨进程写入、跨进程线程创建。

这也是行为检测比只匹配某个 API 更有价值的地方：单独调用 VirtualAllocEx 可能有正常用途，但它与后续写入和远程线程创建在短时间内连续出现时，语义明显发生变化。

4. SnowWall 日志中的行为链

日志时间集中在 06:52:20 至 06:52:21，关键记录如下：

4.1 第一步：跨进程分配导致污点升级

首先，NtAllocateVirtualMemory 被记录为规则评估事件，随后 SnowWall 输出 CrossAlloc 告警，原因是“污点等级升级为 1”，可疑度分数为 15，并标记为永久污染。

这一步并没有立即给出最终阻断结论，但它为后续行为建立了上下文状态。也就是说，SnowWall 并非把每一次系统调用都孤立处理，而是为进程累积行为标签。

4.2 第二步：向 CalculatorApp.exe 写入内存

紧接着的 NtWriteVirtualMemory 事件显示：

• 发起 PID：7108；
• 目标 PID：4236；
• 目标映像：CalculatorApp.exe；
• CrossProcess=1；
• 发起程序未签名，且没有可信祖先进程标记。

该条记录中的 rule_action=1 和 reason=RULE_ALLOW 表示这一条规则评估本身没有阻断，不能理解成整个注入流程已经被 SnowWall 放行。它只是行为链中的中间事件。

4.3 第三步：远程线程创建触发阈值

随后到达 NtCreateThreadEx——用户态调用 ZwCreateThreadEx 最终进入的正是这个内核系统服务，因此日志记录的是 NtCreateThreadEx。日志明确标出 CrossThreadCreate，匹配规则“远程线程注入链”，可疑度分数升至 82.91，并出现 behavior_hit=1、reason=BEHAVIOR_THRESHOLD。

之后 SnowWall 输出：

1
2

行为累积判定恶意: PID=7108 LastTag=CrossThreadCreate
event=DECISION ... action=BLOCK reason=BEHAVIOR_THRESHOLD

因此，本次实验的完整判定是：前面的单条规则评估允许记录继续进入决策流程；当跨进程分配、写入和远程线程创建形成可疑序列后，行为累计分数达到阈值，SnowWall 最终执行 BLOCK。

5. 截图与日志的相互印证

5.1 SnowWall 开启：注入被阻断

截图中可以看到 SnowSword 的目标进程列表、Windows 计算器窗口和 SnowWall 窗口，同时弹出“注入失败”的提示。它与日志最后的 action=BLOCK 相互印证：测试程序观察到失败，SnowWall 侧则给出了行为阈值阻断记录。

5.2 SnowWall 关闭：作为对照的成功提示

关闭 SnowWall 后，界面弹出“注入成功”的提示。

6. 结果分析：为什么是“行为链”而不是单点告警

本次日志可以整理成一条简化链路：

1
2
3
4
5
6
7
8
9
10
11

未签名 SnowSword.exe
        │
        ├─ NtAllocateVirtualMemory ── CrossAlloc，污点等级 1，分数 15
        │
        ├─ NtWriteVirtualMemory ───── CrossProcess=1，写入 PID 4236
        │
        └─ NtCreateThreadEx ───────── CrossThreadCreate，分数 82.91
                                      ↓
                              BEHAVIOR_THRESHOLD
                                      ↓
                                     BLOCK

其中有三个值得注意的设计点：

1. 状态累积：第一次分配操作先建立污点，后续事件可以继承上下文；
2. 目标关联：日志不仅记录 API，还记录目标 PID、目标映像和跨进程标志；
3. 分级决策：中间事件可以先记录或允许，最终由行为阈值统一决定是否阻断。

这种策略比“看到 OpenProcess 就直接拦截”更适合降低误报，也比只等待 DLL 加载完成再处理更及时。

7. 工程观察与防御建议

从测试代码和日志可以得到几项工程上的观察：

• PROCESS_ALL_ACCESS 权限过宽，防御产品可将句柄权限、调用者身份和目标进程保护级别纳入风险评分；
• VirtualAllocEx 与 WriteProcessMemory 的组合比单独的内存分配更值得关注；
• NtCreateThreadEx 是行为链中的关键收敛点，但检测不应只依赖函数名，还要核对入口地址、目标进程和前序事件；
• 32 位分支需要额外的可执行内存和 shellcode，64 位分支则直接将 LoadLibraryW 作为线程入口，跨架构差异可以作为日志字段而不是简单的放行条件；
• 测试程序在清理路径中关闭句柄，但还应确保远程内存和 shellcode 在所有失败分支都得到释放，避免实验代码自身引入泄漏或不稳定因素。

对防御侧而言，较稳妥的策略是保留原始事件、建立短时间窗口内的行为关联，并把签名、路径、父子进程关系和目标映像作为辅助证据。最终动作可以按风险等级分为记录、告警、挂起或阻断，同时为调试工具和受信任软件保留明确的审计例外。

8. 当前局限与证据边界

本次实验仍有以下限制：

1. 只有一组目标进程和一次主要日志片段，尚未进行多次重复统计；
2. 未覆盖签名的合法调试器、不同完整性级别和受保护进程；
3. 未分别验证 32 位目标进程分支与 64 位目标进程分支的全部路径；
4. 截图中的“注入成功”来自测试程序提示，尚未用独立工具确认 DLL 模块、入口执行和线程退出状态；
5. 当前日志没有展示完整规则配置、阈值定义和所有前置事件，因此不能据此推断 SnowWall 在其他版本或其他策略下必然给出相同结果。

换句话说，日志能够证明本次运行中 SnowWall 观察到了这些 API 事件，并在该策略下输出 BLOCK；截图能够证明两种开关状态下界面现象不同。至于检测覆盖率、误报率和跨版本稳定性，还需要更系统的实验设计。

9. 后续实验计划

后续准备建立一个小型复现实验矩阵，至少保留以下字段：

• SnowWall 版本、规则版本和 Windows 版本；
• 发起进程签名、路径、完整性级别与父进程；
• 目标进程架构、保护属性和 PID；
• 每个 API 事件的时间戳、目标和规则动作；
• 最终动作、测试程序返回值和独立验证结果；
• 正常调试场景与注入测试场景的重复次数。

在此基础上，再比较只调用单个 API、缺少前序事件以及完整行为链时的分数变化，才能更准确地评估 SnowWall 的阈值设计和误报边界。

总结

这次实验展示了 SnowWall 如何从 NtAllocateVirtualMemory、NtWriteVirtualMemory 到 NtCreateThreadEx 逐步积累上下文，并将跨进程内存操作与远程线程创建关联为“远程线程注入链”。日志中的 CrossAlloc、CrossThreadCreate、BEHAVIOR_THRESHOLD 和最终 BLOCK，与 SnowWall 开启时的失败提示形成了较完整的证据链；关闭 SnowWall 后的成功提示则提供了直观对照。

这个结果说明，针对高风险进程行为，按序列关联和分级决策比单点 API 拦截更有解释力。但它仍然是一次受控环境下的功能验证，不能替代多版本、多样本和正常软件基线测试。

参考

• Microsoft Learn：OpenProcess、VirtualAllocEx、WriteProcessMemory、NtCreateThreadEx
• Windows Internals, 7th Edition
• 本系列前篇：日报_SnowSword隐藏驱动检测实测、SnowSword-隐藏驱动检测原理与工程实现
• SnowSword 项目地址：https://gitee.com/le-ziyi/SnowSword

前面的文章分别讨论过模块列表、对象目录和内存特征扫描。把这些内容放在一起后，可以得到一个更清晰的结论：驱动检测的难点不是读取某一个列表，而是判断多个独立视角是否能够相互解释。

正常加载的驱动通常同时具有映像、驱动对象和运行时行为等信息。攻击者如果只修改其中一处登记信息，其他视角仍可能留下痕迹。因此，SnowSword 的设计目标不是寻找一个“绝对可信”的 API，而是把多个来源关联起来，降低单一数据源被篡改带来的影响。

这里的“隐藏驱动”是检测语境中的结果标签，不等于已经完成恶意归因。一个条目被标记为异常后，还需要结合系统版本、加载方式、对象关系和调试器结果进行人工复核。

2. 威胁模型：驱动可能藏在哪里

本文只讨论防御性检测和实验验证，不实现或复现隐藏驱动代码。为了理解检测边界，可以把攻击者可能修改的登记位置抽象成下面几类：

这几类现象并不互相等价。例如，模块列表中没有某个基址，可能是摘链，也可能是结构读取失败或版本适配问题。检测程序应该输出证据和置信等级，而不是直接输出“恶意”。

3. SnowSword 的总体架构

SnowSword 的检测流程可以拆成三个层次：

1
2
3
4
5
6
7
8
9
10
11
12

用户态界面与调度
        │
        │ IOCTL
        ▼
内核态采集与安全读取
        │
        ├─ 模块列表集合
        ├─ DRIVER_OBJECT 集合
        └─ 内存 PE 候选集合
                │
                ▼
        用户态按基址关联、分级展示和人工复核

内核态适合访问对象管理器和内核地址空间，但需要严格处理 IRQL、对象引用和异常读取；用户态适合做集合运算、路径格式化、结果排序和界面展示。把这两类职责分开，既能减少驱动中的复杂逻辑，也方便后续替换某一种采集方式。

一个统一的检测结果至少应包含以下字段：

• 映像基址和大小；
• 驱动名称或路径（如果能够获得）；
• 来源视角：模块列表、对象目录或内存扫描；
• 是否能与其他视角按基址关联；
• 当前状态：已知模块、对象关联、游离 PE 或需要人工复核；
• 目标系统版本和扫描时间。

4. 第一视角：枚举内核模块列表

SnowSword 已有的模块枚举使用 SystemModuleInformation。这类信息通常来自内核维护的已加载模块链表，可以得到驱动路径、映像基址和映像大小。

由于返回缓冲区大小不固定，常见实现是两阶段查询：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 伪代码：只展示查询流程，不代表完整的错误处理
status = ZwQuerySystemInformation(
    SystemModuleInformation,
    NULL,
    0,
    &requiredSize
);

if (status != STATUS_INFO_LENGTH_MISMATCH || requiredSize == 0) {
    return status;
}

buffer = AllocateNonPagedPool(requiredSize);
if (buffer == NULL) {
    return STATUS_INSUFFICIENT_RESOURCES;
}

status = ZwQuerySystemInformation(
    SystemModuleInformation,
    buffer,
    requiredSize,
    &requiredSize
);

实际代码还需要处理大小变化、内存释放、返回结构版本和路径编码。用户态拿到结果后，可以将 ImageName 的最后一段作为显示名，但不能只依赖名称进行关联，因为名称可能被截断、重复或格式化不同。

4.1 这一视角的优点和局限

优点是接口相对稳定，能够快速得到已加载映像的基址和大小，适合建立系统基线。局限也很明显：如果模块链表中的记录被摘除，查询结果就不会包含它；因此，模块列表更适合当作一个参考集合，而不是唯一事实来源。

5. 第二视角：对象管理器中的驱动对象

驱动加载后，通常会在对象管理器命名空间中留下 DRIVER_OBJECT。普通驱动常见于 \\Driver，文件系统相关驱动还需要关注 \\FileSystem 及其可能的子目录。漏掉子目录会使检测视野不完整。

5.1 枚举流程

工程上可以按以下步骤组织对象枚举：

1. 打开目标目录对象；
2. 将句柄转换为内核对象引用；
3. 遍历目录项并取得对象指针；
4. 用 ObGetObjectType 判断对象是否为驱动对象；
5. 在确认对象有效后读取 DriverSection 和 DllBase；
6. 将基址、名称和对象来源写入结果集合；
7. 严格配对所有对象引用。

某些实现会直接遍历 OBJECT_DIRECTORY 的哈希桶，以取得对象指针。需要强调的是，OBJECT_DIRECTORY、目录项布局和哈希桶数量都不是适合无条件硬编码的公开稳定接口。已有研究中常见的 37 个桶不能直接视为所有 Windows 版本的通用结论；目标系统必须通过符号、调试器或版本适配逻辑确认布局。

5.2 基址关联

DRIVER_OBJECT 的 DriverSection 通常可以关联到加载器数据表项，再从 DllBase 得到映像基址。这个基址是连接两个视角的关键字段：

1
2
3
4

对象目录中的 DRIVER_OBJECT
              │ DriverSection->DllBase
              ▼
模块列表中的 ImageBase

5.3 引用计数纪律

遍历对象时，引用生命周期比查找逻辑更容易出错：

1
2
3
4
5
6

ObReferenceObject
        │
        ├─ 非目标对象：ObDereferenceObject
        └─ 目标对象：把引用明确转交给调用者
                         │
                         └─ 使用结束后 ObDereferenceObject

漏释放会造成对象引用泄漏，多释放或在引用转交前释放则可能导致后续访问失效。驱动端应该为“本次遍历持有的引用”和“返回给上层的引用”建立清晰的所有权约定，并在错误路径中逐一回收。

6. 第三视角：内存中的 PE 特征

如果一个可执行映像不再出现在模块列表，且没有可枚举的驱动对象，前两种视角可能同时失效。作为补充，SnowSword 的设计还考虑在受控的内核内存范围内寻找 PE 镜像特征。

6.1 两级特征校验

驱动映像通常具有 DOS 头的 MZ 签名，并能通过 e_lfanew 定位到 PE\\0\\0 签名。扫描时应该先进行轻量检查，再读取后续头部：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 伪代码：候选识别，不等于恶意判定
if (ReadSafely(address, &dosHeader, sizeof(dosHeader)) != STATUS_SUCCESS) {
    return CandidateReadFailed;
}

if (dosHeader.e_magic != IMAGE_DOS_SIGNATURE) {
    return NotPeImage;
}

if (!IsReasonableOffset(dosHeader.e_lfanew)) {
    return InvalidPeOffset;
}

if (ReadSafely(address + dosHeader.e_lfanew,
               &signature, sizeof(signature)) != STATUS_SUCCESS) {
    return CandidateReadFailed;
}

return signature == IMAGE_NT_SIGNATURE ? PeCandidate : NotPeImage;

这里的 ReadSafely 代表安全的内核拷贝。

6.2 扫描范围不是“全内存”

全地址空间逐字节扫描既不现实，也会带来严重的性能和稳定性问题。当前设计优先考虑内核模块附近的受控范围，并把非分页池、高地址内存和已清除 PE 头列为盲区。扫描范围必须页对齐，地址和结果字段必须使用足够宽的 64 位类型。

早期实现可以由用户态按页发起 IOCTL，但这会产生大量上下文切换。正式版本应考虑批量传递地址区间，让驱动一次处理一批页，并只返回候选结果。无论采用哪种方式，都不能把“命中 PE 头”直接等同于隐藏驱动：正常模块、残留映像或数据误匹配都可能产生误报。

7. 结果关联与分级判定

三个集合可以抽象为：

1
2
3

A = 模块列表中的基址集合
B = 对象目录关联到的 DRIVER_OBJECT 基址集合
C = 内存扫描得到的 PE 候选基址集合

按基址关联后，可以采用更保守的状态分类：

A 有而 B 无并不天然表示隐藏。早期启动驱动、没有典型设备对象的驱动以及版本差异，都可能导致这种结果。相反，B有而A` 无也只能说明两个视角不一致，最终结论还需要 WinDbg、文件签名、加载日志和运行时行为等独立证据。

8. 工程实现中的几个关键问题

8.1 IOCTL 边界

用户态传入的地址、长度、线程数量和输出缓冲区都必须做范围检查。不能信任用户态传来的指针，也不能让单次请求覆盖过大的扫描区间。对于输出结果，要明确结构版本、元素数量和总字节数，避免整数溢出和越界写入。

8.2 安全读取与执行级别

访问内核地址前，需要确认当前代码运行在允许的 IRQL，并使用适合当前环境的安全拷贝方式。MmCopyMemory、异常保护和地址有效性检查各自解决的问题不同，不能把某一个检查当成“绝对安全”的保证。读取私有结构时还要考虑对象并发销毁和字段被修改的情况。

8.3 线程与资源管理

用户态多线程可以缩短实验扫描时间，但共享结果数组、停止事件和驱动句柄必须有明确的同步策略。驱动卸载时要停止工作线程、完成未决 IRP、释放池内存和对象引用。调试输出只能在命中或关键错误时记录，不能在逐页循环中无条件打印。

8.4 版本适配

OBJECT_DIRECTORY、LDR_DATA_TABLE_ENTRY 以及其他内核私有结构都可能随 Windows 版本变化。工程上应把版本识别、符号验证和字段读取失败作为正常分支，而不是假设所有系统都使用同一组偏移。对不确定的数据，宁可返回“未知”，也不要用危险的硬编码继续访问。

9. 当前实测边界

已有测试使用自写 DriverLoader 加载 TestHideDriver1.sys，并通过 DebugView 观察到 Driver is alive! 等输出。在当时的 SnowSword 界面中，该驱动显示了名称、基址 0xFFFFF80267140000、大小 0x1000 和桌面测试路径，同时被红色标记。

同一篇记录还保留了 OpenArk 的对比截图：截图中的 OpenArk 驱动列表没有显示 TestHideDriver1.sys，而 SnowSword 显示了该项。这个结果能够证明两个工具在该测试状态下的枚举结果不同，但不能单凭截图断言某个工具一定正确，也不能据此推出对所有隐藏方式都有效。

目前仍缺少以下数据：

• 干净系统基线和多次重复测试；
• 模块、对象目录和内存候选的逐项对照；
• 扫描耗时、CPU 占用和 IOCTL 次数；
• 非分页池、清除 PE 头和不同 Windows 版本的验证。

10. 后续实验计划

后续可以按照下面的顺序完善证据链：

实现层面的 v2 方向包括：批量化内存扫描、研究非分页池定位、为 DRIVER_OBJECT 增加多特征交叉校验，以及把 WinDbg 验证信息纳入结果报告。

总结

SnowSword 隐藏驱动检测的核心不是某个特殊 API，而是把模块加载器、对象管理器和内存特征三个视角放到同一条证据链中：

1
2
3
4
5
6
7

不同来源采集
      ↓
按基址和名称关联
      ↓
输出差异与证据
      ↓
人工复核后再做结论

这种设计无法保证发现所有内核隐蔽技术，但能让攻击者必须同时处理更多独立痕迹，也让检测结果比单一列表更容易解释和复核。对于 ARK 工具，工程上的稳定性、版本适配和误报控制，与“能否扫到一个对象”同样重要。

参考

• Windows Internals, 7th Edition（对象管理器、加载器、驱动对象和内存管理章节）
• Microsoft Learn：ZwQuerySystemInformation、ZwOpenDirectoryObject、ObReferenceObjectByHandle、ObGetObjectType、MmCopyMemory
• 本系列文章：隐藏驱动检测学习记录、内存暴力搜索隐藏驱动、SnowSword 隐藏驱动检测实测
• SnowSword 项目地址：https://gitee.com/le-ziyi/SnowSword

上一篇（隐藏驱动检测）我讲了两个视角的交叉验证：模块列表（PsLoadedModuleList）和对象目录（\Driver、\FileSystem）。写完我顺手模拟了一下攻击者视角，发现一个问题：

如果攻击者 摘链 PsLoadedModuleList + 不注册 \Driver 对象，两个视角会同时落空——驱动”理论上不存在”，但它明明在内核里跑着。

这就是所谓的纯内存驱动（memory-only driver）：不落地、不注册对象，代码直接拷进内核内存执行。传统的驱动检测手段对它全部失效。

我当时在上一篇结尾留了个伏笔：DRIVER_OBJECT 是真实存在于内核内存里的结构，能不能直接扫内存把它捞出来？这篇就来填这个坑。

2. 攻击者模型：驱动到底怎么”藏”

先明确一下我们要对抗的威胁模型。一个驱动想隐藏，需要同时做两件事：

注意一个关键点：这两个手段都是在”登记处”动手脚，而不是销毁对象本身。驱动要跑，DRIVER_OBJECT 这个结构体就必须活在内存里——它是 I/O 子系统操作驱动的唯一凭据（派发例程、卸载例程都挂在上面）。

所以问题变成了：怎么找到这块”没登记但真实存在”的可执行内存？

如果我是攻击者，怎么让检测失效？

1. 双杀：摘链 PsLoadedModuleList + 同时从 \Driver 目录删除对象（需调用 ObMakeTemporaryObject 等，但也会留下新的痕迹）；
2. 不注册 DRIVER_OBJECT：纯内存执行，两个视角都看不到 → 引出本篇方案；
3. 伪造 DriverSection->DllBase：指向一个合法模块的基址，交叉比对时被”吸附”到合法基址，产生假阴性；
4. 彻底 shellcode 化：无 PE 头、无驱动对象，纯手工 hook 内核代码——这是 inline hook 检测的战场（见本系列后续篇）。

检测的本质不是”找到所有坏人”，而是提高攻击者的隐藏成本。

3. 方案对比：DRIVER_OBJECT 特征 vs PE 头特征

理论上可以直接扫描 DRIVER_OBJECT 结构体特征，但我最终选择了 PE 头特征。以下是两条路线的对比和取舍过程。

3.1 DRIVER_OBJECT 特征（精确但脆）

DRIVER_OBJECT 是驱动在内核里的身份证。它在 x64 上是 0x150 字节，关键字段如下（以 Win10 1809 x64 实测布局为准，我用 IDA 反编译 afd.sys 的 DriverEntry 验证过字段用法）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

typedef struct _DRIVER_OBJECT {
    CSHORT Type;                    // +0x00  ← 类型魔数 IO_TYPE_DRIVER (0x0B)
    CSHORT Size;                    // +0x02  ← 结构大小 0x150
    PDEVICE_OBJECT DeviceObject;    // +0x08
    ULONG Flags;                    // +0x10
    PVOID DriverStart;              // +0x18  ← 驱动代码基址
    ULONG DriverSize;               // +0x20
    PVOID DriverSection;            // +0x28  ← LDR_DATA_TABLE_ENTRY*（模块链表节点）
    PDRIVER_EXTENSION DriverExtension;  // +0x30 ← 扩展结构，内含回指
    UNICODE_STRING DriverName;      // +0x38  ← 驱动名字符串
    PUNICODE_STRING HardwareDatabase; // +0x48
    PFAST_IO_DISPATCH FastIoDispatch; // +0x50
    PVOID DriverInit;               // +0x58
    PVOID DriverStartIo;            // +0x60
    PVOID DriverUnload;             // +0x68
    PVOID MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1]; // +0x70，共 28 个
} DRIVER_OBJECT;

💡 类比理解：MajorFunction 就是一张 28 格子的”接线表”，每个格子对应一类 IRP，填的是处理函数地址。驱动要处理什么请求，就往对应格子塞函数指针。这张表就是驱动功能的索引——攻击者想改驱动行为，或者我们想识别驱动，都得看它。

三个最值钱的”指纹”（组合起来几乎不可能被自然数据巧合满足）：

1. Type == IO_TYPE_DRIVER (0x0B)：I/O 子系统初始化驱动对象时写入的魔数；
2. DriverExtension->DriverObject == 自身：_DRIVER_EXTENSION 第一个字段回指驱动对象指针。这是最强的判据——相互引用、自我指涉的数据结构，随机数据几乎不可能形成这种闭环；
3. MajorFunction[0..27] 全部指向内核代码区：28 个指针都必须落在内核可执行地址范围内。

但这条路我最终没选，原因很现实：

• 布局跨版本敏感：字段偏移、IO_TYPE_DRIVER 魔数在不同 Windows 版本可能不同；
• 扫描范围难定：对象在非分页池，而 Win10 1809+ 非分页池定位本身就很麻烦；
• 实现成本高：需精确结构布局 + 池定位，维护负担重。

结论：DRIVER_OBJECT 四关卡校验留着当升级方案，先不实现。

3.2 PE 头特征（粗糙但稳）

驱动是一个 PE 镜像，必然以 MZ 头（IMAGE_DOS_SIGNATURE）+ PE 签名（IMAGE_NT_SIGNATURE）开头。这个特征：

• 跨版本稳定（PE 格式几十年没变过）；
• 只需读内存开头几十字节（实现成本低）；
• 配合模块列表差集就能区分正常驱动和隐藏驱动。

设计取舍：与其”扫结构体特征”（精确但脆），不如”扫 PE 镜像特征 + 和模块列表做差集”（粗糙但稳）——凡是带合法 PE 头、又不在模块列表里的可执行页 = 疑似隐藏驱动。

4. 扫描范围与性能考量

这一步我纠结了最久，也是我觉得这篇最有价值的部分——怎么在合理时间内扫完内核内存，以下都是我的试错过程。

4.1 无脑方案：全地址空间逐字节扫

x64 内核地址空间约 128 TB。按 16 字节步进 = 8 万亿次检查，而且大部分地址是无效映射，直接读会触发页面错误蓝屏。这个方案在第一分钟就该被毙掉。

4.2 改进：按页遍历 + 先验页有效性

128 TB / 4 KB = 340 亿页，每页一次 MmIsAddressValid，哪怕单次 100ns 也要近 1 小时。作为 ARK 的”开机扫描”仍然不可接受。

4.3 最终选择：先扫”内核驱动加载区”（有已知盲区）

穷举地址空间不现实，但纯内存驱动的代码总不能凭空出现——它要么拷进驱动加载区（ntoskrnl 附近的系统模块区域），要么落在非分页池。

我选择先扫 [ntoskrnl基址 - 0x70000000, ntoskrnl基址] 的驱动加载区：

1
2
3

' 扫描范围 = [ntoskrnl基址 - 1.75GB, ntoskrnl基址]
ulonglong endAddr = GetKernelModuleBase("ntoskrnl.exe", &ModuleSize);
uonglong startAddr = EndAddr - 0x70000000;

共约 44.8 万页，比 128 TB 全空间小了四个数量级，从”扫不完”变成”可接受”。

已知盲区：

• 攻击者若将驱动代码拷到非分页池高地址段，本版扫不到——这是当前实现最现实的绕过路径；
• v2 计划补全非分页池定位（见第 8 节）。

4.4 多线程分片

44.8 万页不能单线程傻扫。解决方式是多线程分片：把 [StartAddr, EndAddr] 按线程数均分，每个线程扫一段，互斥锁保护共享结果数组。

关键：区间边界必须按 PAGE_SIZE 对齐，否则 StartAddr + i * addrRange 落在页中间，漏掉页首的 MZ 头（PE 头在镜像基址=页首）。我一开始没对齐，扫出来的结果少了一大截，debug 半天才发现。

4.5 性能优化（架构设计阶段即考虑）

第一版实现是每页一次 IOCTL——44.8 万页就是 44.8 万次用户态↔内核态往返。作为验证思路的第一版能接受，但正式功能必须优化：

• 批量化：把一批页地址塞进一个缓冲区，一次 IOCTL 让驱动循环检查，回传结果数组——IOCTL 次数从 44.8 万降到几十；
• 驱动内差集：干脆驱动直接拿 SystemModuleInformation 缓存模块基址集合，在驱动内完成差集，用户态只收最终结果。

本版先跑通每页 IOCTL 的验证逻辑，优化在 v2 实现。

5. 特征校验：PE 头 + 模块列表差集

范围扫到了，接下来是”怎么算命中”。命中判定拆成两半：驱动端认 PE 头，用户态认模块归属。

5.1 驱动端：MZ → PE 签名两步走

内核里逐页检查，读页首数据验证 PE 头。安全读是核心——内核地址不是都能直接解引用的，读无效页会直接蓝屏，所以必须先预检再拷贝：

1
2
3
4
5
6
7
8
9
10
11
12
13

// ⚠️ 以下为核心逻辑示意，非完整可编译代码
// 实际实现需自行补全安全拷贝、异常处理、入参校验

// 1. 页对齐粗检 + ProbeForRead 快速预检（比直接拷贝快一个量级）
// 2. 安全拷贝 DOS 头（MZ 魔数）——必须用 MmCopyMemory/VxkCopyMemory，不能直接解引用
if (dosHeader.e_magic != IMAGE_DOS_SIGNATURE)   // 'MZ'
    return Normal;

// 3. MZ 命中，再安全拷贝 PE 头（e_lfanew 指向 PE 签名）
if (ntHeader.Signature == IMAGE_NT_SIGNATURE) {  // 'PE\0\0'
    // 4. 疑似 PE 镜像 → 标记为候选隐藏驱动，交用户态做模块归属差集
    return HideDriver;
}

💡 类比理解：这就像保安查门禁——每个进楼的人都要带工牌（PE 头），保安只拦”没登记的人”（模块列表里没有的 PE）。工牌本身人人都有，关键在登记簿上有没有你的名字。

5.2 用户态：和模块列表做差集

驱动端只负责”这页长得像 PE 镜像”，它不区分正常驱动和隐藏驱动（正常驱动也是 PE）。区分工作交给用户态：命中页地址用 GetDriverPathByAddr 反查它属于哪个已加载模块——

• 能查到路径 → 是已知模块的镜像，正常；
• 查不到 → 游离 PE 镜像 = 疑似隐藏驱动，记录地址，之后和模块列表交叉复核。

6. 实现：驱动端扫 + 用户态多线程调度

6.1 总体架构

1
2
3
4
5
6
7
8

用户态（FreeBasic）                    驱动端（SnowSword.sys）
┌─────────────────────┐   IOCTL    ┌─────────────────────────┐
│ 多线程分片扫描        │ ─────────▶ │ OptimizedScanKernelMemory│
│ 每页发一次 IOCTL 询问  │ ◀───────── │ 逐页 PE 特征检查          │
│ 互斥锁保护结果数组     │           └─────────────────────────┘
│ GetDriverPathByAddr  │
│ 差集 → 展示          │
└─────────────────────┘

6.2 用户态线程工作函数（核心逻辑）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

' ⚠️ 以下为核心逻辑示意，非完整可编译代码
' 实际实现需自行补全错误处理、内存管理、类型安全

for (ulonglong addr = p->startAddr ; ddr <= p->endAddr ; addr += PAGE_SIZE) {
    stMemory.addr   = (PVOID)addr;
    stMemory.dwSize = PAGE_SIZE;

    ' 每页发一次 IOCTL，让驱动检查这页是不是 PE 镜像
    if (IoControl(hDrv, IOCTL_ScanKernelMemory, @stMemory, SizeOf(MemoryStruct),
                 @result, SizeOf(MEMORY_SCAN_RESULT)) <> 0) {
        if (result <> Normal) {
            ' 命中：互斥锁保护下记录结果
            MutexLock(p->hMutex);
            ' 记录 Addr 到共享数组
            MutexUnlock(p->hMutex);
        }
    }
}

命中后用户态再调 GetDriverPathByAddr(Addr) 判断模块归属：有路径 → 正常模块；无路径 → 疑似隐藏驱动。

7. 实验计划（待执行）

⚠️ 本文是设计稿，实验结果将在后续补充。

Step 1：特征自检（先证明扫描没瞎）

在干净的 Win10 1809 虚拟机里，加载 SnowSword 驱动跑扫描：

1. 扫描 [ntoskrnl基址 - 0x70000000, ntoskrnl基址] 驱动区，收集所有 PE 特征命中页；
2. 对每个命中地址调 GetDriverPathByAddr 反查模块归属，与 SystemModuleInformation 模块列表交叉；
3. 预期：正常系统里，所有命中都应能归属到已知模块（ntoskrnl、hal、afd 等）；归属不到模块的命中数为 0——这是自检通过的第一道标准；
4. 用 windbg lm / !drvobj 抽查几个命中地址，确认 PE 头校验没有把数据区误认成镜像。

自检通过的标准：命中全部可解释——每个 PE 命中都能对应一个已知模块，没有莫名其妙的多余项，也没有把正常驱动漏掉。

Step 2：对抗测试（证明能揪出隐藏驱动）

构造一个”纯内存驱动”样本：

1. 写一个普通驱动，DriverEntry 里自摘链：把自己的 DriverSection->InLoadOrderLinks 从 PsLoadedModuleList 摘掉；
2. 不调用 IoCreateDevice（不产生设备对象），也不依赖 \Driver 目录注册的常规路径——模拟”双视角皆盲”；
3. 再跑一遍扫描，预期：模块列表和对象目录都看不到它，但 PE 扫描按镜像特征把它捞出来——GetDriverPathByAddr 查不到归属 = 命中列表里出现一个”游离 PE”；

8. 已知局限与后续计划

8.1 当前局限

1. 扫描范围盲区：只扫驱动加载区，非分页池高地址段未覆盖——攻击者把代码拷到非分页池即可绕过；
2. IOCTL 频率：每页一次 IOCTL，44.8 万次上下文切换，全扫分钟级；
3. PE 头可抹除：攻击者加载后擦掉 MZ/PE 魔数即可让本方案失效（但会破坏 I/O 子系统的加载假设，纯 shellcode 才能这么干）。

8.2 后续计划

• v2：补全非分页池定位（Win10 1809+ 无 MmNonPagedPoolStart/End 导出，需特征扫 _POOL_DESCRIPTOR 或借 windbg/PDB）；
• 升级方案：DRIVER_OBJECT 四关卡校验（Type + 回指 + MajorFunction），覆盖”抹掉 PE 头但保留驱动对象”的场景。

9. 遇到的问题与注意事项

1. 页对齐：扫描区间边界必须按 PAGE_SIZE 对齐，否则漏掉页首的 MZ 头（4.4 节有详细说明）；
2. 地址类型宽度：内核地址是 64 位的，用户态保存扫描范围/结果时必须用 ULongInt，不能用 ULong。截断后起始地址直接错位，扫出来全是噪音；
3. 安全读内核内存：不能直接解引用，必须先 ProbeForRead 预检 + MmCopyMemory 安全拷贝 + __try/__except 兜底——缺一步都可能蓝屏；
4. IOCTL 频率：每页一次 IOCTL 有几十万次上下文切换，全扫分钟级；正式功能必须批量化（见 4.5）；
5. 调试输出：DbgPrint 别放在逐页循环里，命中才会打还好，每页都打能把调试器刷到卡死；
6. 误报：PE 头校验命中的”游离镜像”只是疑似，需和模块列表差集 + 人工复核，不自动判定恶意。

参考

• Windows Internals, 7th Edition（加载器 / 驱动对象 / 内存管理章节）
• Microsoft Learn： IMAGE_NT_HEADERS
• 本系列前篇：日报_隐藏驱动检测_改进版（本篇的伏笔出处）、SnowSword–进程隐藏检测实现
• 实验佐证：IDA 反编译 win10 1809 afd.sys DriverEntry（DRIVER_OBJECT 字段用法，为升级方案做的预研）

之前几篇都在做进程隐藏检测（PID 暴力扫描、PspCidTable 遍历），核心哲学是多视角交叉验证——Windows 里没有绝对可信的单一视角，攻击者篡改一个数据源容易，同时篡改多个独立数据源成本急剧上升。

同样的道理完全适用于驱动。恶意驱动（Rootkit 的加载器、内核后门）想隐藏自己，最常见的手段是摘链 PsLoadedModuleList——这是 Windows 内核维护的已加载模块双向链表，摘链后普通工具（任务管理器、driverquery、甚至 NtQuerySystemInformation(SystemModuleInformation)）就看不到它了。

但问题来了：驱动真的”消失”了吗？没有。只要它注册了 DRIVER_OBJECT，它就在对象管理器的命名空间里留下了痕迹。这就是本篇文章要用的第二个视角。

核心思路：检测进程时可以同时看句柄表、PspCidTable、模块链表；检测驱动，同样可以同时看「模块加载器视角」和「对象管理器视角」。

2. 驱动在内核里的两种”存在形式”

一个正常加载的驱动，会在内核里同时留下两种记录：

视角 1：模块加载器（PsLoadedModuleList）

• NtQuerySystemInformation(SystemModuleInformation) 返回的模块列表就来自这张链表；
• SnowSword 里 GetKernelModuleList 已经用它枚举驱动（路径 + 基址 + 大小）；
• 攻击者摘链 → 这个视角就看不到了。

视角 2：对象管理器命名空间（\Driver、\FileSystem）

• 驱动加载时会在对象管理器根目录下注册一个 DRIVER_OBJECT，名字通常是 \Driver\驱动名；
• 文件系统驱动注册在 \FileSystem，文件系统过滤驱动在 \FileSystem\Filters；
• 这套命名空间由对象管理器独立维护，与 PsLoadedModuleList 是两套互不相干的机制。

攻击者如果只摘链模块链表，对象管理器目录里的 DRIVER_OBJECT 依然在——这就是检出点。

3. 视角 1 回顾：模块列表枚举（已有实现）

SnowSword 里已有实现，核心是两段式调用：

1
2
3
4
5
6

' 第一遍：查询需要的缓冲区大小
st = ZwQuerySystemInformation(SystemModuleInformation, buffer, bufferSize, @bufferSize)
If (st = STATUS_INFO_LENGTH_MISMATCH) Then buffer = Reallocate(buffer, bufferSize)

' 第二遍：取实际数据
st = ZwQuerySystemInformation(SystemModuleInformation, buffer, bufferSize, NULL)

拿到 SYSTEM_MODULE_INFORMATION 后遍历 Modules(i)，用 ImageName 取驱动路径、路径最后一段作为驱动名。

4. 视角 2：枚举 \Driver 与 \FileSystem

这是本篇文章的新内容。对象管理器命名空间像文件系统一样组织目录，核心思路分三步：

4.1 打开目录对象

用 ZwOpenDirectoryObject 打开 \Driver 或 \FileSystem 目录，拿到句柄后再用 ObReferenceObjectByHandle 转成内核态的 OBJECT_DIRECTORY* 结构指针，之后关闭句柄保留对象引用——后续操作都基于结构指针，不走句柄。

4.2 遍历哈希桶（核心逻辑）

OBJECT_DIRECTORY 内部用 37 个 HashBuckets 哈希桶组织目录项，每个桶是一条 ChainLink 链表。遍历所有桶 = 枚举目录下所有对象。这是比 ZwQueryDirectoryObject 更底层的做法（公开接口只能拿名字，直接读结构能拿到对象指针）。

关键遍历逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// ⚠️ 以下为核心逻辑示意，非完整可编译代码
// 实际实现需自行补全错误处理、引用计数、结构体验证

for (int i = 0; i < BUCKET_COUNT; i++) {  // BUCKET_COUNT 需验证，通常为 37
    for (entry = DirObj->HashBuckets[i]; 
         entry; 
         entry = entry->ChainLink) {

        // 1. 增加引用计数，防止遍历期间对象被释放
        ObReferenceObject(entry->Object);

        // 2. 判断是否为 DRIVER_OBJECT
        if (ObGetObjectType(entry->Object) == *IoDriverObjectType) {
            PDRIVER_OBJECT drv = (PDRIVER_OBJECT)entry->Object;

            // 3. 通过 DriverSection->DllBase 获取模块基址
            //    这是与视角1（模块列表）交叉验证的关键纽带
            PLDR_DATA_TABLE_ENTRY ldr = drv->DriverSection;
            if (ldr) {
                PVOID base = ldr->DllBase;  // ← 与 SystemModuleInformation 的基址比对
                // 收集 base，后续与模块列表做差集分析
            }
        }

        // 4. 释放引用计数（匹配对象除外，由上层管理生命周期）
        ObDereferenceObject(entry->Object);
    }
}

为什么是 37 个桶？ 37 是质数，哈希取模时分布更均匀。但这个数字未文档化，不同 Windows 版本可能变化（Win7 确认是 37，Win10/11 需自行验证）。硬编码此值在跨版本工具中存在兼容性风险，建议通过符号解析或特征扫描动态获取。

4.3 引用计数纪律（最容易蓝屏的地方）

遍历过程中每个对象都必须 ObReferenceObject / ObDereferenceObject 配对，这是这段代码最容易出错的地方：

状态流转：

1
2
3
4
5

ObReferenceObject (引用+1)
    ↓
判断对象类型
    ├─ 是 DRIVER_OBJECT 且匹配目标 → 保留引用，返回给调用者
    └─ 其他情况 → ObDereferenceObject（引用恢复）

匹配对象把引用转交给调用者后，调用者用完必须 ObDereferenceObject，否则同样泄漏。

4.4 类型判断与基址关联

• 用 ObGetObjectType() == *IoDriverObjectType 判断驱动对象，走导出 API 而非手动访问对象头，避免踩到无效对象头。
• drvObj->DriverSection（LDR_DATA_TABLE_ENTRY）的 DllBase 与模块列表的基址比对——这一步把「对象管理器视角」和「模块加载器视角」用基址串了起来，正是交叉验证的基础。
• 注意：不是每个 DRIVER_OBJECT 都有有效的 LDR_DATA_TABLE_ENTRY（DriverSection 可能为 NULL），访问前必须判空。

5. 交叉验证：两个视角的差集

把两个视角的结果并排对比：

两个视角的数据源不同，但都能拿到驱动基址：视角 A 直接给 dwBase，视角 B 通过 DriverSection->DllBase 取。所以交叉验证可以按基址对齐：

1. 遍历 \Driver、\FileSystem 目录，收集所有 DRIVER_OBJECT 的基址；
2. 对每个基址与模块列表 A 的基址集合比对；
3. 基址不在 A 中 = 模块列表里没有这个驱动 = 疑似摘链隐藏驱动——模块链表上看不到，但对象管理器里还留着 DRIVER_OBJECT，这就是检出点。

反过来，A 有而 B 无的条目要小心：不是所有模块都会注册 DRIVER_OBJECT（早期 boot 加载的驱动、未创建设备对象的驱动），直接报”隐藏”会误报，需要先收集正常基线再判断。

5.1 攻击者视角：如何绕过？

如果我是攻击者，怎么让这套检测失效？

1. 双杀：摘链 PsLoadedModuleList + 同时从 \Driver 目录删除对象（需调用 ObMakeTemporaryObject 或类似操作，但会留下新的痕迹）；
2. 不注册 DRIVER_OBJECT：纯内存执行，两个视角都看不到 → 引出第九篇；
3. 伪造 DriverSection->DllBase：指向一个合法模块的基址，交叉比对时被”吸附”到合法基址，产生假阴性。

检测的本质不是”找到所有坏人”，而是提高攻击者的隐藏成本。

6. 盲区与第九篇伏笔：内存暴力搜索 DRIVER_OBJECT

如果攻击者连 \Driver 对象都不注册，两个视角都会落空。但 DRIVER_OBJECT 是真实存在于内核内存里的结构，它有一个特征——结构体首部的 Type 字段（IO_TYPE_DRIVER）。所以理论上可以扫描内核内存区域，按特征寻找所有 DRIVER_OBJECT：

1
2
3
4

暴力扫描内核内存
  ↓ 校验结构特征（Type 魔数、DriverName 有效性、MajorFunction 指针合法性）
  ↓ 找到未被任何链表/目录登记的 DRIVER_OBJECT
纯内存隐藏驱动

7. 遇到的问题与注意事项

1. OBJECT_DIRECTORY 是未导出结构：HashBuckets 的桶数（37 个）和 OBJECT_DIRECTORY_ENTRY 的布局依赖系统版本，需要在自己目标系统上验证结构布局。验证方法：

   • Windbg: dt nt!_OBJECT_DIRECTORY
   • 对比不同 Windows 版本的 _OBJECT_DIRECTORY 定义
   • 特征扫描：Directory 对象包含固定数量的指针数组模式

2. 引用计数准则：遍历中每个对象都要 ObReferenceObject / ObDereferenceObject 配对——漏释放会引用泄漏（对象永远无法回收），多释放会直接崩溃。匹配对象把引用转交给调用者后，调用者用完必须 ObDereferenceObject。

3. DriverSection 判空：不是每个 DRIVER_OBJECT 都有有效的 LDR_DATA_TABLE_ENTRY（DriverSection 可能为 NULL），访问前必须判空，否则蓝屏。

4. 误报处理：A 有 B 无 的条目需要基线（boot 驱动、无设备对象驱动都正常），不能直接当隐藏报。

5. \FileSystem\Filters 子目录：MiniFilter 的驱动对象在子目录里，漏枚举会导致视野不全。

6. BUCKET_COUNT 硬编码风险：如前所述，37 这个数字未文档化，跨版本使用需验证。

参考

• Windows Internals, 7th Edition（对象管理器 / 驱动对象 / PsLoadedModuleList 章节）
• Microsoft Learn：ZwOpenDirectoryObject / ObReferenceObjectByHandle / ObGetObjectType / IoDriverObjectType
• 本系列前篇：SnowSword–进程隐藏检测实现、PspCidTable 进程枚举学习记录

在之前为 SnowSword 实现隐藏进程检测时，我用的方案是暴力扫描 PID：以 4 为步长枚举 0 ~ 0x20000，逐个调用 PsLookupProcessByProcessId 反查 EPROCESS。这个方案能用，但有几个明显的局限：

1. 扫描范围是”假设”不是”机制”——0x20000 上限写死，高 PID 进程可能漏检；
2. 大量无效查询——有效 PID 中仍有大量未分配槽位，每次都要完整走一次查询；
3. 依赖 API 语义——PsLookupProcessByProcessId 本身是导出函数，如果攻击者 Hook 了内核查询路径，返回结果同样不可信。

由此想到一个问题：能不能不经过任何查询 API，直接读取 Windows 内核自己维护的 PID → 进程对象映射？这个数据结构就是 PspCidTable。

核心思路：公开 API 是访问内核数据结构的一个入口，直接遍历 PspCidTable 可以降低对单一查询 API 的依赖；但它不能保证绕过对内核数据结构本身的篡改，也不能消除私有结构随系统版本变化带来的兼容性风险。

2. PspCidTable 是什么

PspCidTable 是 ntoskrnl.exe 的私有全局变量，也是进程和线程共用的 CID（Client ID）表。PID 与 TID 都在其中。它不是普通用户态进程句柄表，下面的字段和编码说明也必须以具体 Windows 版本的实测结果为准。

它的类型是 HANDLE_TABLE（未导出结构），遍历的关键字段是 TableCode：

• 低 2 位：表级数——0 单级、1 二级、2 三级；
• 高位：表基址（读取时用 TableCode & ~3 抹零低 2 位）。

单级/二级/三级结构的关系：

1
2
3

单级： TableCode → Entry[]（直接索引）
二级： TableCode → 二级表指针[512] → Entry[]
三级： TableCode → 三级表指针[512] → 二级表指针[512] → Entry[]

其中 Entry 每项 16 字节（x64）。x64 Win10 上 PspCidTable 通常为三级结构。

3. 如何定位 PspCidTable

PspCidTable 是未导出变量，不能直接引用。最直接的办法是从公开导出函数反向追踪。我这里用的是两步跳板定位法：

1. 在 PsLookupProcessByProcessId 开头 0x100 字节内搜特征码 0xE8（call 指令），解析相对偏移，得到它内部调用的 PspReferenceCidTableEntry；
2. 在 PspReferenceCidTableEntry 内搜特征码 48 8B 05（mov rax, [rip+disp32]），再解析相对偏移，就得到 PspCidTable 变量的运行时地址。

调试时的核心反汇编输出如下：

1
2
3

fffff806`ca714a2e 488b0583126b00  mov rax,qword ptr [nt!PspCidTable (fffff806`cadc5cb8)]
...
fffff803`16425cc4 e8a7010000      call nt!PspReferenceCidTableEntry (fffff803`16425e70)

小技巧：48 8B 05 在函数里可能命中多处，先通过 call 跳板锁定 PspReferenceCidTableEntry，再在其内部搜 mov，命中率更高——把调用链当路标。

核心实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

PVOID GetPspCidTable() {
    PVOID PsLookupProcessByProcessIdAddr = (PVOID)PsLookupProcessByProcessId;
    PUCHAR StartSearchAddress = NULL;

    // 第一步：在 PsLookupProcessByProcessId 内搜索 call 指令（0xE8）
    UCHAR pSpecialCode1[1] = { 0xE8 };
    PVOID result = SearchSpecialCode(PsLookupProcessByProcessIdAddr, 0x100, pSpecialCode1, 1);
    if (result != NULL) {
        // call 相对偏移：目标地址 = 指令地址 + 5 + disp32
        LONG offset = *(PLONG)((PUCHAR)result + 1);
        StartSearchAddress = (PUCHAR)((PUCHAR)result + 5 + offset);  // 得到 PspReferenceCidTableEntry
    } else {
        StartSearchAddress = (PUCHAR)PsLookupProcessByProcessIdAddr;  // 降级：直接从头搜索
    }

    // 第二步：在 PspReferenceCidTableEntry 内搜索 mov rax, [rip+disp32]（48 8B 05）
    UCHAR pSpecialCode2[3] = { 0x48, 0x8B, 0x05 };
    result = SearchSpecialCode(StartSearchAddress, 0x100, pSpecialCode2, 3);
    if (NULL == result) return NULL;

    LONG offset = *(PLONG)((PUCHAR)result + 3);
    return (PVOID)((PUCHAR)result + 7 + offset);  // mov rax,[rip+disp] 指令长 7 字节
}

（关键逻辑如上，完整工程代码参照 LyShark实现 补齐。）

4. 遍历 PspCidTable

拿到 PspCidTable 地址后，按 TableCode 的级数逐级遍历。整体流程：

1
2
3
4
5
6
7
8
9

PspCidTable
  ↓ 解析 TableCode（级数 + 基址）
遍历有效 Entry
  ↓ 解码 Entry 得到对象体地址
ObGetObjectType 判断是否为进程对象
  ↓
handle 值即 PID，收进结果数组
  ↓
生成第二份进程列表 B

4.1 解析 TableCode

注意 PspCidTable 变量里存的是 HANDLE_TABLE*，取 TableCode 要两级解引用：先读变量得表地址，再偏移 +8 读 TableCode 字段。

1
2
3
4
5
6

ULONG64 ul_tableCode = *(PULONG64)(((ULONG64)*(PULONG64)TableBase) + 8);
INT i_low2 = ul_tableCode & 3;   // 表级数

if (i_low2 == 0)      parse_table_1(ul_tableCode & ~3, 0, 0, Callback, Context); // 单级
else if (i_low2 == 1) parse_table_2(ul_tableCode & ~3, 0, Callback, Context);    // 二级
else if (i_low2 == 2) parse_table_3(ul_tableCode & ~3, Callback, Context);       // 三级

4.2 逐级遍历

三级表：在当前观察到的 x64 版本中，每层通常是 512 项的指针数组（每项 8 字节），逐级取指针，最底层是 Entry 数组（每项 16 字节）。这里的层级、数量和字段布局不是稳定的公开接口，必须按目标系统版本验证。MmIsAddressValid 只能作为有限的预检，不能替代对象生命周期管理或并发同步。

4.3 Entry 解码（当前版本假设）

在当前参考实现假设下，PspCidTable 使用“锁定句柄”格式，Entry 的低 16 位是引用计数或属性位，对象体地址需要这样解码（右移 16 位并按 16 字节对齐）：

1
2

ULONG64 ul_decode = (LONG64)ul_recode >> 0x10;
ul_decode &= 0xfffffffffffffff0;

4.4 Client ID 与 PID 的对应关系

在 CID 表语义下，条目的 Client ID 数值可以对应 PID 或 TID；只有通过对象类型判断为进程对象后，才能将其作为 PID 收集。当前参考实现假设每个 Entry 承载 4 个 PID 槽位，handle 编码为：

1

handle = i * 4 + 1024 * index1 + 512 * index2 * 1024

PID 必然是 4 的倍数——这也解释了之前暴力扫描为什么能以 4 为步长对齐。进程对象判断用对象管理器 API，配合异常保护：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

static BOOLEAN ProcessEnumCallback(HANDLEINFO* pHandleInfo, PVOID Context) {
    if (!pHandleInfo->Object || !MmIsAddressValid(pHandleInfo->Object))
        return TRUE;  // 无效 Entry 跳过
    _try {
        if (ObGetObjectType(pHandleInfo->Object) == *PsProcessType) {
            // handle 直接作为 PID 存入数组
            EnumContext->ProcessArray[EnumContext->ProcessCount++] = pHandleInfo->Handle;
        }
    }
    _except(EXCEPTION_EXECUTE_HANDLER) {
        // 对象可能已被释放，异常时跳过而非蓝屏
    }
    return TRUE;
}

5. 与现有方案的关系和验证意义

PID 暴力枚举的表面形式是遍历 PID 数值，但每次查询仍然依赖 PsLookupProcessByProcessId 访问内核维护的 CID 映射。因此，它与直接遍历 PspCidTable 并不是两个独立的数据源。

两种方案的主要区别在于访问路径：

• 间接 CID 查询：遍历候选 PID，通过公开 API 查询对应的进程对象；
• 直接 CID 表遍历：定位并解析私有的 PspCidTable，再根据对象类型筛选进程对象。

6. 实验设计

从最后一行可以得出结论：检测机制不是”万能探测器”，而是攻击面与数据源之间的博弈——每多一个可信数据源，攻击者就得多篡改一个地方，但盲区始终存在。

7. 遇到的问题

1. 两级解引用：一开始只解了一次引用，把 PspCidTable 变量地址当成了表地址，遍历全乱；后来意识到它是 HANDLE_TABLE*。
2. 遍历次数困惑：参考实现里一级表循环写的是 for (i < 512) // 256?，作者自己也标了疑惑——表大小 4K / 每项 16B 应该是 256 项，实际循环却写 512 次，这部分涉及每个 Entry 承载 4 个 handle 的映射，还需要再验证。
3. 并发修改：遍历过程中 TableCode 和各级表可能被句柄增删或扩容修改。未经确认不应直接依赖内部锁；当前方案只能接受轻微不一致，后续需要评估版本相关的快照、重试或结果去重策略。

8. 展望

• 在 Win10、Win11 等目标版本上分别确认 HANDLE_TABLE 布局、TableCode 层级、Entry 数量和对象指针编码；
• 为直接遍历逻辑增加版本识别、特征匹配失败处理、遍历边界检查和结果去重，避免把私有结构当作稳定接口；
• 通过正常进程创建和退出、PID 较大进程、并发表扩容等场景验证遍历稳定性；

参考

• Windows Internals, 7th Edition（PspCidTable / HANDLE_TABLE 相关章节）
• ReactOS 源码（HANDLE_TABLE / PspCidTable 的开放实现参考）
• LyShark 公开示例：PspCidTable 定位与三级表遍历参考实现（https://www.lyshark.com/post/93beefb4.html）
• 本系列前篇：SnowSword–进程隐藏检测实现（PID 暴力扫描方案）