Reverse Engineering Curriculum

Reverse-Engineering Curriculum

Overview

Build a reverse engineer by layers: first create and debug native programs, then account for their generated machine code, then recover behavior from unknown binaries, and only then combine Windows, engine, and anti-cheat subsystems into controlled research exercises.

The output is a competency ledger, not a reading checklist. A learner advances only when they can reproduce a result, explain its mechanism from evidence, and solve a nearby variant without a walkthrough. The supplied reading map lives in references/reading-map.md; treat it as a source list, not as a substitute for exercises.

When to Use

• Planning a self-directed curriculum from C/C++ through native reverse engineering.
• Turning a book/resource list into phases, labs, retrieval prompts, and observable graduation gates.
• Assessing a learner's current level and selecting the next reverse-engineering exercise.
• Building a progression from user-mode RE to Windows internals, game engines, or anti-cheat architecture.

Use teach when creating a persistent lesson workspace and individual lessons. Use the relevant specialist skill once the learner begins real technical work; this skill owns sequencing and mastery gates, not the detailed execution of a specific analysis, driver, overlay, or anti-cheat experiment.

Intake

Establish a baseline before assigning material. Record:

Do not infer mastery from titles read, tools installed, or copied code. Assign one short diagnostic per uncertain prerequisite.

Done when: the learner has a dated competency ledger with an objective, tooling baseline, current phase, and one concrete gap to close.

Operating Model

Every study block follows this loop:

1. Read narrowly. Take one concept from the current phase's primary material.
2. Recall unaided. Explain the concept, sketch its data/control flow, or predict program behavior before opening a tool.
3. Build or analyze. Implement a minimal program or inspect a deliberately scoped artifact.
4. Cross-check. Compare source ↔ compiler output ↔ debugger/runtime behavior, or compare static evidence ↔ dynamic observation.
5. Write evidence. Preserve commands, inputs, build identifiers, address coordinates, screenshots/logs, and a short statement of what changed the learner's model.
6. Vary one condition. Change an optimization level, compiler, input, architecture, structure layout, or feature flag and explain the difference.

Keep AI in a coaching role: request a question, a review of an attempted explanation, or a minimal hint. Do the first reconstruction, debugging attempt, and evidence collection before requesting a solution. Never substitute generated code for the learner's own implementation during a competency check.

Done when: every completed exercise has an artifact, an explanation, and a variation result—not only a passing build.

Curriculum Phases

Phase 0 — C/C++ and computational foundations

Goal: reason about memory, object lifetime, data representation, asymptotic cost, and I/O without treating the standard library or a debugger as magic.

Practice:

• Write C programs that parse binary/text input, allocate and free dynamic structures, and handle failures.
• Implement arrays, linked lists, hash tables, heaps, trees, sorting, and graph traversal at least once in C; repeat selected work in idiomatic C++ with RAII.
• Solve algorithm problems under a constraint that forces a stated complexity and representation choice.
• Build a small networked or file-format project and debug malformed inputs.

Gate: given a crash in a self-written program, the learner identifies the failing invariant, confirms it in a debugger, fixes it, and explains the generated object/data layout. They can implement a basic container and justify its time/space tradeoffs.

Route technical coding to: systems-language-engineering, lang-cpp23, and systematic-debugging.

Phase 1 — Machine model, ABI, and assembly fluency

Goal: map ordinary C/C++ constructs to registers, stack frames, calling conventions, relocations, and control flow.

Practice:

• Compile the same small functions at -O0, -O2, and with different compilers; annotate differences.
• Hand-trace loops, switches, pointers, structs, virtual calls, exceptions/error paths, and integer conversions.
• Write small assembly routines that obey the target ABI, then inspect their object-file relocations and unwind behavior.
• Use a debugger to stop before and after calls and reconcile register/stack state with the ABI.

Gate: the learner can recover a function's inputs, outputs, clobbers, locals, and call targets from disassembly, correctly label VA/RVA/file offset, and validate one conclusion with a source-to-assembly reproduction or debugger observation.

Route technical work to: assembly-reversal-engineering, lang-assembly, zydis-disassembly-engineering, and windbg-ttd where appropriate.

Phase 2 — Static binary analysis

Goal: develop an evidence-first static workflow before relying on decompiler output.

Practice:

• Triage a benign, self-built native binary: format, architecture, sections, imports, strings, entry points, symbols, and compiler fingerprints.
• Recover one parser, one state machine, and one data structure bottom-up from code and cross-references.
• Maintain a table of module hash, address coordinate, bytes, interpretation, confidence, and validation plan.
• Compare decompiler output against the actual instructions for all important conclusions.

Gate: produce an annotated analysis note for an unknown-but-benign binary that identifies one end-to-end input → transform → output path and validates its key semantics using a second method.

Route technical work to: reverse-engineering, ida-reverse, ghidra-reverse, radare2, re-source, and rev-struct.

Phase 3 — Dynamic analysis and hostile-code literacy

Goal: observe runtime behavior without confusing a debugger view with ground truth or a malware pattern with an attribution claim.

Practice:

• Debug instrumented toy programs with deliberate anti-debug checks, packing-like decode stubs, IPC, and thread races.
• Trace allocation, file, registry, process, and network behavior in a disposable VM.
• Use breakpoints or Frida to capture function arguments, return values, and plaintext at one carefully selected boundary.
• Analyze benign simulations or archived samples under a documented static-first, snapshot-backed lab workflow.

