Exploring USB DFU

Exploring USB DFU

Speakers: Travis Goodspeed, Reverse Engineer

Conference: DistrictCon

YouTube: https://www.youtube.com/watch?v=xYOT58fi2W0

Overview

In this insightful talk from DistrictCon, renowned reverse engineer Travis Goodspeed delves into the intricacies and pervasive vulnerabilities of the USB Device Firmware Update (DFU) protocol. Goodspeed unveils a new tool, dfu-explorer, designed to interact with and exploit DFU-enabled microcontrollers, allowing security researchers and engineers to "rip the firmware out" of devices, a capability often overlooked in a protocol intended solely for flashing new firmware. The presentation highlights how ambiguities and vendor-specific extensions within the DFU "standard" lead to widespread implementation flaws, offering attackers a fertile ground for bypassing readout protection, identifying counterfeit chips, and achieving remote code execution on a vast array of embedded systems.

Goodspeed's work is critical for anyone involved in embedded systems security, manufacturing, or reverse engineering. By exposing the common pitfalls in DFU implementations, he provides a roadmap for both offensive and defensive strategies. For manufacturers, understanding these vulnerabilities is paramount to securing their product lines against intellectual property theft and unauthorized modification. For researchers, dfu-explorer promises to be an invaluable asset for firmware acquisition and security analysis, democratizing access to the internal workings of countless consumer and industrial devices that rely on this ubiquitous, yet often insecure, protocol.

Background

▶ Watch: Introduction to USB DFU and new tool release (0:00)

Travis Goodspeed has a rich history in the embedded security space, with a focus on microcontroller exploitation. His past projects, such as the International Journal of Proof of Concept or Get the Out and his book Microcontroller Exploits, demonstrate a consistent drive to understand and overcome hardware-level protections. He is also the creator of mask ROM tool, a QT6 application for reverse engineering microchip ROM from physical photographs, and good ASM, a symmetric assembler/disassembler designed for rapid implementation of new instruction sets. A notable past achievement is the MD380 tools project, where his team exploited the bootloader of an off-the-shelf push-to-talk ham radio, dumping its firmware and encryption keys. This allowed them to reverse engineer the firmware, replace the Chinese font, and add advanced features like promiscuous mode and a last heard listing with call signs and talk groups, significantly enhancing the radio's functionality for amateur use.

It was during the development of MD380 tools that Goodspeed encountered the frustrations of the USB DFU protocol. Despite knowing how to exploit it, he found himself repeatedly writing "crummy Python code" for each new target. This inefficiency spurred the creation of dfu-explorer, a scriptable Unix command-line tool aimed at streamlining the exploitation process for newly discovered chips.

The problem, as Goodspeed explains, stems from the DFU protocol's nature. While it is a USB standard, its specification is riddled with ambiguities and missing features. Core functionalities like setting a memory address for read/write operations, erasing flash pages, selecting different memory spaces (e.g., RAM, flash, OTP, ROM), or even initiating a reboot are not standard. These crucial capabilities are typically implemented as vendor proprietary extensions. This fragmentation means that each device often has its own unique set of extensions, requiring specific reverse engineering to understand. Furthermore, embedded devices frequently contain multiple DFU implementations—one in the chip's mask ROM and another in a flash application bootloader—each potentially harboring different bugs due to the common practice of forking reference designs without consistent updates. This gives an attacker more options, as a bug in the unpatchable ROM bootloader can be exploited even if the flash-based one is secure.

Goodspeed illustrates the prevalence of DFU in various devices:

• Counterfeit Chips: An APM32 chip, labeled as an STM32, can be identified as counterfeit because its DFU protocol freely reports its true identity over USB. This highlights DFU's potential for supply chain security.
• MD380 Ham Radio: The original target for his DFU exploitation efforts.
• Hot Shoe Camera Flash: A modern device charging via USB-C that enters DFU mode with a secret button combination (holding a specific button while powering on). Goodspeed used DFU to dump its firmware, aiming to add features like a double flash for dual exposures.

These examples underscore DFU's ubiquity across diverse product categories, making its security implications far-reaching.

Key Findings

▶ Watch: DFU: ambiguous 'standard' with missing features (10:30)

