Game Hacking Fundamentals

Read this first

Game hacking is a fantastic way to learn memory, assembly and reverse engineering — but only within limits. Only ever modify games you own, offline, on your own machine. Cheating in online multiplayer harms other players, usually breaks the terms of service, and can be illegal. Tampering with software you do not own, or distributing cheats, crosses into criminal territory in many places.

Everything in this path is aimed at understanding — the very same skills that defenders and anti-cheat engineers are paid for.

The flag: ASEC{only_hack_what_you_own}

It is just numbers in RAM

While a game runs, its state — health, ammo, position, score — lives as values at addresses in the process memory.

If you can find the address of your health and write a new value there, the game will happily read it back. That single idea is the foundation of memory-based game hacking, and it is exactly what tools like Cheat Engine make easy.

What Game Hacking Actually Teaches You

Poking at a game you own is really a friendly playground for reverse engineering — the skill of understanding software from the outside. You practise reading memory, following pointers, and interpreting assembly, all with instant visual feedback (your health bar) telling you whether you got it right.

Those are exactly the skills malware analysts, exploit developers, and anti-cheat engineers use professionally.

Flag: ASEC{learning_by_playing}

Single-Player vs Multiplayer: The Big Divide

The single most important distinction in this whole field: single-player/offline games only affect you, while online multiplayer games are shared with other people.

Modifying an offline game you own is a private experiment. Cheating online steals fun from real opponents, violates the rules you agreed to, and can be illegal. This path is strictly about the offline, own-it kind.

Flag: ASEC{offline_only}

Client vs Server Authority

In a well-built online game, your computer (the client) only *displays* the game; the server decides what is actually true. If you edit your local memory to say you have 999 gold, the server checks its own records and rejects the lie.

This is why memory edits do not work on good online games — and why understanding the client/server split matters.

Flag: ASEC{trust_the_server}

Why Offline Games Are Fair Game

When a game runs entirely on your own machine with no shared server, *you* are the only one affected by changes. Modifying software you own, for your own use, on your own hardware, is generally allowed and is a recognised way to learn.

The safe rule of thumb: you own it, it is offline, and you keep the results to yourself.

Flag: ASEC{your_game_your_rules}

Anti-Cheat Exists for a Reason

Because some people do cheat online, games ship anti-cheat software that detects and blocks tampering. Far from being your enemy, anti-cheat is a fascinating security system — a real-world example of defenders spotting exactly the techniques you are learning.

Studying how it works (on your own systems) is legitimate and valuable.

Flag: ASEC{someone_is_watching}

The Defender's Perspective

Here is the neat truth: the person building cheats and the person building anti-cheat use the *same* skills — memory analysis, reverse engineering, and code injection. One side hides, the other seeks.

Learning offense makes you a far better defender, which is why these skills are prized on security teams.

Flag: ASEC{poacher_and_gamekeeper}

Setting Up a Safe Practice Target

The ideal practice target is a simple, single-player game you own and run offline — or a purpose-built practice app. That way every experiment is fully legal and nobody else is affected.

Many people use a basic offline game, a trainer-practice tool, or Cheat Engine's own tutorial, which is designed exactly for this.

Flag: ASEC{practice_safely}

Your Toolkit Overview

You will meet several tools, but the classic starting point is Cheat Engine — a free, friendly memory scanner and editor built for exactly this learning. Later you add debuggers (x64dbg) and disassemblers (Ghidra).

Do not worry about mastering them all now; this room builds the concepts first, tools second.

Flag: ASEC{tools_of_the_trade}

What Is RAM?

RAM (Random Access Memory) is your computer's fast, temporary working memory. While a program runs, all its live data sits in RAM, where it can be read and written in an instant.

It is fast but forgetful: switch the power off and it is wiped. Game state lives here, which is why it can be found and changed while the game runs.

Flag: ASEC{fast_and_forgetful}

Bits and Bytes

At the lowest level everything is bits — 0s and 1s. Eight bits grouped together make one byte, the basic unit memory tools count in.

