Classroom Public page

RE-011 Week 13: Capstone Scoping

1,053 words

Instructor-assigned training target, analysis plan, outline sign-off, and Lab 6 CrackMe checkpoint. The deliverable this week is a scoping document, not a report section.

Reading (~30 min)

Read the Lab 9 specification (labs/lab-9-capstone.md) in full. Then read the CAPSTONE.md document. Together, these two documents tell you what the capstone requires and how it will be graded. Read them before you write the scoping document.

If you have not yet read the Week 12 guided teardown notes in your Tool Journal, read those too. The scoping document is a more formal version of the "capstone preview" from Week 12's independent practice.

Lecture outline (~1.5 hr)

Part 1: The instructor-assigned training target (20 min)

The capstone target is assigned by the instructor (or chosen by a self-paced student from the approved list in CAPSTONE.md). It is a small consumer IoT device or legacy router whose firmware is publicly and legally available for download.

Why an assigned target rather than student-chosen:

  • The target must have legally-obtainable firmware (manufacturer provides it for download, or it is under a license that permits analysis).
  • The target must be at an appropriate complexity level: enough binaries to find something interesting, not so large that a 14-week student cannot make meaningful progress.
  • The target must have at least one documented prior finding (a CVE, a security advisory, a researcher write-up) so students have a benchmark to compare their independent analysis against.

For the capstone analysis, you are doing static analysis on the extracted firmware. You are NOT exploiting the device, NOT accessing a physical device, and NOT testing against any live infrastructure. The target is firmware bytes on your workstation.

Part 2: The scoping document (30 min)

The scoping document is your Week 13 deliverable. It is reviewed and signed off by the instructor before you begin writing the capstone report. A report started without sign-off often has the wrong scope, the wrong binary, or the wrong findings focus.

Scoping document structure:

1. Target identification

  • Device name and model
  • Firmware version you downloaded
  • Source URL (where you downloaded the firmware from -- must be legal/official)
  • MD5 or SHA-256 hash of the firmware image

2. Extraction summary

  • binwalk output: what components were found inside the image
  • Filesystem type extracted (squashfs, jffs2, etc.)
  • Filesystem root: what is in /, /bin, /usr/bin, /etc (a brief find listing, not exhaustive)

3. Target binary

  • The specific binary you will focus your capstone analysis on
  • Why you chose it: what made it interesting (library calls, string content, known functionality)
  • Architecture: architecture identified from file and readelf -h
  • Stripped or unstripped: from readelf -s and nm

4. Analysis scope

  • What question you are trying to answer (examples: "Does this binary perform input validation before processing web form data?" or "Does the authentication function implement constant-time comparison?")
  • What category of finding you expect to find (hardcoded credentials, dangerous function, outdated library, debug interface)
  • What tools you plan to use (Ghidra, radare2, strings, readelf; dynamic analysis if applicable)

5. Prior work

  • One or two prior findings or advisories for this device that you found in public sources (CVE, security blog post, conference talk). These are your benchmark.
  • What you will do differently from the prior work (different binary, different question, your own independent analysis).

The scoping document is 1-2 pages. It is a commitment, not a draft report.

Part 3: Instructor sign-off (15 min)

The instructor checks three things before signing off:

  1. Is the firmware source legal? It must be from the manufacturer's website or a source that has permission to distribute it. Firmware extracted from your own physical device is also acceptable.

  2. Is the target binary appropriate for RE-011? A 50 KB stripped MIPS binary is appropriate. The entire 4 MB kernel is not appropriate for a 14-week RE-011 student.

  3. Is the scope question answerable? "Find a vulnerability" is too broad. "Determine whether the authentication function in httpd performs constant-time string comparison" is specific and answerable.

Students who do not receive sign-off by the end of Week 13 must revise their scoping document. Starting the report without sign-off is how students spend two weeks on analysis that cannot be reported.

Part 4: Lab 6 CrackMe checkpoint (25 min)

Lab 6 is due this week. See labs/lab-6-crackme-checkpoint.md for the full specification.

Lab 6 requires 4+ solved CrackMe challenges documented with technique narrative. "Documented" means your Tool Journal has an entry for each with: what the binary does, what technique revealed the solution (static strings, disassembly of check function, dynamic analysis with strace, etc.), what Ghidra view was most useful, and approximate time spent.

The Lab 6 submission is your Tool Journal pages (or a separate summary document) showing the four entries. The instructor confirms at least four are genuinely analyzed, not just "ran the binary and tried inputs."

Independent practice (~2 hr)

  • Write the scoping document. This is the primary deliverable this week. Follow the structure above. Get it reviewed before the end of Week 13.
  • Begin extraction. Run binwalk on your assigned firmware image. Navigate the extracted filesystem. Run file and readelf -h on your target binary. Import it into Ghidra and run the auto-analyser. This is the start of your capstone work.
  • Lab 6 review. If you have fewer than four documented CrackMes, solve and document them this week. Lab 6 is due this week.

Reflection prompts

  1. Why does the scoping document require a specific question ("Does the authentication function perform constant-time comparison?") rather than a general goal ("find a vulnerability")? What goes wrong when the scope is too broad?

  2. The instructor sign-off gate exists partly to prevent students from spending two weeks analyzing a binary that turns out to be outside RE-011's scope (too complex, wrong architecture for available tools, or a legal problem with the firmware source). What other reasons might justify this gate? Are there situations where a sign-off gate would slow down a working practitioner? How would a professional RE team handle scope without a centralized approver?

  3. By Week 13 you have used at least four or five different tools on each binary you have analyzed (file, xxd, strings, readelf, objdump, Ghidra, radare2). How has your tool selection process changed since Week 1? What determines which tool you reach for first now, versus what determined it in Week 2?

Week 13 of 14. Next: Capstone delivery -- report, oral summary, and bridge to RE-101.