More on my ongoing chase of #badBIOS malware.
plus.google.com
plus.google.com
https://plus.google.com/103470457057356043365/posts/3reWRqDM...
"So it turns out that annoying high frequency whine in my soundsystem isn't crappy electrical noise that has been plaguing my wiring for years. It is actually high frequency ultrasonic transmissions that malware has been using to communicate to airgapped computers [...]"
This person is either mentally unbalanced or they're intentionally trying to troll the paranoid.
Case in point regarding this specific post:
"The tell is still that #badBIOS systems refuse to boot CDs (this is across all oses, including my Macs)"
Macs don't have BIOS - they have a BIOS emulation / compatibility layer. They run on EFI. Additionally, there's evidence that Macs contain a hardware Boot ROM which pre-boots before EFI and verifies the firmware cryptographic signature is valid. About the best attack that's been done so far is a malicious dongle that needs to stay connected to the machine during boot. If you'd like more information about how difficult it is to re-program Mac EFI without Apple's secret signing keys, by all means read here: http://ho.ax/De_Mysteriis_Dom_Jobsivs_Black_Hat_Paper.pdf
The only value in reading this submission is science fiction entertainment or research into the possible mental problems of the author.
2. Differentiating BIOS or EFI at that level is a semantics game. It's firmware, and on x86 it's traditionally called BIOS. There's the API difference, but they serve approximately the same purpose. Most "BIOS"es since 2009 are actually UEFI underneath, while some early UEFI implementations were 80% BIOS with just enough UEFI surface tacked on to boot Windows Server in UEFI mode.
3. It's somewhat unlikely that Apple built some custom circuitry to run before the CPU gets its chance to run x86 instructions. Without Anchor Cove, the state of the art on x86 is that the firmware verifies itself by measuring into the TPM. Considerations of the usefulness of such an operation are left as exercise to the reader.
The "SOS" mentioned in the paper beep seems to be recoverable with a rescue CD (https://discussions.apple.com/thread/2164874), so that sounds like a self-test of the firmware (with even enough support to load files from media, for which almost all hardware must be initialized).
The only way to make this remotely safe would be to lock down parts of the flash in hardware (like Chromebooks do), but I'm not sure Apple even considered that as a threat. The SOS thing is probably just a user-friendly way to cope with flash updates that went wrong.
That Black Hat paper stopped with SOS, and it seems like they didn't even look how to circumvent that test.
4. (U)EFI runs whatever PE/TE binaries it gets presented. UEFI Secure Boot (not relevant for Macs) locks that down a bit, but in-flash binaries are typically exempt from signature tests (EDK2 allows to configure security levels for 4 source categories: IIRC Flash, Option ROMs, readonly media, readwrite media)
5. The Black Hat paper claims that UEFI Secure Boot and TPM somehow interact. They don't. Secure Boot is specifically designed to work without a TPM.
Reading across the entire account (there's more than just this post), it indeed sounds like science fiction and there are some wild suspicions, but it's still just so plausible.
At a minimum, this will inform a few more people about real work that's been done with USB and hard drive controllers (by @travisgoodspeed, @SpritesMods).
Instead it provides a lot of weak correlations and handwaving. "Suspicious fonts on my system! Better drink my own^w^w^w assume I have malware from the plot of an AI-takeover-thriller."
I hope people are able to get real evidence on this, stuff like information from bus-analyzer or execution inside a in-circuit emulator.