Skip to content
Game Hacking Academy
Lesson 15.9Defensive Design and Anti-Cheat

Anti-Cheat in Modern Games

Compare documented protection boundaries and lifetimes without treating product names as proof of effectiveness.

Lesson 15.9
Read or listenPrint chapter or book
About 8 minutes

Keyboard shortcuts

?
Open this guide
Alt + B
Show or hide the lesson list
Alt + O
Show or fold the lesson outline
Alt + N
Open or close notes
Alt + H
Toggle semantic colours
Alt + D
Toggle page brightness
Alt + C
Toggle code brightness
← →
Move through a focused code trace
Home End
First or final step in a focused trace
Escape
Close this guide or an open panel

Reader shortcuts pause while you type in a text field.

Cheatsheet for Lesson 15.9Key ideas, reference and questions

A one-page summary of “Anti-Cheat in Modern Games” you can keep beside your notes. Plain Markdown.

Lesson 15.9 — Anti-Cheat in Modern Games: cheatsheet

  • Remember: This comparison was checked on October 5, 2026. Products change their requirements, supported games, and detection systems.
  • Also useful: Compare what a system sees, when it runs, and who owns the decision. Marketing names do not answer those questions alone.

Key terms

  • Opaque: Opaque means the game transports the data without interpreting its internal format.

Review

  • Q: What does the checked June 2026 Vanguard announcement change for sufficiently secured PCs that opt in? A: It permits protection to start with a Riot game
  • Q: A comparison of anti-cheat products says it was checked on a given date. What does that date tell a reader? A: Architecture was checked at that time
Download cheatsheet (.md)

This comparison was checked on October 5, 2026. Products change their requirements, supported games, and detection systems. The examples show documented architecture, rather than a ranking or a guarantee that any particular match is free of cheating.

VALORANT and Vanguard

Section titled “VALORANT and Vanguard”

Riot describes Vanguard as a game-time client component and a kernel driver. Its traditional mode starts the driver at boot so protection can observe the environment before the game client starts.

On June 24, 2026, Riot announced optional on-demand sessions for sufficiently secured PCs. In this mode, protection starts with a Riot game and runs while it is being played. The published prerequisites include an appropriate Windows version, Secure Boot, a TPM, virtualization-based security, code-integrity protection, and an IOMMU. Boot-managed operation remains a different mode; it is inaccurate to describe every Vanguard installation as always starting at boot.

VALORANT also illustrates why client protection cannot replace server design. Its server-side visibility policy limits hidden information sent to a client. Local privilege and server disclosure are separate controls.

Protection lifetime is a concrete difference

Section titled “Protection lifetime is a concrete difference”

A kernel component’s privilege describes what it may access. Its lifetime describes when it runs. The two properties are separate. The diagram compares illustrative boot-managed and session-managed lifetimes. Its animation time is slowed for viewing, rather than measuring a real boot.

When a component runs defines its observation window. This step-by-step trace needs JavaScript. Here is the code and where the run ends.

boot-start component begins at boot
game-session component begins with the game
choose before, during or after the game
ask which selected component is active
stop the session component with the game
report the observation window

Result: selected component active at this moment. Its data access still needs a separate capability explanation.

Final values: lifetime = session; moment = during; starts = game start; active = true; stops = game exit.

Read every step of the lesson’s example

  1. Step 1, line 1. Start with the selected inputs and follow how the next operation changes the state.

    lifetime = session; moment = during.

  2. Step 2, line 2. The two components have different start and stop boundaries.

    lifetime = session; moment = during; starts = game start.

  3. Step 3, line 3. Inspect the selected point in time.

    lifetime = session; moment = during; starts = game start.

  4. Step 4, line 4. Being active is separate from having permission to read a particular source.

    lifetime = session; moment = during; starts = game start; active = true.

  5. Step 5, line 5. The session ends with the game; the boot-long component remains in this schedule.

    lifetime = session; moment = during; starts = game start; active = true; stops = game exit.

  6. Step 6, line 6. Result: selected component active at this moment. Its data access still needs a separate capability explanation.

    lifetime = session; moment = during; starts = game start; active = true; stops = game exit.

