What Client Protection Can See

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.3Key ideas, reference and questions

A one-page summary of “What Client Protection Can See” you can keep beside your notes. Plain Markdown.

Lesson 15.3 — What Client Protection Can See: cheatsheet

• Remember: More local privilege expands what protection can inspect. It also expands the damage its own defects can cause.

Key terms

• User mode: User mode is the operating system's restricted execution environment for ordinary applications.
• kernel: The kernel is the operating system's privileged core.
• kernel driver: A kernel driver is code loaded into that environment to perform operating-system services.
• Attestation: Attestation is a verifiable report about measured system state.

Review

• Q: A driver carries a valid publisher signature, yet the loading policy refuses it. Which reason fits? A: Its identity matches the known vulnerable-driver blocklist
• Q: What can a user-mode protection component inspect? A: Permitted local files, modules, and process access

Download cheatsheet (.md)

Download cheatsheet (.md)

Server validation protects accepted results. It cannot directly inspect every change inside a player’s local process. Client protection adds observations on that machine, including file integrity, loaded code, and access to the game process.

User-mode checks inspect a limited view

User mode is the operating system’s restricted execution environment for ordinary applications. A local protection component can compare game files with trusted hashes, inspect loaded modules, or record permitted process-access events. Its permissions and operating-system interfaces limit what it can observe.

Each check sees one part of the machineA user-mode component works within the permissions Windows gives it.

1. 1 Files: the bytes on disk

   game.exe

   SHA-256 9F2C…41AB

   =

   trusted 9F2C…41ABmatch

   The hash covers game.exe as read from disk, not later changes in memory.

2. 2 Modules: what is loaded in the game

   Loaded

   game.exe

   hud.dllsupported overlay

   helper.dllunknown

   An unknown module is worth a look; it is not proof of a cheat.

3. 3 Access: who opened the game

   Handles to game.exe

   tool.exeread rights

   crash reporterread rights

   The same read rights, different purposes: check provenance and the game’s supported tools.

A user-mode component works within the permissions Windows gives it.

A handle grants access to an operating-system object, such as a process. An unexpected process with game-memory access can be relevant to an investigation. A handle’s existence alone does not establish a cheat. Debuggers, crash reporters, and permitted overlays can also interact with processes. Check the access rights, provenance, and game’s supported tools.

Lesson 14.7 separates integrity checks from the trust in the checking code. If a local checker and its reference are both under an adversary’s control, its successful report cannot establish an independent truth. Lesson 14.8 makes the same distinction for debugger signals: an observation and an enforcement decision are different jobs.

Kernel privilege adds visibility and responsibility

The kernel is the operating system’s privileged core. A kernel driver is code loaded into that environment to perform operating-system services. It can observe or enforce some boundaries unavailable to an ordinary application. See Lesson 12.9 for this trust boundary.

That privilege also increases the consequences of a defect. A bad memory access can crash the system rather than just the game. A vulnerable driver can expose dangerous operations to other software. Signing identifies an approved publisher and protects the signed bytes against alteration; it does not prove that their implementation is free of security bugs.

Microsoft’s vulnerable-driver blocklist illustrates an additional loading policy. A known vulnerable signed driver can be refused even though its signature is valid. An allowed driver still requires maintenance and compatibility testing.

A signature and a vulnerability decision differ. This step-by-step trace needs JavaScript. Here is the code and where the run ends.

read the selected inputs
evaluate each stated condition
combine the required conditions
perform the effect only when accepted
otherwise retain the old state
report the result and its limits

Result: this image passes the illustrated entry gate. That is not a proof of bug-free code.

Final values: signature = yes; blocked = no; signature_accepted = true; not_blocked = true; accepted = true; admitted = true.

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.

   signature = yes; blocked = no.

2. Step 2, line 2. A valid signature identifies a signed image; it does not prove that its code has no vulnerability.

   signature = yes; blocked = no; signature_accepted = true; not_blocked = true.

3. Step 3, line 3. Accept only when the required conditions all hold.

   signature = yes; blocked = no; signature_accepted = true; not_blocked = true; accepted = true.

4. Step 4, line 4. The model performs the accepted effect.

   signature = yes; blocked = no; signature_accepted = true; not_blocked = true; accepted = true; admitted = true.

