Hardware, IoT, firmware and embedded systems

Open canonical module and reverse references

1. 01Choose contract
2. 02Build harness
3. 03Instrument target
4. 04Fuzz within bounds
5. 05Minimize root cause
6. 06Verify consumer impact

At each step: retain the control → record the observation → continue only while the next boundary is understood.

Choose an attacker-relevant parser contract#

Select a public API and a realistic input boundary: imported image, archive, document, packet, model file, project metadata, or CLI input file. Record who supplies bytes, the consumer's preprocessing, format limits, parser options, and the privilege of the process. Fuzzing an internal helper with impossible arguments may reveal a harness defect rather than a violated library contract.

Keep the first harness narrow: one parse operation, deterministic configuration, fresh state for each input, bounded allocations, and cleanup on both success and failure. Remove network and uncontrolled filesystem side effects. Seed with a few valid, small representative samples to reach deeper code; an all-random corpus may spend every iteration failing the magic-header check.

Harness and build cheat sheet#

The following is a template: product_parser.h, ProductDocument, and the parser functions are placeholders to replace with the target's documented API. Return/error ownership must follow that API. The commands have not been executed here.

#include <cstddef>
#include <cstdint>
#include "product_parser.h"

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
    if (size > 65536) return 0;
    ProductDocument* doc = product_parse(data, size);
    if (doc != nullptr) product_document_free(doc);
    return 0;
}

Build the target library itself with compatible sanitizer and coverage instrumentation; instrumenting only the harness misses much of the parser's behavior. Replace the source list with its reviewed build recipe. The example assumes Clang and a compatible C++ project. AddressSanitizer build guidance.

clang++ -g -O1 -fno-omit-frame-pointer \
  -fsanitize=fuzzer,address,undefined -fno-sanitize-recover=undefined \
  ./fuzz_parser.cc ./parser.cc -o ./fuzz_parser
mkdir -p ./corpus ./artifacts ./evidence
./fuzz_parser ./corpus -max_total_time=120 -timeout=2 \
  -rss_limit_mb=512 -max_len=65536 -artifact_prefix=./artifacts/

Add reviewed seed files before running. libFuzzer's time, input-length, timeout, and RSS settings bound the campaign; they are not a VM resource boundary. Run inside your local disposable environment with external memory/CPU limits appropriate for the workload. Track new coverage and distinct root causes rather than raw executions. libFuzzer reference.

Interpret the failure precisely#

-fno-sanitize-recover=undefined makes the selected UBSan failures terminate instead of allowing a fuzzing run to continue after a diagnostic, which helps preserve reproducible failing inputs. UBSan checks selected undefined behaviors, not every arithmetic error. Unsigned integer wrap is defined in C/C++ and is not part of the default undefined group; choose additional checks when the target's threat model requires them. UndefinedBehaviorSanitizer.

Minimize and verify the consumer#

Copy one candidate into ./artifacts/repro.bin, then minimize with a unique output path. Preserve the original input, toolchain, build flags, revision, and symbolized trace.

./fuzz_parser -timeout=2 -rss_limit_mb=512 ./artifacts/repro.bin
./fuzz_parser -minimize_crash=1 -max_total_time=60 -timeout=2 -rss_limit_mb=512 \
  -exact_artifact_path=./artifacts/minimized.bin ./artifacts/repro.bin

Replay the minimized bytes through a supported consumer in the pinned OSS lab. If the consumer rejects them before calling the library, report the library contract separately and leave consumer exposure unproven. A sanitizer crash is not proof of remote code execution, and its absence in an optimized build does not erase a confirmed memory-safety defect.

Hypothetical root cause: a header count is multiplied into a narrow allocation size, then a wider loop trusts the original count. Preserve the values, allocation site, failing access, and missing bound. The fix should bind accepted count to available input and checked allocation size; merely suppressing the crash is insufficient.

• Public API and ownership contract respected.
• Target code, not only harness, instrumented.
• Resources, seeds, revision, and toolchain recorded.
• Minimal input reproduces the same root cause.
• Normal input succeeds in affected and fixed builds.
• Library impact and real consumer exposure are stated separately.

