anti-cheat-systems

Anti-Cheat Systems & Analysis

Overview

This skill covers layered anti-cheat design across kernel drivers, privileged services, in-game components, and backend telemetry. It is most useful for mapping how modern anti-cheats monitor process handles, image loads, memory integrity, driver trust, virtualization abuse, DMA threats, and suspicious input behavior on Windows.

README Coverage

• Anti Cheat > Guide
• Anti Cheat > Stress Testing
• Anti Cheat > Driver Unit Test Framework
• Anti Cheat > Anti Debugging
• Anti Cheat > Page Protection
• Anti Cheat > Binary Packer
• Anti Cheat > CLR Protection
• Anti Cheat > Anti Disassembly
• Anti Cheat > Sample Unpacker
• Anti Cheat > Dump Fix
• Anti Cheat > Encrypt Variable
• Anti Cheat > Lazy Importer
• Anti Cheat > Anti-Cheat Programming
• Anti Cheat > Compile Time
• Anti Cheat > Shellcode Engine & Tricks
• Anti Cheat > Obfuscation Engine
• Anti Cheat > Screenshot
• Anti Cheat > Game Engine Protection:*
• Anti Cheat > Open Source Anti Cheat System
• Anti Cheat > Analysis Framework
• Anti Cheat > Detection:*
• Anti Cheat > Signature Scanning
• Anti Cheat > Information System & Forensics
• Anti Cheat > Dynamic Script
• Anti Cheat > Kernel Mode Winsock
• Anti Cheat > Fuzzer
• Anti Cheat > Windows Ring3 Callback
• Anti Cheat > Windows Ring0 Callback
• Anti Cheat > Winows User Dump Analysis
• Anti Cheat > Winows Kernel Dump Analysis
• Anti Cheat > Sign Tools
• Anti Cheat > Backup File / Backup Drivers
• Anti Cheat > Black Signature
• Windows Security Features

Major Anti-Cheat Systems

Easy Anti-Cheat (EAC)

• Multi-component architecture with service, driver, and game-facing protections
• Process integrity verification and memory inspection
• Runtime driver loading with strong client-side enforcement
• Used by: Fortnite, Apex Legends, Rust

BattlEye

• Kernel driver plus service and game module coordination
• Handle protection, process monitoring, and memory scanning
• Strong focus on injected code and runtime tampering visibility
• Used by: PUBG, Rainbow Six Siege, DayZ

Vanguard (Riot Games)

• Boot-start kernel driver with early visibility into later-loaded drivers
• Boot-time initialization
• Driver allowlisting and aggressive system trust checks
• Used by: Valorant, League of Legends

FACEIT AC

• Kernel-level competitive anti-cheat with strong process and driver monitoring
• Emphasis on platform integrity and low tolerance for hostile drivers
• Often discussed alongside Vanguard in kernel anti-cheat research

Valve Anti-Cheat (VAC)

• User-mode detection
• Signature-based scanning
• Delayed ban waves
• Used by: CS2, Dota 2, TF2

Other Systems

• PunkBuster: Legacy FPS anti-cheat
• FairFight: Server-side statistical analysis
• nProtect GameGuard: Korean anti-cheat solution
• XIGNCODE3: Mobile game protection
• ACE (Tencent): Chinese market protection

Detection Mechanisms

Detection Decision Methodology

Use research-rigor for source verification and empirical validation. Numeric values elsewhere in this skill are examples or research hypotheses unless they are tied to a representative, versioned calibration study for the target game.

1. Define the decision unit: player, engagement, session, account, device, or build; state the game mode, patch, platform, input method, and timeframe.
2. Establish telemetry trust: record whether each field is server-observed, server-derived, client-reported, or reconstructed. Client reports are adversarial inputs; server authority improves trust but does not eliminate clock, replication, schema, or game-logic errors.
3. Keep layers separate: observation -> finding -> attribution -> action. A detector hit is not itself proof of cheating or actor intent.
4. Calibrate locally: derive features, sample floors, and operating thresholds from representative data. Hold out players/sessions and time periods; segment results by relevant populations.
5. Measure deployment risk: report prevalence, FPR, FNR, precision, recall, calibration, uncertainty, and the expected review volume. A score in [0, 1] is not a probability unless calibrated as one.
6. Corroborate correctly: combine causally distinct signals and evaluate their joint errors. Correlated signals, maximum-score aggregation, or a fixed signal count do not guarantee a lower false-positive rate.
7. Review high-impact actions: preserve counterevidence and an appeal path; use human review or independently trusted evidence before punitive action when false positives remain plausible.

For invariant findings, first verify that the invariant is guaranteed in the observed state and exclude rollback, retry, reconnect, replication delay, legitimate transitions, administrator/test paths, stale baselines, and game bugs. Describe the result as a state-integrity violation until exploitation and attribution are separately supported.

