# V2 Anti-Cheat Architecture And Operations

This runbook covers `TODOS.phase-72.72.10.2.15`. It is the source-of-truth
documentation for V2 anti-cheat architecture, detection methods, and operational
procedures across client-side collectors, server-side validators, fair-play
review, third-party providers, and CI testing.

## Architecture

V2 anti-cheat uses layered server authority with client-side evidence as
supporting signal. Client collectors never own match truth by themselves; they
produce signed telemetry, forensic evidence ids, and fair-play signals that the
server, replay system, and reviewer tooling can correlate with authoritative
match state.

The architecture has these control planes:

- Client collectors: memory integrity scanning, process scanner, driver
  integrity, client heartbeat, anti-cheat module obfuscation, screenshot or
  video capture on suspicion, self-update signatures, hardware fingerprinting,
  overlay or hook detection, anti-cheat mode opt-in, and minimal-footprint mode.
- Server validators: server-authoritative movement validation, hit detection,
  damage validation, economy validation, statistical anomaly detection, and
  replay-based cheat review.
- Fair-play adjudication: ban system, appeal workflow, shadow ban routing,
  player-submitted reports, trusted player fast-track review, analytics
  dashboard, and ranked fail-closed policy.
- Provider adapters: EasyAntiCheat and BattlEye integrations are exposed through
  the provider-neutral third-party anti-cheat integration API. Provider events
  are normalized before they can mirror into fair-play review.
- Testing and release gates: the anti-cheat testing framework simulates known
  cheat types, verifies expected detections, checks deterministic replay
  evidence, rejects excessive false positives, and emits fair-play validation
  signals in CI.

The canonical signal flow is:

1. A detector or provider emits a typed detection event with account, match,
   build, detector, risk, and evidence identifiers.
2. Server validators attach authoritative state such as movement replay,
   lag-compensated hit traces, economy transaction history, or replay review
   timestamps.
3. Evidence is normalized into a fair-play signal with a forensic evidence id,
   privacy classification, and reviewer visibility policy.
4. Analytics dashboards aggregate detection rate, ban count, appeal rate, and
   new-cheat emergence metrics without exposing raw player identifiers.
5. Review and discipline systems apply ban, appeal, shadow-ban, or no-action
   outcomes according to ranked mode, evidence quality, appeal route, and
   regional privacy constraints.

Ranked and tournament modes fail closed when required detectors, provider
plugins, replay evidence, or fair-play signal routing are unavailable.
Non-ranked and single-player modes can use anti-cheat opt-out or
minimal-footprint policy when the mode contract allows mods and does not affect
competitive integrity.

## Detection Methods

Detection methods are grouped by source, but all methods must be explainable in
review evidence and reproducible through replay or test fixtures where possible.

### Client-Side Methods

- Memory integrity scanning detects injected DLLs, modified code pages, hooked
  functions, and unexpected executable-page hashes. Findings map to
  `EV2FairPlaySignalType::MemoryIntegrity`.
- Speed hack detection compares signed client game time with server wall-clock
  time and flags sustained divergence above the configured tolerance.
- Aimbot heuristics analyze input patterns, snap-to-target speed, perfect
  tracking, reaction-time windows, target switching, and replay-visible aim
  correction.
- Wallhack mitigation combines server-side visibility culling with client-side
  graphics driver hook detection. The server should not transmit occluded entity
  state that the client does not need.
- Movement, teleportation, and fly-hack validation replay client inputs against
  server physics constraints and rejects impossible position, velocity, or
  acceleration deltas.
- Process scanning detects known cheat tools, debuggers, memory editors, and
  open game-memory handles while preserving an allowlist for signed overlays.
- Driver integrity verifies graphics driver identity, publisher, signature, and
  hook status before ranked admission.
- Client heartbeat requires periodic signed proof that the client build, module
  hashes, provider session, and heartbeat channel are still intact.
- Overlay or hook detection identifies render-pipeline injection and separates
  allowed accessibility, capture, and platform overlays from suspicious hooks.
- Screenshot or video capture is suspicion-triggered, audit logged, reviewer
  gated, and subject to privacy redaction before export.
- Hardware fingerprinting supports repeat-offender correlation and hardware ban
  enforcement, but must use the documented privacy and appeal guardrails.
- Self-update signatures allow detection rules to ship without a full game
  patch. Signature bundles must be signed, versioned, rollback-capable, and
  tested before release.

### Server-Side Methods

- Server-authoritative movement validation replays input streams and compares
  resulting positions to client reports.
- Server-authoritative hit detection validates shots against server-side player
  positions with lag compensation and weapon timing.
- Damage validation rejects impossible damage, fire-rate, range falloff,
  resource, cooldown, and state transitions.
- Resource and economy validation treats the server ledger as authority for all
  currency, item, crafting, and reward transactions.
- Statistical anomaly detection flags players whose ranked behavior, accuracy,
  headshot rate, K/D, economy gains, or match graph patterns deviate from
  population baselines.
- Replay cheat review records match replays, timestamps suspicious plays,
  attaches reviewer notes, and keeps evidence available for ban appeal.
- Third-party anti-cheat provider callbacks map EasyAntiCheat and BattlEye
  session start, heartbeat, violation, sanction, and session-end events into the
  V2 fair-play signal model.
- The testing framework simulates memory tamper, speed hack, aimbot, wallhack,
  movement hack, process tool, driver hook, and heartbeat tamper fixtures to
  verify that detection continues to work.

## Operational Procedures

### Release Preflight

Run the focused gates before an anti-cheat release, self-update signature push,
or ranked-policy change:

