courses

Final Project

Weight: 30% of the course grade Proposal due: Friday of Week 5 — 30 October 2026, 23:59:59 Deliverables due: Friday of finals week — 11 December 2026, 23:59:59

Introduction

The five assignments walk you through a complete assessment pipeline one stage at a time, on targets chosen so that each stage works. The final project asks you to do the whole thing yourself, on a target nobody has pre-verified, and to say something defensible about what you found.

Three options are offered. They are genuinely different kinds of work rather than three difficulty levels of the same work, and they are aimed at different audiences:

Project Shape of the work Best fit
A — Device assessment Breadth. Apply the whole pipeline to one real device. CS 410. The default undergraduate choice.
B — Build and break Engineering. Build defences, then attack a peer’s. Either track. Pairs.
C — Fault injection Depth and novelty. Research methodology and evaluation. CS 510. The default graduate choice.

CS 410 students may attempt Project C, and CS 510 students may choose Project A, but in both cases the deliverable is held to the standard of the track you are enrolled in, not the track the project is aimed at. A CS 510 student doing Project A is expected to produce an assessment of professional depth; a CS 410 student doing Project C is expected to produce real results, not just an attempt. Talk to me before choosing across tracks.

Choosing early matters

Project C in particular benefits from being chosen by Week 4, because the glitching hardware is limited, bench time has to be scheduled, and a literature review is not something to start in Week 9. Projects A and B are safe to commit to at the Week 5 proposal deadline.

Proposal (required, all projects)

Due end of Week 5. One to two pages in final/proposal.md, covering:

  1. Which project you are doing, and for Project B, who your partner is.
  2. Your target — the specific device, or for Project B the specific platform and defence goals.
  3. What you expect to find, stated as something that could turn out wrong.
  4. Your fallback if the primary approach fails. This is not optional and it is graded. Hardware projects fail for reasons outside your control — a locked debug port, a potted module, a dead board — and the plan for that is part of the work.
  5. What you need from the course: hardware to sign out, bench time, a target device from the course stock.

I will return comments within a week. An approved proposal is a commitment; if you need to change targets after approval, tell me rather than discovering it in the final report.

Project A — Full device assessment (undergraduate track)

Aimed at CS 410. This is the project that most closely resembles what a junior consultant actually does.

Take one real consumer IoT device — not the course platform — and assess it end to end using the OWASP IoT Security Testing Guide device model as your structure. Course stock includes a selection of routers, cameras, smart plugs, and sensors; you may also propose a device you own.

What you do

Work every stage the course covered, and report what you found at each, including the stages that yielded nothing:

  1. Reconnaissance. Teardown, chip identification, FCC filing review, vendor documentation, existing published research on the device or its SoC.
  2. Interfaces. UART, I2C, SPI, JTAG/SWD. What is exposed, what is locked.
  3. Firmware. Extraction by whatever path works — download, console, flash read. Filesystem analysis, credential hunting, version inventory.
  4. Network and radio. Traffic capture, service enumeration, update mechanism analysis, and whatever the device’s radios do.
  5. Reverse engineering. At least one binary analyzed to the depth of HW #5 Task 3.
  6. Evaluation against a baseline. Assess the device against ETSI EN 303 645 or NIST IR 8259A. Which provisions does it meet, which does it fail, and which do not apply?

A stage that produced nothing is a result. “Debug port present but locked; I confirmed lockout by X and did not pursue fault injection” is a finding about the device’s security posture, and it is worth reporting.

Deliverables

What distinguishes a strong submission

Depth on something. A report that lists twelve superficial findings is weaker than one that lists four and takes one of them all the way down to the instruction that causes it. Severity ratings that are justified rather than asserted. And honesty about limits — what you could not test, and why.

Project B — Build and break a defensible device (either track)

Suitable for either track. Done in pairs, and the pairing is structural: you build a defended device, your partner attacks it, and you attack theirs.

The pedagogical claim being tested here is that you do not really understand a defence until someone competent has tried to get past it.

Phase 1 — Build (Weeks 5–8)

