🇫🇷 The Last Resort: Debugging Embedded Systems with Unconventional Methods

### Overview In this presentation, Vincent Lopez, a reverse engineer at Quarkslab, demonstrates how to debug low-level embedded systems when standard hardware debug interfaces like JTAG or SWD are locked down or disabled in production (e.g., via STMicroelectronics RDP or Nordic APPROTECT). When an embedded system pairs a main CPU running an OS like Linux with a microcontroller running bare-metal or RTOS code, firmware update binaries stored on the file system may lack cryptographic signatures or encryption. In such cases, security researchers can patch the firmware image directly to inject an assembly-level debug handler and bridge it to GDB.

### Key Topics - **Production Debug Port Restrictions**: Common hardware debug interfaces (SWD/JTAG) and the proprietary mechanisms used to lock them in production environments. - **Firmware Patching as an Entry Point**: Exploiting unsigned, unencrypted firmware binaries on multi-processor devices to achieve code execution without physical debug headers. - **Exception and Interrupt Handling in ARM Cortex-M**: Leveraging core architecture mechanisms—specifically on the ARMv6-M (Cortex-M0+)—to trap execution via custom handlers. - **Custom Debug Stub Architecture**: Implementing a lightweight communication protocol and breakpoint handler directly in assembly, decoupled from GDB's full Remote Serial Protocol (RSP). - **GDB Server Middleware**: Bridging GDB RSP to the embedded stub via an intermediary server running on the host PC or the main CPU.

### Technical Details The practical demonstration targets an ATSAMD21 microcontroller (ARM Cortex-M0+ core implementing ARMv6-M). Key technical aspects include: - **Exception Vector Hijacking**: While ARMv7-M architectures feature dedicated DebugMonitor exceptions, ARMv6-M triggers a HardFault upon encountering a breakpoint instruction. A custom HardFault handler must therefore be written in assembly to distinguish real faults from intentional software/hardware breakpoints. - **Context Preservation & Handler Structure**: Cortex-M hardware automatically pushes `R0-R3`, `R12`, `LR`, `PC`, and `xPSR` onto the stack during an interrupt. The assembly stub saves remaining general-purpose registers, disables interrupts to avoid re-entrancy, checks the IPSR and return address, and increments the program counter when returning from software breakpoints to prevent infinite loops. - **Self-Modifying Code Optimization**: Due to ARMv6-M instruction set limitations (e.g., lacking broad multi-register push instructions like `STM`), Vincent presents a self-modifying code technique. An instruction such as `MOV R0, R0` is dynamically rewritten in RAM to `MOV R0, RN` based on the requested register index, accompanied by pipeline flush instructions, saving space when reading arbitrary system registers. - **Protocol & Middleware**: Instead of fitting GDB's verbose and complex Remote Serial Protocol directly into constrained microcontroller firmware, the stub uses a minimal custom protocol (a single command byte followed by fixed-size parameters). An external intermediary GDB server—built using the open-source `mini_gdbstub` template—translates standard GDB RSP commands (read/write memory and registers, step, continue, breakpoints) into the microcontroller's custom commands.

### Takeaways - Hardware debug locks can be bypassed purely through software if the firmware update mechanism lacks integrity validation. - Debug stub implementations must be tightly adapted to the target processor architecture's exception model and calling conventions. - A two-tier architecture—a tiny custom assembly stub on the chip paired with an external RSP translator—significantly reduces firmware footprint and complexity compared to embedding a full GDB stub.