cat /dev/brain

There's a new Bluetooth vulnerability collection, called BrakTooth . PoCs are under NDA until end of October. Are these bugs real? Do they affect more than the Cypress dev kit, for example, iPhones and MacBooks? Jan, who developed the Frankenstein emulator for Cypress chips and discovered the BlueFrag vulnerability within Android, joined my efforts in reproducing these bugs. All tooling we used is already public, as well as the BrakTooth vulnerability descriptions. We will not publish our own BrakTooth PoCs until the BrakTooth NDA ends to protect end users. Link Management Protocol If you're reading this and already have a background on Bluetooth, continue reading on the next section. Everyone else still needs to get familiar with an over 3k page long nightmare, called "Bluetooth Specification". All page numbers refer to version 5.2, even though version 5.3 was released recently. As of now, there's no 5.3 chip available. The Link Management Protocol (LMP) negoti

 If you ever looked into one of Broadcom's combo chip datasheets, you might have noticed a feature called "WLAN RAM Sharing". In the following, I will explain how to use it to get controlled code execution on Wi-Fi via Bluetooth, which can be helpful in a couple of scenarios: Hack around in Wi-Fi firmware during runtime without disabling SELinux on Android ( Nexmon requires kernel patching with disabled SELinux). Indirect Wi-Fi firmware hacking support on platforms that are not supported by Nexmon (iOS, macOS, etc.). Reaching states in the Wi-Fi driver one could not reach over-the-air (💥💥💥). WLAN RAM Sharing?! Francesco and me looked into so-called coexistence features. If you want more details on this, watch our DEF CON or Black Hat talk from last year :) In short, despite running on different ARM cores, Broadcom and Cypress BT/Wi-Fi have coexistence features, which include a unidirectional RAM sharing feature. This feature is shown in some leaked datasheets in the

Found some time for another Bluetooth rant :) This time it's going to be about BlueZ , the Linux Bluetooth stack. Note that there are other Bluetooth stacks for Linux such as BTstack , but I didn't find the time to play around with these, and BlueZ is still what you get these days if you install a normal Linux distribution. This is my view on about BlueZ and a couple of things might be over-simplified. Feel free to add comments to this post if anything is wrong or is better explained elsewhere. However, I found that there is no good overview from a programming and hacking perspective, and often times I get questions about patching certain things within InternalBlue that have a root cause deep down in the Linux kernel. BlueZ is missing documentation. In fact, I ended up using dynamic debugging here and there to understand which functions are still called and which are deprecated. Otherwise, this blog post would not be needed for an open-source project m) Linux Bluetooth stack vs

The perfect Bluetooth research tooling doesn't exist ;) But since I'm maintaining InternalBlue I can provide you with an overview of compatible devices and the advantages or shortcomings of all of these. There is some open tooling for Bluetooth LE out there. Bluetooth LE is mostly used in IoT devices and modern gadgets. When it comes to Classic Bluetooth, which is still used a lot for audio devices and data transfer like tethering, you need to buy professional equipment or deal with very bad open-source implementations based on software-defined radios (SDRs). A brief overview of this can be found in my Bluetooth Hacking 101 talk from last year. Despite not using anything based on SDRs or microcontrollers, I have a huge variety of devices. All of them have Broadcom (or "Cypress") Bluetooth chips. So, here is a minimal (seriously!) selection required to do some meaningful Bluetooth research that includes a couple of generations of devices and the possibility to test v