- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 421
- Reaction score
- 7
Still think patching g_CiOptions and unlinking your module is a golden ticket to being UD? I’ve been digging into EasyAntiCheat_EOS.sys lately, and the reality is that the old-school flow of "patch ci.dll -> load -> restore" is basically a neon sign for manual bans or instant flags these days.
The Logic vs. The Reality
On paper, the method looks clean:
The problem isn't the load itself—it's the massive trail of breadcrumbs you leave across the kernel. EAC isn't just checking if DSE is on; they're looking at structure consistency.
Primary Detection Vectors
1. PsLoadedModuleList & SystemModuleInformation
EAC walks the PsLoadedModuleList manually. If you're there, they don't just see a name; they parse the cert info and structure sanity. Even if you unlink yourself, they can still hit NtQuerySystemInformation with the SystemModuleInformation class. If one list shows you and the other doesn't? Mismatch. Instant flag.
2. The Ghost of DRIVER_OBJECT
Most people forget that even if you're invisible to module scans, the Object Manager still knows about \Driver\YourDriverName. This is a completely different structure. If you don't nuke the driver object correctly, they’ll find the header and realize there’s a driver running with no corresponding entry in the loaded module list.
3. CI Timing and Integrity Checks
EAC queries SystemCodeIntegrityInformation frequently. If your timing for patching and restoring isn't frame-perfect, or if they catch the CI state in a transitional phase, you're toast. They also perform heavy certificate parsing—checking the entire chain, not just the signature. Fake-signing or self-signing is essentially useless against their current parser.
Does loading before EAC help?
It reduces exposure to initial callbacks, but it doesn't stop the persistent module scans and object lookups that happen once the game is live. DSE bypasses aren't a "set it and forget it" solution anymore. If you aren't managing the consistent state of every kernel structure you've touched, you're just waiting for the next ban wave.
Who's actually managed to keep a DSE-patched driver UD on EOS lately, or are we all moving to DMA and EFI mappers?
The Logic vs. The Reality
On paper, the method looks clean:
- Patch g_CiOptions or hook CiValidateImageHeader.
- Call NtLoadDriver, which hits MmLoadSystemImage.
- DriverEntry runs, you do your business.
- Restore the patches and hope nobody noticed.
The problem isn't the load itself—it's the massive trail of breadcrumbs you leave across the kernel. EAC isn't just checking if DSE is on; they're looking at structure consistency.
Primary Detection Vectors
1. PsLoadedModuleList & SystemModuleInformation
EAC walks the PsLoadedModuleList manually. If you're there, they don't just see a name; they parse the cert info and structure sanity. Even if you unlink yourself, they can still hit NtQuerySystemInformation with the SystemModuleInformation class. If one list shows you and the other doesn't? Mismatch. Instant flag.
2. The Ghost of DRIVER_OBJECT
Most people forget that even if you're invisible to module scans, the Object Manager still knows about \Driver\YourDriverName. This is a completely different structure. If you don't nuke the driver object correctly, they’ll find the header and realize there’s a driver running with no corresponding entry in the loaded module list.
3. CI Timing and Integrity Checks
EAC queries SystemCodeIntegrityInformation frequently. If your timing for patching and restoring isn't frame-perfect, or if they catch the CI state in a transitional phase, you're toast. They also perform heavy certificate parsing—checking the entire chain, not just the signature. Fake-signing or self-signing is essentially useless against their current parser.
Structures that need to stay consistent:
- PsLoadedModuleList (Kernel Module List)
- SystemModuleInformation (Query System Info)
- Driver Object Manager Directory (\Driver\...)
- Registry Service Keys (EAC checks for leftover service entries)
- PiDDB Cache / MmUnloadedDrivers (if you try to unload and hide)
Does loading before EAC help?
It reduces exposure to initial callbacks, but it doesn't stop the persistent module scans and object lookups that happen once the game is live. DSE bypasses aren't a "set it and forget it" solution anymore. If you aren't managing the consistent state of every kernel structure you've touched, you're just waiting for the next ban wave.
Who's actually managed to keep a DSE-patched driver UD on EOS lately, or are we all moving to DMA and EFI mappers?
