git:20260909.90b22a8 to git:20260913.ae72a69

- description: Analyze layered game integrity defenses and select repository resources for process-memory reports, acquired-memory forensics, callback scope, behavioral measurement and driver-policy evidence. Use for DMA versus host-mediated acquisition, input provenance, replay fidelity, collector health, detector rollout/recovery, device/account restrictions, network association and false-positive review. Map prerequisites and observation points, distinguish detection from enforcement, and produce versioned findings with corroboration and limits.

- ---

-

- # 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.

-

- ## Threat Coverage and Enforcement Evidence

-

- For input units, uploaded fields or missing events, use

- [input provenance and measurement](references/input-provenance-and-measurement.md).

- For service faults, shadow/canary evaluation, rollout and affected decisions, use

- [detector operations](references/detector-operations.md).

-

- Separate detector design from

- [server/backend correctness](../game-server-security/SKILL.md). For native Linux,

- SteamOS and Proton observations, use

- [linux-platform-security](../linux-platform-security/SKILL.md) before applying

- Windows-specific assumptions.

-

- Describe each threat by the capability needed, resource exposed, trust boundary

- crossed, and observation point available to the defender. Compare host, device,

- graphics, input, and server observations without assuming one collector sees all

- layers. Use the [attacker capability map](../game-hacking/references/attack-surface-map.md)

- for cross-layer classification, including attacks that do not modify game memory.

-

- For shared networks, account/device association, reported network restrictions,

- or claimed sanction duration, read

- [Network environment evidence](references/network-environment-evidence.md).

- Keep connection failure, rate limiting, detection, and enforcement as separate

- events. A common address, acquisition driver, or unusual input device needs

- context and corroboration before attribution.

-

- For firmware-tier, EPT/DMA, HVCI, containment, or TPM certainty claims, use

- [assurance boundaries](../dma-attack/references/assurance-boundaries.md).

-

- For a two-computer memory setup, first use

- [acquisition and transport classification](../dma-attack/references/acquisition-and-transport.md).

- PCIe inspection addresses a different surface from host-driver acquisition;

- neither observation alone establishes the entire system's integrity.

-

- Produce an evidence record containing the affected build, claimed attacker

- capability, collector and visibility limits, observation timeline, benign

- controls, supported finding, and remaining uncertainty. Consult

- [research-rigor](../research-rigor/SKILL.md) when evaluating a detector or

- turning a finding into an enforcement recommendation.

-

- ## Repository Resource Selection

-

- Choose inspection, forensics, callback, behavioral or policy resources by the

- observation they can support. Read

- [repository resources](references/repository-resources.md) for exact README

- families and the evidence required before drawing a detector conclusion.

-

- ## 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`](../research-rigor/SKILL.md) 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 hardware make absolute latency

- ranges setup-specific

- - Quantization: a specific coordinate-to-HID conversion may leave repeated

- rounding patterns, but integer deltas also occur in legitimate input

- - Correction patterns: some smoothing configurations produce repeated

- overshoot-and-settle shapes; compare them with matched legitimate behavior

- - Target switching: an explicit automated scoring objective may produce more

- consistent ordering than a matched baseline, but implementations vary

-

- Gameplay Behavioral Signals:

- - Anomalous K/D ratio combined with other statistical outliers

- - "Snap" engagement pattern: rapid crosshair movement to target

- followed by immediate fire, repeated consistently

- - FOV-boundary effect: some configured systems produce a sharper engagement

- cutoff near a chosen radius; estimate it statistically and test alternatives

- - Consistent headshot angle distribution that doesn't match

- the player's ranked skill bracket

- - Engagement rate: compare visible-target engagement with a matched population;

- high or stable rates are contextual signals, not class rules

-

- Environmental Detection:

- - OBS Game Capture may load a graphics-capture hook into the game on supported

- paths; this is legitimate capture evidence, not cheat attribution

- - Window/Display Capture backends vary across Windows Graphics Capture,

- BitBlt, Desktop Duplication, OBS version, and source settings

- - Frame-transfer detection should account for shared GPU resources, reusable

