RE-011 Instructor Guide

For instructors and homeschool parents running RE-011. The course is self-runnable from the student-facing materials; this guide adds pacing context, common stumbling blocks, the capstone grading rubric, dual-use posture, and forward pointers.

Course shape at a glance

Cohort pacing recommendations

• Self-paced (one student): 14 calendar weeks comfortable. Students with prior assembly exposure may move faster through Weeks 4-5.
• Homeschool (1-3 students): 14 weeks at one module per week. Lab 5 (assembly-to-C reconstruction) and Labs 7-8 (dynamic + patching) are well-suited to side-by-side sessions.
• Classroom (10+ students): 14-17 weeks. Weeks 6-8 (three Ghidra/r2 weeks) are where wall time blows up; plan extra time for Ghidra orientation.
• Intensive (full-time, ~3 weeks): 110 hours at ~7 hours/day = approximately 16 working days.

Per-week pacing notes and common stumbling blocks

Week 1: What RE is

Pacing: The legal framing section (DMCA, CFAA) needs to be covered seriously, not rushed. Students who skip the ethical framing now will ask uncomfortable questions when analyzing real firmware in Weeks 12-14.

Common blocks:

• Students equate "reverse engineering" with "hacking." Clarify: RE is reading. The legal question is what you do with what you read, not the reading itself.
• Students want to run the Week 1 mystery files immediately. Enforce the read-before-run discipline explicitly: the lab asks them to identify files without running them. This is the course's foundational habit.

Week 2: Byte-level view

Pacing: This week is conceptual and should move quickly. The endianness section needs one concrete example worked through by hand. The xxd output format needs to be demystified (students who have not seen hex dumps before find the three-column format confusing at first).

Common blocks:

• Students confuse byte order with bit order (endianness applies to bytes in a multi-byte value, not to the bits within a byte). Clarify with the 01 00 00 00 = integer 1 (little-endian) example.

Week 3: ELF format

Pacing: The sections-vs-segments distinction is the week's key insight. Spend at least 20 minutes on concrete examples. The .plt and .got.plt section is often skipped or rushed; it matters for Lab 2 and for understanding dynamic analysis in Week 9.

Common blocks:

• Students confuse .symtab with .dynsym. Drill: which one is removed by strip? (.symtab.) Which one must remain for dynamic linking? (.dynsym.) Which one nm reads? (Both; -D for dynamic only.)
• Students expect nm to work on stripped binaries. Clarify: nm without flags fails on fully stripped binaries. nm -D works even on stripped binaries (dynamic symbols are preserved).

Weeks 4-5: x86-64 assembly

Pacing: Two dense weeks. Do not try to cover all x86-64 instructions; focus on the patterns: calling convention, prologue/epilogue, comparison/jump pairs, loop structure. Students who understand WHY test rax, rax is a null check are better served than students who memorized fifty instruction mnemonics.

Common blocks:

• Students memorize jump instructions without understanding the flags that control them. The cmp + flags + conditional jump relationship needs to be drilled with examples, not just listed.
• Students confuse signed and unsigned comparisons (jl vs. jb). The signed/unsigned distinction matters for Lab 5 reconstruction.
• The stack growth direction (downward) is counterintuitive. Students who get confused: draw a concrete diagram with addresses. The stack pointer decreases as you push.

What to watch: Students who cannot identify a loop by a backward conditional jump by the end of Week 5 will struggle with Lab 5 and with the CrackMe ladder.

Week 6: Ghidra I

Pacing: Ghidra's UI overwhelms students in the first session. Budget 30-45 minutes purely for project creation, import, and auto-analyser familiarization before showing any analysis content. The naming discipline section is the week's most important deliverable -- return to it at the end.

Common blocks:

