DKOM 无法安全合法隐藏驱动对象，因现代 Windows 启用 KCFG、PoolHardening 等防护机制，直接修改链表将触发蓝屏或被验证工具拦截；唯一受支持方式是通过 ObRegisterCallbacks 注册对象回调，拦截 Driver 类型的打开请求并返回 STATUS_OBJECT_NAME_NOT_FOUND。
不能安全、合法或可维护地通过 DKOM 隐藏驱动对象。
DKOM 在现代 Windows 上已不可靠且极易触发系统崩溃
Windows 自 8.1 起默认启用 KCFG（Kernel Control Flow Guard），并逐步强化内核堆保护（如 PoolHardening）、结构体随机化（KASLR）和关键链表的完整性校验（如 PsLoadedModuleList 的 Flags 字段校验）。直接修改 DRIVER_OBJECT 或 LDR_DATA_TABLE_ENTRY 中的前/后向指针（如 ActiveThreadList、InLoadOrderLinks）会导致：
- 下一次枚举时触发
CRITICAL_STRUCTURE_CORRUPTION (0x109)蓝屏 -
verifier.exe启用驱动验证后立即检测到链表断裂 - Windows Defender System Guard / HVCI 强制拦截对
ntoskrnl.exe数据段的写入
ObRegisterCallbacks 是唯一受支持的“逻辑隐藏”路径
微软明确禁止直接篡改内核对象链表，但允许通过回调机制拦截对象访问。若目标是让 ZwLoadDriver 或用户态工具（如 sc query）查不到驱动，应注册对象回调过滤 ObOpenObjectByName 和 ObReferenceObjectByName 对 Driver 类型的请求：
- 回调中检查
ObjectType == *PsDriverType且ObjectName->Buffer匹配目标名 → 返回STATUS_OBJECT_NAME_NOT_FOUND - 必须调用
ObRegisterCallbacks并传入含OB_CALLBACK_REGISTRATION的数组，否则注册失败 - 回调函数需在
IRQL 执行，禁止调用分页内存或等待操作 - Windows 10 1809+ 要求驱动签名启用
CI_POLICY_IGNORE_ALL才能加载回调驱动
示例关键判断：
if (ObjectType == *PsDriverType && RtlCompareUnicodeString(ObjectName, &g_TargetDriverName, TRUE) == 0) {
return STATUS_OBJECT_NAME_NOT_FOUND;
}
调试阶段就该放弃手动链表操作
即使在关闭 HVCI 的 Win10 1904x 测试机上手动 patch DRIVER_OBJECT->DriverSection 指向的 LDR_DATA_TABLE_ENTRY 的 InLoadOrderLinks，也会遇到：
立即学习“C++免费学习笔记（深入）”；
-
!drvobj在 WinDbg 中仍显示驱动，因该命令读取的是PsLoadedModuleList（独立于 DriverObject） -
Get-Service不受影响，因它查的是 SCM 数据库，不是内核对象 - 下次热补丁更新或内核模块重载可能覆盖你写的指针值
- 无法隐藏
DRIVER_OBJECT本身——ZwQuerySystemInformation(SystemModuleInformation)仍会暴露模块基址
真正需要隐藏驱动的场景（如安全产品反卸载保护），必须依赖微软公开接口：用 ObRegisterCallbacks 控制可见性，用 WdFilter 或 FltMgr 进行 I/O 层面隔离，而不是碰内核链表。任何绕过校验的 DKOM 行为，在 Windows 11 22H2 及以上版本中几乎必然导致 0x139 或 0x109 蓝屏——这不是技巧问题，是设计封堵。