- staging resources, readback, synchronization, and legitimate capture tools

- - Known hardware input device USB VID/PID signatures

- (KMBox, certain Arduino/Teensy boards)

- - USB device enumeration anomalies: input device appearing/changing

- mid-session

- - Logitech driver version detection: known exploitable G HUB versions

- - A known input-filter driver is a contextual signal; legitimate use and actual

- behavior must be established before assigning risk

-

- Server-Side Statistical Analysis:

- - Aim trajectory reconstruction from server-received input deltas

- - Compare aim distribution against player population at same rank

- - Detect systematic per-frame aim correction vectors

- that deviate from matched legitimate distributions

- - Cross-session pattern analysis: test whether unusually stable metrics remain

- discriminative after controlling for skill, hardware, and play style

- - Replay-based ML classifiers trained on confirmed AI aimbot cases

-

- Anti-AI Countermeasures (Game Design):

- - Evaluate ordinary gameplay effects, visual variety, and UI composition for

- model robustness without degrading accessibility or legitimate play

- - Server-side aim validation: reject physically impossible aim transitions

- - Treat model-targeted visual changes as experiments; adaptive models can

- retrain, and game-design costs may outweigh temporary detection gains

- ```

-

- ### Server-Side Replay Analysis for AI Aimbot Detection

-

- Before interpreting trajectories or reaction time, use

- [input measurement](references/input-provenance-and-measurement.md) and

- [time, ordering and replay](../game-server-security/references/time-ordering-and-replay.md).

-

- ```

- Server-side detection can analyze gameplay and input telemetry without relying

- on local process-scanning hits. It is a strong complementary layer against

- zero-memory AI cheats when telemetry provenance and integrity are trustworthy;

- client-uploaded fields remain untrusted until validated.

-

- Input Telemetry Collection:

- - Separate server-observed view/action state from uploaded client input

- - For each field record origin, units, sample rate, aggregation and validation;

- server tick records alone do not establish raw-device or sub-tick coverage

- - Record timestamps at the highest reliable precision supported by the input,

- engine, transport, and clock-synchronization pipeline

- - Record crosshair angle / view angle per tick

- - Record fire events with corresponding view angle at fire time

- - Record damage events with hit location (head/body/limb)

- - Collect per-session: total engagement count, hit count,

- headshot count, K/D, average engagement distance

-

- Replay-Based Trajectory Reconstruction:

- - Reconstruct only the sampled trajectory supported by recorded data;

- preserve missing intervals, transformations and interpolation uncertainty

- - Overlay trajectory onto 3D game state (player positions, obstacles)

- - Identify "engagement windows": trajectory segments where crosshair

- moves toward and locks onto a target

- - Measure per-engagement: time-to-target, overshoot magnitude,

- correction count, final hold time before fire

-

- Statistical Features for AI Detection:

- (extracted from reconstructed trajectories)

-

- Temporal features:

- - Reaction time distribution: time from target visibility to

- first crosshair movement toward target

- → Distinguish world, replicated, replay and displayed visibility;

- define the available observation point before measuring the interval

- → Compare automation and human distributions only within a matched,

- versioned setup; target-visibility definition, tick rate, latency, skill,

- and input method materially change the result

- - Time-to-lock distribution: time from engagement start to

- crosshair on target

- → Compare matched distributions; consistency is a hypothesis to evaluate,

- not a universal distinction between automation and human behavior

-

- Spatial features:

- - Trajectory curvature: some smoothing algorithms produce repeated parametric

- shapes, but both automation and human trajectories vary by configuration,

- device, sensitivity, and task

- - Overshoot-correction ratio: compare distributions within matched conditions;

- neither automation nor human behavior has a universal shape

- - End-point precision: test for repeated offsets or concentration relative to a

- skill- and context-matched baseline

- - Angular velocity profile: treat smoothness and acceleration as measured

- features, not class-defining rules

-

- Engagement pattern features:

- - Target selection consistency: automation configured with an explicit scoring

- objective may select targets more consistently than a matched human baseline;

