<p align="center"> <img src="docs/logo.svg" width="96" alt="Pointer Lab logo"> </p>

Pointer Lab

A free, open-source memory scanner and debugger for Windows, for 32- and 64-bit targets.

One session, start to finish. Attached to the bundled tutorial, an exact scan for 1000 narrowed to eight hits; the green ones are static, inside a loaded module at the same module+offset every run. Four are tracked below, one frozen, and the pointer scanner has found 427 chains that reach the first.

Pointer Lab attaches to a running process, 32- or 64-bit, searches its memory for values, tracks the addresses it finds, and lets you read, write, freeze, disassemble and patch them. It is a research and learning tool — see Intended use before pointing it at anything.

Pointer Lab is written by Heath Howren (Cyborg Elf) of Game Reversal Club as a companion tool to The Game Hacker's Handbook. Its page on the club's site is gamereversal.club/tools/pointer-lab.

Download

Grab the latest release from Releases. The zip holds PointerLab.exe alongside the licence, the third-party notices and a copy of these docs — but the executable is the only part you need. There is no installer and there are no runtime prerequisites: the C runtime is statically linked and the fonts are embedded, so PointerLab.exe runs on its own from wherever you put it.

Four more files sit beside it: PointerLabSpeed64.dll and PointerLabSpeed32.dll, which are the speed hack's payload and are looked for in that directory, and PointerLabTutorial.exe and PointerLabTutorial32.exe, which are the practice target described below.

Two things to expect on first run:

• SmartScreen will warn you. Release binaries are unsigned. Code-signing certificates cost money this project does not have.
• Antivirus may flag it. Reading and writing another process's memory, injecting a DLL and setting software breakpoints are exactly the behaviours heuristic scanners look for. That is the tool working as designed, not a reassurance that any given binary is safe — build from source if you would rather not take that on trust.

Run as administrator for full access. Without it Pointer Lab still works, but SeDebugPrivilege is unavailable, many processes will open read-only, and the command bar shows a READ-ONLY badge to say so rather than failing writes silently.

Both 32- and 64-bit targets. Pointer Lab is itself a 64-bit process, and attaches to either. A 32-bit (WOW64) target is handled as one throughout: chains step 4 bytes at a time, the disassembler and assembler run in x86 mode, the debugger reads the thread's 32-bit context rather than the emulation layer's, and injection resolves LoadLibraryW out of the target's own kernel32. The current target's width is shown in the command bar, because a DLL you inject has to match it.

The tutorial

PointerLabTutorial.exe ships in the same zip, in both 32- and 64-bit builds, and is the fastest way to find out whether any of this makes sense yet. Nine gated lessons — attach and write, exact scan, unknown initial value, float and double, find out what writes, a pointer, a multi-level pointer, code injection, and shared code — each one revealing the password for the next, so nothing has to be repeated.

It exists because everything else worth practising on belongs to somebody else, and a first lesson should not depend on a third-party download that has changed since it was written about.

The checks are the part worth knowing about: they are arranged so the plausible-but-wrong technique fails. Step 5 calls the writing code and reads back immediately, so freezing the value proves nothing and only removing the instruction passes. Steps 6 and 7 move the object before checking, so an address found by scanning is dead by then. Step 9 damages two objects through one instruction and reads back immediately, so neither a freeze nor a NOP passes — only code that looks at which object is being written to.

Screenshots

The MCP server, mid-session. Everything in these screenshots was done by an agent over this connection: the attach, the scan, the address list, the pointer scan, and the screenshots themselves. The token shown is already dead; a new one is generated every time the server starts, and it is never written to disk.

The address list. Descriptions, groups and types, with the current value re-read on a timer. A ticked freeze box is written back twenty times a second.

427 chains to one address. A heap address is different every run; a chain from a module is not. Each row is a base plus offsets that lands on the value.

The patch list. It keeps the bytes that were there before, here a lea rcx, so a patch can be unticked and put back. The patch is padded with nops to cover whole instructions.

The speed hack at 2.00x. It rebases the clocks the program reads, and it reports how many imports it redirected, so a target that asks the time some other way shows up as zero rather than as a silent no-op.

