ESP32 - Undocumented commands found in Bluetooth chip used by a billion device

Mar 09, 2025 Last reply: 1 year ago 15 Replies

For those who program with electronics on IoT (internet of things) devices, the ESP32 has 29 undocumented commands that could be used as a ‘backdoor’.



Below is the article that provides more details.



formatting link

IMO the takeaway is never to buy anthing from China that has electronice in it.


Amen to that. I suspect Hikvision, for starters.

Chinese chip backdoors have been around for more than a dozen years:

formatting link

It's not a backdoor:

formatting link
It's some undocumented commands (which aren't uncommon) on an interface used when you already control the device. ie it's not a backdoor, it's more like a hidden panel inside your house to access some pipes you could already access by other means, and are never accessible from outside.

Good luck with that. Given this is about a component, it doesn't matter where the device it contains was manufactured, or indeed who designed it.

Theo

That chip is by a US manufacturer.

Theo

Are you dealing in a way that would attract interest to the Chinese authorities.

It has been suggested if you don't want your business get back to the UK government, then the safest approach is to buy Chinese.

Don't US ITAR rules prevent the US exporting encryption standards that the US can't crack or don't have a back door access to the NSA etc? I recall PGP's creator was nearly imprisoned.

Not since the 'crypto wars' of 1990s (Clipper Chip, etc). If encryption has a backdoor it's crackable by anyone with suitable resources - someone will find the weakness. It's not possible to discriminate in favour of one country over another.

Theo

That old "if you have nothing to hide, you have nothing to fear" fallacy again...

Anything that the Chinese (or many other malign state powers) can hack is of interest, even if it is just to be used as a potential stepping stone to something more interesting.

A Chinese company, but "fab less" so they get others to actually make their chips. Currently TSMC do the bulk of it.

Their two main products (ESP32 and ESP8266) are very widely used in all kinds of kit.

formatting link

The paper cited refers to an Actel FPGA (HQ in San Jose) which was bought by Microsemi (HQ Aliso Viejo California) which was bought by Microchip (HQ Chandler Arizona). Nothing to do with China.

Sergei was also being a bit hyperbolic in describing this as a 'backdoor' and a 'military' chip. It's an undocumented command that could potentially be used to read the bitstream of the FPGA. That could potentially lead to cloning and possibly to reverse engineering, but it doesn't allow an attacker to manipulate the state of the FPGA (at least, the paper doesn't say as much), which is what most people would assume is meant by 'backdoor'. Still bad though.

ProASIC 3 is regular cheap FPGA that shows up in consumer products - it so happens there's a military temperature version and a rad-hard version, so they're military in that sense... but they're not claiming military-grade security or anything like that. It's just a jellybean part that gets used in lots of places, some of them military.

Theo

Are you reading the right paper? I can see no mention of an FPGA.

Ah, so that would be why Chinese head office posted a clarification about it, and said they would remove the functionality then?

formatting link
Now I would agree it is not in itself a backdoor. There is no risk of a bluetooth device external to the ESP32 using the chip capabilities to attack other devices.

However there is scope for a malign actor to build a product (or more likely coerce the maker of a product) to include (or "patch") firmware on a device that uses one of the chips to carry out actions that are not the advertised use, by making use of the debug facilities.

Think how many devices using these chips are in devices connected to the internet anyway and so are capable of downloading new firmware patches - possibly autonomously.

I was replying to this comment from Jeff:

which paper refers to an Actel ProASIC 3 FPGA.

I think we're talking at cross purposes.

Agreed.

While direct access to the Bluetooth memory is potentially troublesome, it depends whether this interface was ever a security boundary. Generally these interfaces are not: you're running firmware on the chip that offers an API and it's assumed you have full control over it. Because it's not a security boundary, there's no particular gatekeeping of access via this API

- the API is just for convenience, and it's often possible to do the same things via the published API as it is via the unpublished API. It's only an API because it's a closed source component and that's the interface they publish. There was never any protection to stop you poking things from outside the closed source firmware library.

By analogy, it's like an extra hatch to the ventilation ducts inside your house that you didn't know about. If you have access to the ventilation ducts from other places, there's no problem with having another hatch - it doesn't change anything. As we know from Hollywood, it's only if you decide to keep hostages in the room with the secret hatch (ie make an internal security boundary) that the presence of the hatch becomes important.

Theo

Indeed - sorry had not spotted Jeff's paper.

In general I would agree, although there is always scope for mischief when bad actors realise they possibly have access to new capabilities on their collection of already compromised IoT devices.

"Bad actors" can ruin most forms of entertainment, but they seem to be blamed for all sorts of things lately. I blame America.

Agreed, with Gene Hackman excepted. Zuckerberg included, though.

Apologies for the error and late follow-up. No idea why I added the word "Chinese"! There was an update to that draft paper, but I can't find it and as far as I remember there was little change of even minor significance.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required