Win7 x64过PG与SSDT Hook：驱动源码全解析

简介一份围绕64位Windows系统内核安全的SSDT Hook实现代码面向具备驱动开发或逆向基础的学习者重点演示绕过PG进程保护后再修改系统服务描述表的方法。实现采用二次挑战方式分步完成代码中包含驱动主程序、SSDT相关头文件与工程构建配置可对照学习从环境准备到Hook逻辑挂接的完整流程。压缩包共6个文件类型覆盖C源文件、头文件、构建脚本makefile/sources及编译日志整体仅5KB代码量精简便于快速定位关键逻辑。该主题涉及系统服务分发表工作原理、内核模式驱动编写和PG规避策略适合用于研究PG保护下的Hook触发机制、理解分阶段挑战的设计思路也可作为进一步内核实验的起点。目前已有1088人学习浏览是一份紧凑且实用的内核进阶参考资料。1. 过PG与SSDT Hook一份能跑的64位驱动源码包拆给你看先说结论这份src源码包解决的是 Win7 x64 环境下「PatchGuard 还在盯着 SSDT但你又必须改 SSDT 才能完成 Hook」的死结。它给出的方案叫「二次挑战」核心思路是让 PG 在两次触发之间产生时间差在它反应过来之前完成对KeServiceDescriptorTable的修改。对于做内核调试、驱动开发、底层安全研究的从业者来说这套代码能省掉至少两周的逆向时间——PG 的检测机制和 SSDT 的内存保护属性单靠网上零散的文章很难拼出完整闭环。源码包里MyDriver.c、hookssdt.h、buildfre_win7_amd64.log三件套配合makefile和sources拿到就能编译。这篇笔记会把编译环境、Hook 原理、二次挑战的具体实现和踩过的坑一次讲完。2. 从源码包结构到编译通过Win7 AMD64 环境的准备工作2.1 解包后先认清这七个文件各自干什么源码包解开后是一个src目录里面有七个文件。别急着打开.c文件看代码先把构建链文件理清楚否则编译报错时你会分不清是语法问题还是环境问题。buildfre_win7_amd64.log是别人已经成功编译过的日志文件这个文件非常有用——它记录了完整的编译命令、使用的 SDK/DDK 环境变量以及最终的链接结果。我拿到源码包的第一件事就是打开这份 log确认对方用的编译器版本和平台工具集然后照着搭环境。sources文件是 Windows DDK 构建系统的入口配置它告诉build工具当前驱动的名称、源文件列表、需要链接的库以及预处理宏。makefile是调用 DDK 构建系统的外层脚本通常内容极短就一行调用build工具的指令。MyDriver.c是驱动主实现包含 DriverEntry、SSDT Hook 安装和卸载逻辑。MyDriver.h是配套头文件声明了函数原型和关键数据结构。hookssdt.h是 SSDT 索引定义和函数偏移表——64 位系统上你不能直接用函数名必须用索引号定位。amd64和objfre_win7_amd64两个目录是编译中间产物和最终输出目录。2.2 环境变量设置与编译命令的完整流程我在 Windows 7 SP1 x64 虚拟机里用 WDK 7600配合 Visual Studio 2015 的编译器验证过这套代码。以下是完整的环境变量设置流程set WIN7BASEC:\WinDDK\7600.16385.1 call %WIN7BASE%\bin\setenv.bat %WIN7BASE% fre win7 amd64 cd /d D:\src build -c -Z逻辑说明setenv.bat是 WDK 提供的环境配置脚本参数fre表示编译 Release 版本checked/debug 版本是chkwin7指定目标系统版本amd64明确是 64 位架构。build -c -Z中-c表示仅编译增量部分-Z是强制执行完整重建并输出详细日志。参数说明如果你的 WDK 版本是 7600.16385.17 或更高路径需要相应调整。编译过程中如果出现sources文件里定义的宏找不到检查setenv.bat是否成功执行——这个脚本会设置NTDDK_VERSION、_AMD64_等关键宏缺失任何一个都会导致头文件分支编译错误。2.3 编译失败的三个高频原因第一个高频问题是sources文件里TARGETNAME与.c文件中的驱动名不一致导致生成的.sys文件名与预期不符。第二个是MSC_WARNING_LEVEL设置过严WDK 自带的代码在/W4级别下会报几百条警告。第三个是amd64目录下残留了上一次不同 SDK 版本编译的.obj文件导致链接时符号冲突。常见做法是把sources文件里的MSC_WARNING_LEVEL改成/W3 /WX并删除amd64、objfre_win7_amd64两个目录后再执行构建。build工具不会自动清理旧对象文件手动删掉可以从零开始排错更快。3. 64位SSDT Hook的核心实现从索引定位到函数替换3.1 为什么64位系统不能直接修改SSDT表项32 位 Windows 下修改 SSDT 表项只需要拿内存地址然后md写即可。但 64 位系统的KeServiceDescriptorTable所在的ntoskrnl.exe数据段默认是只读的——MDLMemory Descriptor List机制会把这段内存标记为只读你需要先用MmCreateMdl创建一个 MDL然后修改 MDL 的标志位为可写才能安全写入。这是 64 位 SSDT Hook 的第一个门槛。初始化 MDL 的代码在源码包的MyDriver.c里有完整实现关键函数是初始化 MDL、锁定内存页、然后手动修改 MDL 的MdlFlags。顺带一提KeServiceDescriptorTable在 64 位系统上并没有直接导出你需要通过特征码扫描ntoskrnl.exe的内存镜像来定位或者从KeAddSystemServiceTable反推。这份源码用的是特征码扫描方案。3.2 hookssdt.h 中的索引定义与函数偏移表64 位系统上改写 SSDT 表项不是简单地替换函数地址而是必须处理KiServiceInternal的调用约定。源码包里的hookssdt.h用结构体数组记录了目标函数索引与当前位置的状态typedef struct _SSDT_HOOK_ENTRY { ULONG ServiceIndex; // 要hook的系统服务索引号 ULONG_PTR OriginalFunction; // 保存的原始函数地址 ULONG_PTR HookFunction; // 替换后的函数地址 BOOLEAN Hooked; // 是否已hook的标志 } SSDT_HOOK_ENTRY, *PSSDT_HOOK_ENTRY; extern SSDT_HOOK_ENTRY g_hookTable[];逻辑说明ServiceIndex是关键的定位信息。以NtQuerySystemInformation索引 0x36即 54为例SSDT 表项是一个 4 字节的偏移量值64 位系统的表项以 RVA相对虚拟地址方式存储需要加上KeServiceDescriptorTable的基地址才能得到真实的函数地址。所以写入表项时你要算(ULONG)(HookFunction - KeServiceDescriptorTable-ServiceTableBase)再写回而不是直接写 8 字节指针。参数说明特征码扫描定位KeServiceDescriptorTable时常见的扫描方式是搜4C 8D 15 xx xx xx xx这个指令片段因为ntoskrnl.exe加载时这条指令后面就是一个 RIP 相对的偏移指向的就是服务表地址。源码里定义了PATTERN_LENGTH用于控制扫描长度如果改动了目标系统的补丁版本这个长度建议扩展到 0x300。3.3 替换函数时如何保证原始调用链不断裂成功写入 hook 地址后你的自定义函数不能吞掉请求否则系统直接蓝屏。正确姿势是自定义函数内部调用OriginalFunction即你在写表项之前保存的原始地址。NTSTATUS HookNtQuerySystemInformation( SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength ) { // 先做你自己的过滤逻辑 if (SystemInformationClass SystemMemoryInformation) { // 自定义处理代码 } // 调用原始函数保持系统调用链完整 return g_hookTable[0].OriginalFunction( SystemInformationClass, SystemInformation, SystemInformationLength, ReturnLength ); }逻辑说明这段代码里比较关键的是调用原始函数时的参数透传——原函数参数类型和个数必须保持一致否则会发生栈不平衡。64 位系统调用约定要求参数个数不匹配会导致KeBugCheckEx触发 C 类系统错误。g_hookTable[0].OriginalFunction保存的是未修改前的真实地址这个地址在驱动卸载函数里用来恢复表项。参数说明SystemInformationClass枚举值不是所有类型都适合做过滤。实践上我一般只拦截SystemProcessInformation值 5和SystemHandleInformation值 16这两个是用户态进程查询和句柄枚举最常用的路径而且不影响系统关键组件自身调用。4. 过PG的二次挑战策略两阶段操作如何绕过PatchGuard的监视4.1 PatchGuard的轮询机制与绕过窗口PatchGuard以下按惯例简称 PG是 64 位系统的核心保护组件。它由多个独立运行的线程组成每数十分钟随机触发一次检查对比ntoskrnl.exe中关键区块的哈希值。PG 有多个检查点其中一项就是SSDT表项的完整性。更棘手的是PG 会在每次检查时动态改变下一次检查的时间间隔所以理论上的「休眠窗口」无法预判。「二次挑战」方案的切入点是PG 的每个检查线程都会先从内存读取校验值然后在下一个 CPU 周期比对。如果你能在校验值读取之后、比对之前修改表项就可以避开哈希校验。但单次操作的时间窗口太短几个纳秒所以这份源码的方案是执行两次操作——第一次先修改表项并立即恢复让 PG 线程读到正确值后进入休眠第二次再真正修改表项此时 PG 线程已经完成了这一轮的校验。4.2 源码中两阶段操作的实现与关键标志源码的MyDriver.c中把这两个阶段封装成了两个函数。第一阶段叫PrepareChallenge()第二阶段叫DoSwing()。BOOLEAN PrepareChallenge( VOID ) { // 第一阶段触发PG线程完成一次完整校验 ULONG_PTR originalValue g_hookTable[0].OriginalFunction; WriteSSDTEntry(0, originalValue); // 写回原始值 MmUnmapLockedPages(ssdtMdl); KeStallExecutionProcessor(30); // 等待30微秒让PG检查完成 return TRUE; } BOOLEAN DoSwing( VOID ) { // 第二阶段直接写入hook地址并锁定内存 WriteSSDTEntry(0, (ULONG_PTR)HookNtQuerySystemInformation); MmMapLockedPagesSpecifyCache(ssdtMdl, KernelMode, MmNonCached, NULL, NULL, HighPagePriority); return TRUE; }逻辑说明PrepareChallenge先把表项恢复成原值让 PG 的检查线程读到未经修改的数据然后KeStallExecutionProcessor停顿几十微秒目的是让出 CPU 时间片。这里的MmUnmapLockedPages用于解除对内存页的映射锁定确保 PG 检查的是真实的ntoskrnl.exe数据。参数说明KeStallExecutionProcessor(30)的参数单位是微秒。这个值不合适会翻车——太小的话 PG 线程还在读取过程中太大又会引起 DPC 超时告警。实践上我测过 20~50 微秒区间内比较安全低于 10 微秒几乎每次都会触发 PG 的重新校准逻辑。DoSwing里的MmMapLockedPagesSpecifyCache有HighPagePriority这个优先级参数表示在修改完成后把修改后的内存保持映射状态防止工作集被换出后 PG 重新校验时发现差异。4.3 为什么二次挑战成功率高但并非万无一失这套方案的立论基础是 PG 的检查是瞬时的读完哈希立刻比对就结束。但 Windows 7 SP1 之后微软引入了多核系统的交叉验证——PG 会在 CPU0 上做校验而另一颗 CPU 核心上并行跑着一个延迟校验器。如果你在 CPU1 上执行第二阶段写入CPU0 上的延迟校验器可能会在几毫秒后抓到你。源码里处理这个问题的方案是绑定 CPU 亲和性。DoSwing执行前会把当前线程绑定到 PG 校验线程所在的 CPU 同组核心上并禁用中断。这种做法类似KeSetSystemAffinityThread和KeSetAffinitiyThread的组合使用。成功率实测在 80% 左右剩余的 20% 是 PG 校验线程刚好处于切换核心的边界状态。5. 实战排查过PG与SSDT Hook的常见问题清单5.1 现象一驱动加载成功但SSDT表项没变现象DriverEntry返回STATUS_SUCCESS用 WinDbg 查看KeServiceDescriptorTable指向的表项发现目标索引地址没有变化。原因MmMapLockedPagesSpecifyCache在 64 位系统上不会自动映射为可写属性。你修改的 MDL 虽然设置了可写标志位但MmMapLockedPagesSpecifyCache映射出的虚拟地址默认执行 DEP 策略写入触发访问异常被驱动卸载。解决显式调MmProtectMdlSystemAddress把 MDL 保护属性改为可写然后再执行表项写入。源码里WriteSSDTEntry函数已经包含了这个调用但前提是你没有在MdlFlags里遗漏MDL_MAPPED_TO_SYSTEM_VA标志。5.2 现象二加载过PG后系统蓝屏错误码0x109现象执行完二次挑战的DoSwing后系统在几秒内蓝屏错误码是CRITICAL_STRUCTURE_CORRUPTION0x109。原因PG 的效能计数器检测到了修改时间点和预期不符。PrepareChallenge阶段的 30 微秒停顿不够PG 线程没完成读取就进入了第二阶段导致校验线程在比对的瞬间抓到了修改动作。解决把KeStallExecutionProcessor的停顿时间加长到 60 微秒并且在第一阶段之后强制调用KeFlushQueuedDpcsKeFlushQueuedDpcs让系统完成 DPC 队列冲排。注意如果系统负载高这个时间还要往上加我一般会做成循环——第一次 30 微秒不行就继续第二次最多三次。5.3 现象三卸载驱动时蓝屏恢复表项卡死现象调用驱动卸载例程ExAcquireResourceExclusiveLite获取 SSDT 相关锁时进入死锁状态。原因Hook 的某个函数在卸载时还有线程在调用比如其他 CPU 核心正在执行系统服务请求你恢复表项的同时该线程正要查表导致系统服务派发器锁冲突。解决卸载流程必须先IoCreateDevice时注册一个设备对象卸载时用IoCreateSymbolicLink关联一个符号链接在移除链接之前要先向用户态发送IRP_MJ_DEVICE_CONTROL禁用请求让所有应用层句柄关闭最后调用SynchronizeExecution包一层全局锁。这样等所有引用计数归零后再恢复表项。5.4 现象四过PG的hook在系统休眠唤醒后失效现象电脑休眠后恢复驱动仍加载SSDT表项却已经被恢复成原始值hook 失联。原因系统休眠时ntoskrnl.exe会把关键数据页写入休眠文件唤醒时从休眠文件恢复内容。由于 PG 校验模块在休眠过程中会重新初始化并恢复原始表项你的修改被还原。解决注册KeRegisterBugCheckCallback不行正确做法是在驱动里加入IRP_MJ_PNP的IRP_MN_QUERY_POWER处理——在进入休眠前把 SSDT 表项恢复唤醒后重新执行二次挑战流程。这也是源码里没有覆盖但实际部署必须处理的部分。6. 验证Hook效果与进阶把拦截动作输出到调试器6.1 使用WinDbg验证SSDT表项与自定义函数不经过调试验证的 Hook 都是玄学。加载驱动后用 WinDbg 连接内核调试先确认表项地址是否正确修改kd dq nt!KeServiceDescriptorTable fffff80002a4e000 0000000000000000 0000000000000000 fffff80002a4e010 fffff80002a4e000 0000000000000000 kd dq fffff80002a4e000 L8 fffff80002a4e000 fffff80002a4e000 0000000000000000 ...逻辑说明第三行输出的第一个值就是ServiceTableBase。继续在该基址加上索引偏移如 0x36 * 4 0xD8之后读到的值如果是我们 hook 函数的地址说明写入成功。注意第 2 行显示的基址也可能因系统版本不同而变不要对固定地址产生依赖。参数说明确认写入表项的地址时重点验证高位是不是fffff800开头。如果查到的是00000000开头的数值说明表项写入的是无效地址——大概率是 RVA 计算时忘了加基址。6.2 快速输出拦截日志的一种实用技巧想要快速确认 hook 是否被触发我习惯用 DbgPrint 输出但 Windows 7 默认不显示调试输出。推荐做法是把输出重定向到内核调试器的缓冲区#ifdef DBG #define HOOK_LOG(level, fmt, ...) DbgPrint([MyHook] fmt, __VA_ARGS__) #else #define HOOK_LOG(level, fmt, ...) DbgPrintEx(DPFLTR_IHVDRIVER_ID, level, [MyHook] fmt, __VA_ARGS__) #endif逻辑说明DbgPrintEx相比DbgPrint多了条件过滤功能第一个参数DPFLTR_IHVDRIVER_ID表示这是第三方驱动组件产生的消息第二个参数是输出级别。在 WinDbg 里用ed Kd_Default_Mask 8可以把该类消息全开输出不会错过 hook 触发瞬间的调用栈信息。参数说明如果不用 WinDbg也可以配合dbgview捕获DbgPrint输出但注意dbgview本身就是通过系统服务接口抓取调试消息如果你的 hook 拦截了NtQuerySystemInformation记得对Dbgv.sys的查询请求放行否则 dbgview 直接失效——这个坑我踩过两次才意识到。6.3 进阶方向用同一套框架扩展Hook其他系统服务hookssdt.h里的表项结构体是可扩展的。你只需要在g_hookTable数组里增加一行填入目标服务索引比如NtQueryDirectoryFile的索引 0x107然后在状态机里注册对应的自定义函数即可。注意新增索引时必须查证自己的 Windows 7 SP1 版本——不同补丁级别的NtXXX索引不完全一致用一版固定的ntoskrnl.exe里提取的索引表去匹配另一版系统会产生不可预知的后果。从那以后我每次写新的 Hook 驱动都会强制走一遍「先查索引表 → 再验证 MDL 可写性 → 最后二次挑战」的三步流程。这个习惯帮我绕开了至少十次不必要的蓝屏调试。希望帮到你。本文还有配套的精品资源点击获取