PatchGuard是Windows x64内核强制执行的完整性保护机制，通过周期性校验关键结构防止未授权修改，触发蓝屏而非允许绕过；合法替代方案包括使用微软支持的ObRegisterCallbacks进行对象操作监控，或通过ETW无侵入式事件追踪，二者均避开PG检测范围且符合设计意图。
PatchGuard 不是能“绕过”的功能，它是 Windows x64 内核强制执行的完整性保护机制。任何直接修改 ntoskrnl.exe 内存镜像、篡改 SSDT、打补丁到关键结构（如 EPROCESS 链表、PsLoadedModuleList）的行为，都会在下一次 PG 检查周期（通常数秒到数分钟）触发蓝屏：KERNEL_SECURITY_CHECK_FAILURE 或 ATTEMPTED_WRITE_TO_READONLY_MEMORY。
你真正能做的，是避开 PatchGuard 的检测范围，用它允许的方式做监控——不是对抗，而是适配。
用 ObRegisterCallbacks 监控进程/线程/句柄操作
PatchGuard 不检查回调注册本身，只检查内核内存是否被篡改。微软明确支持 ObRegisterCallbacks 作为合法的、受文档保障的对象访问控制机制。
- 支持 Windows 7 SP1 及以上所有版本（包括 Win11 23H2）
- 回调在对象操作前（
PreOperation）或后（PostOperation）触发，可拦截OpenProcess、TerminateProcess、DuplicateHandle等行为 - 不需要 patch 内核，不修改
EPROCESS或OBJECT_HEADER - 注册时必须提供唯一
Altitude字符串（如L"321000"），避免与其他驱动冲突 - 若回调中执行耗时操作（如发 IRP、写文件），必须用
ExAllocatePoolWithTag+KeDelayExecutionThread脱离 APC 上下文，否则可能死锁
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
OB_OPERATION_REGISTRATION opReg = {0};
opReg.ObjectType = PsProcessType;
opReg.Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE;
opReg.PreOperation = MyPreProcessCallback; // 在这里判断是否放行
<p>OB_CALLBACK_REGISTRATION obReg = {0};
obReg.Version = ObGetFilterVersion();
obReg.OperationRegistrationCount = 1;
RtlInitUnicodeString(&obReg.Altitude, L"321000");
obReg.RegistrationContext = NULL;
obReg.OperationRegistration = &opReg;</p><p>NTSTATUS status = ObRegisterCallbacks(&obReg, &g_CbHandle);
用 ETW（EventTracing）做无侵入系统调用监控
PatchGuard 完全不干涉 ETW 会话启动与事件消费——这是微软自己用来诊断系统的通道，天然白名单。
- 不需驱动，纯用户态即可通过
StartTrace/EnableTraceEx2订阅内核事件（如Microsoft-Windows-Kernel-Process、Microsoft-Windows-Kernel-Thread） - 可捕获进程创建/退出、线程调度、DLL 加载、注册表操作等，粒度细且时间戳精准
- 不依赖符号解析，不扫描内存，不挂钩函数，零触发 PG 风险
- 注意：默认仅限管理员权限；若需监控
System进程，需启用SeDebugPrivilege - 常见坑：忘记调用
ControlTrace关闭会话，导致后续启动失败；ETW session 名重复引发ERROR_ALREADY_EXISTS
别碰 KeInitializeTimer、KeSetTimer 或手动轮询 PG 检查点
网上流传的“定位 KeInitAmd64SpecificState 并 patch 关闭 PG”或“hook KeSetTimer 拦截 PG 定时器”属于高危误导：
-
KeInitAmd64SpecificState在 Win10 1903+ 已移除，Win11 中完全不可靠 - 所有 timer 相关函数地址随机化（KASLR），硬编码 offset 在不同 build/patch 版本必崩
- 即使短时间得手，PG 启动后仍会通过多路径校验（CR3、IDT、GDT、内核堆栈指纹等）发现异常并蓝屏
- 微软在 2025 年已将 PG 检查逻辑拆入 HVCI（基于虚拟化的安全）上下文，R0 驱动无法触达
这类操作不是“技术难度高”，而是设计上就被堵死——不是你没找到偏移，是微软根本没留这个口子。
真实项目里最常被忽略的兼容性雷区
-
ObRegisterCallbacks在某些 OEM 定制版 Win10/11（如 Dell、HP 预装系统）中被厂商驱动抢占Altitude，导致注册失败返回STATUS_FLT_INSTANCE_ALTITUDE_COLLISION - ETW 事件字段在 Win11 22H2+ 新增了
ProcessIntegrityLevel、IsSecureProcess等字段，旧解析逻辑会越界读取 - 所有回调函数必须用
__declspec(code_seg("PAGE"))标记，并确保不在 DPC 或中断上下文中分配非分页池 - 不要试图在回调里调用
ZwQueryInformationProcess—— 它可能再次触发ObRegisterCallbacks，造成递归死锁
真正的安全监控，从来不是比谁 patch 更深，而是比谁用的机制更靠近微软的设计意图。PG 不是墙，是路标——它指明了哪些路被允许，哪些路已被填平。
