Skip to content
Lesson 15.6Defensive Design and Anti-Cheat

Cheat Categories from the Defender's Side

Connect different locations of unauthorized code and automation to the observations and boundaries a defender can use.

Lesson 15.6
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.6Key ideas, reference and questions

A one-page summary of “Cheat Categories from the Defender's Side” you can keep beside your notes. Plain Markdown.

Lesson 15.6 — Cheat Categories from the Defender's Side: cheatsheet

  • Remember: Defend the result and the information boundary as well as the location of code. Different tool categories can produce similar commands.

Key terms

  • Cheat Engine: Cheat Engine is a development and modding tool with memory inspection, debugging, and scripting capabilities.
  • asset: An asset is stored game content such as a model, texture, or sound.

Review

  • Q: The server excludes a hidden enemy position from the client update. What does observing that received client memory reveal? A: Only delivered data; the excluded position is absent
  • Q: What distinguishes an external tool from an internal tool? A: Whether its code runs outside or inside the game process
Download cheatsheet (.md)

A defender benefits from knowing where an unfair advantage originates. That location affects which observations and protections are available. It does not change who should own the game’s accepted results.

Process location changes local observations

Section titled “Process location changes local observations”

An external tool runs outside the game process. An internal tool runs code inside it. Depending on permissions and operating-system interfaces, a defender may observe process access, loaded modules, or unexpected integrity changes. Legitimate development and accessibility software can create some of the same observations.

Where the tool runs changes what a defender can observeBoth tools read the same health value; only the route differs.
  1. 1 External: a separate process

    game.exe

    game.exemodule
    health 100in memory

    tool.exe

    handleread rights
    health 100its copy

    tool.exe opens a handle and asks Windows to copy bytes. A debugger leaves the same kind of handle.

  2. 2 Internal: code inside the game

    game.exe

    game.exemodule
    helper.dlladded

    A defender may see

    a new module
    changed code bytes

    No handle is needed after loading, but the added module, and any bytes it patched, are inside the game. A supported overlay also loads a DLL.

Both tools read the same health value; only the route differs.

Cheat Engine is a development and modding tool with memory inspection, debugging, and scripting capabilities. Those capabilities can be useful in an owned offline program, like the memory examples earlier in this book. The presence of a general-purpose tool is different from proving an unfair action in a protected match. Nor does changing client memory automatically change the server’s inventory or simulation.

Do not assume that a project having publicly visible source settles every license or distribution question. Check the actual components and current terms before redistributing software. This lesson studies tool categories; it does not ask you to install or use them against protected games.

Privilege is one boundary, information is another

Section titled “Privilege is one boundary, information is another”

Kernel-assisted abuse uses privileged operating-system code. It expands the local access problem described in Lesson 15.3. Defenders can combine driver policy, integrity protections, updates, and server validation. These controls cover different parts of the problem.

Direct memory access, or DMA, lets hardware devices transfer memory without having the CPU copy every byte. Lesson 13.1 explains why device access needs isolation. An IOMMU, an input-output memory management unit, restricts which memory regions a device can access under the configured policy. Firmware and operating-system configuration affect whether that protection is actually in place.

Neither greater software privilege nor device access creates a hidden server value that was never sent. In the picture, the server sends the player’s own health but excludes an unrelated hidden enemy. Observing the client’s received memory yields only the available information.

Local inspection can reveal only delivered state. This step-by-step trace needs JavaScript. Here is the code and where the run ends.

server keeps health and hidden position
select the outgoing fields
deliver only those fields
client stores its received copy
inspect the local fields
report available and absent information

Result: this client knows its own health and has no hidden-position field.

Final values: message = limited; sent_fields = health; health = 73; hidden_position = absent.

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.

    message = limited.

  2. Step 2, line 2. The server chooses which fields leave its process.

    message = limited; sent_fields = health.

  3. Step 3, line 3. The message carries no implicit copy of the rest of server memory.

    message = limited; sent_fields = health.

  4. Step 4, line 4. The local copy contains only the delivered fields.

    message = limited; sent_fields = health; health = 73; hidden_position = absent.

  5. Step 5, line 5. Inspecting this record cannot recover a field it never received.

    message = limited; sent_fields = health; health = 73; hidden_position = absent.

  6. Step 6, line 6. Result: this client knows its own health and has no hidden-position field.

    message = limited; sent_fields = health; health = 73; hidden_position = absent.

Watch it happenLimit what reaches client memory

The client receives its own health and no hidden enemy position.

Read the steps
  1. The server stores both permitted local information and a hidden enemy state.
  2. The outgoing update selects the player's own health. The hidden enemy is excluded.
  3. Only that selected value crosses the network boundary.
  4. Client memory gains the received health. It has no enemy position from this update.
  5. Different observers of client memory can inspect available data. Greater local privilege does not create information never delivered.
  6. Server-side disclosure rules complement local protection. The server must still account for information revealed in other updates, sounds, or timing.

The example compares information availability across one message boundary.

This is why local protection and server disclosure rules complement one another. Audit other channels too. Sounds, event messages, timing, or team updates can reveal information that one position filter withheld.

Screen-based automation changes the observation problem

Section titled “Screen-based automation changes the observation problem”

Computer vision extracts information from images. A vision-based automation system can act on the ordinary game view and emulate input. It may not need access to the game’s internal memory.

The server still sees resulting commands and their timing. Behavioral signals, supported-input policy, and review can contribute evidence. Unusual input consistency also occurs with some permitted devices, so a pattern alone needs legitimate-device testing and context.

Network and asset changes need their own controls

Section titled “Network and asset changes need their own controls”

Network abuse can involve invalid messages, repeated requests, excessive work, or inconsistent session claims. Parse bounded input, authenticate the session, validate actions against current state, and define retry behavior. A cryptographically protected connection does not make the authenticated player’s requests truthful.

An asset is stored game content such as a model, texture, or sound. Unauthorized replacement can change the information or visibility a game intends to provide. A server can require an approved asset set where the rules call for it. Use signed manifests and trusted references rather than letting the client select both the content and the expected checksum. See Lesson 10.8.

Permitted mods have a separate policy and supported loading path. They should not be silently treated as cheating merely because their bytes differ from the stock installation. Define the protected mode, authorized extensions, and review procedure before interpreting a local mismatch.

Knowledge check

Privilege and information

The server excludes a hidden enemy position from the client update. What does observing that received client memory reveal?

Finished Lesson 15.6?

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.