A single byte holds a value from 0 to 255. Bigger numbers simply use several bytes together. Knowing this makes data types (coming next) click into place.

Flag: ASEC{eight_bits_a_byte}

What Is a Memory Address?

Memory is one giant row of byte-sized boxes, and every box has a number — its address. When we say "your health is at 0x1A2B3C," that number is the address where the value lives.

Find the right address and you can read or change what is stored there. Addresses are the map of memory.

Flag: ASEC{every_value_has_a_home}

Hexadecimal: Why Addresses Look Weird

Addresses are written in hexadecimal (base-16), using digits 0-9 then A-F for 10-15. Hex is used because two hex digits map neatly to one byte, making memory compact to read.

So 0x1A2B is a perfectly normal number, just written in base-16 instead of the base-10 you are used to.

Flag: ASEC{base_sixteen}

Reading a Hex Address

When you see something like 0x7FF6C21A, the 0x is just a marker meaning "this is a hex number." Everything after it is the value.

You do not need to convert hex in your head — the tools do it. You only need to recognise the 0x prefix and know it is base-16.

Flag: ASEC{0x_means_hex}

Data Types: Integer

An integer is a whole number (no decimals): 100 health, 30 ammo, 5 lives. Integers are the most common thing you will scan for, since so many game values are whole numbers.

When you tell a scanner "I am looking for 100," you usually mean a 4-byte integer holding 100.

Flag: ASEC{whole_numbers}

Data Types: Float and Double

Values with decimals — position, speed, sometimes health — are stored as floats (4 bytes) or doubles (8 bytes, more precise).

This matters hugely when scanning: if a value is a float and you search for an integer, you will find nothing. Many "why can't I find it?" moments are secretly floats.

Flag: ASEC{decimals_need_floats}

Data Types: Bytes and Strings

A single byte holds a small value (0-255) — handy for things like a level number. Text, such as a player name, is stored as a string: a run of bytes, one per character.

To find a name in memory you scan for a string; to find a small counter you might scan for a byte.

Flag: ASEC{text_is_a_string}

How Big Is Each Type?

Size matters because the scanner reads exactly that many bytes at an address. Typical sizes: a byte is 1, a standard integer and a float are 4 bytes each, and a double is 8.

Picking the matching size is part of scanning correctly — the right value at the wrong size looks like garbage.

Flag: ASEC{size_matters}

Signed vs Unsigned

A signed number can be negative or positive; an unsigned one is only zero or positive. Health that can drop below zero is signed; a count that never goes negative might be unsigned.

If a value behaves oddly at the boundaries (like wrapping from 0 to a huge number), signedness is often the reason.

Flag: ASEC{plus_or_minus}

Endianness (Byte Order)

When a number spans several bytes, they can be stored in two orders. Little-endian (used by x86 PCs) stores the least-significant byte first, so 0x1A2B appears in memory as 2B 1A.

You rarely fight this directly, but it explains why raw bytes in a hex editor can look "backwards."

Flag: ASEC{little_end_first}

The Stack

The stack is a tidy region of memory for a function's local variables and its call bookkeeping. It grows and shrinks as functions are called and return, like a stack of plates.

Short-lived values often live here. Understanding the stack becomes essential once you read assembly and debug functions.

Flag: ASEC{stack_em_up}

The Heap

The heap is the big, flexible region where a program requests memory on the fly — for objects that stick around, like the player, enemies, or the inventory.

Most interesting game values live in heap-allocated objects, which is exactly why their addresses move around and why you will need pointers to reach them reliably.

Flag: ASEC{a_big_heap}

Pointers: Addresses That Hold Addresses

A pointer is a value that stores *another* address. Instead of holding your health, it holds "the health is over there."

Pointers are how programs link objects together, and — crucially for you — they are the key to finding values that move each run. Master pointers and you master reliable game hacking.

Flag: ASEC{it_points}

Virtual Memory Per Process

Each running program gets its own private, virtual address space. Two programs can both use "address 0x400000" without clashing, because the OS maps each one's virtual addresses to different real memory.