- implementations need not use closest-to-crosshair or confidence ordering

- - FOV boundary effect: measure boundary behavior in a declared coordinate

- space and context; there is no universal automated/human cutoff shape

- - Engagement rate: measure against a defined visible-target denominator

- and matched task/skill/input context; consistency alone is not attribution

- - Multi-target switching: compare timing and grouping against matched

- baselines; regularity is a candidate feature, not proof of automation

- ```

-

- ### ML Classifier for AI Aimbot Detection

- ```

- Feature engineering and model architecture for detecting

- AI-generated mouse input at scale.

-

- Declare observed coordinate spaces, transformations and sampling/time bases.

- Device-relative units, normalized absolute coordinates, viewport pixels and

- view-angle degrees are distinct; pixel metrics require supported pixel data

- or a documented conversion. See the input measurement reference above.

-

- Feature Vector (per engagement window):

- f1: reaction_time_ms

- f2: time_to_lock_ms

- f3: initial_angular_distance_deg

- f4: trajectory_curvature_mean

- f5: trajectory_curvature_std

- f6: overshoot_magnitude (declared coordinate space and units)

- f7: correction_count

- f8: final_hold_time_ms

- f9: angular_velocity_max_deg_per_sec

- f10: angular_velocity_std

- f11: micro_correction_rate (calibrated threshold, declared units/time base)

- f12: trajectory_straightness_ratio (distance / path_length)

- f13: dx_dy_correlation (Pearson correlation of delta components)

- f14: delta_magnitude_entropy (Shannon entropy of |delta| sequence)

- f15: fire_timing_relative_to_lock_ms

-

- Session-level aggregate features:

- s1: headshot_ratio

- s2: hit_ratio

- s3: reaction_time_cv (coefficient of variation across engagements)

- s4: engagement_rate (targets engaged / targets visible)

- s5: k/d_ratio

- s6: fov_engagement_boundary_sharpness

- s7: target_selection_optimality_score

- s8: trajectory_curvature_consistency (inter-engagement variance)

-

- Model architecture options:

- - Gradient Boosted Trees (XGBoost/LightGBM):

- Strong candidate for tabular feature vectors, with fast inference and useful

- diagnostics; validate explanations and deployment fit

- - Random Forest: useful baseline; overfitting depends on data and tuning

- - 1D-CNN / LSTM on raw delta sequences:

- Operates on raw (dx, dy, dt) sequences instead of engineered features.

- Can capture patterns human engineers might miss.

- Higher compute cost; suitable for batch/offline analysis.

- - Ensemble: combine tree-based features and sequence models only when held-out

- evaluation shows a worthwhile gain after calibration and complexity costs

-

- Training data:

- - Positive samples: confirmed AI aimbot users (manual review, honeypot,

- or controlled testing with known cheat software)

- - Negative samples: legitimate high-skill players (important: include

- top-percentile players to avoid false-positives on skilled play)

- - Hard negatives: players with aim-assist controllers (console),

- players using legitimate accessibility tools

-

- Evaluation metrics:

- - Choose an operating point from prevalence, error costs, enforcement policy,

- and review capacity; there is no universal acceptable FPR or TPR

- - Report FPR, FNR, precision, recall, calibration and confidence intervals on

- representative held-out data, including population slices

- - Session-level aggregation can reduce transient noise, but only after

- validating cross-session dependence, drift, and its effect on both FP and FN

-

- Deployment pipeline:

- Client → input telemetry upload (per tick) → server telemetry DB

- → batch feature extraction (per engagement window)

- → ML inference (per session)

- → risk score aggregation (per player, across sessions)

- → threshold → manual review queue or automated action

-

- Adversarial robustness:

- - Cheat developers tune smoothing parameters to evade specific features

- - Defense: retrain model periodically on newly confirmed samples

- - Use feature combinations rather than single-feature thresholds

- - Aggregate across sessions only after validating dependence, drift, and

- attacker adaptation

- - Evaluate both raw-sequence and engineered-feature models adversarially;

- neither architecture is inherently harder to evade

