DSE是Windows自Vista起强制实施的内核安全机制，确保仅经微软数字签名的驱动程序可加载；未签名驱动默认被拒绝，仅测试签名模式或禁用DSE（需重启且关闭Secure Boot）可临时绕过。
不能可靠实现，且在现代 Windows 上基本无效。 Windows 自 Vista 起强制驱动签名策略（Driver Signature Enforcement, DSE），未签名驱动无法加载到内核，除非系统处于测试签名模式（bcdedit /set testsigning on）或禁用 DSE（需重启 + Secure Boot 关闭）。所谓“遍历驱动对象检测无签名驱动”，本质是误判——你看到的 DRIVER_OBJECT 大多来自已通过签名验证、成功加载的模块；真正绕过签名的恶意驱动（如利用内核漏洞提权后直接映射、PatchGuard 绕过、Bootkit 级加载）根本不会出现在标准驱动对象链表中。
为什么 PsGetProcessImageFileName 和遍历 ObReferenceObjectByHandle 找不到可疑驱动
用户态程序无法直接访问内核驱动对象链表（PsLoadedModuleList 是内核地址，用户态读取会触发访问违规）；而通过 NtQuerySystemInformation(SystemModuleInformation, ...) 获取的模块列表只包含已导出符号的加载模块（SYSTEM_MODULE_INFORMATION），不区分签名状态，且可被 Rootkit Hook 掩盖。常见错误是试图用 EnumDeviceDrivers + GetDeviceDriverBaseName 判断签名——这些 API 返回的是映像路径，不是签名验证结果，路径存在 ≠ 驱动当前受信任。
能拿到的驱动信息里，哪些字段和签名有关
唯一可间接参考的是驱动映像文件的数字签名属性，但必须从文件系统层面验证，而非内核对象：
-
WinVerifyTrust或CryptQueryObject检查驱动文件（.sys）是否含有效 WHQL 或 EV 签名 - 调用
GetSignedStatus（需wintrust.h）传入驱动完整路径，检查TRUST_PROVIDER_CERT结果 - 注意：若驱动已被加载，文件可能被独占锁住，
CreateFile会失败；应先用QueryFullProcessImageName或NtQuerySystemInformation获取路径，再尝试以GENERIC_READ | FILE_SHARE_READ打开 - 签名验证本身不防篡改——攻击者可替换已签名驱动为同名恶意版本（DLL 劫持式加载），此时文件签名有效但内容已被污染
实际检测中更该关注的行为特征而非签名状态
签名只是加载门槛，不是安全保证。真正危险的是驱动行为：
立即学习“C++免费学习笔记（深入）”；
- 检查驱动是否注册了异常的 IRP 处理函数（如拦截
IRP_MJ_CREATE、IRP_MJ_DEVICE_CONTROL）——需用DbgView或内核调试器观察 I/O 请求流 - 扫描驱动是否挂钩关键 SSDT 或 KiServiceTable（需内核态代码，用户态无法直接读取）
- 用
driverquery /v查看驱动启动类型（OnDemandvsSystem）和描述字段是否为空/含乱码——很多无签名驱动为规避扫描会清空DriverSection->DriverName - 对比
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services中服务项的ImagePath是否指向系统目录（%SystemRoot%\System32\drivers\），非系统路径需重点核查文件签名与哈希
真正有效的检测必须结合内核回调（PoSetPowerNotify、CmRegisterCallbackEx）、ETW 日志（Microsoft-Windows-Kernel-PnP 事件 ID 410/411）和内存取证工具（如 volatility 的 driverscan），纯 C++ 用户态遍历既看不到绕过机制，也拦不住已驻留的内核后门。别把签名当盾牌，它只是第一道门禁卡——卡能复制，门锁早被撬开了。
