Source EAC/BE/VGK — Kernel Driver Communication Hook via Trap Frame (C++)

[byte_corvus]

Been digging into some kernel-level logic lately, and I stumbled across a decent educational base for those trying to wrap their heads around how EAC and VGK handle syscall hooking. Found this clean implementation for a custom driver that handles buffer pointers via trap frames in KiSystemCall64.

Technical Breakdown:
The core of this logic relies on grabbing the pointer to your buffer directly from the trap frame within the hook. Since RDX holds the second argument in the x64 calling convention, you are essentially intercepting the data flow before it hits the deeper anti-cheat validation layers.

Key Takeaways for Devs:

1. Architecture: This is a pure Kernel-mode driver approach. It is not designed for production or playing on your main, but it is a solid way to study how hooks interact with the OS syscall interface.
2. Hooking Point: Focuses on the KiSystemCall64 transition. If you are trying to understand how to maintain stability without BSODing the machine every time a thread hits a syscall, read the frame alignment here.
3. Safety Warning: As stated, this is absolutely not UD. Using this on a protected system will get you flagged by EAC/BattlEye/Vanguard heuristics almost instantly. It is purely for learning the mechanics of communication between user-mode and your custom driver.

Spoiler: Source Code

// Snippet of the hook logic for RDX buffer extraction
// Ensure your trap frame is correctly identified within the x64 environment
void* GetBufferFromTrapFrame(PKTRAP_FRAME TrapFrame) {
    return (void*)TrapFrame->Rdx;
}

Downloads:

Has anyone else here messed around with modifying the trap frame directly to bypass handle stripping? I am curious if you guys have found ways to sanitize the thread context further without triggering the watchdogs. Drop your fixes or improvements below if you managed to get a more stable hook out of this.