- ```

-

- ### Hardware Input Device Detection

- ```

- Detecting KMBox and similar hardware input injectors at the

- platform/driver level.

-

- USB Enumeration Signals:

- - Known VID/PID combinations for KMBox, Arduino Leonardo (2341:8036),

- Teensy (16C0:0486), generic CH340/CP2102 serial adapters

- - USB device appearing/disappearing during game session

- - Multiple HID mouse devices where only one physical mouse is expected

- - USB device with HID mouse capability but no manufacturer string

- or generic "Arduino LLC" / "Teensyduino" manufacturer

-

- USB HID Report Analysis:

- - Hardware input devices generate genuine HID reports, but:

- - Report rate: a simplistic injector may expose programmed periodicity, but

- real devices and sophisticated injectors can both show jitter

- - Report timing: some automation pipelines create burst patterns; human and

- legitimate software-assisted input can also be bursty

- - Delta distribution: compare against matched devices, polling rates,

- sensitivity, and movement tasks before drawing conclusions

-

- Network Traffic Indicators (KMBox Net):

- - KMBox Net uses UDP communication on the local network

- - Packet pattern: consistent-size UDP packets at high frequency

- from a secondary device to the KMBox's IP

- - Network evidence requires a collector that receives the relevant traffic.

- A shared LAN or public address alone provides neither visibility into every

- inter-device exchange nor evidence of prohibited use.

-

- Driver-Level Detection:

- - interception.sys: known driver signature, detectable via

- module enumeration and PiDDBCacheTable

- - Logitech G HUB DLL injection: detect unexpected DLL loads

- into GHUB process, or specific exploitable GHUB versions

- via file version checking

-

- Limitations:

- - Protocol-conformant hardware injection may be indistinguishable from a normal

- mouse from an individual HID report alone; descriptors, timing, provenance,

- and gameplay behavior can still provide imperfect signals

- - Device signatures can identify known implementations but are not durable

- attribution; statistical input analysis also requires calibration

- - Dual-machine capture can avoid a cheat process on the gaming PC, but still

- leaves ordinary capture/input-device effects and may leave network or device

- telemetry depending on the design

- ```

-

- ## Anti-Cheat Architecture

-

- ### User-Mode Components

- - Process scanner

- - Module verifier

- - Overlay detector

- - Screenshot capture

-

- ### Kernel-Mode Components

- - Driver loader

- - Memory protection

- - System callback registration

- - Hypervisor and driver trust detection

- - VAD and executable memory inspection

-

- ### Hypervisor-Level Components

-

- Potential roles include CPU memory-permission enforcement and integrity evidence

- for specifically protected regions. Identify the actual hypervisor integration,

- policy owner, protected object/page lifetimes, and configuration interface.

- Hypervisor presence does not establish that callback lists, telemetry structures,

- or arbitrary third-party code are protected. DMA remapping is a separate path.

- [Assurance boundaries](../dma-attack/references/assurance-boundaries.md)

-

- ### Server-Side Components

- - Statistical analysis

- - Replay verification

- - Report processing

- - Ban management

-

- ## Research Techniques

-

- ### Static Analysis

- 1. Dump and analyze AC drivers

- 2. Reverse engineer detection routines

- 3. Identify signature patterns

- 4. Map callback registrations and trust boundaries

-

- ### Dynamic Analysis

- 1. Monitor system calls

- 2. Track driver communications

- 3. Inspect memory layout and module provenance

- 4. Debug with kernel or hypervisor tools

-

- ## Bypass Categories

-

- ### Memory Access

- - Physical memory read/write

- - DMA-based access

- - Hypervisor memory virtualization

- - Driver-based access

-

- ## DMA Cheat Detection Methodology

-

- ### PCIe-Layer Detection Pipeline

-

- Compare supported inventory and device observations with a matched, documented

- baseline. Record exact SKU/function, firmware, driver, platform topology, power

- state, and workload before interpreting an identity or behavior discrepancy.

-

- - Configuration: identifiers, capability structure, OS-assigned resources, and

- collector coverage; an unknown identifier is not an automatic verdict.

- - Function: applicable device contract and existing register/driver evidence;

- a zero value or idle device has legitimate explanations.

- - Link and errors: negotiated state, platform policy, power/workload context,

- available logs, and missing-data limits.

- - Decision: specific discrepancy, plausible benign causes, corroboration, and

- evaluation error rates for the population where the rule will operate.

-

- Windows owns PCI headers and capability registers. A generic collector should

- not modify another driver's bus-master, interrupt, BAR, or remapping state as a

- live classification probe. Use documented, permitted interfaces and read the

- [platform ownership limits](../dma-attack/references/assurance-boundaries.md).

-

- ### Completion Latency Fingerprinting

- ```