This is why you attach a tool to *one specific process* — you are exploring that program's private world.

Flag: ASEC{your_own_space}

The Core Loop: Scan, Change, Rescan

All memory scanning is one loop. Scan for a value, change it in the game (take damage, spend money), then do a next scan filtered by how it changed. Repeat until one address remains.

This "scan → change → rescan" rhythm is the heartbeat of every memory hack.

Flag: ASEC{scan_and_rescan}

Exact Value Scan

If you can *see* the number — health is exactly 100 — start with an exact value scan for 100. This is the simplest, fastest way to begin and usually leaves a manageable list of candidates.

Most first hacks begin here: read the number off the screen, scan for it exactly.

Flag: ASEC{i_know_the_number}

Unknown Initial Value Scan

Sometimes you cannot see the number — a hidden stamina bar, say. Then you start with an unknown initial value scan, which grabs everything, and narrow it down by how the value changes (increased, decreased).

It takes more rounds, but it finds values you can only observe indirectly.

Flag: ASEC{start_from_nothing}

Increased / Decreased Scans

Between scans you compare to the previous result. Took damage? Your health value has decreased, so scan for "decreased value." Picked up ammo? Scan for "increased."

Each comparison throws away addresses that did not move the right way, rapidly shrinking the list.

Flag: ASEC{it_went_down}

Changed / Unchanged Scans

You can also filter by whether a value moved at all. Standing still and want to drop everything that flickered? Scan for unchanged. Want only things that just moved? Scan for changed.

These are perfect when you cannot predict the exact direction, only that it did or did not change.

Flag: ASEC{narrow_it_down}

Narrowing Thousands to One

A first scan might return thousands of addresses. Each rescan filters them, and after a handful of rounds you are usually down to a single correct address — the one that truly holds your value.

Patience over a few rounds beats guessing every time.

Flag: ASEC{needle_in_haystack}

Choosing the Right Data Type to Scan

Before scanning, tell the tool the type you expect — integer, float, byte. Scan for the wrong type and even the right value is invisible, because the bytes are interpreted differently.

When a value stubbornly refuses to appear, the first thing to check is whether you picked the right data type.

Flag: ASEC{pick_the_type}

Floats: The Scanning Gotcha

The single most common beginner trap: values like speed, position, and sometimes health are stored as floats, not integers. Scan for an integer and you get nothing.

If an obviously present value refuses to show up, switch the scan type to float (or double) and try again.

Flag: ASEC{sneaky_floats}

When a Value Won't Scan

Sometimes the number on screen is not the number in memory. A health bar might display 100 while storing the real value as 1.0 (a float 0-to-1) or as a max/current pair.

When scanning the displayed number fails, suspect that the display and the stored value differ, and scan by how it *changes* instead.

Flag: ASEC{display_vs_reality}

Freezing a Value

Once you find an address, tools let you freeze it — repeatedly writing the same value so the game can never change it. Freeze health at 100 and you effectively have god mode (offline!).

Freezing is often more useful than a one-off edit, because the game constantly tries to overwrite the value.

Flag: ASEC{frozen_in_time}

Editing a Found Value

The payoff: once you have the right address, you write a new value to it, and the game reads your number back as if it were its own.

Write 999 to the ammo address and you have 999 ammo. It really is that direct — the hard part was finding the address, not changing it.

Flag: ASEC{just_write_it}

Health, Ammo, Money: Easy First Targets

The friendliest values to practise on are ones you can watch change on screen: health, ammo, money, score. You see the number, scan for it exactly, do something to change it, and rescan.

Start with health — it changes clearly when you take damage, giving you fast, obvious feedback.

Flag: ASEC{first_blood}

Multi-Level Values (Same Number, Many Places)

Sometimes the same number (say, 100) appears at many addresses at once — copies, caches, or unrelated values that happen to match.

That is fine: the rescan loop weeds out the copies that do not change with your health. The one that always tracks the game is the real one.

Flag: ASEC{copies_everywhere}

