Definition of “backdoor”

The Cambridge dictionary defines backdoor as “relating to something that is done secretly or in a way that is not direct or honest”. Wikipedia defines a backdoor in the context of computing as “a typically covert method of bypassing normal authentication or encryption in a computer”. The use of the words “secretly” and “covertly” here is of particular importance, because this secrecy is understood to be in service of intentional malice. A company that inserts a backdoor deliberately is acting in a malicious manner (and could subsequently be held legally liable.)

Background about Tarlogic’s claim

On March 6th 2025 Tarlogic posted a press release (archive link) titled “Tarlogic detects a backdoor in the mass-market ESP32 chip that could infect millions of IoT devices”. This subsequently was picked up by a BleepingComputer article (archive link) which was widely visible via Slashdot, Google News, etc.

The Tarlogic press release is based on work presented at RootedCon March 6th 2025. The Spanish-language-only slides are available here (archive link). The slides can be uploaded to be translated with Google Translate as most of the text is not in images. The videos from the conference are not yet available at the time of writing, so the audio track from the presentation is not yet available.

Background about Bluetooth HCI

Bluetooth has an architectural layer known as the Host Controller Interface (HCI). In architectures like laptops or phones, the main CPU and OS is the “Host” and the Bluetooth chip is the “Controller”. Therefore HCI is the interface between the Host and the Controller. If the Host wishes to scan for available nearby BT devices, or connect to one of them, it sends a Command over HCI to the Controller to inform it of the action the Host would like performed.

The Bluetooth Core specification lays out many HCI commands. However it also reserves a command space for “Vendor-specific Commands” (VSCs). These are commands that the silicon maker of the Controller can use to manage the Controller. This can include things such as how to update the firmware on the Controller, how to get back nice-to-have information that may not be available via spec-defined commands (e.g. chip temperature), how to perform chip-specific actions (e.g. setting the transmit power or a custom Bluetooth address), etc. VSCs are typically interfaced with via a silicon maker’s proprietary software (libraries, user-facing tools, or developer-only tools.)

The HCI interface itself runs via hard-wired physical transports such as UART, USB, PCIe, etc. Therefore when discussing how VSCs are sent, we should always visualize it as an entity on the Host communicating via a wire to the BT Controller’s firmware.

What the research describes

The research describes reverse engineering the ESP32 ROM, via the copy which Espressif provides on its github. (We would note that this is an uncommon level of transparency for a silicon vendor in the Bluetooth space.) The research then analyzes the VSCs and finds instances for reading and writing RAM and flash, as well as sending some types of low level packets which cannot normally be sent from the Host due to the normal separation of duties between the Host and Controller.

The research slides themselves do not contend this is a backdoor. Only the press release does. The slides only indicate there are hidden/undocumented commands present.

Other vendors’ VSC documentation

While some vendors like Texas Instruments document many of their VSCs, there are clearly gaps as the documented functionality, with command opcodes jumping from 0x02 to 0x05 or 0x0A to 0x27. Similarly Cypress documentation describes some VSCs. However there are even larger gaps in the listed commands, with numbering jumping from 0x01 to 0x18, or 0x1D to 0x27. This does not mean vendors are hiding anything or that the missing commands are backdoors. It just means they have chosen not to document all VSCs publicly for customers, and to keep some for internal use only.

As far as we are aware, Broadcom does not publicly document their VSCs anywhere. However, because Cypress acquired Bluetooth intellectual property from Broadcom in the past, documentation by Cypress describing VSCs to read and write RAM was shown to apply to Broadcom. Beyond that, it is known that some Broadcom VSCs are not just Broadcom-specific, but Broadcom-customer-specific. E.g. Apple uses Broadcom chips in Macs and iPhones, and some reverse engineered VSCs correspond to usage with Apple-proprietary functionality.

The main point here is that it is common in the Bluetooth ecosystem for vendors to not document all their VSCs.

Other vendors’ capability to read or write RAM via VSCs