Captured from 3.1.0. 3.2.0 renamed no panel, menu path or tool that they show.

Features

• Scanner — twelve modes over signed and unsigned 8/16/32/64-bit integers, float, double, byte patterns and text: exact, unknown initial, changed, unchanged, increased, decreased, value between, bigger than, smaller than, increased by, decreased by, and same as first scan.

  Three of those are worth calling out. Increased by and decreased by take an exact delta, and usually finish a search in one step — "I lost exactly 7 health" is far more selective than "it went down". Same as first scan compares against the first scan of the run rather than the previous one, which is the only way to find a value that changed and came back. And the absolute filters (value between, bigger than, smaller than) work on a first scan, with nothing to compare against yet.

  Text comes in both flavours: str for one byte per character and wstr for the two-byte UTF-16 that Windows means by "Unicode" and that most player names and chat lines are actually stored in, with optional case folding.

  Byte patterns support ?? wildcards (48 8B ?? 24). Float exact-match uses a configurable epsilon, because bit-exact float comparison finds nothing in practice. The result limit is configurable and truncation is reported rather than hidden. Results that fall inside a loaded module are shown in green: such an address is at the same module+offset in every run, which is the difference between an address worth writing down and one that is wherever the allocator put it today.

• Address expressions — every address box accepts client.dll+0x4A2C10, kernel32.LoadLibraryW+0x10, a module name on its own, or a symbol you have defined, each followed by any number of +/- offsets. Symbols are saved in the project file as the expression rather than the address it produced, so they re-resolve against the next run instead of pointing at wherever the module used to be.

• Address list — groups, descriptions, value freeze, manual add and edit, and F1–F12 freeze toggles registered with Windows, so they fire while the target is in the foreground. Only keys actually assigned to an entry are registered, so Pointer Lab does not take F1–F12 away from the rest of the machine.

• Pointer scanner — multi-level pointer chain search with a rescan pass. Chains are stored as module+offset plus offsets, so a chain found in one run still resolves after the target restarts and ASLR moves everything. Restart the target, find the value's new address and rescan: the chains that still resolve to it are the ones that genuinely track the value, and the thousands that only pointed the right way once are discarded. Resolved chains can be added to the address list as live tracked entries.

• Access watch — "find out what writes to this address", and its read/write twin. A hardware data breakpoint underneath, with the part that makes it usable on top: every hit is aggregated by the instruction responsible rather than arriving as a flood no one can read, and each site can be shown in the disassembler or replaced with nops from the list.

  Two details matter here. A data breakpoint traps after the access, so the instruction pointer names the instruction after the one that touched the address; Pointer Lab walks back to identify the real one, and says so plainly when it cannot rather than reporting the wrong instruction confidently. And each captured register is interpreted against the target — a register sitting a short way below the watched address is called out as the probable base of the structure containing it, which is how you get from "I found my health" to "I found the player object".

• Patch list — every byte Pointer Lab writes into the target's code is recorded with the bytes it replaced, and a tick box puts each one back. That makes the natural experiment — nop an instruction, see what breaks, undo it — cost a click instead of a restart. Overlapping patches are refused rather than recorded with a wrong "original", and a patch whose bytes something else has since changed is flagged instead of quietly claiming a state the memory does not have.

• Hex editor — navigable rather than a fixed window: scroll by row or page, jump to any expression, click a byte to edit it in place, and follow a byte as a pointer to land wherever it points. Bytes that changed since the last frame are highlighted, which is how you find a field by watching a structure repaint itself rather than by scanning for it. Walking backwards from a known address until the start of a structure appears is a scrolling exercise here, not a hex-arithmetic one.

• Disassembler — full x86-64 disassembly via Zydis, with follow-branch navigation. Undecodable bytes are shown as db rather than desynchronising the listing.

• Assembler — full x86-64 assembly via Keystone. Patches are NOP-padded to the next instruction boundary so a short patch never leaves half an instruction behind, and the confirmation dialog tells you exactly how many bytes will be overwritten.

• Structure dissector — a named layout laid over several objects at once. Press Guess and it fills the layout in from what is actually there, calling a slot a point