[spaintech]

First and foremost, I have no affiliation with any of the authors previously mentioned. However, I would like to pose a question to the community:

Is it feasible to exploit these undocumented HCI commands to develop malicious firmware for the ESP32? Such firmware could potentially be designed to respond to over-the-air (OTA) signals, activating these hidden commands to perform unauthorized actions like memory manipulation or device impersonation.

However, considering that deploying malicious firmware already implies a significant level of system compromise, how does this scenario differ from traditional malware attacks targeting x86 architectures to gain low-level access to servers?

[jwr]

It is feasible to develop malicious firmware for the ESP32 even without these HCI commands. The existence of these undocumented commands doesn't change anything.

[u5wbxrc3]

As the article states "These undocumented HCI commands cannot be triggered by Bluetooth, radio signals, or over the Internet, unless there is a vulnerability in the application itself or the radio protocols.". Hence I dont think there is any security risk here assuming the application and radio is safe.

It differs in a way that the person must have access to the device to flash firmware I believe. In x86 as you describe, the person could attack with a connection to the device/machine.

[spaintech]

I agree, hence my direct comment of malicious firmware… For me, the open question is, can one still write a malicious firmware on the ESP32 without the non documented opcodes?

[Etheryte]

This would require you to have root access to the thing, at that point you might as well write literally any code you like and not bother with the HCI commands.

[gblargg]

Just wait until these security researchers learn about the LDR instruction that malicious software could use to read any memory.

[mystified5016]

No.

It is literally just a debug port exposed over the wired HCI interface.

This gives you absolutely nothing at all that you can't get with a normal UART debug port or JTAG. Everything in the HCI commands already exists in the normal bootloader. If you can get a device into bootloader mode, you can peek and poke flash and memory, along with everything else.

There is absolutely nothing here.

You can create malicious firmware, sure, but it has nothing to do with this HCI thing.

[ChrisRR]

It was feasible even without these commands. If you already had code execution on the host then you could've already done what you wanted with the device