The most famous case of a vendor supporting a capability for the host to read or write the RAM of the controller is on Broadcom chips (and Cypress chips because Cypress acquired Bluetooth intellectual property from Broadcom in the past.) The capability to write from the Host to the Controller was used by the InternalBlue tool to send arbitrary BT packets which could not normally be sent from the Host. The capability was also later used in the Spectra attack, to write not just to the BT Controller’s memory, but to memory shared with the Wi-Fi controller in the same Broadcom chips. The VSC capability to write RAM was also used to escape from Linux sandboxing when exploiting the Tesla Model 3.

Likewise, in our previous research, “Finding New Bluetooth Low Energy Exploits via Reverse Engineering Multiple Vendors’ Firmwares”, Veronica Kovah used the capability to read and write RAM via VSCs on Texas Instrument chips to enable a basic debugging capability while developing her over-the-air exploits. However in TI’s case it makes the documentation of their VSCs for memory and Controller-register writing public.

The main point here is that multiple vendors utilize VSCs for reading and writing RAM within the Controller. This is a common design paradigm in Bluetooth chips; it’s not some Espressif-specific backdoor approach. And the use of read-RAM/write-RAM capabilities for the benefit of attackers is already well known in the Bluetooth space.

Conclusion about whether the discovered VSCs constitute a “backdoor”?

They do not.

Espressif partially documented their VSCs, the same as other Bluetooth chip makers, and included a capability to read and write the memory of the chip, the same as other Bluetooth chip makers.

We are left to conclude that the Tarlogic press release is spreading Fear, Uncertainty, and Doubt (FUD) to gain attention. And the BleepingComputer article, and its reposts to platforms like Slashdot exacerbate the FUD by focusing on the fact that Espressif is a Chinese vendor.

Conclusion about whether this feature constitutes a security vulnerability

It depends.

Specifically it depends on a particular customer’s threat model.

Most customers will not attempt to make a distinction between the privileges of the Host and the Controller. And for those customers it will not constitute a vulnerability.

However, it is valid for a customer to not want a compromised userspace on the Host to automatically guarantee a compromised Bluetooth Controller firmware. This was my threat model when I worked at Apple, and I worked to get Broadcom’s VSCs for Controller memory read/write disabled (because I had also helped design secure boot for Apple’s Broadcom chips). Likewise if you read the previously mentioned Tesla attack talk, you can see how the presence of Broadcom’s VSCs allowed the researchers to bypass Tesla’s Linux userspace process sandboxing mechanisms.

It is worth noting that Espressif supports both secure boot and flash encryption. Both features need to be explicitly enabled by customers who purchase ESP32 chips, and will generally not be enabled for low-end devices where the focus is on spending the minimum possible engineering time (cost) on low-margin products. In a well-designed system, the capability to write to the flash memory should not automatically compromise the security provided by either secure boot or flash encryption. And specifically the security that they generally provide is the assurance that only 1st party code, not malicious code, can be executed on the Controller. However the VSCs which enable writes to flash memory could lead to the exploitation of vulnerabilities in the secure update or secure boot system, as have been found on other chips, such as Silicon Labs’ and Renessas’. Likewise, if we consider the goal of secure boot to avoid attacker code execution in the context of the chip which it is protecting, then clearly an architectural ability of an off-chip attacker to write arbitrary code into the chip is a clear violation of the goal of secure boot.

Overall we at Dark Mentor do consider the use of VSCs granting the capability to read and write memory, flash, or registers to be bad security design. It’s bad design for Espressif the same as it’s bad design for Broadcom, Texas Instruments, and any other vendor that uses it.

This issue is now being tracked as CVE-2025-27840.

Addendum

I reached out to one of the researchers, who I’ve worked with in the past, to understand whether this was just a case of the marketing department run amuck. I will update this post if I hear back from him, or if Tarlogic removes or revises their press release.

Update: March 9th 2025: The Tarlogic press release was updated to replace the word “backdoor” with “hidden feature”, which is more factual, and what the original research indicated. After the community raised concerns with the characterization as a backdoor (and before Tarlogic changed their press release), BleepingComputer also updated their article to indicate that these are “undocumented commands”, not a backdoor.