• Ghidra's auto-analyser sometimes runs for several minutes on larger binaries. Students who do not wait for it to finish see a half-analyzed binary and get confused. Emphasize: wait for the "Analysis complete" dialog.
• Students navigate using only the search bar or only the Symbol Tree. Reinforce all three navigation methods from Lab 4 so they have options when one fails.
• Students name functions with verbs only: check, process, handle. Push for specificity: check_serial_number_crc, process_incoming_packet, handle_login_failure.

Week 7: Ghidra II

Pacing: Cross-references are the week's most important concept. The xref-from-string workflow (find "Wrong" string, follow xref to check function) is the CrackMe solve pattern students will use for the next seven weeks. Make sure every student executes this workflow on at least one binary before the end of Week 7.

Common blocks:

• Struct recovery is difficult for students who have not written C structs before. Start with a very simple struct (two fields) and a clearly offset-patterned function before asking students to tackle more complex cases.
• The decompiler-as-hypothesis framing needs to be reinforced. Students who trust the decompiler absolutely will be misled by decompiler artifacts. "The decompiler is a hypothesis; the listing is the ground truth" should be a repeated phrase.

Wall time note: Ghidra analysis on a non-trivial binary can take 20-40 minutes for a student who is orienting for the first time. The Week 7 lab walk takes longer than the time estimate suggests for new Ghidra users. Plan for overflow.

Week 8: radare2

Pacing: This week introduces a second tool that does the same job as Ghidra. Students feel like they are learning the same thing twice. Anchor the week in the "why two tools" framing: cross-verification, scriptability, remote target support. Without the "why," students resist.

Common blocks:

• radare2's command syntax is not obvious. Students need the mnemonic structure (a=analysis, f=function, l=list, p=print, d=disassemble) to make sense of the commands. Teach the structure, not a list.
• VV (visual mode) confuses students who are used to GUI tools. The ASCII-art graph view looks primitive. Reinforce: the graph is the same control flow graph Ghidra shows; just rendered differently.

Week 9: Dynamic analysis

Pacing: The static-first posture must be reinforced at the start of this week. "We are learning dynamic analysis this week so you know when to use it and how to use it -- not so you skip static analysis." Lab 7 enforces this; the grading rubric penalizes going straight to dynamic.

Common blocks:

• Students expect ltrace to always work. Clarify: ltrace only intercepts dynamically-linked library calls. A statically-linked binary or a binary that implements its own string comparison without calling strcmp will show nothing useful in ltrace.
• gdb pwndbg install often fails on student machines due to Python version conflicts. Have a fallback ready: pwndbg is optional; vanilla gdb is sufficient for RE-011.

Dual-use note: Week 9 introduces gdb debugging. This is controlled dynamic analysis against course-assigned binaries. The posture is: your binary, your machine, specific hypothesis. Students should not use gdb to debug binaries they did not compile or that are not explicitly assigned course materials.

Week 10: Anti-RE tricks

Pacing: This week is conceptual. The lab walk (UPX unpack) is the primary activity. Students often want to solve anti-RE tricks immediately; the goal this week is recognition, not bypass. Bypass comes in Week 11.

Common blocks:

• Students think UPX is the only packer. Clarify: UPX is the most common free packer, and it is trivially unpackable with upx -d. Custom packers (common in malware, not in CrackMe challenges) require different techniques. RE-011 covers UPX; ADV-101 covers custom packers.
• Jump table recognition requires knowing what to look for. Students who have not solved a switch-statement CrackMe may not recognize the pattern. The Week 5 lecture section on jump tables is the prerequisite.

Week 11: Patching

Pacing: The smallest-patch discipline needs to be enforced in grading, not just mentioned in the lecture. Students who produce a 20-byte NOP sled when a one-byte opcode flip would work should be redirected.

Common blocks:

• File offset calculation confuses students. The virtual address in Ghidra is NOT the file offset. Walk through the calculation explicitly in the lecture: file_offset = virtual_address - section_vaddr + section_file_offset. Have students calculate this for two or three examples before Lab 8.
• Students patch the wrong branch. If there are multiple conditional jumps in the check function, it is easy to patch the one that does not matter. Encourage students to verify: after patching, test with three distinct wrong inputs. If all three produce "Correct," the bypass is general.

