A while ago we started researching Bluetooth Auracast security and wrote about some of our insights. Back then we released the Auracast Hacker’s Toolkit that allowed scanning, listing, and dumping Auracast broadcasts. The main goal was to be able to capture over-the-air packets in order to brute-force the Broadcast Code. Along with this blog post we’re releasing an updated version of the toolkit. This time we implemented proper sniffing capabilities. If you’re interested in the details, feel free to read on. If not, grab your nRF52840 USB dongle, flash the firmware, start sniffing, and load the captures in our Auracast Packet Visualizer.
Continue reading Continue readingBluetooth
Beats Studio Buds: Insecure Pairing Window
As part of our Bluetooth Audio security research, we found a security vulnerability in Apple’s Beats Studio Buds’ pairing mechanism. The devices were found vulnerable to an insecure Bluetooth pairing window in which an attacker could pair with the earbuds without user interaction and establish a valid Bluetooth bonding. This would allow an attacker to eavesdrop on the victim through the earbuds’ microphone, play audio on the device, or track the device via Bluetooth Low Energy.
Continue reading Continue readingYour Android Bluetooth Traffic Captures Should Be Live
In this post I want to talk about a very essential part of my workflow when dealing with Bluetooth devices, particularly IoT devices with a corresponding mobile app: Live capture of Android Bluetooth traffic with Wireshark.
Before you stop reading because you think you know how to do this already, the method does not involve pulling bug reports off your phone, and it does not require root. And most importantly it gives you a live packet log in Wireshark.
Continue reading Continue readingHacking a Bluetooth Printer Server: GATT to UART Adapter?
This blog post describes the journey of how we discovered an interesting Bluetooth SoC within the Datong NP330, a Printer Server IoT device. Our initial goal was to reverse-engineer and analyze the Bluetooth controller that is included in the device. So we wanted to be able to dump the firmware or, if possible, get shell access on the printer server. During that journey we found a few vulnerabilities that ultimately let an attacker fully compromise the device. This is possible over Bluetooth or network via unauthenticated remote code execution with root privileges.
Continue reading Continue readingSecurity Advisory: Airoha-based Bluetooth Headphones and Earbuds
Important note: Some media coverage on this topic falsely or inaccurately depicts the attack conditions. To be clear: Any vulnerable device can be compromised if the attacker is in Bluetooth range. That is the only precondition.
During our research on Bluetooth headphones and earbuds, we identified several vulnerabilities in devices that incorporate Airoha Systems on a Chip (SoCs). In this blog post, we briefly want to describe the vulnerabilities, point out their impact and provide some context to currently running patch delivery processes as described at this year’s TROOPERS Conference.
Continue reading Continue readingUsing the Raspberry Pi Pico W as a Bluetooth Dongle
During our recent research, we experimented with different Bluetooth USB dongles. There are tons of options, and sometimes, it’s challenging to determine what chipset a dongle actually contains, what Bluetooth features it supports, and whether it works on Linux. Inspired by the recent ESP32 Bluetooth research, we wondered whether we could turn our Raspberry Pi Pico Ws into a functioning Bluetooth dongle. We had a few lying around, and the advantage here is that we know exactly which Bluetooth controller it uses – the Infineon CYW43439. It’s also very easy to get one. You can just buy the Pico W for a few bucks, even cheaper than some Bluetooth dongles. You also have a controller family that has been researched quite a bit in the internalblue project. However, there was one disadvantage. We did not find any code that exposes the CYW43439’s HCI interface via USB. So we had to write that on our own.
Continue reading Continue readingCVE-2025-20908: Use of insufficiently random values in Samsung's Auracast implementation
As part of our research into the Auracast feature set in Bluetooth, we also started looking into vendor implementations. At the time we started with our research, there weren’t a lot of products on the market yet. But new products are coming out pretty frequently now.
One of the vendors that had Auracast implemented pretty early was Samsung. At the time the Samsung Galaxy S23 and S24 phones were able to broadcast Audio, while the Galaxy Buds were able to join these broadcasts.
Continue reading Continue readingPart I: Bluetooth Auracast from a Security Researcher’s Perspective
Auracast, the new Bluetooth LE Broadcast Audio feature has gained some publicity in the past months. The Bluetooth SIG has introduced the LE Audio feature-set to the Bluetooth 5.2 Specification in 2019 and vendors are only now starting to implement it. Auracast facilitates broadcasting audio over Bluetooth LE to a potentially unlimited number of devices. It does not require pairing or interaction between the sender and the receivers.
We also presented this topic at 38c3. This blog post will contain similar contents albeit with some more details.
Continue reading Continue readingChange Your BLE Passkey Like You Change Your Underwear
Using a static passkey for Bluetooth Low Energy pairing is insecure. Recent versions of the Bluetooth specification contain an explicit warning about this. However, in practice, we often see static passkeys being used. Moreover, there are no public implementations of proofs-of-concept that can practically show why using a static passkey is an issue. This is why we implemented one.
In a recent assessment, we were testing a device that offered a Bluetooth interface for data export and configuration. This device uses Bluetooth Low Energy (BLE), and a static passkey (or PIN) is required to pair with it. This passkey is displayed for a few seconds when the device is booted and stays the same on each reboot. In fact, it is derived from static, device-specific data.
Continue reading Continue readingCVE-2020-0022 an Android 8.0-9.0 Bluetooth Zero-Click RCE – BlueFrag
Nowadays, Bluetooth is an integral part of mobile devices. Smartphones
interconnect with smartwatches and wireless headphones. By default, most devices
are configured to accept Bluetooth connections from any
nearby unauthenticated device. Bluetooth packets are processed by the Bluetooth
chip (also called a controller), and then passed to the host (Android, Linux,
etc.). Both, the firmware on the chip and the host Bluetooth subsystem, are a
target for Remote Code Execution (RCE) attacks.