Verifying You Found the Right One

Before trusting an address, prove it: change the value and watch the game update on screen. If editing the address moves your health bar, you found the right one.

Always verify — an address that looks right but does nothing is a decoy that will waste your time.

Flag: ASEC{trust_but_verify}

Saving Your Findings

Good hackers keep notes: the addresses (or better, pointer paths) they found, the data types, and what each value does. Tools let you add found addresses to a saved table.

Without notes you redo the same scan tomorrow. With them, you build a reusable map of the game.

Flag: ASEC{write_it_down}

Why Addresses Change Next Launch

Frustrating discovery: the address you found today is wrong tomorrow. Modern systems use ASLR (Address Space Layout Randomization) to load things at different places each run, for security.

So a raw address is a one-time find. To make a hack that survives restarts, you need pointers — the next few tasks.

Flag: ASEC{it_moved}

Dynamic vs Static Addresses

Most useful values sit at dynamic addresses that move each run. But some locations — inside the loaded module itself — stay put relative to the module's base; these are effectively static.

The trick to reliability is starting from a static point and following pointers to the moving value.

Flag: ASEC{some_things_stay}

Introducing Pointer Chains

A pointer chain is a path: start at a stable base, read the pointer there to get another address, add an offset, read again, and so on until you reach the value.

Because the chain begins somewhere stable and follows the game's own links, it lands on the right value every run — even though the value itself moved.

Flag: ASEC{follow_the_chain}

What Is a Base Address?

Every good pointer chain starts from a base address — a reliable, static anchor, usually the game module's load address (like "game.exe"+something).

The base is the one part that does not randomize away, so it is the trustworthy starting line from which the chain is followed.

Flag: ASEC{start_at_the_base}

Offsets Along the Chain

At each hop of a chain you add a small fixed number — an offset — before reading the next pointer. Offsets are the "+0x10, +0x8" steps that walk from one object to a field inside it.

Offsets stay constant even when addresses randomize, which is what makes the whole chain dependable.

Flag: ASEC{mind_the_offset}

Pointer Scanning

Finding a chain by hand is hard, so tools include a pointer scan: give it the current address of your value, and it searches for base+offset paths that reach it.

Restart the game (the value moves), rescan to filter the paths, and you are left with chains that work every launch.

Flag: ASEC{scan_the_pointers}

Testing a Pointer After Restart

A pointer chain is only proven once it survives a restart. Close the game, reopen it, and check that following the chain still lands on your value.

If it works after a fresh launch (and ideally on another day), you have a reliable, reusable hack rather than a one-time lucky address.

Flag: ASEC{survives_a_restart}

Module + Offset Notation

Static bases are written as module + offset, like "game.exe"+0x1234. This means "the game.exe module's load address, plus 0x1234."

Because the OS tells you where the module loaded, this notation resolves to a real address every run, giving your chain its stable anchor.

Flag: ASEC{module_plus_offset}

Why Pointers Beat Raw Addresses

A raw address is a snapshot that expires at the next launch. A pointer chain is a *recipe* that recomputes the address each time, giving you stable access no matter how memory is randomized.

This is the leap from "it worked once" to "it works reliably" — the mark of real skill.

Flag: ASEC{stable_access}

Multi-Level Pointer Chains

Simple values need one hop; deeply nested ones need several. A multi-level pointer chain follows pointer after pointer (base → object → sub-object → value).

More levels are harder to find but reach values buried deep in the game's object tree. Pointer scans handle the searching for you.

Flag: ASEC{hop_hop_hop}

From Code to Machine Instructions

Games are written in languages like C++, then compiled down to assembly — the human-readable form of the raw machine instructions the CPU runs.

You do not get the original source, but you *can* read the assembly. It is lower-level and terse, yet learnable, and it is where you go once memory editing is not enough.

Flag: ASEC{closer_to_metal}

What the CPU Actually Does

Underneath everything, the CPU does something simple at blinding speed: fetch one instruction, do it, move to the next. Add these, compare those, jump there.

