Trammell Hudson writes about firmware security, hardware hacking, and maker projects, including Heads and the Thunderstrike Apple EFI attacks.
HN commenters recommend his site for the Heads secure boot project, Magic Lantern work, and projects like a Mac SE video adapter.
> As far as I know, you’ll need to take the machine apart to reflash it, plus special hardware
This doesn't take very long. Maybe 5 minutes to disassemble the machine.
As for hardware, you can flash SPI chips using a Teensy and a clip chip. [1] The total cost of parts is under $30.
Incidentally, I highly recommend investing in one of these if you're doing firmware development for routers. It's so much easier to flash a backup than muck around with TFTP.
> because when a firmware password is set, a Mac requires the password to choose a different boot disk.
This is hardly unique to Apple. Most PC laptop manufacturers also disable changing the boot device or choosing a temporary boot device when a setup password is enabled.
> with this feature, Apple HQ can give a service center the ability to clear a particular firmware password without giving them a universal backdoor (hardware or software).
Um, this is how it works for PC firmware passwords as well. Unless there is a keygen available, most modern implementations use a hashed value from the serial number or hard drive as the master unlock password. It's unique to the laptop being unlocked.
[1] https://trmm.net/SPI_flash
Why are you insisting on going back to the 1970s?
What you are describing is more or less what my first computer terminal was in 1978: a second-hand ASR33 (https://trmm.net/Model_ASR33_Teletype/). If that's too big and bulky for you, there was a Brother electronic typewriter in the mid-1980s that could save small amounts of text in its memory for printing later. (https://www.shopgoodwill.com/Item/85456117) You could also interface it to some form of computer.
These things were superseded by word-processors: Dedicated computers that had screens, keyboards and printers. That enable you to prepare text, fix up your typos, shift text around, and when you were satisfied with it, to print out your final copy.
Finally we had general-purpose personal computers that could not only do word-processing, but were just as happy doing financial work and also browsing the internet.
With Intel Boot Guard (now almost pre-enabled on all laptops on the market), the CPU verifies the digital signature of BIOS code. The public key is burned into the chip [0] by the OEM before it leaves the factory. If signature verification fails, the CPU refuses to execute any code. Naturally, any code modification in the BIOS causes the check to fail and effectively bricking the BIOS.
[0] Actually the PCH, aka southbridge, not the CPU. But it's not much of a difference for end users.
See:
* Intel Boot Guard, Coreboot and user freedom
https://mjg59.dreamwidth.org/33981.html
* Why You Don't See Coreboot Supported By Many Modern Intel Systems
https://www.phoronix.com/news/Intel-Boot-Guard-Kills-Coreboot
* Bootguard (for a technical description)
https://trmm.net/Bootguard/
>> It was completely implausible - the chip that was identified could not possibly carry enough processing ability to do anything useful as far as espionage goes, had no connectivity to networking, and there was never any evidence of communication from these devices to anything suspicious or unknown.
> Could the device not simply get the host to do these things for it, by e.g. rootkit-ing the server’s BMC? A “hardware virus”, per se.
IIRC, that's exactly what was alleged in the article. It was an implant that sat on the BMC ROM bus, fiddling with bits as the ROM was read during bootup. No need for any networking or processing ability beyond what was needed to that. This guy actually did a POC of that: https://trmm.net/Modchips/.
So totally plausable.
> That said I don't like contributing to the business model of paying for privacy - seems broken.
I fully agree.
But to be fair, in a other comment someone linked to a website [0] explaining that the app could be used without connection to internet. So in this case perhaps Bosch didn't have as much of a malicious intent as originally thought.
Quote from the link:
However, [..], the BSH "HomeConnect" appliances have a no-cloud mode built into their app without any hacks required to disconnect them from the internet. They do require a one-time connection to perform key exchange of a long-live authorization key, but from then on the appliances can be operated entirely disconnected from the network. [0] https://trmm.net/homeconnect/#no-cloud-mode
Several months after the story was published someone actually presented a proof of concept demonstrating the practical feasibility of the claimed hack[1]. See presentation at https://media.ccc.de/v/35c3-9597-modchips_of_the_state (https://www.youtube.com/watch?v=C7H3V7tkxeA), and project website at https://trmm.net/Modchips
There's irony in how people repeat and share the technical rebuttals long after those rebuttals have been conclusively rebutted themselves. That in no way absolves Bloomberg, but the indignation of their critics is tiresome.
[1] Of course the specific details of the claimed hack were never reported, but the proof-of-concept fits the claims, and in any event is more than sufficient to rebut the rebuttals.