- Completion-latency distributions can reflect memory, arbitration, buffering,

- power state, link, driver, and workload behavior. A simplistic BRAM-backed

- emulator may show unusually low variance, but neither distribution shape is

- universal.

-

- Statistical methods:

- - Kolmogorov–Smirnov test: compare empirical CDFs vs reference

- - Hill estimator: tail index (real silicon has non-trivial tail)

- - Anderson-Darling test: sensitive to tail differences

-

- Added random jitter is not equivalent to reproducing a donor distribution.

- Validate mean, variance, tails, modes, autocorrelation, and condition changes

- against matched hardware.

- ```

-

- ### MSI/MSI-X Behavioral Validation

- ```

- - Device with MSI Enable + programmed Address/Data + attached driver

- should produce interrupts when a verified device condition triggers them

- - Zero interrupts when driver should exercise device = anomalous

- - Uniform arrival times may indicate timer-driven emulation, but legitimate

- periodic workloads must be excluded

- - MSI-X probe: mask vector → induce condition → observe PBA bit →

- unmask → observe interrupt firing. Conforming implementations should preserve

- the expected state transition; incomplete emulations may fail.

- ```

-

- ### Cheat-Phase Access Pattern Recognition

- ```

- One possible pattern is a slow, broad discovery phase followed by narrower,

- periodic reads of a smaller offset set during use. Rates and phases vary by

- implementation and can be randomized.

-

- Execution phase statistical signature:

- - High temporal periodicity

- - Low address-space breadth

- - Alignment to game-frame intervals

- - Distinguishing features: Fano factor, autocorrelation at frame intervals,

- address-space coverage entropy

-

- Decoy evidence must identify the requester and collector. An EPT trap concerns

- CPU access; device DMA needs its own remapping/fault or platform evidence.

- An application event has different semantics. None alone establishes cheating.

- ```

-

- ### IOMMU-Layer Detection

- ```

- Fault-Rate Monitoring:

- - Per-device fault rate from IOMMU fault-recording / WHEA

- - Establish a platform-, device-, driver-, and workload-specific benign

- baseline; legitimate bugs, resets, firmware issues, and mapping races can

- produce faults

- - A sustained nonzero rate is evidence of failed or invalid DMA requests, not

- by itself evidence of cheating or actor intent

-

- Domain Assignment Audit:

- - Flag devices on passthrough/identity domains under strict mode

- - Flag unexpectedly large IOMMU groups (poor ACS topology)

- - Verify multi-function devices sharing Domain ID legitimately

-

- ACS Topology Verification:

- - Walk bridge topology, verify Source Validation, Translation Blocking,

- P2P Request/Completion Redirect on every relevant bridge

- - Missing/disabled ACS is a potential isolation gap where peer routing is

- possible; confirm the full topology, root-complex behavior, and IOMMU grouping