A whole game is millions of these tiny steps per second. Reverse engineering is just slowing that down enough to read it.

Flag: ASEC{one_step_at_a_time}

Registers: The CPU's Scratchpad

The CPU has a small set of ultra-fast storage slots called registers. It uses them as a scratchpad to hold the values it is working on right now.

Assembly is mostly moving data between registers and memory and doing arithmetic on registers. Knowing they exist is enough to start reading code.

Flag: ASEC{cpu_scratchpad}

Common x86 Registers

On 32-bit x86 you will constantly see general-purpose registers named EAX, EBX, ECX, and EDX. (On 64-bit they become RAX, RBX, and friends.)

EAX in particular is a workhorse — often holding function results. You do not memorise them all; you just get comfortable seeing them in code.

Flag: ASEC{meet_the_registers}

The Instruction Pointer

One special register, EIP (RIP on 64-bit), holds the address of the *next* instruction to run. The CPU follows it forward, step by step, and jumps change it.

Controlling where EIP goes is the essence of both game patching and exploitation — it decides what runs next.

Flag: ASEC{whats_next}

MOV: Moving Data

The instruction you will see most is MOV — it copies data from one place to another (register to register, memory to register, and so on).

MOV eax, [health] means "copy the health value into eax." Despite the name it copies rather than relocates, but it is the fundamental data-shuffling instruction.

Flag: ASEC{move_it}

ADD and SUB

Arithmetic shows up as ADD (addition) and SUB (subtraction). Taking 10 damage is literally something like SUB [health], 10 somewhere in the code.

Finding that one subtract instruction — and neutralising it — is a classic way to stop damage entirely. Simple math, big effect.

Flag: ASEC{do_the_math}

CMP: Comparing Values

CMP compares two values (for example, "is health <= 0?") and sets internal flags with the result. A following jump instruction then decides what to do based on those flags.

CMP-then-jump is how all the game's decisions — alive or dead, enough ammo or not — are made.

Flag: ASEC{compare_them}

JMP and Conditional Jumps

Programs are not straight lines; they branch. JMP jumps unconditionally to another instruction, while conditional jumps (JE, JNE, JLE...) jump only if the last comparison met a condition.

Changing a conditional jump — say, forcing "if dead" to never trigger — is a powerful, surgical way to alter behaviour.

Flag: ASEC{take_the_leap}

Reading a Disassembly

Turning raw machine bytes back into readable assembly is called disassembly, and a disassembler does it for you. The result is a list of instructions you can read top to bottom.

You will not understand every line at first — and that is fine. You learn to spot the few lines that matter.

Flag: ASEC{read_the_asm}

Opcodes vs Mnemonics

Each instruction has a numeric opcode (the actual bytes the CPU reads) and a friendly mnemonic — the short name like MOV or JMP that humans use.

Disassemblers show you mnemonics; hex editors show the opcodes. Knowing both are the same instruction, just displayed differently, avoids a lot of confusion.

Flag: ASEC{easy_to_remember}

NOP: The Do-Nothing Instruction

NOP (No Operation) is an instruction that does absolutely nothing but take up space and move to the next instruction.

That sounds useless, but it is a favourite tool: overwrite an unwanted instruction (like the one that subtracts your health) with NOPs, and that behaviour simply stops happening.

Flag: ASEC{do_nothing}

Finding What Writes to an Address

Memory scanning finds *where* a value is; to find the *code* behind it, tools offer "find what writes to this address." Trigger the value to change and the debugger catches the exact instruction responsible.

This bridge from a found value to the code that changes it is a pivotal skill.

Flag: ASEC{who_touched_it}

The "Find Out What Accesses" Trick

A cousin feature, "find what *accesses* this address," catches every instruction that reads or writes your value — great for discovering the surrounding code and other useful pointers.

By watching who touches a value while you play, you map out the game's logic around it without ever seeing the source.

Flag: ASEC{catch_it_in_the_act}

From Value to Code

Put it together: memory scanning gives you the *value*, and the "what writes/accesses" features give you the code that manages it. That is the leap from editing numbers to editing behaviour.

