Definitions of common terms you will see when using Cheat Engine, the forum, and the wiki.
A location in a process’s virtual memory, usually shown in hexadecimal (e.g. 0x00401234). When you find a value with the scanner, you get one or more addresses. That address holds the current value (e.g. health). Addresses can change when the game restarts, which is why pointer scans are used to find stable references.
A value stored in memory that is itself an address. A pointer “points to” another location. Games often store the address of the player object in a global or in a chain of pointers. Pointer scan finds these chains so your cheat still works after restarting the game.
First Scan: search memory for values matching your type and condition (exact value, unknown, increased, etc.). Next Scan: among the previous results, keep only addresses that now match the new condition. Repeating “change value in game → Next Scan” narrows the list until you find the right address.
A sequence of byte values (often written in hex, e.g. 8B 0D ?? ?? ?? ??) that uniquely identifies a place in the game’s code. “??” means “any byte.” AOBs are used in Auto Assembler scripts so the script finds the correct location even after a game update, as long as that code pattern still exists.
When you “freeze” an address in the address list, Cheat Engine continuously writes the current value back to that address. So if the game tries to decrease your health, the value is immediately restored. Used for infinite health, ammo, etc.
A file that stores addresses, scripts, and options. Cheat tables are XML and can be opened in a text editor. They are shared on the forum. Only use tables from sources you trust; they can contain Lua or assembly that runs on your system.
A standalone program (often an .exe) built from a cheat table. It lets users enable cheats with checkboxes or hotkeys without opening Cheat Engine. Created with the Trainer Maker in CE.
A scripting system in CE where you write x86/x64 assembly plus directives (alloc, aobscan, inject, etc.) to patch game code. Used for code injection, replacing instructions, and building robust cheats that survive restarts when combined with AOBs.
A CE feature that changes how fast the game runs (e.g. 0.5x for slow motion, 2x for faster). It hooks time-related APIs so the process “thinks” time is passing slower or faster. For single-player only.
Debugger Virtual Machine. A hypervisor that runs below the OS and gives CE extra capabilities (e.g. ultimap, advanced breakpoints). Optional; requires compatible hardware and loading via UEFI or similar.
To open a process in Cheat Engine so you can scan and modify its memory. You select the process from the process list (File → Open Process or the computer icon). Some processes require running CE as administrator.
The kind of data you are scanning: 1/2/4/8 byte integer, float, double, string, etc. Choosing the wrong type (e.g. 4 bytes when the game uses 8) can give no or wrong results.
A point where the debugger stops execution. You can set breakpoints on an instruction (break when the CPU runs it) or on memory (break when something reads or writes that address). Used to find which code accesses a value.
Managed code runtimes. Many games (e.g. Unity) use Mono or .NET. CE can enumerate classes and fields in these runtimes so you can find “Player.Health” by name instead of raw addresses.
Scripting language built into CE. Used for automation, custom UI, and extensions. Lua scripts can access memory, the address list, and the debugger via the CE Lua API documented on the wiki.
Writing your own assembly code into the target process (often into allocated memory) and redirecting the game’s execution to run your code. Used for infinite ammo, no recoil, etc. Done via Auto Assembler scripts.
A running instance of a program. You “attach” CE to a process (e.g. a game) to read and write its memory. Each process has its own virtual address space.
The list at the bottom of the CE window where you add addresses you have found. You can edit values, freeze them, add descriptions, and attach scripts. Saved as part of a .CT file.
First Scan searches all matching memory for the value/condition you set. Next Scan narrows the previous results by the new value/condition. Repeating narrows the list until you find the right address.
A key combination you assign to an address or script (e.g. Ctrl+H to toggle infinite health). Set via right-click on the address or in the script options.
Assembly “No Operation.” Replacing an instruction with NOPs effectively removes it. Used to disable checks (e.g. a check that decreases ammo) so the game no longer runs that code.
A CE feature (when DBVM is loaded) that traces execution to see which code runs. Used for advanced analysis. See the wiki for Ultimap documentation.
XML file that stores addresses, scripts, and options. You save and load .CT files to keep your work. Can be shared; only open tables from trusted sources since they can run code.
A server component that runs on Linux, Android, or other platforms so that a Windows CE client can attach to the process over the network. For advanced users. See Downloads.
The starting address of a module (e.g. the game .exe or a DLL). Addresses inside the module are often expressed as base + offset. Base addresses can change each run due to ASLR; pointers and AOBs are used to find code/data reliably.
A fixed number added to a base or pointer to reach a field. E.g. “player + 0x10” might be health. Offsets stay the same across runs; the base or pointer value may change. Pointer scan results show a chain of offsets.
An executable or library loaded into the process (e.g. the main game .exe or a .dll). CE can enumerate modules and limit scans to a specific module. The “main module” is usually the primary executable.
A spot where execution pauses when hit. You set breakpoints on instructions or on memory access (read/write). When triggered, you can inspect registers and memory. Used with “Find out what writes/reads” and manual debugging.
Redirecting execution from the original code to your code (e.g. replacing the start of a function with a jump to your routine). CE does this for Speedhack (hooking time APIs) and in code injection. Your code can call the original and modify behavior.
CE feature to visualize memory as a structure (e.g. a C struct): you define offsets and types and CE displays fields. Helps when reverse engineering how the game stores player data, entities, or arrays.
How a value is stored in memory: 1/2/4/8 bytes (integer), Float, Double, String, AOB, etc. You must choose the correct value type when scanning; wrong type gives wrong or no results. See the scanner dropdown and wiki.
The condition for a scan: Exact value, Unknown initial value, Bigger than, Smaller than, Increased value, Decreased value, Changed value, Unchanged value, etc. First Scan uses the initial condition; Next Scan narrows by the new condition.
Connecting CE to a running process so you can read and write its memory. Use the process list (computer icon) to select the game or app. You must attach before scanning. “Open process” is the same as attach.
CE’s scripting for assembly: you write instructions and directives (alloc, aobscan, code injection, etc.) and CE finds the location (e.g. by AOB), allocates memory if needed, and patches the game. Used for infinite ammo, NOPs, and custom code.
A standalone .exe built from a cheat table (File → Create Trainer). It usually has a small window with checkboxes and hotkeys so users can enable cheats without opening CE. Only run trainers from trusted sources; they can contain malware.
Address Space Layout Randomization. The OS loads modules at random addresses each run, so direct addresses change. That is why we use pointer scans and AOBs instead of fixed addresses in scripts.
Runtime used by Unity and other managed games. CE’s Mono support lets you browse classes and fields by name and add them to the address list. Activate via Mono menu after attaching to a Mono process.
Shows machine code as human-readable assembly (x86/x64). In CE you use it to view the game’s code, find instructions that access your address, and prepare patches. The Assembler lets you edit or add instructions.
In Auto Assembler, alloc reserves a block of memory in the target process for your code or data. Your script then injects code there and redirects the game to run it. The allocated address is stable for the session but not across restarts without a pointer or AOB.