Goodspeed’s exploration of USB DFU reveals several critical findings that challenge conventional assumptions about embedded device security:

1. DFU is a Pervasive Attack Surface: Despite its intended purpose for firmware updates, DFU is frequently implemented insecurely, transforming it into a primary vector for extracting firmware, bypassing hardware protections, and achieving arbitrary code execution. The protocol's "sharp edges" and ambiguities lead to inconsistent and often vulnerable implementations across vendors and even within the same device.
2. Firmware Extraction, Not Just Flashing: The core finding is the ability to leverage a protocol designed for downloading firmware into a device to upload firmware out of it. This "readout" capability is crucial for security analysis, intellectual property recovery, and counterfeit detection.
3. Multiple DFU Implementations in One Device: Many microcontrollers, particularly STM32 chips, feature both a ROM-based DFU bootloader and a flash-based application bootloader. This redundancy is a boon for attackers, as they can choose the implementation with the most exploitable vulnerabilities. Crucially, bugs in the ROM-based bootloader are permanent and cannot be patched via firmware updates, requiring expensive chip revisions.
4. Categorization of DFU Vulnerabilities: Goodspeed identifies three primary categories of bugs commonly found in DFU implementations:

• Stability Bugs: Issues that cause device crashes when unexpected inputs (e.g., wrong addresses, invalid sizes) are provided. While seemingly minor, these can be significant for devices with soft power switches and long battery life, as a crash might render the device unusable for an extended period without physical intervention.
• Logic Bugs: Flaws in the protocol's state machine or command handling that subvert intended security measures. These are often subtle and difficult for automated tools to detect.
• Null Pointer Dereferences: A common C programming error that, in the context of microcontrollers without virtual memory, can lead to the unintended leakage of boot memory contents (e.g., bootloader code, encryption keys) by accessing mirrored memory at address 0x0.

1. Counterfeit Detection Capability: The DFU protocol can be leveraged during manufacturing to identify counterfeit chips. Goodspeed cited an instance where an APM32 chip, disguised as an STM32, could be unmasked by querying its DFU descriptors, which accurately reported its true identity. This has significant implications for supply chain integrity.
2. dfu-explorer as a Universal Tool: The release of dfu-explorer provides a standardized, command-line interface for interacting with and exploiting DFU devices. This tool addresses the previous need for custom, often "crummy Python code," making DFU exploitation more accessible and efficient for researchers.

These findings collectively underscore the critical need for robust security audits of DFU implementations in embedded systems and highlight the power of targeted tooling for uncovering deep-seated vulnerabilities.

Technical Deep Dive

▶ Watch: DFU Explorer tool demo: listing and scanning (22:50)

The USB Device Firmware Update (DFU) protocol is a fascinating blend of standardization and vendor-specific improvisation. Goodspeed emphasizes that while it's a USB standard, its ambiguities and missing features necessitate numerous proprietary extensions, making a truly universal DFU client challenging to build without prior knowledge or reverse engineering.

DFU Protocol Mechanics:

1. Entry Modes: Devices enter DFU mode through various mechanisms:

• IO Pin: Many ST Microelectronics chips, like the STM32, use a boot zero pin (BT0) that, when shorted to 3.3 volts during power-up, forces the chip into its ROM-based DFU bootloader.
• Secret Button Combo: As seen with the camera flash, a specific sequence (e.g., holding a button while powering on) can trigger DFU mode.
• USB Alternate Settings: A device initially enumerating as a different USB class (e.g., mass storage) can be commanded by the host to switch to a DFU interface.
• Always On: Some devices, particularly those without strict boot mode requirements, may always expose their DFU interface.

1. Descriptors and Verbs: Devices advertise DFU support through standard USB descriptors. Within the DFU protocol, there are specific "verbs" or commands:

• DETACH: Often causes the device to exit DFU mode and execute the application at the current working address.
• DOWNLOAD: Copies data from the host to the device.
• UPLOAD: Copies data from the device to the host.
• ABORT: Terminates a DFU operation.
• Status Bits and State Machine: The protocol involves a state machine with various status bits to track the operation's progress.

1. Two-Based Addressing: A peculiar aspect of DFU is its block addressing. Unlike common zero-based or one-based indexing, DFU uses two-based addressing.

• Block 0: Reserved for exchanging status information and often contains vendor-proprietary commands.
• Block 1: Goodspeed notes he has "never actually seen" this block used.
• Blocks 2 and up: Used for actual data transfers.
• The actual memory address is calculated as: base_address + (index - 2) block_size. For instance, with a base address of 0x0800C000, a block size of 0x400 (1024 bytes), and an index of 3, the access occurs at 0x0800C000 + (3 - 2) 0x400 = 0x0800C400.

1. Vendor Proprietary Extensions: The standard is notably missing commands for fundamental operations, leading to extensions:

• Setting Base Address: No standard way. ST Microelectronics established a de-facto standard: sending a 5-byte command to block 0. This is widely copied.
• Erasing Pages: Essential for flash memory, but not standard.
• Memory Listing: Providing a list of available memory regions (RAM, Flash, OTP, Boot ROM) is a useful ST Micro extension.
• Rebooting and Selecting Memory Spaces: Also non-standard.

Vulnerability Categories and Exploitation:

Goodspeed categorizes DFU vulnerabilities into three main types, illustrating how dfu-explorer can leverage them:

1. Stability Bugs: Caused by invalid inputs (e.g., reading from an illegal address or with an incorrect size), leading to device crashes. On devices with soft power switches and large batteries (like the camera flash with its 10,000 mAh battery), a crash can leave the device in an unresponsive state for days or even a week until the battery drains, making rapid iteration during exploitation difficult. Goodspeed resorted to physically cutting power traces on his device to enable quick reboots.
2. Logic Bugs: These are flaws in the DFU state machine or command handling.

• STM32F407 DETACH Bug: Early versions of the STM32F407 chip had a security feature requiring a mass erase of flash memory before any read/write operations, intended to prevent counterfeiting. However, a logic bug existed: the DETACH command, which executes the application at the current working address, was not restricted. An attacker could set the working address to a location in RAM containing shellcode and then issue a DETACH command, achieving remote code execution (RCE) without performing the mass erase. This allows dumping firmware via other means (e.g., blinking LEDs and capturing with an oscilloscope). Such bugs are challenging for automated analysis tools to detect.

1. Null Pointer Dereferences: In C, malloc returns 0 on allocation failure. On typical Unix systems, dereferencing 0 causes a segmentation fault. However, in many microcontrollers without virtual memory, address 0x0 is often mirrored or ghosted to the boot memory region (either flash or ROM). If a DFU implementation attempts to read from an uninitialized buffer (which might be at 0x0 if malloc failed) via a DMA transfer, it can inadvertently send the contents of the boot memory.

• MD380 Encryption Key Leak: This vulnerability was critical for the MD380 tools project. A null pointer dereference allowed Goodspeed to dump the raw protected boot memory, revealing an XOR encryption key at address 0x08004AC8. This key was then used to decrypt the device's firmware, enabling full reverse engineering and custom feature development.

dfu-explorer Tooling:

Goodspeed's dfu-explorer is a Unix command-line tool designed to interact with DFU-enabled devices. It runs well on macOS (which has a "better USB stack" than Linux, according to Goodspeed, especially with libusb) and mostly on Linux.

Key commands demonstrated include:

• dfu-explorer -l: Lists all detected DFU devices.
• dfu-explorer -A -H: Automatically connects to the first DFU device and reads a block of data from the default flash memory address, displaying it in hexadecimal.
• dfu-explorer -A -H 0x1FFF0000: Reads a block from a specified address, such as the beginning of ROM.
• dfu-explorer -A --scan-addresses: Scans the entire 32-bit address space to identify valid memory regions (flash, ROM, OTP, SRAM) by observing error responses. This process can take up to 30 minutes for a full scan after quickly identifying common regions.
• dfu-explorer -A --upload-all -x 0x1FFFF000/0x1000 -o dump.bin: Dumps all identified memory regions to dump.bin, excluding specified regions (e.g., option bytes).
• dfu-explorer -A --strings: Dumps all USB indexed strings (UTF-16, potentially region-encoded). These strings can sometimes contain useful metadata, including listings of memory spaces provided by ST Micro-derived code.