Once you can walk from a value to the instructions that touch it, you can change *how the game works*, not just what a number currently is.

Flag: ASEC{value_to_code}

Patching an Instruction

Changing an instruction's bytes to alter behaviour is called patching. Replace, remove (NOP), or rewrite an instruction and the program does something different from here on.

Patching is more powerful than value editing: instead of setting health to 100 once, you can stop the code that ever reduces it.

Flag: ASEC{apply_a_patch}

NOP-ing Out Damage

The textbook example: find the SUB [health], 10 that runs when you are hit, and overwrite it with NOP instructions. Damage code now does nothing, so your health never drops — effectively infinite health, offline.

One tiny patch, a dramatic result, and a perfect illustration of value-to-code thinking.

Flag: ASEC{no_more_damage}

Code Caves

Sometimes you need to add *more* code than fits in place. A code cave is a patch of unused, empty space in the program where you can write your own instructions.

You redirect execution into the cave, run your custom code, then jump back — a classic way to inject new behaviour without overwriting anything important.

Flag: ASEC{into_the_cave}

Detour / Hook Basics

A hook (or detour) redirects execution: at some instruction you insert a jump into your own code, do something, then jump back.

Hooks let you observe or change what the game does at a precise moment — reading a value as it is calculated, or overriding a result — and they underpin most trainers and, on the flip side, anti-cheat.

Flag: ASEC{hook_the_code}

Assembly Injection

Writing brand-new assembly into a running game (via a cave and a hook) is code injection. You are literally adding instructions to a program while it runs.

This is how more advanced cheats and, importantly, many debugging and instrumentation tools work. Done to your own software, it is a superb way to learn how programs execute.

Flag: ASEC{inject_the_code}

Cheat Engine Auto Assembler

Cheat Engine bundles all of this into scripts written in its Auto Assembler, which can find a spot, allocate a code cave, install a hook, and cleanly undo it all.

These scripts (often shared as "[ENABLE]/[DISABLE]" blocks) are how the community packages reversible patches for offline games.

Flag: ASEC{scripted_patches}

AOB (Array of Bytes) Scanning

Instead of a fragile fixed address, you can locate code by its unique byte pattern — an Array of Bytes (AOB) scan searches memory for that signature and finds the instruction wherever it moved to.

AOB scanning is how robust patches locate their target reliably, even at different addresses.

Flag: ASEC{find_by_pattern}

Why AOB Beats Fixed Addresses

A patch tied to a fixed address breaks the moment the game updates and the code shifts. An AOB signature, chosen from stable bytes around your target, keeps finding it across many versions.

That resilience is why serious patches identify code by pattern rather than by a brittle hard-coded address.

Flag: ASEC{survive_the_update}

Making a Patch Reversible

A good patch can be turned off again, restoring the original bytes. Cheat Engine's [ENABLE]/[DISABLE] scripts save the original instruction so you can toggle your change cleanly.

Reversibility keeps your experiments safe and tidy — you can always put the game back exactly as it was.

Flag: ASEC{on_and_off}

Testing Patches Safely

Always test patches on a copy of a game you own, offline, ideally with saves backed up. Patches can crash a program, and you never want to risk important data or online accounts.

Experiment freely — but on your own copy, disconnected, where a crash costs nothing but a restart.

Flag: ASEC{test_on_a_copy}

Cheat Engine: The Beginner's Swiss Army Knife

Cheat Engine is the classic all-in-one starter: memory scanner, value editor, pointer scanner, debugger, and Auto Assembler in one free package. Its built-in tutorial teaches every scanning skill step by step.

Almost everyone begins here, and it remains useful long after, precisely because it bundles so much into one friendly window.

Flag: ASEC{the_classic_tool}

Debuggers: x64dbg and Others

A debugger lets you pause a running program, inspect registers and memory, set breakpoints, and step through instructions. On Windows, x64dbg is a popular free choice.

Debuggers are how you watch code execute in slow motion, which is essential once you move from editing values to understanding logic.

