Hardware interfaces: production debug access and protected data

Distinguish diagnostic output from privileged UART, JTAG/SWD and firmware-secret boundary failures on an owned lab unit.

Used in these playbooks#

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.

Vulnerability reverse references#

• Boot or recovery path executes an unverified component — A reachable boot path omits an authenticity check required by the product’s execution trust model.
• Production UART exposes an unauthenticated privileged console — The in-scope physical access model yields a protected console capability without required authentication.
• On-chip debug interface exposes protected memory or control — A production debug/test interface permits a protected capability beyond the documented physical-access authorization.
• Firmware contains a reusable shared authentication credential — An attacker-accessible firmware artifact embeds a credential that grants protected access, potentially across multiple devices.

Nearby shared procedures#

Proxy normalization, cache isolation, and request boundaries · Libraries and parsers: bounded fuzzing to a minimal reproducer · DNS, TLS and email trust boundaries · Database, cache, queue and management service boundaries · Firmware update and boot trust: signed bytes, product binding and rollback