HW 3: Firmware Extraction

Covers: Weeks 5–6 Due: Friday of Week 6 — 6 November 2026, 23:59:59 Points: 100

• HW 3: Firmware Extraction
  • Introduction
  • Part A — Extraction from flash
    • Task 1 — Dump the flash
    • Task 2 — Map the image
    • Task 3 — Entropy analysis
    • Task 4 — Extract and explore the filesystem
  • Part B — Extraction from the wire
    • Task 5 — Recover firmware from a packet capture
  • Submission
  • Grading
  • Note on binwalk versions
  • References

Introduction

Everything so far has been preparation for this. You identified the flash in HW #2; now you read it, and turn 16 MiB of undifferentiated bytes into a filesystem you can browse.

You will extract firmware two ways: off the chip, and off the wire. The two paths produce different artifacts and have different prerequisites, and knowing which to reach for is a large part of doing this work efficiently. The wire path requires no physical access at all — which is precisely why vendors should worry about it more than they do.

⚠️ Run extraction in a container or throwaway VM. binwalk -e invokes external extractors on attacker-controlled data. That is remote code execution waiting to happen, pointed at a file you pulled off a device you do not trust. The course provides a container image; use it. Extracting hostile firmware on your daily driver is the kind of mistake you only make once.

Part A — Extraction from flash

Task 1 — Dump the flash

25 points.

Which technique applies depends on where your target keeps its firmware, and establishing that is part of the task.

• Internal flash, on a microcontroller with a debug port: read it out over SWD or JTAG using the access you established in HW #2 Task 4. For an STM32 target that is st-flash read dump.bin 0x08000000 <size>, or the equivalent OpenOCD dump_image. No clip, no desoldering, no bus contention. Determine <size> from your own device — st-info --probe reports its flash size, and so does the boot log — rather than copying a length out of a tutorial.
• External SPI flash, in a separate package beside the SoC: read it in-circuit with a SOIC-8 clip and a flashrom-supported programmer.

1. State which case your target is, and give your evidence — the JEDEC ID from HW #2 Task 2, the debug port result from Task 4, and what you saw physically on the board. If those disagree, that disagreement is itself worth reporting.
2. Dump the flash by whichever route applies. Record the exact command line.
3. If you took the external route and in-circuit reading fails, apply the contention remedies from HW #2 Task 3 and document what you tried, in order. Desoldering is permitted with instructor approval — ask before you reach for hot air.

4. Dump the flash at least twice and compare the images:

   $ sha256sum dump1.bin dump2.bin
   

   Report whether they match. If they do not, your read is unreliable — do not proceed until you understand why. Common causes are a marginal clip connection, a running SoC contending for the bus, or clock rate set too high.

5. Verify the dump is real rather than an artifact: report the file size and confirm it matches the part’s documented capacity. Include a hex dump of the first 64 bytes, and say what the first two 32-bit words are. On a Cortex-M target they are not arbitrary — you will need both again in HW #5 Task 1.

Include the SHA-256 of your final image in your notebook. It is the identifier you will reference in HW #5.

Task 2 — Map the image

20 points.

1. Run binwalk against your dump and include the complete output.
2. Produce a table of the image layout: for each identified region, give the offset, size, type, and what it is. Account for every byte — including regions binwalk did not identify. Unidentified regions are findings, not gaps in your work.
3. Cross-reference this layout against the partition table you recovered from the boot log in HW #1 Task 4. Do they agree? Explain any discrepancy.

Task 3 — Entropy analysis

15 points.

1. Generate an entropy plot of your dump and include it.
2. Annotate the plot: mark the regions you identified in Task 2 and state which entropy signature each exhibits, using the interpretation table from Week 5.
3. Your dump contains three regions above 0.99 entropy. Report each measurement to four decimal places and state whether the numbers alone let you tell compressed data from encrypted data. They will not — on the course target all three agree to three decimal places — and saying so is the correct answer. A submission claiming the entropy value settles it loses the points.
4. Now settle it by other means. For each high-entropy region, apply the three discriminators from Week 5: is there a header, does a decompressor accept it, and what do the edges look like? Show the command output that decides each case.
5. Having identified the genuinely encrypted region: where must the decryption key live, given that the device itself has to decrypt at boot? List the candidate locations in the order you would investigate them.

Task 4 — Extract and explore the filesystem

20 points.