- ```

-

- ### IOMMU Containment Boundaries

-

- Identify the OS/platform authority for device isolation, the affected hierarchy,

- current mappings, in-flight work, recovery owner, and evidence of completed

- isolation. Remapping, bus-master state, and downstream-port containment have

- separate prerequisites; their effectiveness is not determined by a firmware tier.

-

- A generic game-security driver must not take ownership of another driver's PCI

- configuration or remapping state. Use documented platform lifecycle/policy

- controls, evaluate availability effects, and separate authorized access restriction

- from a sanction decision.

- [Containment contract](../dma-attack/references/assurance-boundaries.md)

-

- ### External Trust Anchors

-

- Attestation can support confidence in selected measurements when key enrollment,

- verifier trust, freshness, measurement-log consistency, and appraisal policy are

- validated. It does not automatically reveal a present DMA device or every live

- IOMMU mapping, and a manufacturer certificate is not a universal attestation-key

- trust chain.

-

- PCR meanings and reset/extend rules depend on the platform profile. The Windows

- OEM DMA-protection event has a specified scope; interpret absence only with an

- applicable and trustworthy measurement path. Keep measured boot, runtime evidence,

- and protection-policy compliance as separate findings.

- [TPM and platform evidence](../dma-attack/references/assurance-boundaries.md)

-

- ### Layered Detection Synthesis

- ```

- No single signature is durable. Production pipeline layers:

-

- 1. Pre-game: record platform support, effective remapping and security policy,

- observed-running services, applicable firmware fixes, topology, attestation

- coverage, and explicit unknowns; apply a documented deployment baseline

-

- 2. Inventory: supported device/configuration snapshot with readable span,

- missing fields, problem codes, and SMBIOS slot cross-reference

-

- 3. Config integrity: per-donor reference database comparison

-

- 4. Behavioral sampling: Link Status, AER counters, interrupt rates,

- IOMMU fault rates, BAR content

-

- 5. Statistical analysis: latency distributions, interrupt distributions,

- ASPM transition rates

-

- 6. Cheat-phase: honeypot access, access pattern classifiers

-

- Verdict requires multi-signal correlation — single signals can

- false-positive. Use causally distinct signals and measure the joint error rate;

- correlated detectors can fail together, and no fixed signal count guarantees a

- practical false-positive rate.

- ```

-

- ### Device Evidence Instead of Firmware Tiers

-

- Public/private labels and informal tier numbers are not validated assurance

- levels. Evaluate identity/provenance, configuration/function, runtime behavior,

- remapping policy, and platform trust separately. An identifier match can support

- a classification rule only within its evaluated scope; it does not imply

- immediate detection or malicious intent. No device label establishes that TPM

- attestation is necessary or sufficient for its detection.

-

- Report observed dimensions, untested properties, collector requirements, matched

- benign baselines, and measured decision error rates.

- [Device evidence dimensions](../dma-attack/references/assurance-boundaries.md)

-

- ### Forensic Evidence for DMA Cases

- ```

- Capture on detection:

- - Supported configuration snapshot and capability structure, with missing fields

- - PCIe link state history (LTSSM, ASPM transitions)

- - MSI/MSI-X arrival timeline

- - AER correctable counts

- - IOMMU fault log entries + domain assignments

- - ACS bridge state

- - Protected-page CPU events (EPT evidence, with policy context)

- - Device DMA events from the relevant platform/IOMMU collector

- - TPM quote, selected measurement profile, and consistent event log

- - MCFG / DMAR / IVRS ACPI tables

- - SMBIOS slot inventory + BIOS version

- - Completion latency distribution histograms

-

- A useful evidence package combines hardware, behavioral, and temporal signals.

- The combined package is stronger only when provenance is trusted, alternative

- causes are tested, and the joint false-positive behavior is validated.

