Home / Attacks & tests / Firmware Extracting & Reversing in Penetration Testing
7 test cases
Firmware Extracting & Reversing in Penetration Testing
Firmware testing treats the device's software as the artefact under examination. Obtaining it, reading it, and establishing whether it can be replaced with something the manufacturer did not sign are the three questions, and they determine how much of the rest of the assessment is possible.
What an attacker is trying to achieve
The attacker wants the firmware image, because everything else follows from it: credentials, keys, the update mechanism and the services running on the device. Beyond reading it, they want to write it — a device that accepts unsigned firmware is a device that runs the attacker's code permanently.
Test cases
7 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
IOT-FIRM-01 Firmware Extraction
Objective — Determine whether the device's firmware can be obtained, and by which of the routes available to an attacker.
How it is tested — Attempt retrieval in order of cost: download the published update image; capture an update in transit; read it from the device's own interfaces; and finally read the memory directly. Establish which routes succeed and what each requires, since a firmware obtainable by download is available to everyone while one requiring chip removal is not. Record whether the image obtained is encrypted.
Prerequisites — A device; network access for the update capture; hardware tools where direct memory access is required; authorisation to dismantle.
Indicators — A firmware image published without authentication; an update captured in transit unencrypted; the image readable through a device interface; no protection against direct memory reads.
Coverage — CWE-1263CWE-200
Depth — Manual Physical work on a device; nothing here is reachable from a network scan.
IOT-FIRM-02 Firmware Reversing
Objective — Determine what the firmware discloses once unpacked: credentials, keys, services, and the logic protecting the device.
How it is tested — Identify the image format and unpack the filesystem and any bootloader or kernel components. Enumerate the services configured to start, the accounts present, and the certificates and keys embedded. Search for credentials in configuration and in binaries. Disassemble the application binaries handling network input and authentication, and establish where those functions are actually implemented.
Prerequisites — A firmware image; unpacking and disassembly tooling; where the image is encrypted, the decryption key recovered separately.
Indicators — Credentials or private keys in the image; accounts present that the documentation does not mention; services enabled by default beyond the device's function; authentication implemented in a recoverable way.
Coverage — CWE-798CWE-321
Depth — Hybrid Unpacking and credential scanning automate; understanding the logic requires disassembly.
IOT-FIRM-03 Memory Dumping
Objective — Determine whether the device's storage and memory can be read directly, bypassing whatever the running software would otherwise enforce.
How it is tested — Identify the storage and memory components on the board and the interfaces through which each can be addressed. Attempt to read the flash in place through a programmer or an exposed bus, and where that fails, by removing the component. Establish whether readout protection is enabled on the microcontroller, and whether it can be defeated. Establish whether the contents are encrypted and where that key is held.
Prerequisites — A device that may be dismantled and destroyed; a programmer and probes; component datasheets; authorisation for irreversible work.
Indicators — Flash readable in place; readout protection disabled or bypassable; storage unencrypted; an encryption key held in the same component as the data it protects.
Coverage — CWE-1263CWE-1191
Depth — Manual Requires hardware work on the board itself.
IOT-FIRM-04 Firmware Downgrading
Objective — Determine whether the device can be persuaded to accept and run an older firmware version whose defects have since been fixed.
How it is tested — Obtain firmware versions preceding the current one and offer each to the device through every update route it supports. Establish whether the device compares versions before accepting, and whether that comparison can be defeated by manipulating the version metadata. Where the update is delivered over the network, attempt to serve an older image from a position the device trusts.
Prerequisites — A device; earlier firmware versions; the ability to serve updates from a controlled position; authorisation, since a downgrade may be irreversible.
Indicators — An older firmware accepted and run; version metadata trusted from the image; no anti-rollback mechanism; a downgraded device that cannot be returned to the current version.
Coverage — CWE-1328CWE-494
Depth — Manual Requires obtaining earlier images and a controlled update path.
IOT-FIRM-05 Update Verification Bypass
Objective — Determine whether the device verifies that firmware originates from the manufacturer before installing it.
How it is tested — Modify a legitimate firmware image and offer it to the device through each update route. Establish whether the signature is checked at all, whether it covers the whole image or only a header, and whether the verifying key is held somewhere the attacker can replace. Test whether verification can be skipped by altering metadata, by interrupting the update, or by using a recovery mode that applies weaker checks.
Prerequisites — A device that may be rendered inoperable; a legitimate firmware image to modify; access to every update route including recovery; authorisation.
Indicators — A modified image accepted; a signature covering only part of the image; the verifying key replaceable; recovery mode accepting unsigned firmware.
Coverage — CWE-347CWE-494
Depth — Manual Confirmation risks rendering the device inoperable and is run deliberately.
IOT-FIRM-06 Malicious Update Installation
Objective — Establish, where verification can be bypassed, what an attacker actually gains — whether modified firmware persists and survives recovery.
How it is tested — Build a firmware image with a benign but observable modification and install it through the route found to be weakest. Establish whether it runs, whether it survives a reboot and a factory reset, and whether the device reports its version honestly afterwards. Determine whether the modification could be applied remotely or requires physical access, since that decides the severity entirely.
Prerequisites — A device that may be permanently modified; a working build and packaging process for its firmware; explicit written authorisation.
Indicators — Modified firmware running; persistence across reboot and factory reset; the device reporting an unmodified version; the route exercisable remotely.
Coverage — CWE-494CWE-1326
Depth — Manual The highest-consequence test in the category; run once, on a device designated for it.
IOT-FIRM-07 Reset to Insecure State
Objective — Determine whether resetting the device returns it to a state that is insecure, or leaves data behind that should not survive.
How it is tested — Configure the device fully, then perform every reset the device offers — software reset, hardware button, recovery mode. After each, establish whether it returns to default credentials, whether pairing and network configuration are cleared, and whether previous user data remains in storage. Establish whether reset can be triggered by someone with brief physical access or from the network.
Prerequisites — A configured device with recognisable data; access to every reset mechanism; storage inspection after each reset.
Indicators — Default credentials restored and accepted; previous user data surviving reset; pairing or keys retained; reset triggerable remotely or by brief physical access.
Coverage — CWE-1188CWE-212
Depth — Manual Requires configuring, resetting and then inspecting storage, which is a physical sequence.
What we need from you
Physical possession of at least one device that may be dismantled and, if necessary, destroyed; hardware tools for memory access; the vendor's update files where published; and written authorisation, since this work is irreversible on the unit under test.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- CWE-1263 — Improper Physical Access Control
- CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor
- CWE-798 — Use of Hard-coded Credentials
- CWE-321 — Use of Hard-coded Cryptographic Key
- CWE-1191 — On-Chip Debug and Test Interface With Improper Access Control
- CWE-1328 — Security Version Number Mutable to Older Versions
- CWE-494 — Download of Code Without Integrity Check
- CWE-347 — Improper Verification of Cryptographic Signature
- CWE-1326 — Missing Immutable Root of Trust in Hardware
- CWE-1188 — Initialization of a Resource with an Insecure Default
- CWE-212 — Improper Removal of Sensitive Information Before Storage or Transfer
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.