Replay timeout and memory artifacts under the same resource limits as discovery. A minimized crash must retain the original root cause; a shorter input that fails differently is not equivalent evidence.

Open canonical module and reverse references

1. 01Identify image and board
2. 02Trace acceptance gates
3. 03Compare artifact variants
4. 04Inspect boot and recovery
5. 05Record bounded result

At each step: retain the control → record the observation → continue only while the next boundary is understood.

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.

Open canonical module and reverse references

1. 01Document access model
2. 02Observe baseline
3. 03Classify interface
4. 04Check protected capability
5. 05Confirm production state

At each step: retain the control → record the observation → continue only while the next boundary is understood.

Setup and security invariant#

Record exact retail SKU, board revision, installed firmware, provisioning state and whether the case must be opened. Distinguish unauthenticated nearby access, opened-case access and already privileged administrator access. Use a recoverable owned bench device, its matching documentation and a passive capture first. The invariant is: the documented physical access level does not expose a protected command, memory region or reusable credential without the required authorization.

Use the shared authorization matrix for local service roles and identity/session checks when the device also has app/cloud identities. Network callbacks or downloaded configuration belong in the shared SSRF boundary procedure; permission to inspect a purchased device does not extend to unrelated cloud services.

Controlled procedure#

1. Preserve the retail baseline. Photograph configuration and interface locations without unnecessary serial numbers. Record whether secure boot, flash encryption and debug locks are configured, using read-only vendor diagnostics when available. A development board or previously unlocked unit cannot establish behavior on a locked retail device.
2. Observe UART without transmitting. Verify pinout, ground and logic voltage before connecting a receive-only capture adapter or logic analyzer. Keep transmit and power pins disconnected for passive observation. Record baud/framing from documentation or the capture, startup stage and visible data. Do not assume that an RS-232 adapter and a TTL UART use compatible electrical levels.
3. Classify the capability. Separate boot logs, an authenticated console, an unauthenticated restricted monitor and a privileged shell. A prompt string proves neither interactivity nor privilege. If a console is within the lab scope, use a benign identity query or read a synthetic fixture after documenting why that access should be restricted. Compare logged-out versus correctly authenticated behavior. OWASP's internal-interface tests distinguish exposed functionality and authorization. OWASP internal interfaces
4. Assess JTAG/SWD conservatively. Start from documented lock state and allowed read-only diagnostics. Prove a specific protected capability only on a suitable lab unit; avoid unlock, erase, fuse and flash commands. Finding pads or a debug identifier is weaker than reading a protected synthetic memory region. CWE-1191 specifically covers access control for on-chip debug and test interfaces. CWE-1191
5. Classify recovered secrets. In offline firmware, distinguish public certificates, password hashes, test credentials, per-device private keys and fleet-wide credentials. Compare two authentic owned-device images if available. Demonstrate a candidate credential's function on a local service, with redacted output; do not try it against vendor infrastructure. Installed-firmware review includes exposed authentication material and configuration. OWASP installed firmware
6. Confirm and restore. Reproduce after a supported clean reset if needed and safe for the unit. Record what access survived, what was configured during testing and whether recovery succeeded. State emulation or missing hardware limitations explicitly.

Offline command cheat sheet#

rg -n -i 'login|console|debug|jtag|swd|password|private.key' extracted-rootfs
readelf -hW extracted-rootfs/usr/sbin/example-daemon
readelf -lW extracted-rootfs/usr/sbin/example-daemon
sha256sum evidence/uart-capture.bin

These commands inspect an already extracted filesystem and saved UART capture. Replace the daemon with an identified ELF; readelf is not useful for arbitrary compressed firmware. -h shows the ELF header, -l program headers and -W wide output. GNU readelf

Evidence and completion#

Capture access level, wiring diagram, voltage, tool version, production lifecycle state, before/after decisions and protected capability. A verbose boot log, root access granted to an intended administrator, generic missing hardening, or readable public key is not automatically a vulnerability.

• Retail and debug configurations are distinguished.
• Passive observation precedes any authorized interaction.
• Prompt visibility and protected capability are separate findings.
• Secret classification is supported without exposing usable values.
• No irreversible debug unlock or device write was performed.