KERNEL LEVEL ANTI-CHEAT BYPASS
⚠️ DISCLAIMER: EDUCATIONAL PURPOSES ONLY
Bypassing anti-cheat software violates Terms of Service and can lead to permanent account bans, IP bans, and in some jurisdictions legal consequences. This guide is for understanding defensive techniques only.
INTRODUCTION
Modern anti-cheats like BattlEye, Easy Anti-Cheat (EAC), and Vanguard operate at Ring 0 (Kernel Mode). Traditional
user-mode cheats using ReadProcessMemory are instantly detected
by kernel-mode callbacks.
To bypass these systems, attackers must load their own unsigned driver into the kernel to read/write memory without triggering detection mechanisms. This guide explains how these techniques work.
Windows Protection Rings Architecture
PREREQUISITES
- C/C++ Programming Experience - Advanced knowledge required
- Windows Driver Kit (WDK) - For driver development
- Understanding of Windows Internals - Kernel structures, callbacks, etc.
- A Vulnerable Driver - For exploiting Driver Signature Enforcement (DSE)
CORE CONCEPTS
1. Driver Signature Enforcement (DSE)
Windows requires all kernel-mode drivers to be digitally signed by Microsoft. Since cheat developers can't get Microsoft signatures, they must bypass DSE.
Common Bypass Methods:
- KDMapper: Exploits vulnerable Intel/AMD drivers (e.g., iqvw64e.sys, gdrv.sys) to manually map unsigned drivers into kernel memory
- Bootkits: Hook the bootloader to disable DSE before Windows kernel loads
- DSEFix: Patches the kernel's CI.dll module to disable signature checks
HANDLE hDevice = CreateFileA(
"\\\\.\\VulnerableDriver",
GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING, 0, NULL
);
DWORD bytesReturned;
DeviceIoControl(
hDevice, IOCTL_MAP_DRIVER,
driverBuffer, driverSize,
NULL, 0, &bytesReturned, NULL
);
2. Kernel Callbacks & Detection
Anti-cheats register callbacks for process/thread/image load events. Any suspicious activity triggers detection.
Common Callbacks to Avoid:
PsSetCreateProcessNotifyRoutine- Monitors process creationPsSetLoadImageNotifyRoutine- Monitors DLL injectionObRegisterCallbacks- Protects process handles
3. Communication Methods
Standard IOCTL communication is easily detected by scanning for registered device objects.
Stealthier Alternatives:
Shared Memory (SMAP)
Create a shared memory section accessible from both user and kernel mode. No device object = harder to detect.
Data Pointer Hooking
Hijack a pointer in a legitimate driver (e.g., NIC driver) to point to your communication function.
Mouse/Keyboard Filters
Attach a filter to input devices and encode commands in fake input events.
4. Cleaning Traces
After loading, you must remove all traces of your driver from kernel memory.
PVOID MmUnloadedDrivers = GetProcAddress("MmUnloadedDrivers");
RtlZeroMemory(MmUnloadedDrivers, sizeof(UNLOADED_DRIVERS) * 50);
// Clear Big Pool allocations
ExFreePoolWithTag(DriverObject, 'TAG');
// Wipe PE headers
RtlZeroMemory(DriverBase, 0x1000);
5. Memory Reading Without Detection
Direct MmCopyVirtualMemory calls are hooked. Use alternative methods:
- Physical Memory: Read via
MmMapIoSpaceafter translating virtual→physical addresses - MDL Mapping: Create Memory Descriptor Lists to map target process pages
- APC Injection: Queue Asynchronous Procedure Calls to execute in target context
CONCLUSION
Kernel-level anti-cheat bypass is a cat-and-mouse game. As soon as a public mapper or technique is released, it gets flagged within days or weeks.
⚠️ Legal & Ethical Reminder:
- Using cheats in online games violates Terms of Service
- Distributing cheating software may violate computer fraud laws
- This information is for security research and understanding defensive techniques only
The only way to stay undetected long-term is to develop private, custom drivers and find your own vulnerable drivers to exploit. Public tools are burned immediately.
FAQ / CONCEPTS
⚠️ Defensive perspective: understanding attacks to build better defenses
❓ What is DSE and why does Windows require signed drivers?
Driver Signature Enforcement ensures that only Microsoft-approved kernel code can load. This stops the majority of rootkits and keyloggers, but it is not bulletproof — vulnerable signed drivers can be exploited to load arbitrary code anyway.
❓ How do anti-cheats detect manually-mapped drivers?
Several techniques: scanning for known vulnerable driver hashes, looking for
unlinked drivers in PsLoadedModuleList, detecting Big Pool allocations with suspicious tags,
enumerating MmUnloadedDrivers, and integrity-checking critical kernel structures.
❓ Is using a vulnerable driver illegal?
For security research and pentesting on systems you own: legal in most jurisdictions. For evading anti-cheat in online games: violates the game's EULA/ToS and can result in permanent bans. For loading unsigned drivers on a system you don't own: computer fraud / unauthorized access in most countries.
❓ What's the difference between BattlEye, EAC, and Vanguard?
BattlEye and EAC load on game start and unload on close (user-mode + optional kernel driver). Vanguard (Riot Games) loads at boot and stays resident, requiring a full system restart to disable — the strictest model. All three use kernel callbacks and integrity checks.
❓ Can you use HVCI (Hypervisor-Enforced Code Integrity) to fully block this?
HVCI (Credential Guard in enterprise) raises the bar significantly by enforcing code integrity in a VTL-1 hypervisor. It blocks most manual mapping techniques but is not enabled by default on consumer Windows and incurs a small performance cost (~3-5%).
❓ What about Linux / macOS games?
Most AAA anti-cheats target Windows only. Easy Anti-Cheat has Linux support (used by some games via Proton), but kernel-level detection is less mature. macOS games rely on GameIntegrity / Notarization but lack the rich kernel attack surface of Windows.
📚 Further reading (defensive research):
Microsoft WDK Documentation · WDF Samples · UnknownCheats (research archive)