Flag: ASEC{pause_and_inspect}

Disassemblers: IDA and Ghidra

A disassembler takes a compiled program and shows its assembly, often with navigation, function detection, and graphs. Ghidra — free and released by the NSA — and IDA are the big names.

These are for deeper static analysis: understanding a whole program's structure, not just one value.

Flag: ASEC{free_from_the_nsa}

Decompilers: From ASM to C-like

Reading raw assembly is slow, so modern tools include a decompiler that reconstructs approximate C-like source from the assembly. Ghidra and IDA both do this.

It is not the original code and it is imperfect, but readable pseudo-C makes understanding a function far faster than instruction-by-instruction.

Flag: ASEC{almost_source}

Hex Editors

A hex editor shows a file's raw bytes as hexadecimal and lets you edit them directly. It is how you patch a program *on disk* (rather than in memory) or inspect unknown file formats.

Every reverse engineer keeps one handy for peering at the raw bytes beneath the abstractions.

Flag: ASEC{raw_bytes}

Process Monitors

Process Monitor (and similar tools) records what a program does to files, the registry, and the network in real time.

When you want to know *what a program touches* — which config file it reads, where it saves — a process monitor shows you, which is invaluable for both game hacking and malware analysis.

Flag: ASEC{watch_the_process}

Breakpoints: Pausing Execution

In a debugger, a breakpoint is a marker that pauses the program when execution reaches it (or when a chosen address is read/written).

Breakpoints are how you freeze the game at the exact moment something interesting happens, so you can inspect the state right then and there.

Flag: ASEC{stop_right_there}

Stepping Through Code

Once paused, you step — running one instruction at a time (step into, over, out). Watching registers and memory change with each step reveals exactly how a routine works.

Stepping turns an intimidating wall of assembly into a slow, understandable story you can follow line by line.

Flag: ASEC{one_line_at_a_time}

Reading the Call Stack

When paused, the call stack shows the chain of functions that led to the current spot — who called whom to get here.

It answers "how did the program end up running this code?" and helps you climb back up to the higher-level logic, such as the function that decided to apply damage.

Flag: ASEC{how_did_i_get_here}

Choosing the Right Tool

Match the tool to the job: quick value edits and pointer scans → Cheat Engine; live stepping through code → a debugger; understanding a whole binary → a disassembler/decompiler; raw file bytes → a hex editor.

Knowing which to reach for saves hours. Most tasks start in Cheat Engine and graduate to the others as you go deeper.

Flag: ASEC{right_tool_right_job}

What Is Reverse Engineering?

Reverse engineering is figuring out how something works when you do not have the plans — taking a finished program apart to understand its inner logic.

Everything in this room is applied reverse engineering. The mindset — observe, hypothesise, test, refine — carries far beyond games into malware analysis, security research, and software archaeology.

Flag: ASEC{take_it_apart}

Static vs Dynamic Analysis

Static analysis studies a program *without running it* — reading the disassembly or decompiled code. It is safe and gives the big picture, but you must reason out what will happen.

It pairs with dynamic analysis (next). Together, reading and running, they let you understand almost anything.

Flag: ASEC{look_dont_run}

Dynamic Analysis: Watch It Run

Dynamic analysis studies a program *while it runs* — using a debugger to watch values, step through code, and see real behaviour.

It shows what actually happens (including things static analysis might miss), at the cost of needing to run the code. Most reverse engineering blends both approaches.

Flag: ASEC{watch_it_live}

Functions and Calling Conventions

Code is organised into functions, and a calling convention is the agreed set of rules for how arguments are passed (which registers, the stack) and how results come back.

Recognising function boundaries and conventions turns a soup of instructions into meaningful, named routines you can reason about.

Flag: ASEC{how_to_call}

Identifying Loops and Conditions

In assembly, a loop appears as code that ends with a jump *back* to an earlier point, repeating until a condition changes. Conditions show up as CMP followed by a conditional jump.

Learning to spot these patterns lets you read the control flow — the shape of the logic — even without comments.

