Home / Attacks & tests / Exposed Debugging Interfaces Security Testing for Embedded & Mobile Devices
5 test cases
Exposed Debugging Interfaces Security Testing for Embedded & Mobile Devices
Hardware debug and programming interfaces exist so the device can be built and serviced, and they are frequently still functional on shipped units. Each is a path to memory, storage or a console that bypasses every control the running software would otherwise apply.
What an attacker is trying to achieve
The attacker with the device in hand wants the shortest route past the software. A live debug port gives memory, firmware and often an authenticated console directly, without any need to find a defect in the code at all.
Test cases
5 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-DBG-01 UART and Serial Console Access
Objective — Determine whether a serial console is present and active, and what it grants to someone who connects to it.
How it is tested — Identify candidate test points on the board and confirm them with a logic analyser, determining the line rate from the captured signal. Connect and observe the boot output, which commonly discloses the bootloader, kernel arguments and the services starting. Establish whether the console offers a shell, whether it is authenticated, and whether the boot process can be interrupted to reach the bootloader.
Prerequisites — An opened device; a serial adapter and logic analyser; the ability to power-cycle while connected.
Indicators — Boot output disclosing configuration and credentials; an unauthenticated shell; a bootloader prompt reachable by interrupting boot; the console accepting input at all.
Coverage — CWE-1191CWE-1244
Depth — Manual Physical probing and signal analysis; nothing about this is reachable without the board.
IOT-DBG-02 JTAG and SWD Access
Objective — Determine whether the processor's debug interface remains enabled, giving direct control of execution and memory.
How it is tested — Identify the debug pads from the board layout and component datasheets, and probe to confirm which are active, since production boards frequently retain the pads while removing the connector. Attempt to attach a debugger and establish whether the interface responds, whether debug authentication is required, and whether readout protection has been set at manufacture. Where the interface is live, establish what it grants: memory read, memory write, halting and single-stepping execution, and extraction of the firmware in full.
Prerequisites — An opened device; a debug probe and adapters; datasheets identifying the debug pins; authorisation for irreversible work.
Indicators — The debug interface responding; no debug authentication; readout protection unset; memory readable or writable; execution haltable.
Coverage — CWE-1191CWE-1263
Depth — Manual Requires probing the board and attaching hardware.
IOT-DBG-03 SPI Flash Access
Objective — Determine whether the external flash holding firmware and configuration can be read or written directly on the bus.
How it is tested — Identify the flash component and its bus, and attach a programmer either in place or after removing the component. Read the contents and establish whether they are encrypted. Attempt to write modified contents and establish whether the device validates them at boot. Capture bus traffic during boot, which reveals what is read and in what order.
Prerequisites — An opened device; a programmer and clip or rework tools; a logic analyser for bus capture; authorisation to remove components.
Indicators — Flash contents readable in place; contents unencrypted; modified contents accepted at boot; secrets visible on the bus during boot.
Coverage — CWE-1263CWE-1191
Depth — Manual Requires hardware attachment to the bus or component removal.
IOT-DBG-04 USB and Exposed Port Interfaces
Objective — Determine what the device's external ports expose beyond their documented purpose.
How it is tested — Enumerate the interfaces the device presents on each external port, including any that appear only in recovery or during boot. Establish whether a console, storage, network or debug interface is presented in addition to the documented function. Where the device acts as a host, test how it handles unexpected devices and malformed descriptors. Establish whether firmware can be loaded through the port.
Prerequisites — A device with external ports; a computer able to enumerate and emulate devices; the ability to observe the device during boot and recovery.
Indicators — A console or storage interface presented on an external port; a debug interface appearing in recovery; firmware loadable through the port; the device mishandling malformed descriptors.
Coverage — CWE-1244CWE-1188
Depth — Hybrid Enumeration automates; the recovery-state and host-mode behaviours have to be provoked deliberately.
IOT-DBG-05 I2C and Peripheral Bus Access
Objective — Determine whether peripheral buses expose components holding secrets or controlling security-relevant behaviour.
How it is tested — Identify the bus lines on the board and enumerate the components responding on each. Establish what each holds — configuration memory, a secure element, sensors, power control — and whether it can be read or written directly. Capture bus traffic during boot and operation to establish whether secrets cross it unprotected, and whether responses from a component can be substituted.
Prerequisites — An opened device; probes and a bus adapter; a logic analyser; datasheets for the components found.
Indicators — Configuration memory readable or writable on the bus; keys crossing the bus unprotected; a component's responses substitutable; security decisions depending on an unauthenticated bus device.
Coverage — CWE-1191CWE-1263
Depth — Manual Requires probing the board and interpreting captured bus traffic.
What we need from you
A device that may be opened and, if necessary, destroyed; probes, a logic analyser and adapters for each interface; component datasheets and board photographs; and written authorisation, since this work leaves visible traces.
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-1191 — On-Chip Debug and Test Interface With Improper Access Control
- CWE-1244 — Internal Asset Exposed to Unsafe Debug Access Level or State
- CWE-1263 — Improper Physical Access Control
- CWE-1188 — Initialization of a Resource with an Insecure Default
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.