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).

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."