What Bloomberg proposed - sniffing the TTL signal between BMC and boot ROM and flipping a few bits in transit - is far from science fiction. It would be easy to implement in the smallest of microcontrollers using just a few lines of code: a ring buffer to store the last N bits observed, and a trigger for output upon observing the desired bits. 256 bytes of ROM/SRAM would probably be plenty. Appropriately tiny microcontrollers can also power themselves parasitically from the signal voltage as https://en.wikipedia.org/wiki/1-Wire chips do. SMBus is clocked from 10khz to 1mhz, assuming that's what the ROM was hanging off of, which is comfortably within the nyquist limit on an 8 - 20mhz micro.
Something similar has been done in many video game console mod chips. IIRC, some of the mod chips manage it on an encrypted bus (which Bloomberg's claims do not require).
"On PsNee, there are two separate mechanisms. One is the classic PS1 trick of watching the subchannel/Q data stream and injecting the SCEx symbols only when the drive is at the right place; the firmware literally tracks the read pattern with a hysteresis counter and then injects the authentication symbols on the fly. You can see the logic that watches the sector/subchannel pattern and then fires inject_SCEX(...) when the trigger condition is met.
PsNee also includes an optional PSone PAL BIOS patch mode which tells the installer to connect to the BIOS chip’s A18 and D2 pins, then waits for a specific A18 activity pattern and briefly drives D2 low for a few microseconds before releasing it back to high-impedance. That is not replacing the BIOS; it is timing a very short intervention onto the ROM data bus during fetch."
> why not just modify it instead of adding physically observable devices to mess with it?
Look to the video game mod chip industry for your answer. Consoles obsessively verify system integrity from boot ROM to game launch. Most firmwares and OSes are encrypted, signed, hashed. Flipping bits in transit and perhaps only at specific times like system power on allows for the ROM to be read, verified, and checksummed correctly without detection of the implant. This makes the implant not only persistent, but stealthy. Even pulling the ROM chip and replacing it with a different IC would not remove the implant. And if the injection point were chosen carefully, implant functionality may reasonably be expected to persist across ROM updates. This is exactly the case with the PSNee mod chip I mention above. If I had to wager a guess, it'd be because the target, like console makers, was known to update and verify ROMs, which is SOP is any large org.
In terms of being physically observable... barely. You'd need an X-ray to find such a thing buried between PCB layers or inside another component. And not only that, you'd need to be routinely X-raying all your incoming equipment and comparing all the images. And even if you dug the thing out, you'd get a few dozen bytes of ROM out of it with no clue about who made it or how. Perhaps you might be able to determine origin for the silicon based on doping ratios and narrow it down to a few facilities operating at the right feature size. How many of us, upon receiving new equipment, immediately disassemble it to bits, individually x-ray each, then re-assemble it? Not many.
It's not a dumb idea. And whether or not actual evidence exists, exploiting the firmware on the board management controller is exactly the place where you can poke with the least effort for the greatest reward. That alone makes the attack plausible. Honestly surprised we haven't seen a BMC worm yet.
Something similar has been done in many video game console mod chips. IIRC, some of the mod chips manage it on an encrypted bus (which Bloomberg's claims do not require).
Here's one example of a mod chip for the PS1 which sniffs and modifies BIOS code in transit: https://github.com/kalymos/PsNee
"On PsNee, there are two separate mechanisms. One is the classic PS1 trick of watching the subchannel/Q data stream and injecting the SCEx symbols only when the drive is at the right place; the firmware literally tracks the read pattern with a hysteresis counter and then injects the authentication symbols on the fly. You can see the logic that watches the sector/subchannel pattern and then fires inject_SCEX(...) when the trigger condition is met.
PsNee also includes an optional PSone PAL BIOS patch mode which tells the installer to connect to the BIOS chip’s A18 and D2 pins, then waits for a specific A18 activity pattern and briefly drives D2 low for a few microseconds before releasing it back to high-impedance. That is not replacing the BIOS; it is timing a very short intervention onto the ROM data bus during fetch."