Every evidence package should retain the raw artifact or immutable reference, timestamps and ordering, schema/game/detector versions, feature transforms, threshold/model version, sample counts, provenance, contradictory evidence, limitations, and the exact rule that fired.

Memory Detection

- Code section hashing and integrity verification
- Executable private memory and manual-map detection
- Injected module and anomalous image mapping detection
- Memory modification and stack provenance monitoring

Process Detection

- Handle access stripping and protected-process enforcement
- Thread start address, APC, and context inspection
- Debug register and hidden-thread monitoring
- Stack trace and module-correlation analysis

Kernel-Level Detection

- Driver verification, signature policy, and blocklist checks
- Callback registration and object access monitoring
- System call, dispatch table, and hook integrity checks
- PatchGuard, test-signing, and kernel trust state checks
- Kernel pool scanning (Segment Heap aware) for hidden drivers and shellcode

Kernel Pool Scanning (Segment Heap Era)

Why Segment Heap matters for anti-cheat:
Cheat drivers allocate memory in NonPagedPool for shellcode, hook tables,
hidden modules. The Segment Heap (19H1+) changed pool internals:
headers are HeapKey XOR encoded, allocation paths are split (kLFH, VS,
Segment, Large), metadata is isolated. Anti-cheat pool scanners must
understand these mechanisms to scan accurately without false positives.

Detection targets:

1. BigPool / Large Allocation scanning:
   - Walk nt!PoolBigPageTable (nt!PoolTrackTable)
   - Find allocations without corresponding DRIVER_OBJECT or loaded module
   - Detect manually mapped drivers that allocate large pool chunks
   - Large allocations have no inline header; metadata is external

2. VS Allocator chunk scanning:
   - Traverse _SEGMENT_HEAP → VsContext → SubsegmentList
   - Decode _HEAP_VS_CHUNK_HEADER using HeapKey:
     real_sizes = encoded_header ^ chunk_address ^ HeapKey
   - Check decoded chunk for suspicious PoolTag, executable content,
     or allocation without matching driver
   - VS chunks carry both _HEAP_VS_CHUNK_HEADER (encoded) and
     _POOL_HEADER (PoolTag still present)

3. kLFH bucket scanning:
   - _SEGMENT_HEAP → LfhContext → Buckets[] → AffinitySlots → Subsegments
   - kLFH randomizes block placement (harder to predict adjacency)
   - FreeHint encoded with LfhKey
   - Allocation pattern anomalies in specific size buckets can indicate
     pool grooming by cheat drivers

4. Suspicious PoolTag detection:
   - Cheat drivers use custom or rare tags; maintain blacklist
   - Cross-reference tags against known-good tag database (pooltag.txt)
   - Tags present in pool but absent from any loaded module = suspicious

5. Executable memory in NonPagedPool:
   - Find chunks with X permission but no corresponding module
   - Scan decoded chunk content for known cheat signatures, ROP gadgets,
     specific syscall stub patterns

6. Segment Heap integrity checks:
   - Validate the build-specific `_SEGMENT_HEAP` signature/layout using symbols
     and runtime checks (0xDDEEDDEE is observed on relevant layouts)
   - Verify VS chunk header encoding consistency
   - Detect tampered heap metadata (indicates heap exploitation attempt)

Required knowledge for scanner:
- nt!RtlpHpHeapGlobals (HeapKey, LfhKey) — obtained via pattern scan
- nt!ExpPoolQuotaCookie — for ProcessBilled decoding
- Per-pool-type _SEGMENT_HEAP instance addresses (nt!PoolVector)
- Allocation path determination (size → kLFH/VS/Segment/Large)

Anti-cheat KDP integration:
- Store detection rule tables in Secure Pool (ExAllocatePool3 + KDP)
- Correctly configured KDP can protect selected pages from ordinary VTL0 writes,
  including kernel R/W primitives, while the hypervisor and policy path remain
  trustworthy

Behavioral Analysis

- Raw input timing and pattern analysis
- Movement and aim anomaly detection
- Statistical improbability and ML-assisted scoring
- Telemetry collection and server-side review
- AI visual aimbot detection (input pattern + gameplay behavior)

AI Visual Aimbot Detection

AI visual cheats (screen capture + computer vision + hardware input) can be
among the harder classes to detect because some designs avoid game-memory
access, code injection, and a cheat driver on the gaming PC. Detection then
leans more heavily on trusted behavioral telemetry and contextual signals.

Input Pattern Analysis:
- Mouse movement micro-signature: a particular automation pipeline may retain
  acceleration or correction patterns distinguishable from a matched human
  baseline; this must be demonstrated rather than assumed
- Engagement timing: a given automation pipeline may produce a narrower
  latency distribution than a matched human baseline, but capture, inference,
  transport, smoothing, frame rate, and input hardw

---

*Content truncated.*