Recently there was a panicked scrambling after the announcement by [Tarlogic] of a ‘backdoor’ found in Espressif’s popular ESP32 MCUs. Specifically a backdoor on the Bluetooth side that would give a lot of control over the system to any attacker. As [Xeno Kovah] explains, much about these claims is exaggerated, and calling it a ‘backdoor’ is far beyond the scope of what was actually discovered.
To summarize the original findings, the researchers found a number of vendor-specific commands (VSCs) in the (publicly available) ESP32 ROM that can be sent via the host-controller interface (HCI) between the software and the Bluetooth PHY. They found that these VSCs could do things like writing and reading the firmware in the PHY, as well as send low-level packets.
The thing about VSCs is of course that these are a standard feature with Bluetooth controllers, with each manufacturer implementing a range of these for use with their own software SDK. These VSCs allow for updating firmware, report temperatures and features like debugging, and are generally documented (except for Broadcom).
Effectively, [Xeno] makes the point that VSCs are a standard feature in Bluetooth controllers, which – like most features – can also be abused. [Tarlogic] has since updated their article as well to distance themselves from the ‘backdoor’ term and instead want to call these VSCs a ‘hidden feature’. That said, if these VSCs in ESP32 chips are a security risk, then as [Xeno] duly notes, millions of BT controllers from Texas Instruments, Broadcom and others with similar VSCs would similarly be a security risk.
A better analogy is a door to a secret room. You need to be in the house to access the door to the secret room. The room does not make the house less secure (unless you disable the security system from within that room, for instance).
Yes and another analogy would be:
“Let’s bolt down these free extra features, so no one can have fun with them!”
And then people complain as with Wifi how hard it is to get a device supporting “promiscuous mode”.
This is HaD, this is “hacker” friendly. The last thing we need is people crying wolf over free extras.
Undocumented also means untested, unsupported, and may change at any time.
I’m pretty sure these vendor commands are tested and supported by the vendor itself.
They are indeed not tested by the public, but then again, they are also not used by the public, nor publicly accessible.
This is only a potential issue if these commands were undocumented commands that were publicly accessible.
Is it really standard that manufacturers have them undocumented?
Absolutely. They’re for the manufacturer to use, not others.
As with GPS modules from experience, not the manufacturer per se. Usually the customer at a hefty fee and an NDA to have more freedoms with their hardware.
Depends on the manufacturer. U-Blox, probably. But Quectel for example are very helpful and encourage hacking on their forums.
I think he means “standard” in the sense that they are common, not in the sense that they conform to a published standard. It is very common to have undocumented features that are there for initial testing and special needs of manufacturing. There are things that you would rather not have to explain because the usage is too obscure, and you really don’t want to support people who would misuse it or complain that it doesn’t do everything they want to abuse it for.
Could also mean they’re part of the standard in that the standards may, like with USB stuff, list ranges that are meant for vendor specific use.
For at least 30 years, basically yes. Complexity and capabilities has gone up while physical size is down. It isn’t as viable to break out to test points every possible thing you’d like to test.
It’s trivial these days however to simply integrate your test equipment directly into the silicon.
Once it’s in there, there is no reason at all to remove it later. Finding that initial space is the only cost.
An example is Intels Core-i chips, there are dozens of logic analyzers and an entire scope built in, as well as smaller dedicated cores used for nothing but unit tests. All accessible through opcode sequences in its existing ISA.
Disable through fusible links would be a compromise.
That would disable the test equipment for returns they might need to diagnose. Not to repair of course, but to find out what went wrong and avoid doing that in the next design.
I just find it hard to justify any reason to disable it at all. It’s not hurting anybody.
In this instance it’s not clear which memory is accessible. It may be code that runs in the Bluetooth transceiver. That could enable a supply chain attack by hiding back door code in the Bluetooth stack that isn’t usually touched when programming the esp32
Not to mention that the presence of this infrastructure has actually been turned into a customer facing feature for continuous self testing in Xeons that feature “In-Field Scan”.
All undocumented?
By the manufacturer to the public at least. Some has been reversed engineered and that made public. I’m sure they have internal documentation, but even here for the ESP chips, no reason to think espresif doesn’t also.
I started asking questions about a scanning function in a BCM WiFi chip and in the next public release of the SDK that whole feature became undocumented. Apparently it was never supposed to be “out there” for us.
The main reason you’d leave them undocumented, is you are making a product, you aren’t committing to supporting those commands on every one of those devices, not every revision of the hardware is guaranteed to have that command.
You don’t want to have to keep updating your documentation if a vendor development command changes, so you just don’t document it.
There’s an interesting blog posting about an “uptick in extremely low-quality, spammy, and LLM-hallucinated security reports” —> https://sethmlarson.dev/slop-security-reports
that is a thing, but not really relevant here. The researchers clearly understood what they found, but they or their employer wanted to hype it up.
And in the end, the devs HAVE promised to release a firmware update that removes the commands, for those who prefer. So clearly they felt there wasn’t /nothing/ to this. (Or simply felt it was easier to cave than to defend a position with such bad optics. Same thing, really.)
The amount of xenophobia I saw in social media about this was immense. I wish technology was bringing us together to better face the challenges in our communities and world. The things people say without evidence is astounding, the things chat bots say at scale without evidence is hazardous
So… Could this be a BT bootloader that doesn’t waste half your ESP32 memory?
No, since it’s not remotely accessible. The code must already be running on the mcu to call these commands. If you’re doing that, you can just write directly to the flash. I think this lets you corrupt the Bluetooth firmware you don’t usually have access to? It’s been very poorly reported.
It might just be general flash memory access, which the running code has access to anyway.
Isn’t every backdoor a hidden feature as well? It may not be a wanted feature by many though. So not sure if this makes it better or worse.
Moreover, when this “feature” can be used to bypass ESP32’s FLASH protection and/or used dump RAM/FLASH to extract secret keys, TLS session keys, etc. then this “hidden door” will start to act like much like a backdoor IMO.
Its like stating if you have SWD debug access you don’t need a backdoor to do all these things. But 1) SWD requires hardware access, while this attack can bridge air gaps. 2) SWD is a public standard, while this one was hidden. 3) Both ‘interfaces’ can potentially be used to circumvent protections.
So this sounds much like a “Well actually..” point (much like my own post, I know). Regardless its a huge security flaw.
These undocumented commands are in the HCI, they don’t inherently bridge air gaps. Unless HCI boot mode is used, you already have to have full software access to the chip to access the HCI. In short, they generally don’t give you any more access than you already had.
As far as I can tell, the researchers overhyped the importance of what they had found, and outlets rapidly latched onto that hype without considering the technical details of their actual claims.
Given that you need to be running custom code on the ESP32 to use these commands, you can do all of those things already! These VCS’s can’t be used remotely, they can only be used by code already running on the ESP32, so…. a complete nothingburger.
If you have actual secure supply chain requirements then yes, this access should be cut. Let’s be honest, we aren’t building CIA clean room based applications when ordering off AliExpress.
A backdoor is a hidden API implemented by the vendor, which can be used while runtime.
Xeno Kovah has a nice sense of black humor ;-)
Couple this capability with pervasive bluetooth networks (such as the ‘find my’ features of apple and android), and now you could be talking about the ability to ‘remotely’ compromise the firmware on an ESP device. And given the billions of such devices out there, it’s at least conceivable that a malicious actor could rapidly spread malicious code.
this is more than an nothingburger, but maybe not quite ‘the chinese are wiretapping your browsing.’
I’m pretty sure the reason its being pushed to de escalate the severity of this is specifically because it cannot be used over the wireless side. You have to be talking to chip using the HCI spec. Which normally runs over uart or similar.
Not even close, the is no remote aspect to this at a all.
FYI, Espressif has written a post detailing what exactly this affects: https://developer.espressif.com/blog/2025/03/esp32-bluetooth-clearing-the-air/ (Disclaimer: I work for Espressif)
I think someone is trying to whitewash the fact that a company has put a mechanism to access the most trusted resources if a system without informing the users (this is the definition of a back door)? The question is if it is the result of pressure from China, as it had been seen in other situations, or it is the pressure of the Chinese company?
If you have access to these undocumented debug commands, you also have access to the documented commands that already give you full access.
No whitewashing.
It also only affects ESP32, not ESP32-C, ESP32-S, and ESP32-H series.
Nevertheless, the debug commands will be disabled by default with a software update and the debug commands will be fully documented.
Nothing to see here.
Never heard of Tarlogic and now they’ve dragged their name through the tar by over sensationalizing a nothing burger. For what also read as an ad for their company. Good riddance and hopefully the security community never takes you seriously again.
And hopefully the hacks and the publications they worked for that parroted the misleading press release without the slightest understanding of the subject matter won’t be taken seriously either.
Tarlogic = paid by competitor
Seeking Alpha
bpayne37 Today, 10:08 AM
Data Center issues?
1 High power consumption?
2 x86 hardware which is being obsoleted by inexpensive low-power Reduced Instruction Set chips
containing USB, Wi-Fi, Bluetooth, … all on a chip?
3 Big Tech obfuscating c++/c 10X hyperactive six-figure salaries managers/programmers
unmaintainable software requiring endless series of costly updates which spook investors?