- ```

-

- ### Code Execution

- - Manual mapping

- - Thread hijacking

- - APC injection

- - Kernel callbacks

-

- ### Detection Evasion

- - Signature mutation

- - Timing attack mitigation

- - Stack spoofing

- - Module hiding

-

- ## Security Features Interaction

-

- ### Windows Security

- - Driver Signature Enforcement (DSE)

- - PatchGuard/Kernel Patch Protection

- - Hypervisor Code Integrity (HVCI)

- - Secure Boot

- - TPM-backed attestation considerations

-

- ### Virtualization Detection

- - VT-x/AMD-V detection

- - Hypervisor presence checks

- - VM escape detection

- - Timing-based detection

-

- ### Hypervisor-Based Defense for Anti-Cheat

-

- A trusted hypervisor can enforce processor memory permissions outside the guest

- kernel's direct control. This is conditional isolation, not a guarantee that

- all kernel-level tampering is prevented. Verify the actual integration, protected

- regions and lifetimes, policy/configuration authority, backing-memory isolation,

- and coverage of other privileged access paths.

-

- EPT violations concern CPU access under an active policy. Device DMA uses the

- separate IOMMU path; a hypervisor may manage both, but EPT alone is neither DMA

- protection nor DMA telemetry. Conversely, device DMA does not universally defeat

- a hypervisor deployment that also enforces appropriate IOMMU policy.

-

- Operating outside the guest kernel does not imply invisibility. Hyper-V provides

- guest-visible discovery interfaces, and performance or compatibility effects may

- also be observable. Presence alone identifies neither misuse nor specific

- protection coverage.

-

- Treat VBS/memory integrity, driver-blocking policy, and DMA remapping as separate

- controls with deployment and compatibility requirements. Memory integrity does

- not make every signed driver safe. Report supported, configured, and running

- state; a missing feature is not by itself misconduct. Use existing trusted

- platform evidence and owned-build review to verify these assumptions.

- [Hypervisor and DMA assurance](../dma-attack/references/assurance-boundaries.md)

-

- ## Code Protection Techniques

-

- ### Page Protection

- ```

- - Executable page guard pages and trap-based integrity monitoring

- - NX bit enforcement and DEP policy

- - PAGE_GUARD + single-step trap for code coverage without patching

- - VirtualProtect monitoring to detect runtime permission changes

- ```

-

- ### Binary Packing & Encryption

- ```

- - PE packers: UPX, Themida, VMProtect, Enigma, MPRESS

- - CLR protection: .NET obfuscation (ConfuserEx, Dotfuscator, .NET Reactor)

- - Encrypt Variable: runtime value encryption to frustrate memory scanners

- - Lazy Importer: compile-time import hiding to avoid IAT-based detection

- - Compile-time techniques: string encryption, constexpr obfuscation, COFF obfuscation

- ```

-

- ### Shellcode & Obfuscation

- ```

- - Shellcode engines: position-independent code generation, syscall stubs

- - Obfuscation engines: OLLVM-based, custom LLVM passes, MBA (Mixed Boolean-Arithmetic)

- - Anti-disassembly: opaque predicates, junk code insertion, control flow flattening

- ```

-

- ## Heartbeat & Screenshot

-

- ### Heartbeat Mechanisms

- ```

- - Periodic client-to-server health check packets

- - Encrypted challenge-response with server nonce

- - Timing anomalies can reflect scheduling, transport, collector or backend

- faults as well as other causes; diagnose the observation path first

- - Apply documented access-continuity policy separately from misconduct

- attribution; heartbeat failure alone does not establish grounds for a sanction

- ```

-

- ### Screenshot Capture

- ```

- - AC-initiated screen capture for manual or automated review

- - BitBlt / PrintWindow / DXGI desktop duplication

- - Anti-screenshot evasion: overlay hiding, DWM composition bypass

- - Server-side ML classifiers for ESP/overlay detection in captured frames

- ```

-

- ## Telemetry Pipeline

-

- ### Client-Side Collection

- ```

- - Module list enumeration and hash reporting

- - Handle table snapshots for suspicious access patterns

- - Stack trace sampling at periodic intervals

- - Driver load events and callback registration state

- - Hardware fingerprint (disk serial, NIC MAC, SMBIOS, GPU)

- ```

-

- ### Transport & Server-Side

- ```

- - Encrypted telemetry channel (TLS + custom encryption layer)

- - Server-side aggregation and anomaly scoring

- - ML-based behavioral clustering for ban waves

- - Replay system integration for suspicious session review

- ```

-

- ## Ethical Considerations

-

- ### Research Guidelines

- - Focus on understanding, not exploitation

- - Report vulnerabilities responsibly

- - Respect Terms of Service implications

- - Consider impact on gaming communities

-

- ### Legal Aspects

- - DMCA considerations

- - CFAA implications

- - Regional regulations

- - ToS enforcement

-

- ## Resources Organization

-

- ### Detection Research

- ```markdown

