Maybe, maybe not. Keep in mind that opcodes are the lowest-level part of the programming stack. They're literally just integers transmitted on the system bus. So if you've got, for example, 35 operations that you're actually trying to implement, you need 2n ≥ 35 or n = 6 signal lines in your bus to transmit it. But since 26 = 64, that means it's possible to put another 29 values on that 6-bit bus, with completely undefined behavior unless you go out of your way to handle them in the instruction decoder (increasing the size and therefore cost of your silicon, which is very undesirable in an embedded chip that sells for less than $1).
It is not at all implausible for one of those undefined instructions to just happen to do something that an attacker would find useful, by sheer coincidence.
It is not at all implausible for one of those undefined instructions to just happen to do something that an attacker would find useful, by sheer coincidence.
It amazing how there is an endless supply of these "coincidence"
step 1 Tracking and profilling
step 2 selling data
step 3 profit
Android and ios use completely different methods. For example, they listen to frequencies that are inaudible to us and, for example, TV advertising plays an inaudible sound as a trigger for Android/IOs in addition to the audible sound. To impose targeted advertising in order to allocate devices even without a network, etc. They wouldn't actually need backdoors as they get more than enough information as it is. But I don't want to imply that I don't expect backdoors there, because this has been proven in any case and often enough.
The "attack" is from the host side, any remote attack is theoretical and would depend on exploiting the software on the host first to then gain access to the BT chip.
Tarlogic developed a new C-based USB Bluetooth driver that is hardware-independent and cross-platform, allowing direct access to the hardware without relying on OS-specific APIs.
Armed with this new tool, which enables raw access to Bluetooth traffic, Targolic discovered hidden vendor-specific commands (Opcode 0x3F) in the ESP32 Bluetooth firmware that allow low-level control over Bluetooth functions.
I am conflicted on the one hand its a great thing we know about the exploit. The problem is, now everyone knows about it, seems like they've documented exactly how to do it for anyone who didn't already know how...
In addition to what others have said, ESP32 is often used by hobbyists, like a more powerful Arduino. These devices are extremely versatile and cheap. I have several of these in my home automation and this is very bad news :(