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.
In our previous blog post we analyze the security of Auracast broadcasts. In short, broadcasts can be encrypted by specifying a so-called Broadcast Code (or Passcode). We show that the key derivation used to derive an AES key from the Broadcast Code is not sufficient to properly protect the broadcast. The weak key derivation, combined with the way the encryption works, allows an attacker to perform an efficient offline brute-force attack against captured Auracast packets. However, when the Broadcast Code is chosen properly, this attack can be made very difficult and likely economically unreasonable.
However, we found that the Bluetooth specification is lacking in this regard. Both the specification of the Broadcast Code itself, and the example values given in the specification and other documents are inadequate.
This, in our opinion, inadequate specification and the poorly chosen examples of Broadcast Codes lead us to suspect that vendors may not be aware of the requirements for a secure Broadcast Code.
This is essentially what happened with Samsung’s implementation.
CVE-2025-20908
When a new Auracast Broadcast is started on a Samsung Galaxy device, the device generates a default Broadcast Code. This code presents as four characters. However, looking at implementation reveals that it actually consists of only two random bytes that are encoded in hex. The password is not generated from a set of random bytes, but the hex characters are taken from a random UUID.
public final String generateRandomPassword() {
return UUID.randomUUID().toString().substring(0, 4);
}So a resulting Broadcast Code could be 4c5a, for example.
This means, attackers only need to brute-force two bytes to obtain the Broadcast Code and decrypt the broadcast packets. Afterwards the attackers might even be able to hijack the broadcast. More details on this can be found in our previous post.
It is important to note that this is just the default Broadcast Code that is set up by the phone. Users are free to set their own Broadcast Code values.
Samsung’s Fix
Samsung chose to follow the AOSP behavior of generating 6 bytes – or rather 12 hex characters.
public final String generateRandomPassword() {
String uuid = UUID.randomUUID().toString();
return uuid.substring(0, 8) + uuid.substring(9, 13);
}A resulting Broadcast Code here could be 552cacf3fcbf. Essentially, six bytes encoded in hex.
PoC: Brute-Forcing the Broadcast Code
The following video shows how our Auracast Hacker’s Toolkit can be used to dump encrypted Auracast packets and crack the Broadcast Code. With a two byte value, this cracking process takes less than a second. Again, more details on how and why that works are in our other post
Let’s unwrap what’s happening in the video. First, we’re starting an Auracast broadcast on our Samsung Galaxy S23. This device has the default Broadcast Code 4c5a. We’re then connecting to our nRF5340 DevKit which is running our Auracast Hacker’s Toolkit. After initializing the device (init), we can start scanning for broadcasts (scan on). You can see that the phone’s broadcast is detected.
To get more information about the broadcast, including the ones required to fully “subscribe” to the broadcast, we obtain the broadcast’s BIGInfo (scan biginfo). We can see some parameters and properties of the broadcast, including the information that it’s encrypted (broadcast list).
We then start the PDU dump (broadcast dump 0). Picocom was started with the -g option which logs all output to a file. We do this so that we can process the dumped PDUs later on.
After some packets have been logged we disconnect from the nRF DevKit and get to the next step, the cracking of the Broadcast Code. For this we implemented biscrack. First, we run the log_extract.sh script included in the repository. This script extracts all the information we need for the cracking process. It extracts the data packets and the BIGInfo packets, which include relevant parameters for the encryption. At the end, it outputs the full biscrack command line. The only thing that needs to be adapted is the mode (-m numeric) and the length of the code, which is two bytes in this case (-l 2).
Running this command then cracks the Broadcast Code in less than a second.
Broadcast Code Security
While the slightly longer six byte default Broadcast Code is much harder to crack in a sensible time, it is still not as secure as it should be. We’ve shown that the Broadcast Code should ideally be treated similar to an AES encryption key, due to the way the derivation to the actual AES key works. However, from a user perspective this is usually not possible, as the Broadcast Code will mostly be printable ASCII characters only.
For now, the advice for users is to treat the Broadcast Code like a very secure password and to use up all the available space of 16 characters. In our previous post we also provided some thought for vendors and the specification itself.
Disclosure Timeline
Below is a brief timeline of the disclosure process. In our opinion this process went very smoothly and Samsung was very transparent. They asked us to refrain from naming them and details of the issue in our CCC talk. We complied with the request as 90 days were not over at that time. Additionally, our focus was more on the specification itself than a specific vendor implementation. The patch was released exactly 90 days after our report and Samsung assigned it CVE-2025-20908 (and SVE-2024-2271).
- 4th of December 2024: Report to Samsung.
- 27th of December 2024: Request from Samsung to not mention them in our CCC talk.
- 29th of December 2024: CCC Talk
- 21st of January 2025: Response from Samsung with details on planned fix.
- 22nd of January 2025: Final acknowledgement of issue with rating “Moderate”.
- 4th of March 2025: Patch release and publication of CVE by Samsung.
Frieder and Dennis