Gate: provide a timeline that joins a static code location to a runtime event, shows the exact build/tool versions, distinguishes observed facts from inferred behavior, and includes a negative control.

Route technical work to: malware-analysis, frida-dbi, frida-instrumentation, anti-debugging-techniques, memory-forensics, and digital-forensics.

Phase 4 — Windows internals and kernel foundations

Goal: explain Windows as interacting identity, object, memory, loader, I/O, and telemetry systems rather than a list of undocumented offsets.

Practice:

• Trace a process creation, handle, token, module-load, file-I/O, and RPC/COM transaction end-to-end.
• Resolve symbols and compare public types, disassembly, and runtime observations on the exact Windows build.
• Build a minimal, safe driver or a user-mode mock that models an IOCTL contract, cancellation, and cleanup.
• Capture an ETW trace with a known sentinel event, then account for provider configuration and event loss.

Gate: present a build-pinned subsystem map for one transaction, including trust transitions, object lifetime, cleanup, and the observation that could falsify the conclusion.

Route technical work to: windows-internals, windows-symbols-debugging, windows-telemetry-etw, kernel-dev, driver-comm, and windbg-ttd.

Phase 5 — Engine and protocol literacy

Goal: recover data flow in game-like real-time programs while respecting build provenance and server authority.

Practice:

• Build a toy client/server simulation with replicated entities, prediction, correction, and a serialised message format.
• Map the toy client's entity, transform, camera, and renderer data; validate each field from both runtime and static evidence.
• Implement WorldToScreen from a known matrix and prove it with synthetic camera/viewport cases.
• Decode a locally captured test protocol and document framing, state, error handling, and replay boundaries.

Gate: show one local actor transform flowing through camera projection to a screen coordinate, then distinguish local prediction from server-confirmed state in a packet/runtime timeline.

Route technical work to: game-internals, game-hacking, external-esp, offset-dumper, network-protocol-re, and protocol-reverse.

Phase 6 — Anti-cheat architecture and defensive measurement

Goal: analyze the defender's observation and decision pipeline as a layered, falsifiable system.

Practice:

• Model a toy anti-cheat as game component, user-mode service, kernel telemetry collector, and backend decision system.
• Inventory observable surfaces such as handle access, image loads, memory mappings, input, ETW, driver trust, hardware, screenshots, and server-side behavior.
• Design clean baseline, positive-control, one-variable, and rollback runs; distinguish telemetry, block, kick, server correction, delayed action, and inconclusive outcomes.
• Implement one defensive detector in a lab and measure its false positives against varied benign behavior.

Gate: deliver a version-pinned detection hypothesis with trusted telemetry provenance, a healthy positive control, negative controls, measured outcome classes, and cleanup evidence. A missing event is not a bypass conclusion until sensor health and loss are accounted for.

Route technical work to: ags-anti-cheat, anti-cheat-bypass, game-hacking, windows-telemetry-etw, kernel-callbacks, vbs-hvci-research, and tpm-attestation-research.

Phase 7 — Capstone and independent practice

Goal: solve a bounded new problem by choosing tools and evidence rather than following a copied recipe.

Choose a legal local artifact or self-built target, pin its build, write an analysis plan, and complete a project such as:

• a file-format parser reverse-engineering report with a compatible reimplementation;
• a self-built client/server protocol recovery and mutational test harness;
• an engine schema/offset recovery pipeline with regression tests;
• a Windows subsystem tracing lab with symbols, ETW, and debugger evidence; or
• a toy anti-cheat telemetry/detector evaluation with an evidence package.

Gate: a reviewer can reproduce the environment, follow Evidence → Finding → Path, identify known limitations, and run one independent validation command without the learner present.

Competency Ledger Template

Maintain one row per competency:

Statuses: introduced, attempted, demonstrated, needs-variation, or regressed. A concept is not durable until it survives a variation after a delay.

Common Failure Modes

1. Reading without retrieval. Convert every chapter into a prediction, implementation, or artifact analysis before continuing.
2. Tool-first reversal. Start with file identity, address coordinates, and hypotheses; tools test models rather than provide them automatically.
3. Decompiler worship. Treat pseudocode as a hypothesis and check ABI, instructions, references, and runtime behavior.
4. Offset collecting. Keep build hash, source, signature/recipe, semantic assertions, and a regression result for each recovered field.
5. Skipping systems fundamentals. A learner who cannot explain pointers, object lifetime, ABIs, or process boundaries will stall on advanced tooling; return to the first failed gate.
6. Copying complete solutions. Use partial hints after an attempt; require an independently written variation before marking a skill demonstrated.
7. Confusing a detection observation with an enforcement result. Preserve baselines, controls, telemetry health, and backend outcome separately.

Verification Checklist

• Objective, current baseline, tools, weekly budget, and next gap are recorded.
• Each phase has a concrete artifact and evidence-backed gate.
• Completed work includes recall, implementation/analysis, independent validation, and one variation.
• Address, offset, schema, and build claims are pinned to a specific artifact/build.
• Learner-produced explanations distinguish observed facts, inference, and unresolved questions.
• Specialist skills are selected only after the relevant curriculum phase exposes a concrete task.
• The capstone is reproducible by another reviewer from its evidence package.