Full Report
Das U-Boot - the universal boot loader, is a bootloader for embedded boards for ARM, MIPS and several other processors. This is typically installed early on in the boot process to initialize things components. It has support for an unreal amount of things, such as various drive types, a network and USB stack... U-Boot has an interactive shell that is turned on by default. If enabled on embedded devices, attackers can modify or dump the firmware quite easily. The article contains many ways of doing this, such as using TFTP, over USB or even over serial. Using TFTP, we can boot into a modified file system to backdoor the device. Pretty neat! They mention a tool called DepthCharge as well. This is a tool for jailing U-Boot with a lot of automated information dumping. If you're doing an audit of U-Boot, this appears to be the tool to use. The age-old trick of modifying the init script to be set to /bin/bash did not work. So, instead, they choose to modify the flash memory chip with their own version. They dumped the code, used unsquashfs to unpack the file system, backdoored it, resquashed it and wrote it back. The bootdelay variable is used to determine how long to wait prior to booting into the OS. If this is set to -1 or -2, this check is skipped entirely. Practically, this means that it's not trivial to get into U-Boot shell. To bypass this, a forced error in the reading of flash will drop you into a U-Boot shell - this is called Pin2Pwn. Can we stop this!? You can't. The variables bootdelaykey and bootstopkey are passwords for stopping/delaying autoboot. If you don't know these passwords, then you can't go into the shell (even with a glitch like before). This is simply a plaintext password in an ENV variable. By either reading this from the NVRAM or brute forcing the password, it's still possible to break in. bootstopkeysha256 is similar but a sha256 hash. This begs the question: how do we secure U-Boot? Sign and authentication U-Boot with a secure chain of trust. Disable the autoboot interrupt and the serial console. Ensure that bootargs for Linux are not trivial to modify. Overall, a very in-depth post! I didn't cover everything in my recap since some of it is already in my notes. But, will be a go to article for U-Boot going forward.
Analysis Summary
# Tool/Technique: U-Boot Exploitation & DepthCharge
## Overview
Das U-Boot (Universal Boot Loader) is an open-source, primary bootloader used in embedded systems (ARM, MIPS, etc.) to initialize hardware and boot operating systems. From an offensive perspective, an insecurely configured U-Boot provides an interactive shell that allows attackers to dump firmware, bypass authentication, and backdoor the device's file system or kernel. **DepthCharge** is a specialized security tool designed to automate the discovery and exploitation of these U-Boot environments.
## Technical Details
- **Type**: Tool (DepthCharge) / Technique (Bootloader Exploitation)
- **Platform**: Embedded systems (ARM, MIPS, PowerPC, x86)
- **Capabilities**: Firmware dumping, memory manipulation, environment variable modification, and automated "jailbreaking" of bootloader restrictions.
- **First Seen**: U-Boot has existed since 2002; DepthCharge development/usage gained prominence in hardware security audits in recent years.
## MITRE ATT&CK Mapping
- **[TA0001 - Initial Access]**
- **[T1200 - Hardware Additions]** (Modifying flash chips or physical access)
- **[TA0003 - Persistence]**
- **[T1542.001 - Pre-OS Boot: System Firmware]** (Backdooring the bootloader or OS image)
- **[TA0005 - Defense Evasion]**
- **[T1562.001 - Impair Defenses: Disable or Modify Tools]** (Disabling Secure Boot/Chain of Trust)
- **[TA0009 - Collection]**
- **[T1005 - Data from Local System]** (Dumping firmware/NVRAM)
## Functionality
### Core Capabilities
- **Interactive Shell Access**: Default configuration often allows users to interrupt the boot process to gain a "hush" shell.
- **Firmware Manipulation**: Tools like `unsquashfs` are used to unpack dumped file systems, insert backdoors (e.g., modifying `init` scripts), and repackage them.
- **Boot Parameter Modification**: Changing `bootargs` to gain root access (e.g., changing `init=/bin/sh`).
- **Data Transfer**: Utilizing TFTP, USB, or Serial (UART) to load rogue kernels or file systems into RAM.
### Advanced Features
- **Pin2Pwn (VCC Glitching)**: A hardware technique where an attacker forces an error by shorting a data pin on the flash memory chip during read operations, causing U-Boot to fail its boot sequence and drop into a recovery shell.
- **Credential Brute-forcing**: Automating the guessing of `bootdelaykey` or `bootstopkey` plaintext passwords.
- **DepthCharge Automation**: Automatically identifying memory maps and dumping the entirety of the attached flash storage via the U-Boot console.
## Indicators of Compromise
- **Behavioral Indicators**:
- Periodic interruptions in the boot sequence (indicated by serial logs).
- Presence of non-standard U-Boot environment variables (e.g., `bootdelay` set to high values for testing or specific `bootargs` like `init=/bin/bash`).
- Hardware evidence of "blue-wiring" or clips on Flash/UART pins.
- **Network Indicators**:
- Unauthorized TFTP requests from the device to local/internal IP addresses (e.g., `192.168.1[.]100`).
## Associated Threat Actors
- **Hardware Reverse Engineers**
- **Security Researchers/Auditors**
- **State-sponsored actors** (for persistence on networking/IoT equipment)
## Detection Methods
- **Physical Inspection**: Look for soldered wires on UART headers or evidence of tampering with SPI Flash chips.
- **Console Monitoring**: Log the UART/Serial output during boot; look for "Interrupting autoboot" entries or shell prompts (`=>`).
- **Integrity Checks**: Verify the checksums/hashes of the U-Boot binary and the stored OS images against known-good baselines.
## Mitigation Strategies
- **Secure Boot**: Implement a hardware-based Chain of Trust to verify signatures of U-Boot and the Linux Kernel.
- **Hardening Environment**:
- Set `CONFIG_BOOTDELAY` to 0 or -1 (though note this is bypassable via Pin2Pwn).
- Use `CONFIG_BOOTSTOPKEY_SHA256` to require a hashed password for shell access.
- **Hardware Hardening**: Physically disable UART/JTAG headers by removing pins or filling them with epoxy.
- **Console Lockdown**: Disable the interactive shell entirely in production builds (`CONFIG_CMDLINE` disabled).
## Related Tools/Techniques
- **Flashrom**: Used for reading/writing flash chips directly.
- **Binwalk**: Used for analyzing and extracting firmware images.
- **UART / JTAG**: Physical interfaces used for initial communication.
- **Pin2Pwn**: The specific glitching technique to bypass boot delays.