```bash
python3 V2/ue/Tools/check-v2-online-anti-cheat-fair-play.py
python3 V2/ue/Tools/check-v2-anti-cheat-report-system.py
python3 V2/ue/Tools/check-v2-trusted-player-program.py
python3 V2/ue/Tools/check-v2-anti-cheat-analytics-dashboard.py
python3 V2/ue/Tools/check-v2-third-party-anti-cheat-integration.py
python3 V2/ue/Tools/check-v2-anti-cheat-testing-framework.py
python3 V2/ue/Tools/check-v2-process-scanner.py
python3 V2/ue/Tools/check-v2-driver-integrity.py
python3 V2/ue/Tools/check-v2-client-heartbeat.py
python3 V2/ue/Tools/check-v2-anti-cheat-module-obfuscation.py
python3 V2/ue/Tools/check-v2-suspicion-capture.py
python3 V2/ue/Tools/check-v2-anti-cheat-self-update.py
```

Release approval requires signed detector configuration, current provider SDK
metadata, replay evidence coverage, fair-play review routing, appeal route
coverage, and analytics dashboard visibility. Ranked releases must verify
fail-closed behavior before enabling matchmaking.

### Signature And Provider Rollout

Detection signatures roll out in stages:

1. Generate and sign the self-update bundle.
2. Run the anti-cheat testing framework against known cheat fixtures and benign
   false-positive fixtures.
3. Canary non-ranked telemetry first when the detector can operate in
   observation mode.
4. Enable ranked enforcement only after detection recall, false-positive rate,
   appeal-rate baseline, and replay-evidence coverage are within policy.
5. Keep rollback bundles available until the new-cheat emergence dashboard is
   stable for the release window.

Third-party provider rollout follows the provider-neutral API. EasyAntiCheat and
BattlEye plugin readiness, signed session tickets, heartbeat channel status,
server callback signatures, and fallback fail-closed policy must pass before
ranked admission.

### New Cheat Emergence

When analytics detects a new cheat emergence signal:

1. Triage detection rate, ban count, appeal rate, affected mode, platform,
   region, and provider session distribution.
2. Preserve representative replay evidence, telemetry snapshots, and detector
   evidence ids.
3. If evidence is weak, route to manual fair-play review instead of automatic
   discipline.
4. Build a known-cheat fixture for the anti-cheat testing framework.
5. Update signatures or provider mappings, rerun release preflight, and canary
   before ranked enforcement.
6. Monitor appeals and false-positive reports after rollout.

### Review, Discipline, And Appeals

Player-facing discipline must be traceable to evidence. A reviewer should be
able to see match id, timestamp, detector id, provider event id when present,
replay segment, risk score, account history, and prior appeal outcomes.

Ban waves are allowed when evidence quality is consistent and reviewer-approved.
Shadow-ban routing is reserved for confirmed cheater pool isolation and must not
hide evidence from the appeal workflow. Hardware bans require stronger evidence,
privacy review, and explicit appeal coverage.

Appeals must preserve the original evidence bundle, reviewer notes, detector
version, provider session id, and final reviewer decision. If a detector or
signature is rolled back for false positives, affected sanctions are requeued
for review.

### Evidence, Privacy, And Access

Anti-cheat evidence uses least-privilege access:

- Raw screenshots, video, hardware fingerprints, and provider payloads are
  restricted to fair-play operations and privacy-approved tooling.
- Analytics dashboards use redacted player identifiers and aggregate slices by
  mode, platform, region, detector, and provider.
- Evidence exports include audit id, reason, reviewer id, timestamp, and
  retention classification.
- Minimal-footprint and opt-out modes must never feed ranked enforcement.
- Classifier and statistical outputs are review-prioritization signals unless a
  separate policy explicitly authorizes automated action.

### Incident Response

For active bypass incidents, open an anti-cheat incident ticket with detector,
mode, build, region, provider, replay, and appeal context. Disable ranked
admission for affected detector families if required dependencies are missing.
Preserve logs and replay artifacts before changing signatures. Coordinate with
privacy, platform, security, and fair-play review owners before expanding
collection or discipline scope.

### Verification Inventory

The documentation contract is
`V2/ue/Content/V2/Online/AntiCheatDocumentation_V2_Contract.json`, and the
focused checker is `V2/ue/Tools/check-v2-anti-cheat-documentation.py`.

The documentation is anchored to these implementation contracts:

- `V2/ue/Content/V2/Online/OnlineAntiCheatFairPlay_V2_Contract.json`
- `V2/ue/Content/V2/Online/AntiCheatReportSystem_V2_Contract.json`
- `V2/ue/Content/V2/Online/TrustedPlayerProgram_V2_Contract.json`
- `V2/ue/Content/V2/Online/AntiCheatAnalyticsDashboard_V2_Contract.json`
- `V2/ue/Content/V2/Online/ThirdPartyAntiCheatIntegration_V2_Contract.json`
- `V2/ue/Content/V2/Online/AntiCheatTestingFramework_V2_Contract.json`
- `V2/ue/Content/V2/Online/ProcessScanner_V2_Contract.json`
- `V2/ue/Content/V2/Online/DriverIntegrity_V2_Contract.json`
- `V2/ue/Content/V2/Online/ClientHeartbeat_V2_Contract.json`
- `V2/ue/Content/V2/Online/AntiCheatModuleObfuscation_V2_Contract.json`
- `V2/ue/Content/V2/Online/SuspicionCapture_V2_Contract.json`
- `V2/ue/Content/V2/Online/AntiCheatSelfUpdate_V2_Contract.json`

Required release gates:

- `anti-cheat-documentation-source-present`
- `anti-cheat-documentation-architecture-coverage`
- `anti-cheat-documentation-detection-methods`
- `anti-cheat-documentation-operational-procedures`
- `anti-cheat-documentation-evidence-privacy`
- `anti-cheat-documentation-ci-wired`