I don't post here often, forgot my password and even my username. So I created a new just to post this:
I used to have a computer store, and used a very advanced data recovery system called PC3000.
What I had retailed for $14K, it did amazing things, one of which was "fixing" the firmware on drives to enable data recovery.
I had a special cable that connected to the HDD, and I would be able to intimately work on the firmware using commands from hyperterminal. (if you
look at a Seagate drive you will see four pins at the end of the board, that's where you connect)
There was a bug in a certain Seagate 500 gb drive where a cache area in the firmware wasn't large enough and would "spill" over, crashing the
firmware and making your data inaccessible. The drive would not even show up in the BIOS when this happened. In addition to the cache, there are other
"writable" areas of the drive, such as the S.M.A.R.T table which tracks errors and warns of impending failure.
I would have to apply power to the drive with a piece of paper interrupting the contacts that give the drive power, connect in hyperterminal, and then
pull the paper to spin the drive. Then perform some erase functions via the menu driven interface, blowing away the S.M.A.R.T table, faulty cache, and
some other values. (I sold the system, so this is all from my recollection. ) There were some steps you had to go through, it would sometimes take
multiple tries, and I would even have to stray from the documented procedure to get the data off. Then I would immediately flash the firmware without
the bug, so help ensure a successful recovery. The hyperterminal interface was menu driven, and well documented by Seagate, WD and others not so much.
There are message boards, full of Russian guys, where you could MAYBE get questions answered. They had the WD, Maxtor & other docs, but as you may
notice, the HDD manufacturers have kind of consolidated.
Another trick was to remove the NVRAM chip from a donor drive, and put the NVRAM chip from your data drive in it's place and switch boards. The NVRAM
chip holds all the specific geometry for your drive and is specific to EVERY drive, since every drive has bad sectors initially at manufacture and
this must be described EXACTLY or you ain't reading nothing.
I only delved into the firmware operations enough to get the EU's data recovered. But there were many more options in the menu, most of which I had
no idea what the result would be, and I obviously did not experiment with customer's data.
The long and short of this is that I certainly can imagine some extraneous code being in there that could place a DLL on ANY sector it wants. It has
complete and full control.
But - for this to be successful I think it needs to know something about your OS. I would suspect Windows and Mac to be the most vulnerable. There
isn't a lot of room in there, and the more possible scenarios they try to cover needs precious space which possible future firmware updates may
clobber. If the exploit covers ALL scenarios it is also easier to detect.
When I had the store I also submitted quotes to the US Army for a network attached storage system I sold. It used ATA over Ethernet, and unlike iSCSI
or NFS it DID NOT USE TCPIP. The box was addressed by MAC address, and was commonly used in VMware ESXi virtual environments. It's manufactured by
ONE company - Coraid, the inventor of the ATAOE protocol. To access the storage system you needed an HBA manufactured ONLY by them, which is
essentially an Intel E1000 nic with special FIRMWARE. I suspect the US Army may be clued in on how to avoid this HDD exploit.....
I was not such a high level Coraid partner to get the "good" pricing, so I think I was receiving the RFP's just to be quote #3 to follow the get 3
quotes rule. But they were for HUNDREDS of drives, Enterprise Class SAS, & MANY cabinets.
Virtualization is most likely the the key here. VMware uses a disk image file like drive.vmdk. There is no firmware in a disk image file. The bios of
a VM is the Intel 440BX reference bios from the late 90's, and you can switch this out with a known clean one. SO how does bad firmware code know
where to insert a DLL in a monolithic disk image? I think such a feat may not "fit" in the limited extra space available in HDD firmware. It's one
thing to add some code, but to make Seagate solder a bigger chip on the board? And just to be sure, lets put the disk subsystem in a remote box, with
NO IP stack, attached to a special NIC with NO IP stack.
So the countermeasure is to run a Virtualized system, you can even build an ATAOE SAN if you are really paranoid.
All of my pc's are virtual, this one I am typing on, my kid's pc's etc. I use PCI Passthrough for the graphics cards, and can play the latest
Wolfenstein The New Order on the highest settings. The box I use has 6 video cards, with a different OS running on each one. As I type, my 10 yr old
is playing Teraria on Steam, & the 13 yr old is playing Super Meat Boy on the same box. It runs any Windows, Linux, SteamOS, Mac, and even Android
x86. I have been lazy about the SAN though......
I have a project on Hackaday.io (Hydra Multiheaded Virtual Computer) that details the 6 card build. Check it out, build one yourself, and keep the NSA
out of your data, questions are welcome and it's Open Source. I haven't updated in a while, but I am working on a single card living room gaming
build and will be updating soon....
Hydra Multiheaded Virtual Computer