- - Anti-cheat driver analysis

- - Detection routine documentation

- - Callback enumeration tools

- ```

-

- ### Bypass Research

- ```markdown

- - Memory access techniques

- - Injection methods

- - Evasion strategies

- ```

-

- ### Tools

- ```markdown

- - Custom debuggers

- - Driver loaders

- - Analysis frameworks

- ```

-

- ## Repository Navigation

-

- Load [repository resources](references/repository-resources.md) for this

- domain's resource choices and evidence outputs. Use

- [shared repository navigation](../overview/references/repository-navigation.md)

- for local discovery layers, case-sensitive paths, missing snapshots and current

- upstream verification. Generated summaries are discovery aids, not independent

- evidence.

-

- The compiled [anti-cheat overview](../../../wiki/overviews/anti-cheat.md)

- can help locate related material; trace consequential claims to their underlying

- source.

-

- ## Data Source

-

- Use the following repository sources directly when applying this skill. Prefer

- available local files for discovery and scoped historical inspection; use the

- raw URLs when the collection is not installed locally. These entrypoint details

- are retained here so source lookup does not depend on loading another skill.

-

- ### 0. Compiled Wiki

-

- Start with [wiki/index.md](../../../wiki/index.md) for topical synthesis and

- cross-project connections. [Wiki schema](../../../wiki/AGENTS.md) describes its

- structure. Generated wiki pages are discovery aids; follow their original

- citations before adopting technical claims.

-

- Raw catalog: [wiki/index.md](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/wiki/index.md).

- For this domain, read [wiki/overviews/anti-cheat.md](../../../wiki/overviews/anti-cheat.md).

- Raw URL: [anti-cheat overview](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/wiki/overviews/anti-cheat.md).

-

- A direct project question can start with its README entry or description below;

- reading the entire wiki is unnecessary.

-

- ### 1. Project Overview and Resource Index

-

- [README.md](../../../README.md) contains the collection's actual categories,

- subcategories, project URLs and short descriptions. Find the relevant category

- and retain the original URL, including any specific file or revision suffix.

-

- Raw index: [README.md](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/README.md).

-

- ### 2. Repository Descriptions

-

- For a concise project summary, look for the actual local path:

-

- ```text

- description/{owner}/{repo}/description_en.txt

- https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/{owner}/{repo}/description_en.txt

- ```

-

- Example: [bgfx description](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/bkaradzic/bgfx/description_en.txt).

- Extract owner/repository from the original GitHub project URL, omitting a .git

- suffix. Resolve existing path casing before constructing a local/raw path.

- Descriptions are generated summaries, not independent verification. If absent

- or inaccessible, use the README entry, relevant archive or original project.

-

- ### 3. Repository Source Archives

-

- For deeper inspection of an available captured source tree, locate:

-

- ```text

- archive/{owner}/{repo}.txt

- https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/{owner}/{repo}.txt

- ```

- Example: [bgfx archive](https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/bkaradzic/bgfx.txt).

- Prefer inspecting the relevant portion of an existing archive over re-cloning

- merely to inspect the same captured material. Archives may exclude files, use

- fallback extraction or contain truncation; they are not guaranteed complete

- checkouts. Record any upstream revision evidence and included-file limits.

- If missing or insufficient, follow the README's original upstream URL.

- ### Choose and Verify the Source

- For a specific project, locate its README identity, use a description or wiki

- page for orientation when helpful, then inspect the relevant archive/source

- artifact for the question. For current compatibility or exact implementation,

- verify the matching upstream documentation, release or immutable source revision.

- Keep the collection revision and capture/generation dates separate from the

- upstream version. Multiple generated layers from one source are not independent

- corroboration, and missing archive content does not establish upstream absence.

- The per-domain resource guide above helps choose useful artifacts. Shared

- [repository navigation](../overview/references/repository-navigation.md) adds the optional read-only indexer,

- case-ambiguity handling and maintenance details; it supplements this Data Source

- section rather than replacing it.