Weeks 12-14: Firmware and capstone

Pacing: Week 12 is the guided rehearsal; students should leave it with a clear workflow they can execute independently. Week 13 is scoping sign-off; do not let students start the report without sign-off. Week 14 is delivery; no new lecture content.

Common blocks:

• Students pick firmware with no good analysis target. The custom course-provided training image eliminates this problem for self-paced students. For student-proposed alternatives, the sign-off gate is the fix.
• MIPS big-endian is the most common capstone architecture (most routers are MIPS). Students who configured Ghidra for x86-64 by default need to select the correct MIPS variant at import. Check this at the scoping sign-off.
• Section 3 (findings) is consistently the weakest section. Students describe what the binary does rather than documenting specific security-relevant properties with specific evidence. Provide examples of a strong finding vs. a weak finding at the Week 13 scoping session.

Dual-use posture

RE-011 is a read-only static analysis course with a controlled dynamic analysis week. The dual-use content:

1. CrackMe analysis: All CrackMe binaries are from crackmes.one or course-assigned materials -- intentionally-designed training targets. Students run them on their own machines. This is authorized by design.

2. gdb and strace (Week 9, Lab 7): Dynamic analysis against course-assigned binaries on the student's own machine. Not against third-party software, not against network services.

3. Binary patching (Week 11, Lab 8): Patching a course-assigned CrackMe. Not patching commercial software for license bypass.

4. Firmware analysis (Weeks 12-14, Lab 9): Static analysis of firmware downloaded from manufacturer's website (legal) on the student's own workstation. Not running extracted code on a physical device. Not testing against live network infrastructure.

If a student asks: "Can I run this analysis against [real device] or [real service]?" the answer is: not in RE-011. RE-101 covers how to scope an authorized engagement. Until then: your binaries, your machine, course-assigned training targets.

Forward pointers for instructors

When students ask "what comes next?":

• RE-101 entry: Ghidra fluency (Weeks 6-7), x86-64 assembly reading (Weeks 4-5), firmware teardown methodology (Week 12), and the static-analysis posture. Students who cannot navigate Ghidra to a function via three different methods, read assembly to reconstruct control flow, and run binwalk on a firmware image should review before RE-101.

• ADV-101 entry: The MITRE ATT&CK vocabulary from SEC-101 + dynamic analysis tools from Week 9 (gdb, strace) + anti-RE recognition from Week 10. ADV-101 adds: VM-based sandbox, unpacking pipelines, behavioral IOC extraction.

• ADV-102 entry: Week 9 dynamic analysis + Week 10 anti-RE + Week 11 patching are the three RE-011 prerequisites for ADV-102's advanced dynamic analysis and emulation-based analysis content.

• RE-201 entry: The firmware teardown methodology (Week 12) is the RE-201 prerequisite. RE-201 adds physical access: JTAG, UART, SPI flash reading, live firmware extraction. Students who can run binwalk on a downloaded firmware image and analyze a MIPS binary in Ghidra are ready for RE-201.

What RE-011 does NOT teach

• Exploit development: Finding a bug and writing working shellcode is RE-101 and ADV-101 domain. RE-011 finds the bug (conceptually) and describes the security implication.
• Kernel analysis: The capstone analyzes userland binaries. Kernel analysis (paging, system call tables, kernel modules) is RE-201 domain.
• Custom packer analysis: UPX is covered; custom runtime packers and VMs are ADV-101 / ADV-102 domain.
• Malware sandbox analysis: The dynamic analysis week covers clean CrackMe binaries on the student's own machine. Malware in an isolated VM is ADV-101.
• Windows PE analysis: RE-011 is Linux/ELF focused. PE analysis uses the same Ghidra workflow but a different ABI, different toolchain, and different anti-RE landscape. PEN-101 and ADV-101 cover PE analysis.

Instructor guide v0.1. Revise after first pilot cohort runs.