5. Step 5, line 6. Result: this image passes the illustrated entry gate. That is not a proof of bug-free code.

   signature = yes; blocked = no; signature_accepted = true; not_blocked = true; accepted = true; admitted = true.

Watch it happenCheck more than the signature

A vulnerable signed driver stops while an allowed driver enters the kernel.

Read the steps

1. Both driver fixtures have valid signatures. One is also known to be vulnerable.
2. Signature verification alone would accept the vulnerable driver. The loading policy also checks the blocklist.
3. A matching blocked identity stops at the boundary. Its signature does not override that policy.
4. The other driver satisfies the fixture policy. Compatibility and update testing still matter.
5. Only the allowed driver enters this kernel. A blocklist helps reduce risk; it is not proof that every remaining driver is safe.

A synthetic loading policy illustrates signature and vulnerable-driver checks.

Trend Micro documented ransomware abuse of a vulnerable Genshin Impact anti-cheat driver. The lesson is broader than one game: a privileged security component can become a security liability if its exposed operations are unsafe. Driver revocation, updates, constrained interfaces, and operating-system protections all matter.

Why some anti-cheat runs a kernel component

If an anti-cheat and an interfering tool both run in user mode, both are subject to process handles, access rights, and the other Windows permission checks. Running at the same processor privilege does not itself grant either process access to the other. It does limit what either can establish about system-wide events and privileged components from inside its own process.

A kernel component changes that balance. Running in ring 0 lets it use documented Windows facilities that user-mode code cannot reach:

• process and image-load notifications, so it learns about every new process and every DLL or driver as it loads, instead of scanning for them afterward;
• handle-operation callbacks, which run while another process opens a handle to the game and may remove rights from the request. A tool that asks for read and write rights can receive a handle without them, and its ReadProcessMemory then fails at the handle-rights check that Lesson 12.4 followed;
• a view of loaded drivers and system state that user-mode code cannot quietly alter.

The costs described above fall on players. Anti-cheat code in the kernel has the same authority as the rest of the kernel, so its bugs become bug checks on players’ machines, and a vulnerability in it becomes a vulnerability in every machine it is installed on. It asks players to trust a game company with ring-0 code. Kernel placement also creates another boundary to protect: which drivers may load and what authority they expose. Windows uses signing rules, vulnerable driver block policies, and memory integrity to reduce that risk.

Boot trust and attestation answer narrower questions

Loading protection at boot can help it observe the environment before the game starts. Loading it with the game limits its lifetime. Neither timing choice makes privileged code infallible. A product may support different modes on systems with different security guarantees.

Secure Boot checks that the boot chain uses components authorized by the configured signing policy. A Trusted Platform Module, or TPM, can retain protected keys and record boot measurements. A measurement is a record of what was loaded, commonly represented by cryptographic hashes.

Attestation is a verifiable report about measured system state. A verifier checks the signing identity, expected measurements, and a fresh challenge so an old report cannot be reused as a current one. The protocol must also bind the report to the intended session. The hash and signature distinction from Lesson 10.8 applies here.

Such a report can support a claim about a measured boot environment. It does not prove that every later action is fair, or that all possible software and hardware behavior was measured. Server-owned rules remain necessary.

TL;DR: More local privilege expands what protection can inspect. It also expands the damage its own defects can cause.

Collect what the defense needs

Protection should document its lifetime, privileges, collected information, retention, and uninstall behavior. Limit collected data to its stated purpose. Test updates against supported hardware and software, with a recovery path for failures.

Privacy and reliability are engineering constraints. A protection system that repeatedly crashes honest players or cannot explain its data use weakens trust in the game it is trying to protect.

🧩

Knowledge check

A valid signature has limits

A driver carries a valid publisher signature, yet the loading policy refuses it. Which reason fits?

1Its identity matches the known vulnerable-driver blocklist2Its signature guarantees safety only in ordinary user mode3Its signature expires whenever a protected game starts4Its kernel role makes every publisher signature invalid

Check answer

Finished Lesson 15.3?

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.

Mark lesson doneLesson done. Mark it not done

Chapter 15: 10 lessons

📝 Notes