Guide [Discussion] EasyAntiCheat_EOS.sys Startup — Reverse Engineering the VM and Anti-Debug Gates

[byte_corvus]

Anyone currently digging into the latest EasyAntiCheat_EOS.sys build has probably noticed it's bloated into a 37MB monster. I've been running the startup path through a kernel emulator to map out exactly what happens before the monitoring loop kicks in. The short version? Most of the logic is buried inside a 33.3MB VM section (.sec7), and if your environment doesn't mirror what their SEH handlers expect, it simply refuses to load.

Initial Driver Entry & Registry Diagnostics
Right at DriverEntry (RVA 0x173188), EAC sets up diagnostic trackers in the registry. It's looking to see if initialization finishes or where it dies.

Spoiler: Registry Diagnostic Values

EAC writes these under \Registry\Machine\Software\Wow6432Node\EasyAntiCheat_EOS:

1. ErrRpt_ServiceState — Tracker (0 = starting).
2. ErrRpt_LastInitTime — FILETIME timestamp.
3. ErrRpt_LastInitInfo1 — Driver base address.
4. ErrRpt_LastInitInfo2 — Driver size (0x23CE000).

If it crashes, the service knows exactly what the driver state was during the next boot.

The .sec7 VM Section
Once diagnostics are up, execution jumps into the VM layer. This isn't your average virtualization; we're talking about 1,025 unique handler addresses and a context structure that tracks everything from GPRs to VM state words. This is where most of the anti-debug and anti-VM logic is obfuscated.

Anti-Debug Gate Checks (The Burn Phase)
EAC uses specific hardware and exception traps to gate the initialization. If you're testing this in a debugger and the SEH doesn't land correctly, it returns STATUS_DRIVER_UNABLE_TO_LOAD (0xC000026C) and kills the load.

1. INT 1 Single-Step Trap: Fires at drv+0x30303D. It expects the local SEH handler to catch this and branch execution. A debugger consuming this event will cause a mismatch.
2. RDTSC Timing Burst: Back-to-back checks with randomized loop counts to detect the overhead of hypervisors or heavy instrumentation.
3. INT 3 Breakpoint Trap: Same logic as INT 1, used as a secondary check at drv+0x311BB0.

Hardware Fingerprinting & VM Detection
EAC is aggressive with environment probes. They aren't just looking for VBox; they are building a full hardware inventory.

Spoiler: Environment & VM Probes

1. Hypervisor Check: NtQuerySystemInformation(0xC5) checks the user-mode mapping of the hypervisor shared page.
2. ACPI/SMBIOS: Uses HalAcpiGetTableEx and IoWMIQueryAllData for board vendors, serials, and UUIDs.
3. PCI Config Scan: 512 calls to HalGetBusDataByOffset to identify VM-related hardware (VirtIO, Vmware, etc.).
4. BCD Check: Scans BcdOSLoaderBoolean_AllowPrereleaseSignatures to detect test-signing mode.
5. Module Blacklist: Scans the module list for VBoxGuest.sys, vm3dmp.sys, viostor.sys, and even dbk64.sys (Cheat Engine).

Memory & Integrity Monitoring
After spawning 5 worker threads, the driver begins heavy scanning. This isn't just about PIDs; they are performing deep reads into core system modules like FLTMGR.SYS and hal.dll looking for inline hooks.

Parsing Pattern:
1. Read e_lfanew at RVA 0x3C
2. Resolve Export Directory
3. Walk AddressOfNames
4. Read code sections sequentially for hook detection.

Continuous Monitoring Summary
Once initialized, the threads cycle through handle table scans (0x10), system module refreshes (0xB), and full TID walks via PsLookupThreadByThreadId. Interestingly, the DriverEntry thread behavior changes depending on the CPU vendor identified—on some Intel configs, it returns an error status even while the worker threads remain active and monitoring.

Don't run this on your main if you're messing with the BCD or custom EFI drivers; their certificate store enumeration is massive, covering over 1,000 key queries just to build a trusted baseline for signature validation.

Have you guys noticed any specific behavior changes when spoofing the hypervisor shared page to NULL?