Project 2: Cheat Engine Value Scanning Workflow

Build a repeatable Cheat Engine scan workflow to locate and validate HP and ammo values in your sandbox.

Quick Reference

Attribute Value
Difficulty Level 2
Time Estimate Weekend
Main Programming Language Tool-driven (Cheat Engine)
Alternative Programming Languages N/A
Coolness Level Level 3
Business Potential Level 1
Prerequisites Deterministic sandbox (P01)
Key Topics Memory scanning, validation

1. Learning Objectives

By completing this project, you will:

  1. Execute a disciplined scan/filter workflow that converges on the true game value.
  2. Validate candidate addresses by modification and freeze tests.
  3. Document a scan diary you can repeat across runs.

2. All Theory Needed (Per-Concept Breakdown)

Memory Scanning Workflow

  • Fundamentals Memory scanning is a narrowing process. You start with a value you know (like HP=100), then filter results as the value changes. Each scan removes addresses that no longer match your criteria. In a deterministic lab, this is a predictable sequence that should converge quickly. The goal is not just to find any matching address, but to identify the authoritative value that the game logic uses.

  • Deep Dive into the concept The most important mental shift is to treat scanning as an experiment. Your hypothesis is “this address stores HP.” The scan provides candidate addresses. You test each candidate by changing the value or freezing it and observing whether the game’s behavior changes. This is why deterministic inputs matter: if you control the scenario, you can tell exactly when HP should change, and any address that changes at other times is likely a false positive.

    Value types are a major source of error. HP might be an integer in memory but displayed as a percentage or a rounded number in the UI. It could also be stored as a float or scaled integer. This means you should use scan types appropriate to the representation. A robust scan workflow involves testing multiple representations and documenting the result. You should also note whether the value is signed or unsigned, since a negative value may appear unexpectedly when interpreted incorrectly.

    Another subtlety is that games often maintain multiple copies of a value. For example, a UI layer might have its own copy of HP to display, and the logic layer might have the authoritative value. Freezing the UI copy will not change gameplay, so your validation step is critical. The correct address is the one that affects actual behavior. In a lab, you can verify by freezing HP and observing that damage no longer takes effect in the log.

    Finally, scanning is limited by your search space. If you scan the entire address space, results will be noisy and slow. A refined workflow uses region filters (heap or module data segments) to reduce noise. Cheat Engine’s memory region settings help you focus on likely areas. The key is to balance breadth with efficiency and to record your scan parameters so you can reproduce results later.

  • How this fit on projects This scanning workflow is reused in Projects 3, 7, and 8. It is your baseline skill for finding values.

  • Definitions & key terms
    • First scan: Initial search for a known value.
    • Next scan: Filtering previous results based on change.
    • Authoritative value: The real value used by game logic.
    • False positive: A matching value that is not authoritative.
  • Mental model diagram ``` Scan Funnel

All Memory -> First Scan -> Filter -> Filter -> Few Candidates -> Validate


- **How it works (step-by-step)**
  1. Choose a deterministic scenario (HP changes at tick 10).
  2. Run first scan for HP=100.
  3. Trigger the HP change and scan for HP=95.
  4. Repeat until few candidates remain.
  5. Validate candidates by freezing/modifying.

- **Minimal concrete example**

Scan 1: HP=100 -> 25,000 results Scan 2: HP=95 -> 120 results Scan 3: HP=95 (unchanged) -> 8 results Validate: freeze candidate #3 -> HP no longer drops


- **Common misconceptions**
  - “The smallest list is always correct.” (You must validate behavior.)
  - “All copies of HP are the same.” (UI copies often exist.)

- **Check-your-understanding questions**
  1. Why do multiple copies of HP exist?
  2. How do you validate an authoritative value?
  3. What is the risk of scanning the entire address space?

- **Check-your-understanding answers**
  1. Different subsystems cache values for convenience and speed.
  2. Change or freeze it and confirm gameplay changes.
  3. It creates noise and slows convergence.

- **Real-world applications**
  - QA tooling to verify game logic.
  - Memory analysis in debugging sessions.

- **Where you’ll apply it**
  - This project’s §5.4 and §6.2.
  - Also used in: P03-cheat-engine-pointer-chains.md, P07-linux-gdb-watchpoints.md.

- **References**
  - Cheat Engine Wiki tutorials (value types, scanning).
  - "Practical Reverse Engineering" - Ch. 4.

- **Key insights**
  Scanning is a hypothesis-driven funnel, not a guessing game.

- **Summary**
  A disciplined scan workflow is the most reliable way to locate game state values.

- **Homework/Exercises to practice the concept**
  1. Create a scan diary with values and filter steps.
  2. Repeat the scan after restarting and compare results.

- **Solutions to the homework/exercises**
  1. Your diary should show how each scan reduces candidates.
  2. You should find the same authoritative value after validation.

---

## 3. Project Specification

### 3.1 What You Will Build

A documented Cheat Engine scanning workflow to locate HP and ammo values in your deterministic sandbox. You will produce a scan diary, a validated address list, and a short report explaining why the chosen addresses are authoritative.

### 3.2 Functional Requirements

1. Attach Cheat Engine to the sandbox process.
2. Locate HP and ammo via a scan/filter sequence.
3. Validate each value by freezing or modifying.
4. Document scan settings and results.

### 3.3 Non-Functional Requirements

- **Performance**: Scan should complete in under 2 minutes.
- **Reliability**: Results must be reproducible across runs.
- **Usability**: Scan diary is clear and step-by-step.

### 3.4 Example Usage / Output

[Address List] HP 0x1A2B3C4D 95 Ammo 0x1A2B3C88 12


### 3.5 Data Formats / Schemas / Protocols

- **Scan diary**: Table with value, scan type, candidate count, notes.

### 3.6 Edge Cases

- HP stored as float instead of int.
- UI copy that does not affect gameplay.

### 3.7 Real World Outcome

#### 3.7.1 How to Run (Copy/Paste)

1. Launch sandbox.
2. Open Cheat Engine and attach to process.

#### 3.7.2 Golden Path Demo (Deterministic)

- Scan HP=100.
- Trigger a hit (HP=95).
- Filter to 8 candidates.
- Freeze candidate #3 and confirm HP no longer drops.

#### 3.7.3 Failure Demo

- Scan without controlling the scenario: results remain >1000 and cannot be validated.

---

## 4. Solution Architecture

### 4.1 High-Level Design

[Sandbox] -> [Cheat Engine Scan] -> [Candidate List] -> [Validation]


### 4.2 Key Components

| Component | Responsibility | Key Decisions |
|-----------|----------------|---------------|
| Scan Diary | Record steps | Consistent format |
| Validation | Confirm authority | Freeze vs modify |

### 4.3 Data Structures (No Full Code)

- **Scan diary table**: step, value, filter, candidate count, notes.

### 4.4 Algorithm Overview

**Key Algorithm: Scan Funnel**
1. First scan for known value.
2. Filter on change.
3. Validate finalists.

**Complexity Analysis**
- Time: O(n) scanning per filter step.
- Space: O(k) candidate list.

---

## 5. Implementation Guide

### 5.1 Development Environment Setup

- Install Cheat Engine in a Windows VM.
- Ensure sandbox is compiled with debug symbols.

### 5.2 Project Structure

project/ ├── scan-diary.md └── screenshots/


### 5.3 The Core Question You're Answering

> "How do I prove a memory address is the true game state value?"

### 5.4 Concepts You Must Understand First

- Value types and representation
- Deterministic state changes

### 5.5 Questions to Guide Your Design

1. Which value changes at a known tick?
2. How will you verify the address is authoritative?

### 5.6 Thinking Exercise

Draw a scan funnel with three filter steps and the expected candidate count.

### 5.7 The Interview Questions They'll Ask

1. "Why are there multiple candidate addresses?"
2. "How do you validate a candidate?"
3. "What is a false positive?"

### 5.8 Hints in Layers

**Hint 1:** Start with HP because it changes clearly.
**Hint 2:** Use decrease filters after damage.
**Hint 3:** Freeze and observe behavior.
**Hint 4:** Document each step.

### 5.9 Books That Will Help

| Topic | Book | Chapter |
|-------|------|---------|
| Debugging tools | Practical Reverse Engineering | Ch. 4 |

### 5.10 Implementation Phases

#### Phase 1: Setup (2 hours)
- Attach Cheat Engine and run first scan.

**Checkpoint:** Candidate list generated.

#### Phase 2: Filtering (2 hours)
- Apply change filters and narrow list.

**Checkpoint:** <10 candidates.

#### Phase 3: Validation (2 hours)
- Freeze and confirm authoritative value.

**Checkpoint:** Behavior changes as expected.

### 5.11 Key Implementation Decisions

| Decision | Options | Recommendation | Rationale |
|----------|---------|----------------|-----------|
| Value type | int vs float | int first | HP changes in whole numbers |
| Validation | freeze vs edit | freeze | Clear behavioral proof |

---

## 6. Testing Strategy

### 6.1 Test Categories

| Category | Purpose | Examples |
|----------|---------|----------|
| Repeatability | Same results | Restart scan |
| Authority | True value | Freeze test |

### 6.2 Critical Test Cases

1. Repeat scan after restart: same address or pointer chain found.
2. Freeze HP: damage no longer reduces HP.

### 6.3 Test Data

HP sequence: 100 -> 95 -> 95 ```

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Wrong value type No results Try float or byte
UI copy selected Freeze has no effect Validate behavior