Flag: ASEC{round_and_round}

Strings as Clues

Readable text left inside a binary — menu labels, error messages, file names — are strings, and they are gold for reverse engineers.

Search for a message you saw on screen, find where it lives, and the nearby code is often exactly the logic you were hunting for. Strings are the fastest shortcut into unknown code.

Flag: ASEC{follow_the_strings}

Job-Ready Notes

Tools to know: Ghidra, IDA, x64dbg, gdb (with pwndbg), radare2.
Cheat sheet

file ./bin; strings ./bin        # quick triage
gdb ./bin                        # dynamic analysis

Interview practice

• Static vs dynamic analysis — strengths of each?
• What is a pointer chain and why is it useful?
• How do programs try to detect a debugger?

Cross-References (XREFs)

A cross-reference (XREF) shows everywhere a function, string, or address is used from. Right-click a function and "show XREFs" to see who calls it.

XREFs let you navigate a program like a web of links: find an interesting string, follow its XREF to the code, then follow that code's XREFs upward to the important logic.

Flag: ASEC{who_calls_this}

Naming and Commenting as You Go

Reverse engineering is memory-intensive, so as you figure out what a function does, rename it and add comments. "sub_401000" becomes "apply_damage."

This makes every later step easier, because the code slowly turns from cryptic to readable. Good reversers leave a trail of breadcrumbs for their future selves.

Flag: ASEC{leave_breadcrumbs}

Packing and Obfuscation

Some programs resist reverse engineering with packing (compressing/encrypting the code so it only unpacks in memory) or obfuscation (deliberately confusing code).

These slow you down but rarely stop a determined analyst — you often let the program unpack itself in memory, then dump and analyse it. Recognising a packed binary is an early, useful skill.

Flag: ASEC{hidden_in_plain_sight}

Patience: The Real RE Skill

More than any tool, reverse engineering rewards patience. Progress comes from many small, careful observations — rename a function, test a theory, follow one XREF — that slowly add up to understanding.

Nobody reads assembly fluently on day one. The people who get good are simply the ones who keep chipping away, calmly.

Flag: ASEC{slow_and_steady}

How Anti-Cheat Detects You

The simplest anti-cheat method scans your memory for the byte signatures of known cheats and tools, exactly like antivirus. If it spots Cheat Engine's fingerprint or a known trainer, it flags you.

Understanding signature detection — and why it only catches *known* things — is the first lesson in the defender's side of this game.

Flag: ASEC{they_scan_for_you}

Signature vs Behavioral Detection

Beyond signatures, behavioral detection watches *how you play* and flags the impossible: perfect aim, superhuman speed, seeing through walls. It does not need to recognise your specific cheat — only that your behaviour is not humanly plausible.

This is why even a brand-new, undetected cheat can still get you banned for playing "too well."

Flag: ASEC{too_good_to_be_true}

Kernel-Level Anti-Cheat

Some anti-cheat runs at the kernel level — the deepest, most privileged layer of the operating system — so it can observe things a normal program cannot, including tools trying to hide from it.

It is powerful and controversial (it sees a lot of your system), and it dramatically raises the difficulty for cheat developers.

Flag: ASEC{deep_in_the_system}

Server-Side Validation Wins

The strongest defence is not on your machine at all: server-side validation. The server independently checks every action — is that move possible, was that shot legitimate — and ignores anything the client claims that does not add up.

Client-side checks can always be bypassed; server authority cannot, which is why serious online games rely on it.

Flag: ASEC{the_server_decides}

Putting It All Together

Look how far you have come. You know that game state is just numbers in memory; that you find them by scanning, reach them reliably with pointers, and understand them through assembly and the debugger. You can patch code, choose the right tool, reverse-engineer logic, and you understand how anti-cheat fights back — and why the server always wins online.

That mental model — a program as data and instructions you can read and change — is the real prize, and it powers everything from malware analysis to exploit development. Keep practising, offline, on games you own.

Flag: ASEC{you_understand_the_machine}