- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 247
- Reaction score
- 7
Boys, I've been digging into this for a minute. About two weeks ago, EAC started flagging systems where Driver Signature Enforcement (DSE) is disabled. I've been running EfiGuard to bypass this, but they seem to have found a way to verify the state regardless of the bootkit masking.
The issue:
EAC is clearly doing some kind of integrity check on the kernel environment. Even with EfiGuard patching the ntoskrnl bits, they are sniffing out the state change. I am trying to figure out if they are:
Has anyone else noticed their loader getting flagged for this recently? If you're using EfiGuard or a similar boot-time patcher, are you getting hit with manual bans or just the standard 'System modified' error code?
Curious if anyone has found a way to spoof the reported DSE state or if we need to look into a more robust hypervisor-level obfuscation to hide the patch. Drop your findings below if you've done any tracing on the latest EAC updates.
The issue:
EAC is clearly doing some kind of integrity check on the kernel environment. Even with EfiGuard patching the ntoskrnl bits, they are sniffing out the state change. I am trying to figure out if they are:
- Querying the registry keys directly and validating against a heartbeat.
- Performing a stack walk on the driver object and checking for modifications in the memory region associated with CI.dll.
- Cross-referencing the GDI/DSE status via a kernel-mode callback that triggers post-load.
Has anyone else noticed their loader getting flagged for this recently? If you're using EfiGuard or a similar boot-time patcher, are you getting hit with manual bans or just the standard 'System modified' error code?
Curious if anyone has found a way to spoof the reported DSE state or if we need to look into a more robust hypervisor-level obfuscation to hide the patch. Drop your findings below if you've done any tracing on the latest EAC updates.