7.2 Debugging Strategies

  • Use a write breakpoint if values are ambiguous.
  • Reduce scan scope to heap only.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Find ammo and add it to the address list.

8.2 Intermediate Extensions

  • Find position coordinates and freeze movement.

8.3 Advanced Extensions

  • Identify a timer variable that changes every tick.

9. Real-World Connections

9.1 Industry Applications

  • QA and debugging for game logic validation.
  • Use the sandbox from P01.

9.3 Interview Relevance

  • Demonstrates hypothesis-driven debugging.

10. Resources

10.1 Essential Reading

  • Cheat Engine Wiki Tutorials
  • Practical Reverse Engineering - Ch. 4

10.2 Video Resources

  • Cheat Engine tutorial walkthroughs (official/community).

10.3 Tools & Documentation

  • Cheat Engine official site and wiki.
  • P01-deterministic-game-state-sandbox.md
  • P03-cheat-engine-pointer-chains.md

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain why multiple candidates appear.
  • I can explain how I validated the authoritative value.

11.2 Implementation

  • Scan diary is complete.
  • HP and ammo values are verified.

11.3 Growth

  • I can repeat the scan workflow without notes.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • HP found and validated.
  • Scan diary documented.

Full Completion:

  • HP and ammo validated.
  • Scan reproduced after restart.

Excellence (Going Above & Beyond):

  • Pointer chain discovered in Project 3 style.