It’s not even over USB by default. It’s an internal binary driver API. The USB part is a custom firmware for the ESP that exposes that api via USB that the people giving the talk wrote because it’s useful for pentesting / development of exploits for other Bluetooth devices.
Maybe we can find out for sure through the magic of the fediverse…
@antoniovazquezblanco@mastodon.social Is the “backdoor” mentioned in https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-devices/ about what you shared in your RootedCON talk? If so, how worried should people using devices containing ESP32s be?
Huh, that is interesting. Though, that post doesn’t seem to have any info about what the backdoor is either.
Tarlogic Security has detected a backdoor in the ESP32, a microcontroller that enables WiFi and Bluetooth connection and is present in millions of mass-market IoT devices. […] This discovery is part of the ongoing research carried out by the Innovation Department of Tarlogic on the Bluetooth standard. Thus, the company has also presented at RootedCON, the world’s largest Spanish-language cybersecurity conference, BluetoothUSB, a free tool that enables the development of tests for Bluetooth security audits regardless of the operating system of the devices. [Emphasis mine.]
Maybe the presentation has nothing to do with the actual backdoor?
Though, this part later might seem to imply they are related:
In the course of the investigation, a backdoor was discovered in the ESP32 chip, […] Tarlogic has detected that ESP32 chips […] have hidden commands not documented by the manufacturer. These commands would allow modifying the chips arbitrarily to unlock additional functionalities, […].
Which, best I can work out, seems to be talking about the information on slide titled “COMANDOS OCULTOS” (page 39 / “41”).
If the “backdoor” is the couple of commands in red on that slide, I maintain what I said above. If it’s not talking about that and there’s another “backdoor” that they haven’t described yet, well, then ¯\_(ツ)_/¯ we’ll see what it is when they actually announce it.
I fully acknowledge there may be something I’m missing. If there’s a real vuln/backdoor here, I’m sure we’ll hear more about it.
What is this article on about?
Here’s the actual presentation: https://www.documentcloud.org/documents/25554812-2025-rootedcon-bluetoothtools/
I don’t speak Spanish and only have the slides to go off of, but this doesn’t sound like a “backdoor”. This sounds like they found the commands for regulatory testing. To do emissions testing you need to be able to make the device transmit on command so that your testing house can verify you’re within legal limits on everything.
These are commands that can be given over USB. You know what else you can do over USB? Fucking anything, these chips have a JTAG USB device. (Now, if these are commands that can’t be turned off, that would be kinda bad, I guess? But still not really a super big problem. And I don’t see anything that implies that in the slides.)
[Edit: It’s not even that this is a “backdoor” in an internal peripheral interface. I think the “backdoor” is if you have software that exposes that interface somehow? Like you’re running an example that blindly copies stuff from an external UART to this interface? Like I think that’s it?]
The tone I get from the slides is more “hey we found this cool tool for doing Bluetooth stuff that doesn’t require writing embedded software”. Which, cool. But that’s sure not the point this article is trying to make.
I agree that would make sense. I think it’ll come with time.
To others, I’m pretty sure what OP is suggesting is just a generic activity pub server that all the various front ends could use.
I’m pretty sure this is what the original (?) authors of the AP spec intended and that’s why they specified a client-server protocol. My understanding is that (almost?) no one uses that API though, they all just specify their own.