1. Extract the filesystem. Record the command and the resulting directory tree at depth 2.
2. Report the filesystem type, its compression, and its mount point per the init scripts.
3. Find and report at least four of the following, quoting the file and line. If one genuinely is not present, say so and show how you searched:
   1. User accounts and password hashes.
   2. A hardcoded credential, key, or certificate.
   3. A hostname or URL the device contacts.
   4. A network service that starts at boot.
   5. A version string for a third-party component with a known CVE.
4. For one password hash you find, identify the hash algorithm and state which hashcat mode would attack it. Do not actually crack it — identification only. See the hash cracking page for the identification method.

Part B — Extraction from the wire

Task 5 — Recover firmware from a packet capture

20 points.

The capture is ota-update.pcap: an AL-2100 checking for updates and downloading a new firmware image. Your job is to reconstruct that image from the capture alone, without touching the device.

This is a real capture taken across a lossy link, so it contains retransmissions, duplicates, and out-of-order segments. That is normal for a device updating over a marginal connection, and it is your problem to deal with.

1. Open the capture in Wireshark. Use conversation statistics to find the bulk transfer — tshark -z conv,tcp ranks by bytes and finds it in one command. Show your working.
2. Identify the protocol carrying the firmware and the endpoint it came from. There are two requests in this capture; say what each one is for.
3. Export the firmware image from the capture. Document the method — object export, stream follow, or manual carving with the tools on the pcap tools page.

4. Verify your extraction: run binwalk against the recovered image and show that it identifies a valid structure. A truncated or misaligned carve produces a file that binwalk reports nothing at all about, which is the point of doing this check.

   ⚠️ If your carve comes out far smaller than the size the server advertised, the problem is not your carving method — it is that your tool gave up partway through reassembling the stream. Work out why, and what you can tell it to do about it. The answer is a setting, and the tcp.analysis.* display filters will point you at the cause.

5. Assess the update mechanism itself and report on each:
   1. Was the transfer encrypted in transit?
   2. Was the image signed, and can you tell from the capture alone? The update metadata carries an integrity value — say whether that is the same thing as a signature, and why it matters here.
   3. Could an attacker positioned on the network have substituted a different image? Justify your answer from evidence in the capture.
6. Compare the image you recovered here against the one you dumped in Part A. They are not the same build. Report three differences that matter for security, and for each say whether the newer image is better, worse, or unchanged. At least one of the three should be something the vendor did not change.

Item 5 is the actual security finding. Items 1–4 are how you earn the right to make it.

Submission

Commit hw3/hw3.md and supporting artifacts to your repository.

Do not commit the firmware images themselves. They are large, and some course targets carry redistribution restrictions. Commit the SHA-256 hashes, the binwalk output, the entropy plot, and your analysis. If an instructor needs to verify a claim against your image, they will ask.

Grading

Note on binwalk versions

binwalk v3 is a complete rewrite in Rust and its command-line interface differs from the v2.x Python tool that most online tutorials describe. Notably, extraction output paths and several flags changed. Check binwalk --help against whatever tutorial you are following, and state in your notebook which version you used. Per the verify-before-you-cite principle, a command copied from a blog post without checking it against your installed version is how you lose an afternoon.

References

• binwalk (v3, Rust) — https://github.com/ReFirmLabs/binwalk
• flashrom — https://www.flashrom.org/
• OWASP Firmware Security Testing Methodology — https://github.com/scriptingxss/owasp-fstm
• OWASP IoTGoat, deliberately vulnerable firmware — https://github.com/OWASP/IoTGoat
• Squashfs documentation — https://docs.kernel.org/filesystems/squashfs.html
• Wireshark User’s Guide, Export Objects — https://www.wireshark.org/docs/wsug_html_chunked/ChIOExportSection.html#ChIOExportObjectsDialog
• hashcat example hashes (mode identification) — https://hashcat.net/wiki/doku.php?id=example_hashes
• NIST National Vulnerability Database — https://nvd.nist.gov/

Related course pages: Schedule · HW #2 · HW #5 · Wireshark · Pcap Tools · Network Traffic Capture

🛠️ Maintenance note: binwalk v3’s CLI is still evolving; re-verify the commands in this assignment each term. The Part B packet capture is course-provided — regenerate it if the reference device’s update endpoint changes, and keep an archived copy so the assignment does not depend on a live vendor service.