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.
Section: 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.
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.
Section: 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.
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.
Section: 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 D L L, dynamic link library, 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.
Section: 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.
In brief: More local privilege expands what protection can inspect. It also expands the damage its own defects can cause.
Section: 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.