Guide Evading EAC/BE Detections on Ophion EPT Hooks — Shadow Pages

[byte_corvus]

Been ripping apart a custom EPT hook implementation based on the Ophion hypervisor architecture. The setup is the standard Execute = Fake Page, Read/Write = Original Page logic, specifically designed for hitting protected modules under EAC and BattlEye environments.

After some aggressive A/B testing, I've narrowed down the detection surface. Here is what we know for sure:

1. Mapping a bare driver (no VMX) is currently safe.
2. Initializing the hypervisor (VMXON/VMLAUNCH) and hooking an arbitrary, unpublicized address doesn't trigger a ban.
3. The hammer only drops when the EPT hook is applied directly to the protected target module.

My write-protection is solid (revokes on write) and #DB tripwires are active to handle breakpoint challenges. Since the anti-cheat isn't generically flagging the HV infrastructure itself, they are likely using targeted scans once the module is touched.

Suspected Detection Vectors

1. R0 Live Hook State Discovery
Most Ophion-based pastes keep an

EPT_HOOK_STATE

(OriginalPfn, FakePfn, TargetCr3, etc.) in a global linked list. If the AC is dumping pool allocations or scanning the driver's memory for pointers leading to the game module, it's game over. Encryption or scattering this metadata is mandatory for production.

2. Physical Memory Scanning for Shadow Pages
This is the most likely culprit. The AC iterates through the 4KB original pages of the target module's executable sections and scans physical memory for pages that aren't image-backed but are nearly identical to the originals (differing only by the jump/patch). Even without the Hook RVA, the Original -> Shadow Page correlation stands out.

3. Timing Checks (R3/R0)
Internal pointer reads hitting VMEXITs cause a significant time delta. Even with MTF (Monitor Trap Flag) synchronization, the overhead is measurable. The consensus is usually that these are flagging mechanisms rather than instant ban triggers, leading to manual review.

4. Total Infrastructure Concealment
Standard DKOM is suicide. For a real release, you need to use the hypervisor to hide its own physical pages (VMCS, EPT structures, driver body) from the guest OS. Relying on

USE_PRIVATE_HOST_CR3

isn't a silver bullet.

Spoiler: Technical Notes

Current Challenges:
- PFN database unlinking to spoof physical memory scans.
- Hypervisor-level stealth for VT-x structures.
- Minimizing VMEXIT overhead during heavy pointer reads.

Any of you guys managed to successfully spoof physical memory correlation on Ophion without getting clapped by a PFN scan? Drop your thoughts on whether you're unlinking fake pages or just encrypting the hook state.