Firmware update and boot trust: signed bytes, product binding and rollback

Separate download trust, update authorization, image verification, rollback policy and boot enforcement using local artifacts.

Used in these playbooks#

Setup and security invariant#

Obtain an authentic image and record product/SKU, board revision, SoC revision, firmware version, source and SHA-256. Use an isolated non-root workspace with no device attached for initial review. Prepare an original and disposable copies, the relevant verification code if available, and a recoverable owned lab device only if later needed. The invariant is: only authorized, correctly targeted software at an allowed security version reaches execution.

Separate five gates: who can request an update, how metadata is authenticated, which payload bytes are verified, whether that image fits this product, and what the boot path enforces. TLS does not replace image authenticity. An encrypted package is not automatically signed. OWASP treats update authorization, signature verification and rollback as distinct tests. OWASP firmware update tests

Controlled procedure#

1. Map the container. Identify headers, manifest, payload, signatures and any bootloader/recovery component. Locate verification before extraction, writing and execution. If source is available, follow length and offset calculations using source dataflow. Keep extraction confined because the archive parser is itself exposed to untrusted input.
2. Establish the acceptance baseline. Feed an unchanged vendor image into the actual local verifier, emulator or documented validation-only path. Confirm it accepts the correct product and rejects a genuinely malformed sample. A checker that rejects every file provides no useful security comparison.
3. Change one field or byte. On disposable copies, alter one non-executable payload marker, remove the signature, change a target identifier or alter a signed manifest field. Record both package parsing and signature decisions. Use a vendor-accurate container parser: an arbitrary byte flip that destroys compression only demonstrates malformed-input rejection.
4. Test version policy. Compare an allowed current image with an authentic older signed image that has a known lower security version. Inspect whether the permitted caller can lower the stored security counter or select an alternate recovery path. A lower marketing version is not necessarily a lower security version. Espressif's OTA documentation distinguishes application rollback after failed validation from anti-rollback based on security version. Espressif OTA
5. Inspect execution trust. Map ROM → bootloader → selected application, including alternate slots and recovery. Determine whether an update accepted into storage would still fail at boot. For supported ESP32 revisions, Secure Boot v2 verifies bootloader and application signatures; applicability depends on chip revision and enabled configuration. Espressif Secure Boot v2

Local inspection cheat sheet#

mkdir -p evidence
sha256sum firmware.bin > evidence/firmware.sha256
file firmware.bin > evidence/firmware-format.txt
binwalk firmware.bin > evidence/firmware-layout.txt
rg -n -i 'signature|rollback|secure_version|board_id|verify' ./source

Binwalk's default file argument identifies embedded content; extraction requires a format-appropriate, separately reviewed procedure. These commands do not flash, boot or rewrite firmware. Binwalk README

Create this reusable acceptance matrix before modifying any copy:

Evidence, false positives and completion#

Report precisely where the candidate crosses a boundary: parse acceptance, staging, installation or actual execution. Do not turn acceptance by a standalone inspection tool into a device execution claim. Debug builds, an administrator's explicitly supported downgrade, unsigned non-executable padding and a vendor checksum mismatch alone are common false positives.

• Authentic baseline and every modified copy are hashed.
• Parser rejection and authentication rejection are distinguished.
• Security-version policy and attacker update privilege are stated.
• Boot/recovery enforcement limits the claimed impact appropriately.
• No fuse, bootloader or production-device write was needed for this procedure.

Vulnerability reverse references#

• Firmware verifier accepts unauthenticated protected bytes — The relevant update acceptance path fails to authenticate executable payload or security-relevant metadata correctly.
• Firmware security-version state can be lowered — An attacker can reduce the protected security version and thereby restore software excluded by the anti-rollback policy.
• Firmware verification fails to enforce required product binding — An otherwise authentic image is accepted for an incompatible product or security configuration despite required target restrictions.
• Boot or recovery path executes an unverified component — A reachable boot path omits an authenticity check required by the product’s execution trust model.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity