Bluetooth Headphone Jacking: A Key to Your Phone

Bluetooth Headphone Jacking: A Key to Your Phone

Speakers: Dennis Heinze, Penetration Tester, ERW; Frieder Steinmetz, Penetration Tester, ERW

Conference: 39C3

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

Overview

In this compelling talk, "Bluetooth Headphone Jacking: A Key to Your Phone," Dennis Heinze and Frieder Steinmetz from ERW, a German security company, unveil a critical vulnerability ecosystem affecting a vast array of Bluetooth audio devices. Their research, initially focused on the theoretical aspects of Bluetooth's Oracast feature, pivoted to practical implementation analysis, leading to the discovery of a widespread security flaw in Bluetooth System-on-Chips (SOCs) from a Taiwanese vendor, Aroa. This presentation details how unauthenticated access to a proprietary protocol on these devices can compromise user privacy, enable eavesdropping, and even facilitate account hijacking on connected smartphones.

The talk highlights a significant shift in the cybersecurity landscape, where hardened smartphone platforms are increasingly secure, pushing attackers to target less protected peripherals. Heinze and Steinmetz demonstrate how seemingly innocuous Bluetooth headphones, when vulnerable, can become a gateway to sensitive personal data and services on a user's phone. Their findings underscore the urgent need for comprehensive security assessments in the IoT and embedded systems space, particularly for devices that maintain cryptographic bonds with primary communication devices like smartphones.

The implications of this research are far-reaching, impacting numerous popular headphone brands that integrate Aroa SOCs. The speakers not only dissect the technical mechanisms of the vulnerabilities but also provide a candid account of the disclosure process, revealing the complexities of coordinating fixes across a fragmented supply chain. Ultimately, the talk serves as a stark reminder that the security of our personal devices is only as strong as its weakest link, often residing in the peripherals we connect and trust implicitly.

Background

▶ Watch: Introduction to Bluetooth headphone security research (0:00)

The journey into "Bluetooth Headphone Jacking" began as a continuation of previous research presented at 38C3, which focused on the theoretical aspects of Bluetooth's Oracast feature for audio broadcasting. The speakers, Dennis Heinze and Frieder Steinmetz, felt the need to move beyond specification analysis and investigate real-world implementations. Their initial target was a randomly chosen Oracast-compatible transmitter and a pair of matching headphones from a Taiwanese vendor. The primary goal was to reverse engineer the firmware of these devices to understand their internal workings.

The first step involved obtaining the firmware. For the transmitter, a firmware update file was conveniently available on the vendor's website. Initial analysis of this file revealed a header followed by what appeared to be compressed or encrypted data, making direct unpacking challenging. This led the researchers to adopt a dynamic analysis approach, focusing on a Windows configuration tool used to manage the transmitter via USB. By sniffing the USB traffic with Wireshark while interacting with the tool, they discovered that USB HID (Human Interface Device) was being used as a generic transport for a custom vendor protocol. This is a common practice for embedded devices to communicate with host systems. Crucially, configuration messages were observed in cleartext, indicating an unencrypted protocol. Further analysis of firmware update traffic revealed that the binary data was simply chunks of the firmware update file, transmitted with an incrementing value that corresponded to memory addresses, suggesting a direct memory write mechanism.

This understanding allowed them to identify command IDs, notably 0x402 for flash write and 0x401 for flash read. A serendipitous discovery of an existing unpacking tool for similar firmware images greatly aided their efforts, enabling them to load the firmware into Ghidra for static analysis. This combination of dynamic and static analysis allowed them to re-implement the flash read command, successfully dumping the firmware from the transmitter, and, significantly, from the headphones for which no firmware was publicly available.

Hooked by these discoveries, the research expanded beyond Oracast, focusing instead on the capabilities of this newly understood protocol. A key question arose: do these vulnerabilities extend to more widely used, "prestigious" devices? Opening the initial transmitter and headphones revealed that both were powered by an Aroa System-on-Chip (SOC), a Taiwanese vendor specializing in Bluetooth audio SOCs, known for their SDKs and reference implementations. This led to a broader investigation into devices using Aroa chips. Through Google searches, tear-down websites like 52audio.com, and even AirPod replica communities, the researchers identified numerous popular brands, including Sony, Marshall, Jabra, JBL, Biodynamic, and Bose, that utilize Aroa SOCs in some of their products.

However, many of these "prestigious" devices did not expose the proprietary protocol over USB. This prompted the researchers to investigate how these devices are configured and updated, leading them to analyze companion mobile applications. Decompiling Android apps revealed that the same proprietary protocol, which they named "Race" (acronym unknown), was also implemented over Bluetooth, specifically Bluetooth Classic and Bluetooth Low Energy (BLE). The apps provided valuable symbolic information, including names for many of the Race commands.

To fully understand the Bluetooth-based implementation of Race, a brief overview of Bluetooth classic and BLE was necessary. Bluetooth Classic is designed for high data throughput, primarily for audio, and uses fixed, static addresses. Devices are typically only discoverable when in pairing mode. Bluetooth Low Energy (BLE), on the other hand, prioritizes energy efficiency, uses both fixed public addresses and periodically changing random addresses (for privacy), and devices constantly advertise their presence. For custom protocols, Bluetooth Classic often employs RFCOMM (emulating a serial interface, discoverable via UUIDs through SDP), while BLE typically uses GATT (Generic Attribute Profile), a hierarchical structure of services and characteristics, also discoverable by UUIDs. The Race protocol was found to leverage both RFCOMM and GATT for its Bluetooth communications.

Key Findings

▶ Watch: Sniffing USB HID traffic for custom protocols (3:30)

The research uncovered a critical and widespread vulnerability ecosystem stemming from the unauthenticated "Race" protocol implemented on Aroa Bluetooth SOCs. The core findings can be summarized as follows:

1. Widespread Vulnerability in Aroa SOCs: A significant number of popular Bluetooth headphone and earbud brands, including Sony, Marshall, Jabra, JBL, Biodynamic, and Bose, utilize Aroa SOCs. This means that vulnerabilities discovered in the underlying chip affect a broad spectrum of consumer devices, extending far beyond the initial generic test devices.

1. Unauthenticated "Race" Protocol: The proprietary "Race" protocol, used for device configuration and firmware updates, was found to be accessible without any authentication over both Bluetooth Classic (via RFCOMM) and Bluetooth Low Energy (BLE) (via GATT). This fundamental lack of authentication is the root cause of most subsequent vulnerabilities.

1. Powerful Protocol Capabilities: The "Race" protocol offers extensive capabilities that are highly dangerous when exposed without authentication. These include:

• Read/Write Flash Memory: Attackers can dump entire firmware images or sensitive configuration data. While writing to flash is limited, it could potentially be abused.
• Read/Write RAM: Access to RAM allows for reading runtime data (e.g., currently playing audio metadata) and, critically, writing to arbitrary memory addresses, including peripheral registers, opening doors for code injection.
• Firmware Update Operations: While the researchers did not weaponize this, the capability to initiate and control firmware updates without authentication is a severe risk.
• Query Bluetooth Classic Device Address: This allows an attacker to discover the static Bluetooth address of the target headphones, crucial for impersonation attacks.
• Read Build Version: Useful for fingerprinting devices and identifying specific firmware versions.

1. Extraction of Sensitive Data: Due to the unauthenticated flash read capability, attackers can extract highly sensitive configuration data, including:

• Connection Tables: These tables store information about previously paired devices, including their Bluetooth Classic addresses and, most critically, the Bluetooth Link Key (BT_LinkKey).
• Bluetooth Link Keys: The link key is a shared secret established during pairing, forming the cryptographic bond between a headphone and a smartphone. Stealing this key allows an attacker to impersonate the headphones to the paired smartphone.
• Smartphone Bluetooth Addresses: The addresses of paired smartphones are also stored, providing targets for impersonation.

1. Three CVEs Assigned: The researchers identified three distinct vulnerability categories, which were assigned CVEs:

• Broken Pairing with Bluetooth Classic: Specific issues related to how pairing is handled or bypassed in Bluetooth Classic.
• Broken Pairing with Bluetooth Low Energy: Similar issues affecting BLE connections.
• Race Protocol Vulnerability: The core issue of the powerful, unauthenticated "Race" protocol itself. While some vendors (e.g., Jabra) had fixed the pairing issues, the Race protocol vulnerability remained prevalent across many devices.

1. Pivoting to Smartphone Compromise: The most significant finding is the ability to leverage the stolen link key to impersonate the headphones to a paired smartphone. This enables powerful attacks via the Bluetooth Hands-Free Profile (HFP), including:

• Call Control: Answering, rejecting, ending, and even dialing calls.
• Audio Routing: Intercepting audio streams, including incoming calls.
• Access to Subscriber Number: Querying the phone's own number.
• Voice Assistant Triggering: Interacting with Siri or Google Assistant.

This impersonation allows for WhatsApp account hijacking by intercepting verification calls and Amazon account takeover by routing verification codes via the compromised WhatsApp.

Technical Deep Dive

▶ Watch: Uncovering firmware update chunks and memory addresses (4:30)

The technical foundation of these vulnerabilities lies in the reverse-engineered Race protocol and its unauthenticated exposure over various transports.

The initial breakthrough came from analyzing the USB HID traffic. USB HID, typically for human interface devices, was repurposed as a generic transport for a custom vendor protocol. By observing configuration changes, the researchers noted cleartext messages, indicating a lack of encryption. Firmware updates, however, contained binary data. Closer inspection revealed these were direct chunks of the firmware file, accompanied by an incrementing value. This value, upon comparison with the firmware file structure, was identified as a memory address offset. This confirmed a direct memory access mechanism for firmware updates. Command IDs, such as 0x402 (flash write) and 0x401 (flash read), were identified by their consistent presence in specific message types, interpreted in little-endian format. This allowed the creation of a tool to dump flash memory directly via USB HID.

Once the firmware was unpacked using an existing tool and loaded into Ghidra, the researchers could map the observed USB messages to specific functions within the firmware. A key discovery was a switch-case statement handling various command IDs, including command_write_flash and command_read_flash. This confirmed the direct memory manipulation capabilities.

The Race protocol itself has a simple structure:

• Header (1 byte): Typically 0x5A for requests and 0x5B for responses (or 0x05 for firmware updates).
• Type (1 byte): Indicates request or response.
• Length (2 bytes): The total length of the message payload.
• Command ID (2 bytes): Identifies the specific operation (e.g., flash read, get build version).
• Payload (variable length): The content of the message, specific to the Command ID.

For instance, a Flash Read command's payload includes:

• Type byte: Specifies whether to read from internal or external flash.
• Num: The number of flash pages to read (not individual bytes).
• Address: The starting memory address for the read operation.

In contrast, a Get Build Version command has no payload, as its Command ID alone triggers the response containing the firmware's build information.

The Race protocol's capabilities, accessible without authentication, are extensive:

• Read Flash: Dump entire firmware images, bootloaders, and crucially, configuration partitions.
• Write Flash: Limited write capabilities were observed, primarily for firmware updates, but the potential for malicious modification exists.
• Read/Write RAM: This is particularly dangerous on small ARM Cortex-M4 microcontrollers, where RAM often maps directly to peripheral registers. Writing to RAM can manipulate hardware state or even inject code into executable memory regions.
• Firmware Update Operations: Complete control over the device's firmware update process.
• Query Bluetooth Classic Device Address: Essential for impersonation attacks.
• Read Build Version: For device fingerprinting.

The Race protocol is exposed over two primary Bluetooth transports:

• Bluetooth Classic - RFCOMM: This protocol emulates a serial interface. Channels are identified by numbers, which can be discovered using their UUIDs via the Service Discovery Protocol (SDP). Each vendor using Aroa SOCs typically employs a slightly different, vendor-specific UUID for their Race RFCOMM channel.
• Bluetooth Low Energy (BLE) - GATT: GATT defines a hierarchical structure of services and characteristics. Characteristics act as communication channels that can be read from, written to, or subscribed to for notifications. These are also identified by UUIDs. For Race over GATT, two main UUIDs were observed: a general Aroa upstream UUID and a Sony-specific UUID.

The most impactful attack vector leverages the Bluetooth Link Key. During the initial pairing process between a Bluetooth device (e.g., headphones) and a host (e.g., smartphone), a shared secret called the link key is established. This cryptographic bond is fundamental for mutual authentication and encryption of subsequent communication. The researchers discovered that this link key, along with the Bluetooth Classic address of the paired smartphone, is stored unencrypted in a configuration partition (often named NVDM) within the headphone's flash memory.

By dumping this NVDM partition via the unauthenticated Race protocol over BLE (which does not disrupt the ongoing audio connection), an attacker can extract:

1. The headphone's own Bluetooth Classic address.
2. The smartphone's Bluetooth Classic address.
3. The shared Bluetooth Link Key.

With these three pieces of information, an attacker can then impersonate the headphones to the smartphone. This is achieved by using a Bluetooth controller that allows its address to be spoofed (e.g., certain CSR controllers) and providing the stolen link key to a Bluetooth host stack (e.g., BTS Stack). The smartphone, believing it is communicating with its legitimate paired headphones, will establish a connection, including support for the Hands-Free Profile (HFP).

The HFP is a set of protocols defining how a hands-free device (like headphones) interacts with a phone. Through HFP, the impersonating attacker gains extensive control:

• Call Control: Answer, reject, end, or dial calls.
• Audio Routing: Route incoming call audio to the attacker's device.
• Caller Information: Access to who is calling.
• Network Information: Operator name, and critically, the subscriber number (the phone's own number).
• Voice Assistant Trigger: Activate Siri or Google Assistant.
• Limited phonebook access (though requiring permissions).

This sophisticated technical chain, from unauthenticated protocol access to link key exfiltration and HFP impersonation, forms the basis for the severe attacks demonstrated.

Demo / Proof of Concept

▶ Watch: Reverse engineering flash read and write functions (7:00)

The speakers conducted a series of live demonstrations, showcasing the capabilities of their custom tooling and the severe implications of the discovered vulnerabilities. The demos involved "demo Dennis" as the target, listening to music on vulnerable headphones connected to his smartphone.

The initial phase of the demo focused on Bluetooth Low Energy (BLE) attacks, which are silent and do not disrupt the user's audio experience.

1. Reading Build Version: Using their custom Python tool (built with Google's Bumble library), the attackers connected to Dennis's headphones via BLE (GATT). They successfully queried and displayed the firmware's build version, including the build date, vendor name, and SOC name. This information is valuable for fingerprinting and identifying specific device models and potential vulnerabilities.
2. Reading RAM for Media Info: The tool then demonstrated reading specific RAM addresses to extract "media info," revealing the song Dennis was currently listening to. This highlights the ability to access runtime data without user knowledge.
3. Dumping Configuration Partition (NVDM): The most critical BLE-based attack involved dumping the NVDM partition from the headphone's flash memory. This partition, acting as a key-value store, contains vital configuration data. The tool identified the NVDM partition (typically partition 6) and proceeded to dump its contents. Crucially, Dennis remained unaware, with his music playing uninterrupted. The dumped data revealed a "connection table" containing the name, Bluetooth Classic address, and, most importantly, the Bluetooth Link Key of Dennis's smartphone, along with the headphone's own address. This information is the lynchpin for the subsequent impersonation attacks.

The second phase demonstrated Bluetooth Classic attacks, which are more intrusive but enable powerful audio-related exploits.

1. Eavesdropping via Audio Connection: The attackers first queried the headphone's Bluetooth Classic address using a Race command. Then, they established a new Bluetooth Classic audio connection to Dennis's headphones. This action did disrupt Dennis's music, making it a "noisy" attack. Once connected, they could route audio to the headphones, effectively using them as a microphone to broadcast "Hello Hamburg," demonstrating an eavesdropping capability (though requiring the user to not be actively listening to their own audio).

The most impactful and complex demonstration was the Pivoting Attack, which leverages the previously stolen link key to impersonate the headphones to Dennis's smartphone, even when the actual headphones are absent.

1. Spoofing Headphone Address: The attacker used a CSR Bluetooth controller, which allows its MAC address to be changed, to spoof the Bluetooth Classic address of Dennis's headphones (which was extracted from the NVDM dump).
2. Establishing a Forged Connection: Using BTS Stack, a robust Bluetooth host stack, and providing the stolen link key, the attacker established a Bluetooth Classic connection to Dennis's phone. The phone believed it was connecting to its legitimate headphones.
3. Voice Assistant Control (Siri): The attacker then used the Hands-Free Profile (HFP) to interact with Siri on Dennis's locked iPhone, successfully asking "What's the current time?" This demonstrated control over the phone's voice assistant functionality.
4. WhatsApp Account Hijacking:

• The attacker queried Dennis's phone number via HFP.
• They initiated a WhatsApp registration process on a separate device using Dennis's number, requesting a verification call.
• Crucially, by spamming the HFP "accept call" command, the attacker could intercept the incoming WhatsApp verification call before Dennis's phone even vibrated. This allowed them to hear the verification code and complete the WhatsApp registration on their own device, effectively hijacking Dennis's WhatsApp account.

1. Amazon Account Takeover: Building on the WhatsApp compromise, the attacker then attempted to log into Dennis's Amazon account using his phone number and the "sign in with code" option. Since the attacker now controlled Dennis's WhatsApp, they received the Amazon login code via WhatsApp, completing the Amazon account takeover.

The speakers acknowledged that the WhatsApp and Amazon attacks are "noisy," as they generate notifications on the target phone. However, they emphasized the vast "window of opportunity" for such attacks, as they can be performed at any time after the link key is stolen, without needing the headphones present. This allows an attacker to wait for opportune moments when the user is distracted or their phone is unattended. The demo conclusively proved that unauthenticated access to headphone firmware can directly lead to compromise of a user's smartphone accounts.

Defensive Implications

▶ Watch: Successfully dumping firmware from devices via USB (8:00)

The findings presented in "Bluetooth Headphone Jacking" carry significant defensive implications for both manufacturers and end-users. Addressing these vulnerabilities requires a multi-faceted approach, targeting the root causes and mitigating the potential for exploitation.

For Manufacturers (Aroa, OEMs, and Device Vendors):

1. Comprehensive Security Assessments: The most critical recommendation is for all manufacturers, especially those selling high-value consumer electronics, to conduct thorough and independent security assessments of their products. This includes embedded firmware, proprietary protocols, and Bluetooth implementations. The speakers explicitly stated, "If you sell customers a $600 pair of headphones, have someone look at it, please."
2. Fix Pairing Issues: The underlying Bluetooth Classic and Bluetooth Low Energy pairing vulnerabilities (assigned CVEs) must be patched to prevent unauthorized connections and access. This includes ensuring proper authentication mechanisms are in place for all Bluetooth connections.
3. Strip Down/Authenticate "Race" Protocol: The powerful "Race" protocol, specifically its dangerous commands (flash/RAM read/write, link key extraction, firmware update), must either be:

• Removed entirely if not essential for user-facing features.
• Strongly authenticated with robust cryptographic methods if critical functionalities must remain accessible. Configuration commands for non-sensitive settings (e.g., equalizer, ANC) can remain unauthenticated, but critical system access must be protected.

1. Secure Storage of Sensitive Data: Bluetooth link keys and other sensitive connection data (like paired device addresses) must be stored securely. This includes encryption, secure enclaves, or other hardware-backed security features to prevent their extraction even if flash memory is dumped.
2. Transparent Disclosure and Patching: The disclosure process highlighted significant challenges. Manufacturers should:

• Maintain functional and monitored security contact channels (e.g., PGP-signed email addresses, clear response SLAs).
• Act transparently with researchers and users about discovered vulnerabilities.
• Clearly communicate which devices are affected, what vulnerabilities are patched (mentioning CVEs), and when updates are available.
• Collaborate effectively across the supply chain (SOC vendor to OEM to device vendor) to ensure patches are developed, distributed, and applied promptly.

1. Secure Firmware Update Mechanisms: While the Race protocol's update capabilities were not weaponized, ensuring that firmware updates themselves are cryptographically signed and authenticated is crucial to prevent malicious firmware injection.

For Users:

1. Update Firmware Immediately: The most immediate and important action for users is to update their headphone or earbud firmware as soon as updates become available. Check the manufacturer's website or companion app regularly.
2. Verify Patches (If Possible): While challenging, if technical information or tools become available (like the researchers' toolkit), users can attempt to verify if their updated devices are indeed fixed.
3. Consider Wired Alternatives: If a user is at exceptionally high risk or has extreme security concerns, using cable-bound headphones eliminates the Bluetooth attack surface entirely.
4. Remove Unused Pairings: Periodically review and remove Bluetooth pairings with devices that are no longer in use. Stored link keys from old, vulnerable headphones could still pose a threat to your phone if an attacker gains access to those headphones.
5. Be Aware of Peripheral Risks: Recognize that while smartphones are highly secure, peripherals can introduce new attack vectors. Be mindful of the security posture of all connected devices.
6. Monitor Phone Notifications: Despite the "silent" aspects of some attacks, the account hijacking demos showed that follow-up actions (like WhatsApp verification calls or Amazon logins) often generate visible notifications. Users should be vigilant about unexpected calls or messages, even if they are quickly dismissed.

The talk concludes with a strong message that attacks on peripherals are likely to become more common as core platforms harden. This necessitates a fundamental shift in how security is approached across the entire IoT ecosystem.

Key Takeaways

• Widespread Vulnerability: Numerous popular Bluetooth headphone brands (Sony, Marshall, Jabra, JBL, Biodynamic, Bose) are affected due to their reliance on vulnerable Aroa System-on-Chips (SOCs).
• Unauthenticated Protocol: A proprietary "Race" protocol, used for device configuration and firmware updates, is exposed without authentication over both Bluetooth Classic and Bluetooth Low Energy.
• Data Exfiltration: Attackers can silently read device flash memory, extracting sensitive data including Bluetooth link keys, paired smartphone Bluetooth addresses, and even runtime information like currently playing media.
• Account Hijacking: Stolen Bluetooth link keys enable an attacker to impersonate headphones to a smartphone, allowing for interception of verification calls (e.g., WhatsApp account takeover) and control over voice assistants (e.g., Amazon account takeover).
• New Attack Vector: The research highlights that as smartphones become more secure, peripherals with direct access and cryptographic bonds to phones are becoming attractive new targets for sophisticated attacks.
• Manufacturer Responsibility: There's an urgent need for manufacturers to conduct thorough security assessments, implement strong authentication for sensitive protocol commands, secure storage of link keys, and improve transparency in vulnerability disclosure and patching across the entire supply chain.

About the Speaker(s)

Dennis Heinze and Frieder Steinmetz are penetration testers at ERW, a German security company. Their professional work primarily involves conducting technical assessments within the realm of the Internet of Things (IoT), with a particular focus on embedded systems and communication security. Both have dedicated significant research time to Bluetooth technologies, with Dennis having a longer history in this area. They are known for their practical, implementation-focused research, as evidenced by their previous presentation at 38C3 on Bluetooth Oracast and their detailed reverse engineering work presented in this talk. Their expertise lies in uncovering deep technical vulnerabilities in widely used hardware and communication protocols.