Spritesmods

The VM may get compromised, it depends on how you set it up, not all apps need to phone home for a start and dont need anything more than limited network access but thats firewall/IPS/IDS domain. You hint your may be corporate unlike a home user who has less tools and disposable income at their disposal and VMware unity is a quick cheap fix as its free for home use.

Its ok to burn an image to the ground, do you check your firmware like your bios with something like Copernicus?
https://www.mitre.org/publications/technical-papers/copernicus-2-senter-the-dragon
or HDD firmware hacking ?
https://spritesmods.com/?art=hddhack&page=1

Your persistence is right there, doesnt matter how often you reinstall an OS then if you have a system running like a sim card working with a smartphone OS but also independently communicating with the hw like a bluetooth/wifi mesh network but you also have network printers/scanners and other HW that connects to a network to check out to check out the firmware for. I loved having to flash the old EEPROM's, physically taking the chip out, removing the sticker over the quartz window, exposing it to UV light, before sticking the label back over the window and then flashing it on a EEPROM flash machine, that physical process made it harder to hack unlike today.

So how quickly can you get your backup loaded on blank servers, workstations and switches? Exchange server can take its time if people have GB+ mailboxes.

This is an interesting post mortem of…

Oh, you're absolutely right that modifying SSD firmware gives you a lot of fun possibilities for hijacking a machine, but that is not new either, it's a threat vector that has been known and investigated for many years now. Here's someone running Linux on an HDD controller in 2013:

https://spritesmods.com/?art=hddhack&page=1

It's well known that SSD vendor security is usually atrocious; these companies do not have much experience building secure-boot systems, and there are often vendor-specific backdoor commands and such. You absolutely do not need the resources of a state actor to pull that off; a good reason and 5-6 digits' worth of (competent) security researcher time ought to do it. I've spent half of my life breaking systems that try a lot harder to have secure boot than SSDs, as a hobby.

Indeed, IOMMU support is critical in the modern hardware ecosystem. Honestly, any system that does not use them by default for all off-chip peripherals in 2021 is just unsuitable for any kind of sensitive use case. That, plus FDE with hashtree authentication, eliminates SSD compromise as an attack vector.

Is the controller really going to be that much simpler on a HDD? On HDD you still have things like command queuing, caching, checksumming and bad block remapping just as with SSD. Sure you don't have the flash translation layer, but I'd expect processing of the analog signal going to/from the heads to be a processing headache too. I wouldn't be surprised if they have to do temperature compensation and factory and/or runtime calibration of the analog path. Of course much of that will be done in fixed-function custom hardware blocks, but almost certainly so would a SSD for eg. ECC calculations.

https://spritesmods.com/?art=hddhack&page=3 has some data points on a 10+ year old HDD - 3 ARM9 feroceon cores + Cortex-M3 core. Doesn't sound too simple.

There might be a way tune the risc-v port to this chip if there isn't one tuned already, and while it is likely you wouldn't be able to run linux well on them at the moment, and you'd definitely need some additional rw memory of some form, it would be possible, it does run on microcontrollers with worse specs.

For example here is how to get Ubuntu linux to boot on an 8-bit AVR ATmega1284p, by emulating ARMv5:
http://dmitry.gr/index.php?proj=07.+Linux+on+8bit&r=05.Projects

And as most people know, but if they didn't, here is linux on a hard drive microcontroller
http://spritesmods.com/?art=hddhack&page=1

And probably the best option for performance, if it can be ported over, uClinux doesn't require an mmu.
http://www.uclinux.org/ports/

I guess writing a new hard drive firmware from scratch, without inside knowledge, would be close to impossible.

But why start from scratch if you can just modify the existing firmware? And that seems to be perfectly possible:
http://spritesmods.com/?art=hddhack

I'd say the most difficult and resource consuming part is to make versions which work on as many brands, models and revisions as possible, and make them all robust enough so they won't be detected because of random malfunctions.

But I don't know anything about hard disk firmwares: Perhaps they are not too diverse and once you know how to modify one drive, the others will follow easily?

FYI all modern hard drives have multi-core ARM or Risc-V microprocessors built-in. Usually one core manages the motor control and signal decode from the RW head and another core runs an embedded OS and manages the data interface to the host computer. Folks have managed to get malware running on the hard drive's embedded CPU(s)[0] as well as full blown Linux distributions [1]. So your average hard drive definitely already has enough grunt to get the job done. Just needs a firmware written to expose the functionality.

0: https://hackaday.com/2015/06/08/hard-drive-rootkit-is-frighteningly-persistent/

1: https://spritesmods.com/?art=hddhack