Breaking Bootloaders on the Cheap

## Overview

Cassie Mesa (Security Researcher, low-level security focus) and David Oswald (Associate Professor, University of Birmingham, hardware attacks specialist) presented bootloader security analysis across three embedded device families, demonstrating that code reader protection can be defeated via software-based attacks using only cheap UART serial cables—no expensive glitching equipment required. Embedded devices implement "code reader protection" (named differently by vendors: RDP, CRP, etc.) at the bootloader level to prevent extraction of sensitive data and encryption keys. The bootloader checks protection levels during initialization and decides whether to allow communication with debug interfaces (UART bootloader commands) or to jump directly to user code. The researchers analyzed STM8 (8-bit), STM32 (ARM-based, 3 protection levels), and NXP LPC1343 (ARM-based, 3 CRP levels). Results: STM8 and STM32 are secure against software attacks; LPC1343 contains a critical vulnerability allowing stack-based return-oriented programming (ROP) to bypass Code Reader Protection Level 1 without hardware glitching.

## Bootloader Architecture and Protection Mechanism

**Bootloader Startup Flow**: When an embedded device initializes or resets, the bootloader (residing in ROM) checks if code reader protection is enabled by reading a protection flag from flash memory at a specific address. If protection is enabled, the bootloader imposes access restrictions and disables dangerous commands (read, write to restricted memory regions). The bootloader then offers two paths: (1) communication mode allowing HCI-style commands to program/read/verify the device, or (2) direct jump to user code. Code reader protection gates which commands are permitted based on protection level.

**Device-Specific Protection Levels**: STM8 implements single binary protection—when enabled, all communication is blocked and bootloader jumps directly to user code, preventing any debug access. STM32 enforces three ascending protection levels at the command-function level; every bootloader command checks the protection level and rejects operations accordingly. Notably, STM32 forbids memory writes even at lowest protection level. NXP LPC1343 implements three CRP (Code Reader Protection) levels: CRP1, CRP2, CRP3 with escalating restrictions. CRP1 (most commonly used by developers due to simplicity) still permits Write-to-RAM commands but with address restrictions—cannot write to addresses <0x300 (where CRP values and bootloader code reside). CRP3 blocks most operations entirely.

**Protection Configuration Storage**: Code reader protection values are stored in flash memory at device-specific addresses (e.g., LPC1343 loads CRP from flash into memory address 0x184 at boot). The bootloader compares this loaded value against protection constants to determine enforcement. This architecture assumes bootloader integrity and correct flash configuration.

## LPC1343 Stack-Based ROP Vulnerability

**Vulnerability Root Cause**: The LPC1343 Write-to-RAM command checks if the target address is less than 0x300 (protecting bootloader and CRP values), but fails to validate whether the address falls within the stack region at the high end of RAM. The RAM layout places CRP values and bootloader data in lower addresses (<0x300) and stack in upper addresses; the check only protects the lower region.

**Stack Manipulation via ROP**: Because LPC1343 allows writes to stack addresses via Write-to-RAM commands, an attacker can craft a ROP (Return-Oriented Programming) chain by: (1) writing gadget addresses to the stack via Write-to-RAM, (2) manipulating stack pointers or invoking stack-resident code, (3) executing arbitrary bootloader functions or accessing protected memory regions. Unlike hardware glitching attacks (which require expensive equipment and can be unreliable), this pure software attack uses only UART communication—a $10 serial cable suffices.

**Comparison to STM32 Security**: STM32's stricter approach of forbidding memory writes entirely at all protection levels prevents this class of attack. By not allowing Write-to-RAM even at lowest protection levels, it eliminates the stack-manipulation vector. In contrast, LPC1343 developers often select CRP1 believing it provides sufficient protection, unaware that the granular restriction (address < 0x300) creates an exploitable boundary condition.