Full specification, approved target list, two-tier grading rubric, and forward pointers. See also: labs/lab-9-capstone.md for the student-facing deliverable spec.
Capstone summary
The RE-011 capstone is a static analysis report on an instructor-assigned training target: a small consumer IoT device or legacy router with publicly-available firmware. Students extract a filesystem from the firmware image, identify a specific binary, analyze it with Ghidra and supporting command-line tools, document their findings with specific evidence, and situate their analysis against prior public research.
| Item | Value |
|---|---|
| Format | Git repository + Markdown report |
| Length | 5-8 pages |
| Git requirement | At least 3 commits |
| Primary tool | Ghidra |
| Supporting tools | binwalk, readelf, objdump, nm, strings, xxd |
| Capstone weeks | 13 (scoping + sign-off) + 14 (delivery) |
Approved target list
| Target | Architecture | Firmware source | Notes |
|---|---|---|---|
| TP-Link TL-WR841N | MIPS32 LE | tp-link.com/support | Most common training target; squashfs FS; prior research widely available |
| Netgear R6700v3 | ARM Cortex-A9 | netgear.com/support | Multiple prior CVEs; httpd binary well-studied at RE-101+ level |
| D-Link DIR-615 | MIPS32 BE | dlink.com/support | Classic router; straightforward firmware format |
| ASUS RT-N56U | MIPS32 | asus.com/support | Broad prior research |
| Custom course-provided training image | x86-64 | Provided by instructor | Recommended for self-paced students; controlled complexity |
Proposed alternative targets must have: (1) firmware legally available for download, (2) at least one public CVE or prior security write-up, (3) a binary appropriate for RE-011-level analysis (not a kernel, not a 20 MB binary with no prior tooling).
What the scoping document must establish (Week 13)
Before a student begins writing the capstone report, the instructor sign-off confirms:
- The firmware source is legal (manufacturer download page, or a device the student owns with firmware they extracted themselves).
- The target binary is appropriate for RE-011 scope (not the kernel, not a trivially-simple static binary with no functions, not a binary that requires unpacking a custom packer not covered in this course).
- The scope question is answerable: a specific question ("Does the httpd binary validate length before copying user-supplied strings into a fixed-size buffer?") rather than a general goal ("find something wrong").
Sign-off is written and recorded. Students who submit without sign-off have their report returned for a scoping revision before grading begins.
Report sections and expectations
| Section | Length | Key expectation |
|---|---|---|
| 1: Target overview | ~1 page | Device, firmware version, hash, binwalk output, filesystem type |
| 2: Target binary | ~1 page | Binary name, architecture, stripped/unstripped, import table summary, Ghidra import |
| 3: Findings | 2-3 pages | Each finding has: type, location, evidence (address/string/version), security implication |
| 4: Comparison to prior work | ~1 page | At least one prior CVE or advisory; comparison to your own findings |
| 5: What would be next | ~1 page | Dynamic analysis hypothesis, hardware access impact, RE-101 forward pointer |
| 6: Tooling narrative | ~0.5 page | Practitioner reflection on which tools, in what order, what each contributed |
Tier 1: Pass/fail gate
Before any scoring, verify:
- Firmware source is legal. Check that the student provided a download URL from the manufacturer or described a self-extracted source.
- The binary analyzed is from the assigned target. Check that the architecture and binary characteristics match the device.
- The findings in Section 3 are technically accurate. Cross-check at least one finding against the firmware image (the instructor downloads the same image version and verifies).
- No paragraph-level copying from public writeups (standard plagiarism check).
Reports that fail the gate are returned with specific feedback. The student may revise and resubmit once.
Tier 2: Scored rubric
| Dimension | Weight | Strong (full credit) | Acceptable (partial credit) | Weak (no credit) |
|---|---|---|---|---|
| Technical depth (Section 3) | 40% | Findings cite specific addresses, strings, or function calls with exact values; security implication is specific to the evidence ("strcpy at 0x801b30 copies user-supplied Content-Length without bounds check, enabling heap overflow") | Findings are generally accurate but evidence is vague ("the binary uses strcpy in several places without validation") | Findings are assertions without evidence ("the binary is probably vulnerable to buffer overflow") |
| Analytical clarity (all sections) | 30% | Non-specialist reader could follow the firmware extraction and binary analysis without a Ghidra background; jargon explained on first use; findings described in terms of observable evidence | Some unexplained jargon; findings occasionally stated without evidence; readable by a technical generalist with effort | Written for a security professional only; unexplained terms throughout; findings not connected to evidence |
| Research situatedness (Section 4) | 30% | Prior work accurately cited with specific CVE or advisory; student's findings compared specifically to prior work ("My analysis found the same strcpy in httpd that CVE-2023-XXXX reports; I confirmed the call site at 0x801b30 independently") | Prior work cited but comparison is generic ("my analysis is similar to prior research on this router") | Prior work not cited, or cited without any comparison to student's own findings |
Common failure modes (for instructor reference)
Section 3 too thin: Students summarize what the binary does without finding specific evidence of a security-relevant property. "The httpd binary processes HTTP requests and calls malloc" is not a finding. "httpd calls strcpy at 0x801b30 with query_string as the source, which is read directly from the GET request without length validation" is a finding.
Section 4 is a bibliography: Students list prior CVEs without comparing them to their own analysis. Section 4 must connect the prior work to what the student actually observed.
Architecture mismatch: Students import a MIPS binary into Ghidra without selecting the correct MIPS processor variant. The disassembly is garbage. Verify at the scoping sign-off that the student knows the architecture and has the correct Ghidra processor module.
Single-commit repository: Check git log before scoring. Three commits are required; a single commit fails the Lab 9 spec.
Forward pointers from the capstone
The firmware analysis skills built in the capstone connect directly to:
- RE-101: The SB6141 is an MIPS-architecture cable modem. The firmware analysis methodology from RE-011 (binwalk, extract, identify, Ghidra) is the first three steps of the RE-101 lab target workflow. RE-101 adds physical access and vulnerability validation.
- RE-201: Hardware-level firmware extraction (JTAG, SPI flash reader, UART console) is the RE-201 layer that RE-011 deliberately excludes. Students who completed the capstone have the analysis workflow; RE-201 adds the extraction step.
- ADV-101: Malware analysis uses the same Ghidra workflow but on Windows PE samples in a sandboxed VM. The analysis methodology transfers; the environment and toolchain differ.
CAPSTONE.md v0.1. RE-011 capstone specification for instructors and self-paced students.