TBF the specific backdoor isn’t the point of the article. It’s a cautionary tale. The point is that practically all systems above the MCU level, and even some of those, have lower level systems that are often undocumented or not intended for use by the hardware designers, much less the end users. Those systems often have extremely low level access to system resources.

For example, I am building a device that records motion data, video, audio, and lidar imaging. Inside the 6 dollar IMU and the 12 dollar lidar sensor are powerful processors that load binary blobs provided by the manufacturer. The lidar could potentially gain access to any of the system data stored on the SPI bus, which includes the bulk storage and secondary RAM for the system. It could exfiltrate that data using its laser to anyone within a few hundred meters in the laser fov. It could also receive remote c&c over its optical sensor. The only thing that prevents that from being the case is that I trust the blob does not include the code to do those things, but it would be trivial to replace the blob with one that does.

Millions of devices are made that include basic wifi functionality. often, this comes in the form of a dedicated WiFi module. Those almost entirely consist of a powerful processor running a proprietary binary blobs, connected to some internal bus of the system that may give it access to some or all of the functions of the device, or at the very least could cause the device to malfunction. These WiFi phy modules are sub$1, pervasive, and often built in to devices that do not have any advertised connectivity features. A threat actor that has knowledge of an attack surface for that opaque blob can probably cause >50% of the connected devices built with that product to malfunction, in some cases in serious and dangerous ways, and sometimes to exfiltrate data that might be compromising or valuable.

That’s what this article is really about.

> This backdoor only appears on decades-old VIA C3 embedded x86 processors

Modern Intel and AMD chips also have separate CPU cores that neither the user nor the installed OS control.

Intel Management Engine:

https://en.wikipedia.org/wiki/Intel_Management_Engine

AMD Platform Security Processor:

https://www.wikipedia.org/wiki/AMD_Platform_Security_Process...

Intel added them in 2008. AMD followed suit about five years later.

They should have mentioned that in the first line of the github readme, not burried deep down in the text.

It's not even a "backdoor", it's documented in the datasheet...

http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemia... (page 82)

...which along with the already publicly-known microarchitecture of the C3 makes this statement sound like total nonsense:

The rosenbridge backdoor is a small, non-x86 core embedded alongside the main x86 core in the CPU

I remember laughing at this with a few others knowledgeable in x86 when it first came out; a self-proclaimed "security researcher" who somehow failed to RTFM.

There's even a Wikipedia article about it now, with a link to the alternate instruction set documentation: https://en.wikipedia.org/wiki/Alternate_Instruction_Set

Also worth noting that the exploit was published nearly decade ago. Still, even at that time, those VIA CPUs were over 15 years old.

Perfect. The next the the bank's ATM "cannot process the transaction" we now have a pathway to debug the issue.