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.

Threat Coverage and Enforcement Evidence

For input units, uploaded fields or missing events, use input provenance and measurement. For service faults, shadow/canary evaluation, rollout and affected decisions, use detector operations.

Separate detector design from server/backend correctness. For native Linux, SteamOS and Proton observations, use linux-platform-security 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 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. 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.

For a two-computer memory setup, first use acquisition and transport classification. PCIe inspection addresses a different surface from host-driver acquisition; neither observation alone establishes the entire system's integrity.