Watch it happenCompare protection lifetimes

One monitor starts at boot; another starts and stops with the game.

Read the steps
  1. At boot, the boot-managed monitor is active. The game and session-managed monitor are not yet running.
  2. Starting the game activates the session-managed monitor too.
  3. During play, both examples are active. Their bars record when each service ran.
  4. The game stops. The session-managed monitor stops, while the boot-managed example remains active.
  5. The ongoing boot bar and ended session bar explain why protection lifetime and privilege are separate choices.

Illustrative lifetimes, not measured startup durations. Products can offer different modes.

The bars preserve the period each component was active. Ending a session-managed monitor when the game stops does not mean it had lower privilege while the game was running.

When protection is active, relative to the gameIllustrative spans, not measured product timelines: one protection starts at boot, the other with the game.

  1. 1 Boot-managed protection starts at boot

    Observation window
    bootend of window
    before the game
    game running
    after the game
    Boot-managed protection
    active from boot, past the game’s end, to the window’s edge

    The game runs for part of the window. This protection is active before it starts and after it ends, up to the window’s edge.

  2. 2 Session-managed protection follows the game

    Observation window
    bootend of window
    before the game
    game running
    after the game
    Session-managed protection
    active only while the game runs

    It starts and stops with the game. Both may have kernel privilege while active: they differ in when, not in how privileged.

Illustrative spans, not measured product timelines: one protection starts at boot, the other with the game.

Counter-Strike and Valve’s layers

Section titled “Counter-Strike and Valve’s layers”

VAC, Valve Anti-Cheat, contributes client-side detection and server enforcement of VAC status. The game still needs its own validation and review systems. The public material does not provide a complete recipe for VAC or VAC Live detections, so do not infer one from a product label.

Valve’s August 19, 2024 update described initial limited-match testing of VacNet 3.0 and asked for details of incorrectly cancelled matches. That dated announcement does not establish a universal current rollout or a measured detection rate.

Valve’s April 25, 2024 Counter-Strike 2 notes added an Overwatch system for match-demo review by trusted partners. This is a dated description of review support, not a promise that every account can access the old CS:GO review interface.

The earlier CS:GO Trust Factor documentation describes matchmaking using account and play observations, with changing factors left undisclosed. Matchmaking risk, detection, and a reviewed sanction are different decisions. A historical FAQ cannot establish today’s internal CS2 scoring formula.

Call of Duty and RICOCHET

Section titled “Call of Duty and RICOCHET”

Activision’s current description combines server-side systems and investigation with a PC kernel driver. It states that the driver operates only while a protected Call of Duty title runs, and monitors software interacting with those titles.

Server-side protections can also affect console players through shared services and cross-play. The presence of a PC driver does not imply that every participant uses the same local component.

Easy Anti-Cheat and BattlEye

Section titled “Easy Anti-Cheat and BattlEye”

Epic’s Easy Anti-Cheat integration through Epic Online Services supports client-server and peer-to-peer architectures. In client-server mode, game network code carries opaque messages between the client and server protection modules. Opaque means the game transports the data without interpreting its internal format. The developer still owns game-rule validation and must integrate the required session and message lifecycle.

BattlEye describes user-mode and kernel-mode protection, proactive prevention, and detection. These descriptions establish parts of its design, rather than an independent measurement of how well it protects every supported title.

A useful comparison also includes supported platforms, privacy, reliability, appeals, and the game’s own authority model. Public ban counts lack the undetected cases and legitimate population needed to calculate precision or recall. Lesson 15.4 explains those missing denominators.

Knowledge check

Separate lifetime from privilege

What does the checked June 2026 Vanguard announcement change for sufficiently secured PCs that opt in?

Finished Lesson 15.9?

Mark it done and the lesson list shows a beside it. A chapter whose lessons are all done is marked done too. Progress is saved in this browser only.

Chapter 15: 10 lessons

This book grew out of the original Game Hacking Academy by attilathedud and has been rewritten as a beginner-first course. Like the original repository, its source is published under the Apache License 2.0.