A Windows Lab You Can Reset

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

A one-page summary of “A Windows Lab You Can Reset” you can keep beside your notes. Plain Markdown.

Lesson 1.7 — A Windows Lab You Can Reset: cheatsheet

• Remember: A VM with snapshots is an undo button for experiments. It is a recovery point, not a force field, so test the restore.
• Also useful: Snapshots recover one VM. Full and linked clones make second VMs; a linked clone still needs its source base disks. Check networking and host sharing separately.

Key terms

• trojan: That is called a trojan, after the wooden horse, and it is one of the most common ways players lose accounts, because the cheat working is exactly what makes people trust it.

Review

• Q: Why take a virtual-machine snapshot before a memory or debugger lab? A: It gives you a known recovery point to return to after a mistake or crash
• Q: What does a virtual machine snapshot give you, and what does it not give you? A: A saved point to roll back to, not a promise that every action is safe

Download cheatsheet (.md)

Download cheatsheet (.md)

Before using a scanner or debugger on the course game, set up a place where the game, tools, and starting conditions can be repeated. This lets you tell a real game change from a difference in the environment.

Use a separate Windows virtual machine for the book. A virtual machine (VM) is a computer simulated inside your main computer. It can run its own copy of Windows and can be reset without reinstalling your everyday system.

Why the VM is useful

A VM gives the experiments a controlled environment:

• old game builds and debugging tools stay separate from personal files;
• a snapshot can restore a known state after a crash or bad configuration;
• the Windows and tool versions stay fixed, so results repeat;
• optional connections to the host can stay disabled until needed.

A snapshot is not a security guarantee and does not make every action harmless. It is a recovery point. Test that you can restore it before depending on it.

TL;DR: A VM with snapshots is an undo button for experiments. It is a recovery point, not a force field, so test the restore.

The same caution covers what you bring into the VM. A program can do exactly what it advertises and something else at the same time: a “free trainer” that really does give you gold while it quietly copies the passwords saved in your browser. That is called a trojan, after the wooden horse, and it is one of the most common ways players lose accounts, because the cheat working is exactly what makes people trust it. Every tool in this book comes from its official project page or is one you build yourself.

Create the Windows VM

VirtualBox (Recommended: This lesson’s screenshots and VBoxManage commands use VirtualBox, so its menus match what you see here. VMware and Hyper-V work too, but you then find the matching menu yourself.), VMware, or Hyper-V can work. A practical starting configuration is:

• 2 or more virtual CPU cores;
• 4–8 GB of RAM;
• about 50 GB of storage;
• graphics acceleration if a target game requires it.

Install Windows, apply updates, and create a normal user account. Run an individual tool with additional rights only when its operation requires them.

Keep shared folders, clipboard sharing, drag-and-drop, and USB passthrough off at first. Enable a connection only when you need it and know what crosses it.

Install the required tools

Inside the VM, install:

1. rustup (Reference: The official Rust installer and version manager. It installs rustc and Cargo into your own user folder.) for the compiler and Cargo;
2. Visual Studio Build Tools (Reference: Microsoft’s own C++ compiler, linker, and Windows libraries, without the full Visual Studio editor. Rust on Windows uses its linker.) with “Desktop development with C++” so the MSVC linker and Windows libraries are available;
3. x64dbg (Reference: An open-source debugger for Windows programs, with a 32-bit and a 64-bit version. Download it from the project’s own page.) for debugging 32-bit and 64-bit programs;
4. Cheat Engine (Reference: A memory scanner and debugger, used here for the first scans. Read each installer screen, and decline any offer of extra software.) for the first value-scanning lessons;
5. Wireshark (Reference: A free tool that records and displays network traffic. The networking lessons later in the book use it on your own computer.) for later local network captures;
6. Git (Reference: The version-control tool. The labs expect the course repository at one exact revision, so your results match the lessons.), so you can use the exact course source revision.

Open PowerShell and check the compiler tools:

rustc --version
cargo --version

Then verify that a tiny program builds:

cargo new first_lab
cd first_lab
cargo run

