- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 546
- Reaction score
- 7
EAC's kernel component is a mess of encrypted imports and stack-walking traps designed to catch anything that isn't a perfectly signed, legitimate module. If you are trying to map a driver or spoof HWIDs on Rust, you need to see what's actually happening under the hood. We dumped the EasyAntiCheat.sys binary from Rust and ran it through IDA to map out the current detection state.
Import Obfuscation — The DecryptImport Nightmare
EAC does not rely on a standard IAT for sensitive kernel APIs. Instead, they resolve almost everything at runtime via a single exported function: DecryptImport (sourced from the EasyAntiCheat_EOS usermode module). Every single callsite in the driver uses unique decryption parameters, making static analysis a massive pain.
There are over 47 callsites using this method. You can't just hook the resolver once; you have to reverse each specific rotation and XOR constant for every API you want to track. This completely nukes generic IAT hooking as a bypass strategy.
DriverEntry Anti-Disassembly
The entry point at 0x18012E054 uses a classic jmp +1 trick to break linear disassemblers like IDA or Ghidra. It jumps into the middle of the next instruction, leading into junk bytes to confuse the auto-analysis. You'll need to manually define the function at the calculated target to get a clean view.
Filesystem & Hardware Visibility
EAC acts as a filesystem minifilter (FLTMGR). They aren't just checking game files; they are monitoring system-wide I/O. They see every read, write, and rename in real-time.
The Mapped Driver Killer: Stack Validation
This is how most of you are getting clapped. EAC uses a two-stage stack validation process that runs during kernel callback events.
Additional Detection Vectors
Detection Priority Summary
Static analysis is effectively dead here due to the DecryptImport logic. If you're working on a project for Rust, focus on how your return addresses look in the kernel stack. If they aren't backed by a legitimate, signed module, you're just a ticking time bomb.
Anyone else digging into the latest EOS modules?
Import Obfuscation — The DecryptImport Nightmare
EAC does not rely on a standard IAT for sensitive kernel APIs. Instead, they resolve almost everything at runtime via a single exported function: DecryptImport (sourced from the EasyAntiCheat_EOS usermode module). Every single callsite in the driver uses unique decryption parameters, making static analysis a massive pain.
Code:
// Example of callsite-specific decryption
// stack frame chain walking func = ROR8(DecryptImport(&RtlWalkFrameChain), 21) ^ 0x84720A4F2CD7A4C1;
// stack unwinding func = ROR8(~DecryptImport(&RtlVirtualUnwind), 1) ^ 0x2DBC37BB37609566;There are over 47 callsites using this method. You can't just hook the resolver once; you have to reverse each specific rotation and XOR constant for every API you want to track. This completely nukes generic IAT hooking as a bypass strategy.
DriverEntry Anti-Disassembly
The entry point at 0x18012E054 uses a classic jmp +1 trick to break linear disassemblers like IDA or Ghidra. It jumps into the middle of the next instruction, leading into junk bytes to confuse the auto-analysis. You'll need to manually define the function at the calculated target to get a clean view.
Filesystem & Hardware Visibility
EAC acts as a filesystem minifilter (FLTMGR). They aren't just checking game files; they are monitoring system-wide I/O. They see every read, write, and rename in real-time.
- FLTMGR: Uses FltGetRequestorProcess to identify exactly which process is touching specific files.
- TBS (TPM): They talk directly to the TPM 2.0 chip using Tbsip_Submit_Command. This means hardware-rooted HWIDs. If they pull your endorsement keys, standard OS-level spoofing is useless.
- CNG (Crypto): Full BCrypt suite for module integrity hashing and encrypted comms.
- UASPSTOR: Accessing USB storage bus interfaces, likely for serial collection on external drives.
The Mapped Driver Killer: Stack Validation
This is how most of you are getting clapped. EAC uses a two-stage stack validation process that runs during kernel callback events.
4.1 Frame Chain Capture (sub_1800A6928)
EAC uses probabilistic sampling. It only captures stack traces about 1% of the time (random % 100 == 0). This is a performance trade-off, but statistically, if you stay connected, they will eventually sample your stack. It grabs 8 kernel stack frames using RtlWalkFrameChain.
4.2 Stack Validation (sub_1800D7870)
Once captured, every return address in the chain is validated against known module bounds stored in globals. If any address points to unmapped memory or memory outside of legitimate signed modules — your manually mapped driver is flagged instantly. They also check for abnormally short stacks (minimum 3 valid frames required).
EAC uses probabilistic sampling. It only captures stack traces about 1% of the time (random % 100 == 0). This is a performance trade-off, but statistically, if you stay connected, they will eventually sample your stack. It grabs 8 kernel stack frames using RtlWalkFrameChain.
4.2 Stack Validation (sub_1800D7870)
Once captured, every return address in the chain is validated against known module bounds stored in globals. If any address points to unmapped memory or memory outside of legitimate signed modules — your manually mapped driver is flagged instantly. They also check for abnormally short stacks (minimum 3 valid frames required).
Additional Detection Vectors
- Image Verification: Hooked into the CI.dll pipeline via SeRegisterImageVerificationCallback. They inspect every driver before it even finishes loading.
- NMI Callbacks: They use non-maskable interrupts to inspect execution state across all cores, making it harder to hide via standard masking.
- VBS/HVCI Check: They query VslGetSecurePciEnabled to adjust their detection logic if Virtualization-Based Security is active.
- Kernel Debugging: Direct check for KdEnteredDebugger to see if you're trying to live-debug the system.
Detection Priority Summary
- CRITICAL: Stack Walking (RtlVirtualUnwind), Image Verification, and Minifilter filesystem monitoring.
- HIGH: TPM 2.0 Hardware Attestation and CI.dll module validation.
- MEDIUM: NMI Callbacks, ETW tracing (NtTraceControl), and Anti-Debug checks.
Static analysis is effectively dead here due to the DecryptImport logic. If you're working on a project for Rust, focus on how your return addresses look in the kernel stack. If they aren't backed by a legitimate, signed module, you're just a ticking time bomb.
Anyone else digging into the latest EOS modules?