Linux libusb Limitation:

A significant practical hurdle for DFU exploitation on Linux and Windows is the libusb library's hardcoded max_control_buffer_length of 4096 bytes (4KB) for control transfers. This means that in a null pointer dereference scenario, where the index is ignored and the base address is 0x0, only 4KB of boot memory can be retrieved at a time. In contrast, macOS's USB stack has no such restriction, allowing dfu-explorer to dump larger chunks, such as the entire 48KB bootloader of the MD380, in a single transfer. This difference highlights how underlying operating system USB stack implementations can impact exploit effectiveness.

Demo / Proof of Concept

▶ Watch: Logic bug exploitation: STM32F407 mass erase bypass (32:00)

While the talk itself doesn't feature a live, interactive "demo" in the traditional sense, Goodspeed effectively demonstrates the capabilities of his dfu-explorer tool through command-line examples accompanied by screenshots of its output. These examples serve as concrete proofs of concept for the DFU exploitation techniques he discusses.

The presentation visually walks through several key functionalities of dfu-explorer:

• Device Listing: Goodspeed shows the output of dfu-explorer -l, which enumerates connected DFU-compatible devices, displaying their vendor and product IDs.
• Hex Dump from Flash and ROM: He demonstrates reading a block of data from a default flash address using dfu-explorer -A -H, then explicitly reads from the beginning of ROM using dfu-explorer -A -H 0x1FFF0000. The output clearly shows hexadecimal bytes, with Goodspeed pointing out characteristic ARM Thumb-2 code patterns (odd pointers, 0x20 prefix for RAM stack pointers) that allow for architectural identification.
• Address Space Scanning: The --scan-addresses command is shown, illustrating how dfu-explorer identifies valid memory regions like flash (0x0800xxxx), mask ROM (0x1FFFxxxx), option memory, and SRAM (0x2000xxxx) by probing addresses and observing error responses. He notes the initial quick identification of common regions, followed by a lengthy full 32-bit address space scan.
• Full Firmware Upload: Goodspeed presents the command --upload-all -x 0x1FFFF000/0x1000 -o dump.bin, explaining how it allows a complete dump of all discoverable memory regions, excluding specific ones, into a binary file for reverse engineering.
• USB String Dumping: The --strings command is demonstrated, showing how dfu-explorer can extract UTF-16 indexed strings from the device, which sometimes include useful memory layout information.

Beyond these tool demonstrations, Goodspeed provides two detailed, conceptual proofs of concept for exploiting DFU vulnerabilities:

1. STM32F407 Logic Bug for RCE: He describes how the DETACH command, when combined with the ability to set the working address, bypasses the mass erase requirement on early STM32F407 chips. By setting the working address to a shellcode payload in RAM and then detaching, an attacker gains remote code execution. This elegantly illustrates how a seemingly innocuous command can be weaponized due to a business logic flaw.
2. MD380 Null Pointer Dereference for Key Extraction: This is presented as a concrete example of how a null pointer dereference can lead to critical data leakage. Goodspeed explains that on the MD380, dereferencing 0x0 accesses mirrored boot memory. He points to the specific address 0x08004AC8 where the device's XOR encryption key was found. The Python code snippet for applying this key to decrypt firmware further solidifies this as a practical, impactful exploit. The discussion also highlights the practical difference between Linux and macOS in this context, where macOS's lack of a 4KB control transfer limit allows for a full 48KB bootloader dump in one go, simplifying the exploit.

These demonstrations and explanations collectively serve as compelling proof that DFU is a vulnerable protocol and that dfu-explorer is a powerful tool for uncovering and exploiting these weaknesses.

Defensive Implications

▶ Watch: Q&A: Other DFU exploitation targets and strategies (42:20)

The vulnerabilities inherent in USB DFU implementations present significant challenges for manufacturers and offer critical insights for defenders. Goodspeed's talk underscores several key areas where security posture can be improved:

