memedit

memedit is a command-line memory scanner and editor for offline, single-player Windows games, written in Go with no CGo. It follows the same workflow as Cheat Engine: attach to a running process, scan its memory for a value you can see in-game, narrow the candidate addresses as that value changes, then write a new value.

Single-player and offline use only

Do NOT use memedit against multiplayer games protected by anti-cheat (VAC, EAC, BattlEye). Reading and writing another process's memory is exactly the access those systems detect and ban for. memedit is for offline, single-player games and for learning how memory scanning works.

memedit runs on windows/amd64 and attaches to 64-bit processes. Opening most game processes needs Administrator rights, so memedit requests them through a UAC prompt unless you pass --no-elevate.

Why the tool is interactive

Narrowing works by rescanning the addresses that matched last time, so the candidates have to survive between commands while the value changes in-game. That makes memedit an interactive session rather than a one-shot command. The candidates and their previous values live in memory only. Quitting discards them.

Build it

memedit needs Go 1.27.1 or later. The binary targets windows/amd64, and make build cross-compiles it from any platform:

make build

Without Make, do the same thing by hand:

GOOS=windows GOARCH=amd64 go build -o memedit.exe .

On 64-bit Windows, drop the environment variables. Every form writes memedit.exe to the repository root.

Attach to a process

Start the game, then open PowerShell where memedit.exe sits and name the target and the type of the value you want to find:

.\memedit.exe --name game.exe --type int32

Accept the UAC prompt. memedit relaunches itself with Administrator rights in a new console, the first console exits, and the session opens:

attached to PID 12345
memedit (int32). Type 'help' for commands.
>

To pick the process by ID instead, use --pid 12345. To skip the elevation attempt, add --no-elevate, though OpenProcess then usually fails with access denied.

Find and edit a currency value walks through a whole session. Every flag and command is in Flags, commands, and scan behavior.

Check a change

make check   # format, vet the host and windows/amd64 builds, test with -race
make lint    # golangci-lint over both builds
make bench   # matcher benchmarks, when you touch matching or scan performance

make lint needs golangci-lint on the path. make help lists every target.

The tests cover the OS-independent code and run anywhere: value parsing, matching, chunk planning, the region filter, and the session commands against an in-memory target. Nothing in the suite touches Windows. Opening a process, requesting elevation, enumerating regions, and reading or writing another process's memory all sit behind //go:build windows, so test those against a real process on 64-bit Windows and say in the pull request whether you did.

Repository guidelines covers where code goes and how tests are written.