Using the course Feather platform, design and implement a device with a defensible security posture. Required properties:

  1. Authenticated, replay-resistant radio protocol. Build on your HW #4 Task 4 defence, hardened. Must survive receiver reboot, message loss, and reordering.
  2. Confidentiality where it is warranted. Justify what you encrypt and what you do not — encrypting everything is a design decision with costs, not an automatic win.
  3. Authenticated firmware update. Any update path must verify authenticity before accepting. You may implement signature verification or a MAC-based scheme; justify the choice.
  4. A documented key management story. Where do keys live, how are they provisioned, what happens when one is compromised, and what does an attacker with physical access to one device learn about the others?
  5. A written threat model stating what you defend against and — equally important — what you explicitly do not. See Threat Modeling.

Phase 2 — Break (Weeks 9–10)

Exchange devices with your partner. You get the hardware and the threat model, but not the source code — this is grey-box, matching the position of a real attacker who can buy the product and read the marketing.

Attack it. Everything in the course is fair: RF capture and replay, bus sniffing, flash extraction, glitching if you have the hardware and approval. Document every attempt, successful or not.

Deliverables

A note on grading pairs

You are graded individually. Your build, your attack report, and your response document are yours. A partner whose device proves weak does not lower your grade — a thorough attack report on a weak device is a better deliverable than a thin one on a strong device. Conversely, “I could not break it” earns full credit if the attempts are documented and competent, and no credit if they are not.

Project C — Fault injection and glitching (graduate track)

Aimed at CS 510. This is the research-shaped option, and the one with real methodological demands.

Fault injection deliberately induces hardware faults — voltage glitches, clock glitches, electromagnetic pulses — to make a processor skip or corrupt an instruction at a chosen moment. It defeats software checks that are otherwise sound, which is what makes it the standard answer to a locked debug port or a signature verification you cannot reverse.

The course kit includes a ChipWhisperer Lite and a Faultier.

Scope options

Choose one, or propose your own:

Research requirements

This option is graded as research, which means:

  1. Literature review. Minimum eight peer-reviewed or equivalent-quality sources. Situate your work: what has been done, what has not, where yours sits. Venues to draw from include USENIX Security and WOOT, CHES, IEEE S&P, ACM CCS, and NDSS.
  2. A stated methodology, written before you collect data, specifying what you will vary, what you will measure, and what result would count as success or failure.
  3. Quantitative evaluation. Success rates across trials, not anecdotes. A glitch that worked once is a story; a glitch that works 3.2% of the time across 10,000 attempts at a characterized parameter set is a result.
  4. Honest negative results. A well-executed attempt that did not succeed is publishable-grade work if the methodology is sound and the negative result is characterized. It is graded as such here. What is not acceptable is an uncharacterized failure — “I tried some settings and nothing happened.”
  5. Threats to validity. What could make your conclusion wrong? Sample size, device-to-device variation, environmental factors, measurement error.

Deliverables

Presentation requirements

All three projects require a recorded presentation. Record a screen capture with voice-over — OBS Studio is free and works well.

Grading

The final project is 30% of the course grade, distributed as follows:

Component Points
Proposal (Week 5), including the fallback plan 10
Technical execution — depth, correctness, and rigor of the work 35
Written deliverable — report, design documents, or paper 30
Presentation — content, clarity, and delivery 20
Notebook and commit history showing work over time 5
Total 100

Graduate submissions are held to a higher standard within the same rubric, principally on the technical execution and written deliverable components. Concretely, for CS 510: claims require evidence, evaluation requires numbers, and related work must be engaged with rather than listed.

What earns full marks on technical execution

Academic integrity

Prior work on your target is often extensive — use it, and cite it. Building on published research is normal and expected; presenting it as your own discovery is misconduct. If someone has already extracted firmware from your device and written it up, cite them, then go further.

Tools are tools. Using binwalk, Ghidra, an LLM, or anyone’s published script is fine and expected. Representing tool output as your own analysis without verifying it is not, and it tends to be self-punishing — a decompiler’s misinterpretation restated confidently in a report is exactly the kind of error these projects are designed to surface.

See the academic misconduct policy on the course home page.

References

Related course pages: Schedule · Course home · HW #4 · HW #5 · Threat Modeling · Technical Writing

🛠️ Maintenance note: Project A depends on course-stock target devices — refresh the pool periodically, since a device that has been assessed by three previous cohorts has published student writeups circulating. Project C depends on glitching hardware availability; confirm the ChipWhisperer and Faultier are functional and that the target part still ships with the protection mechanism the exercise assumes. Conference paper templates and the ETSI/NIST document versions should be re-checked each offering.