1. Rigorous DFU Implementation Audits: Manufacturers must go beyond simply copying reference designs. The ambiguities in the DFU standard mean that custom implementations require thorough security audits. Every vendor-proprietary extension, state transition, and command parameter should be scrutinized for potential logic bugs, buffer overflows, or unintended side effects.
2. Strict Access Control for DFU Commands: Commands like DETACH, SET ADDRESS, ERASE PAGE, and UPLOAD (readout) should not be universally available. Access to these functions must be conditional on the device's security state, potentially requiring authentication, specific hardware fuse settings, or a prior mass erase, as originally intended (but flawed) in the STM32F407.
3. Input Validation and Boundary Checks: To prevent stability bugs and potential memory corruption, DFU implementations must rigorously validate all incoming data:

• Address Ranges: Ensure that requested read/write addresses fall within legitimate, accessible memory regions.
• Block Sizes and Indices: Verify that block sizes are consistent and that indices do not lead to out-of-bounds access.
• Command Parameters: All parameters should be checked against expected values and types.

1. Eliminate Null Pointer Dereferences: Software developers must prioritize robust memory management. All allocated buffers should be initialized, and the return values of malloc or similar allocation functions must be checked to prevent dereferencing NULL (or 0x0). If 0x0 is mirrored to sensitive boot memory, any accidental read from it becomes a critical information leak.
2. Secure Boot and Readout Protection: While not the focus of the DFU protocol itself, robust secure boot mechanisms and hardware-enforced readout protection are crucial. If DFU provides a backdoor to bypass these, their effectiveness is negated. Manufacturers should ensure that readout protection cannot be circumvented by DFU vulnerabilities.
3. Supply Chain Security and Counterfeit Detection: The ability to identify counterfeit chips via DFU (APM32 vs. STM32 example) presents an opportunity for manufacturers to integrate DFU-based checks into their manufacturing lines. This helps ensure that only genuine components are used in their products.
4. Patchable DFU Implementations: For DFU code residing in flash memory, mechanisms for secure over-the-air (OTA) or wired updates should be in place to patch discovered vulnerabilities. ROM-based DFU, being unpatchable, demands even greater scrutiny during the chip design phase.
5. Offensive Security Testing: Integrating tools like dfu-explorer into a security testing regimen can proactively identify DFU vulnerabilities before products ship. Simulating attacker behavior can reveal weaknesses that static analysis or functional testing might miss.

By addressing these defensive implications, manufacturers can significantly harden their embedded devices against the types of DFU-based attacks detailed by Travis Goodspeed, protecting intellectual property and enhancing overall product security.

Key Takeaways

• USB DFU is a widespread, yet often insecure, protocol used in countless embedded devices, ranging from ham radios to camera flashes.
• DFU implementations frequently contain critical vulnerabilities such as stability bugs, exploitable logic flaws, and null pointer dereferences, due to ambiguities in the standard and common developer practices.
• It is possible to "rip the firmware out" of devices using DFU, even though the protocol is designed for flashing, enabling reverse engineering, intellectual property recovery, and security analysis.
• Null pointer dereferences on microcontrollers without virtual memory can leak entire bootloaders or encryption keys by accessing mirrored memory at address 0x0, as demonstrated with the MD380 ham radio.
• The dfu-explorer tool simplifies DFU exploitation, providing a powerful Unix command-line interface for listing devices, dumping memory regions (flash, ROM, SRAM), scanning address spaces, and extracting USB strings.
• Manufacturers must rigorously audit their DFU implementations, validate all inputs, implement strict access controls for sensitive commands, and ensure robust memory handling to prevent these easily exploitable vulnerabilities.

About the Speaker(s)

Travis Goodspeed is a highly respected reverse engineer known for his deep dives into microcontroller security and low-level hardware exploitation. He has made significant contributions to the hacking community through projects like the International Journal of Proof of Concept or Get the Out and his book, Microcontroller Exploits, which teaches how to bypass chip readout protection. His work includes creating specialized tools such as mask ROM tool for reverse engineering from physical chip photographs and good ASM, a symmetric assembler/disassembler for rapid instruction set implementation. Goodspeed is also recognized for leading the MD380 tools project, which successfully exploited a digital push-to-talk ham radio to add advanced features. His early work demonstrated that USB, despite its complex specifications, is fundamentally "just a bus," laying groundwork for understanding its underlying vulnerabilities.