| GitHub | https://github.com/ttdennis |
| https://twitter.com/ttdennis |
We found an interesting Bluetooth Chip in an IoT device. The IoT device is as secure as expected. Root RCE via Bluetooth and a weird HTTP debug shell. However, the Barrot Bluetooth chip is the interesting part here. It's basically a Bluetooth to UART adapter. That sounds very convenient, but holds the potential for lots of security problems.
https://insinuator.net/2026/03/hacking-a-bluetooth-printer-server-gatt-to-uart-adapter/
All hands on keyboard, pen to paper - Elbsides 2026 Call for Paper is open!!!
Make good on your New Year resolution to contribute to the infosec community and present on June 5th in Hamburg. #elbsides2026
RE: https://infosec.exchange/@twillnix/115797806763505506
That was fun! Really happy that all demos worked like a charm.
Also, thanks to the person that tried to manipulate our live demo by calling our target phone... Luckily we had a video prepared to bridge that part.

Join me and @willnix tomorrow at #39c3 talking about Bluetooth headphone hacking and what consequences that might have. We will finally be able to disclose all technical details. We also have a few very cool live demos prepared to demonstrate the issue. Very excited to do the talk and to be back at CCC!

[Airoha](https://www.airoha.com/) is a vendor that, amongst other things, builds Bluetooth SoCs and offers reference designs and implementations incorporating these chips. They have become a large supplier in the Bluetooth audio space, especially ...
One of my favourite parts of the Bluetooth specification is the "hash function" ah, which is used to generate private resolvable BLE addresses. If you follow it through its definitions (ah -> e), you'll find out that it's actually just AES.
In any exam or seminar at university you'd fail if you used AES as hash function. But, sure, for Bluetooth it's fine.
In this case it's not really an issue, but why call it a hash function if it's not a hash function?