You should see Hello, world!. If this step fails, fix the toolchain before adding debuggers, games, or course code to the problem.

Install the 32-bit Windows target

The specific Wesnoth, AssaultCube, Urban Terror, Wyrmsun, and Flare builds used in the historical lessons are 32-bit Windows programs.

rustup target add i686-pc-windows-msvc

Read the target name in parts:

• i686 — 32-bit x86 instructions and plain pointers, which store 32-bit addresses;
• pc-windows — Windows is the target operating system;
• msvc — use Microsoft’s Windows ABI and linker toolchain.

Code loaded inside a process must match that process’s architecture. A 64-bit DLL cannot be loaded into a 32-bit game. Later code changes, register choices, stored-address widths, and calling conventions also depend on the architecture.

Alternative: Think of plugs and sockets: a 64-bit DLL is a plug that will not fit a 32-bit game’s socket, however well it is made.

An external tool can sometimes have a different bitness because Windows copies bytes across the process boundary. The course keeps its Windows labs 32-bit so addresses and machine-code examples stay consistent. For another game build, inspect its executable and choose the matching target instead of copying this choice blindly.

Get and check the course code

The complete Windows workspace is in windows-labs. It is one folder of the repository, beside the other lab projects:

• Directorywindows-labs/ the Windows workspace this chapter builds

  • Cargo.toml
  • README.md
  • Directorysrc/

    • Directorybin/ one program per lab, such as access_probe.rs and injector.rs

      • …
    • Directorywindows_impl/ shared Windows code: process.rs, dll.rs, and more

      • …
    • lib.rs
    • wesnoth_protocol.rs
• Directoryrust-labs/ portable labs that run on any computer

  • …
• Directorylua-labs/ the Lua host from Chapter 10

  • …
• Directoryadvanced-memory-labs/

  • …
• Directoryfirmware-labs/ the bare-metal project from Chapter 14

  • …
• Directorysite/ this book

  • …

From the repository root, run:

cd windows-labs
cargo check --target i686-pc-windows-msvc --all-targets

cargo check parses and type-checks the programs without producing a final optimized build. It is the fastest first check for a compiler or dependency problem.

The workspace uses the windows crate for typed Windows API declarations and anyhow to attach useful context to errors. Cargo reads those dependencies from Cargo.toml; you do not need to copy a long feature list from the lesson.

When a lesson needs an executable or DLL, build the release version:

cargo build --release --target i686-pc-windows-msvc

That command produces a 32-bit Windows build even if the development VM is 64-bit. If it fails, the first error tells you whether the target toolchain, project code, or a Windows library needs attention; a successful build alone does not prove the tool can attach to the course game.

Four Cargo commands you will use often

cargo check   # Find type and API errors quickly
cargo run     # Build and run one program
cargo test    # Run automated checks
cargo fmt     # Apply the standard code format

Read the first compiler error before later errors. One missing type or bracket can cause many follow-up messages.

Create recovery snapshots

Take at least two snapshots:

• Clean Windows — after Windows updates, before the lab tools;
• Ready for lessons — after tools, the 32-bit target, and course code work.

Name snapshots by what they contain. A date alone does not explain which state is safe to restore.

Exporting the finished VM as one appliance file: a portable backup.

You may also export the VM as a slower, portable backup:

VBoxManage export "Game Lab" --output GameLab.ova

Importing the appliance brings the VM back from that file.

VBoxManage import GameLab.ova

A snapshot rewinds one VM; a clone creates a second VM

Use a snapshot to return one VM to recorded files and settings. Use a clone when you want a separate experiment copy beside the baseline. VirtualBox offers two disk arrangements: a full clone copies the dependent virtual disks; a linked clone writes into its own differencing disks while relying on source base disks. Keep that base available. The VirtualBox cloning guide describes these choices and its network-adapter address policy.

Disk separation is one boundary. Before starting both copies, review their network adapter MAC addresses, guest host names and fixed IP settings, and host sharing. A MAC address identifies an adapter on its local network; cloning disk content alone does not make all copied network settings unique. Changes in a shared host folder are outside the guest disk snapshot.

