cat /dev/brain

When looking into the most recent Bluetooth patches of the Samsung Galaxy Note 20 5G, I found something interesting. Once again, it's about the Random Number Generator (RNG). Jörn, Felix and me already published a WOOT paper about this last year. But there were some updates since then, which will be covered in this blog post. Oh, and it also contains assembly for the curious reverse engineer, additional honest opinions (I hope reviewer 2 will never find my blog), rants, and explanations for people who are new to Bluetooth. If you already saw the talk or read the paper, you might want to skip forward to "The unexpected patch". But you will miss some ranting!!!11! Why should anyone look into a random number generator? A RNG is one of those dragons that live deep inside the firmware or even hardware. Just don't look at them. Otherwise, something might break :) The Bluetooth Core Specification , currently at version 5.2, specifies that a Bluetooth chip has to provide a F

Due to some vulnerabilities found recently, Broadcom started to see the "Bluetooth host -> Bluetooth controller" communication as an attack surface. In Bluetooth terminology, the host is the operating system with a Bluetooth daemon, e.g. iOS or Android, and the controller is Broadcom's Bluetooth chip. A lot of manufacturers see that as attack surface - to protect their intellectual property or to prevent that people use their smartphone as software-defined radio. Moreover, it raises the bar for initial exploit development. Other manufacturers protect their chips with secure boot. This means that they sign their firmware. The chip has a minimal bootloader, which loads the vendor's firmware for that chip, checks the signature, and then boots it. Thus, for a lot of chips, the first step is to find a secure boot bypass or to find a vendor/device that has secure boot disabled. Broadcom had an interesting idea on that, for both Bluetooth and Wi-Fi chips. They store their