The model below changes an invented save in an experiment copy, then resets it. Choose how the copy was prepared and inspect the disk dependency.

A recovery point and a second VM solve different problems. This step-by-step trace needs JavaScript. Here is the code and where the run ends.

baseline: save_gold = 100
choose snapshot, linked_clone, or full_clone
prepare a separate test copy, if cloning
test_copy.save_gold = changed_gold
check baseline and disk dependencies
restore the snapshot or reset the test copy

Reset returns the test save to 100. You have one VM at its recorded starting condition.

Final values: choice = snapshot; changed = 75; baseline = 100; test = 100; disk dependency = snapshot disk chain; second VM = false.

Read every step of the lesson’s example

1. Step 1, line 1. The known starting save records 100 gold. We want to compare a change against this starting condition.

   choice = snapshot; changed = 75; baseline = 100; test = 100; disk dependency = snapshot disk chain; second VM = false.

2. Step 2, line 3. A snapshot records a recovery point for this VM. It does not create a second machine for simultaneous comparison.

   choice = snapshot; changed = 75; baseline = 100; test = 100; disk dependency = snapshot disk chain; second VM = false.

3. Step 3, line 4. The same VM now saves 75. Its recovery point still describes 100.

   choice = snapshot; changed = 75; baseline = 100; test = 75; disk dependency = snapshot disk chain; second VM = false.

4. Step 4, line 5. Restoring will rewind the same VM to the recovery point. It does not undo changes to an external shared folder.

   choice = snapshot; changed = 75; baseline = 100; test = 75; disk dependency = snapshot disk chain; second VM = false.

5. Step 5, line 6. Reset returns the test save to 100. You have one VM at its recorded starting condition.

   choice = snapshot; changed = 75; baseline = 100; test = 100; disk dependency = snapshot disk chain; second VM = false.

Keep the baseline stopped while preparing a named experiment copy. Start from the recorded course build and your own resettable test program or save. A separate VM supports comparison and recovery; it does not prove that network peers or host files are isolated.

TL;DR: Snapshots recover one VM. Full and linked clones make second VMs; a linked clone still needs its source base disks. Check networking and host sharing separately.

Recovery cheatsheet: a snapshot rewinds one VM; a full clone copies its virtual disks; a linked clone keeps a dependency on its base disks. Host sharing and networking need separate checks.

What a result depends on

When you later record an address (a location in the running game), an offset (a distance from a chosen start), or a byte pattern (a sequence to search for), record the exact environment too. The next lesson develops these ideas; their usefulness depends on:

• the game name, exact build, and architecture, because a different build can move every function and field;
• the executable’s file hash (Example: In PowerShell, Get-FileHash .\wesnoth.exe prints the file’s SHA-256 hash. The same bytes always give the same hash, and changing a single byte gives an entirely different one.), a short fingerprint computed from its bytes: matching hashes are strong evidence that two copies use the same build even when their version labels are ambiguous;
• the Windows version, because system DLLs change between updates;
• the repository commit and the tool and debugger versions;
• the starting save, map, or settings;
• the VM snapshot the machine started from.

The snapshot restores files and installed tools, and source control restores the exact code. The build and file hash tell you whether an address found last week still applies to the game in front of you.

Narration: A note saying gold lives at some address is nearly useless a week later unless it also records which exact build it came from.

Checkpoint

Before the first memory experiment, confirm that you can:

• restore the “Ready for lessons” snapshot;
• run cargo check in windows-labs;
• launch the target game in the VM;
• identify whether its executable is 32-bit or 64-bit;
• name the exact build and starting state an experiment depends on.

The VM is ready. Lesson 1.8 now shows what a scanner means by an address, a value type, and a pointer before you search the game.

🧩

Knowledge check

Protect the experiment

Why take a virtual-machine snapshot before a memory or debugger lab?

1It gives you a known recovery point to return to after a mistake or crash2It keeps every address in the game fixed so later scans give the same results3It gives the guest Windows unlimited permissions inside your main computer4It stops the game from changing its state while you debug it in the lab

Check answer

Finished Lesson 1.7?

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 1: 10 lessons

📝 Notes