So, there you have it. While the hard disk controller is a beast without much data known about it, it's still perfectly well possible to reverse engineer it and to write custom code for it. The unknown-ness of the controller does make it harder to write generic hacks, which makes me doubtfull that a thing like the evil firmware patch will ever be seen in the wild: it's much easier to just get another zero-day software exploit than reverse engineer the firmware of every single hard disk every server you stumble upon has.

I also hope to have proven that a broken hard disk is something you can still use. While the mechanics of a broken HD probably are shot, the PCB still contains an usable embedded system, which actually is pretty powerful considering you can usually get broken hard disks for free.

Releasing the source-code for a security project always is a nasty subject. I want to release code, but I do not want to be responsible for a lot of permanently hacked servers... I decided to compromise: you can download the code I used here, but I removed the shadow-replacement code. Make note: I'm not going to support the process to get all this running in any way; it's a hack, you figure it out.

« Prev 8 

Last 10 comments Show all

Kevin Matthews wrote at 13 Jun 2015, 15.53:

Could you hide a bit of the hard drive from the OS for your own use? That would really increase what you can do with the drive. No this drive is not this 100 GB it's 90 GB now ignore what I am doing...

Wout wrote at 25 May 2015, 12.04:

Now, a filesystem like btrfs or zfs that has a tree of block checksums going all the way up to the root of the tree is protected against this, right? The disk can only return the data that was written to it, or it would trigger a checksum failure.

mike wrote at 30 Apr 2015, 3.56:

This is the exact method used to build some data recovery tools. ACE labs (from Russia) sells a setup that can flash their recovery firmware to all sorts of drives, including many much much newer ones. They intend it for data recovery, but of course this technique has been used for a lot of other purposes. Being in the forensics side of things, I can tell you that you won't find an open JTAG port on many newer drives. Some controller manufacturers (SandForce) have gone as far as to encrypt their firmware (as well as the data). Not sure anyone has figured out how to do this on their drives yet (I know ACE hasn't). Also with SSDs taking up the market, the controllers are much much more powerful. Modern SSD controllers can be quad-or-hex-core ARM 9+ jobs running at 800MHz+. An exploit could hide anywhere in one of those.

Aivan wrote at 25 Apr 2015, 22.58:

Well, nice job. But there is some fw you can extract I guess. WD make HDD for Xbox and those one use a different FW u can get on Internet. Also there is a DOS aplication that Flash and back up a WD to be complatible for the Xbox 360. FW of WD are not so far. I'm not on the pc with that FW links, but you can extend this hack. Even the embedded system is an interesting thing lol! Regards - Sorry for Engrish ;P

Krtek wrote at 16 Apr 2015, 19.14:

NSA is one step further... :-) http://www.wired.com/2015/02/nsa-firmware-hacking/

Hitechcomputergeek wrote at 11 Apr 2015, 8.03:

What about using the third core, the Cortex-M3, to run stuff (like Linux)?

Sanford Expo wrote at 4 Apr 2015, 21.09:

Common sense would dictate that any and all reprogrammable firmware should have a switch or jumper for manually disabling the reprogramming operations(s). Not just on hard drives, but on all hardware. So why is common sense not being followed? Hmmm... and convenience and dumb users are not valid excuses.

pctek9 wrote at 21 Mar 2015, 18.14:

The United States is the only superpower supporting freedom and democracy. Now that we know nsa uses this through equation group, just imagine what those brilliant little chinese electronic designers have at their disposal? or even the russians? I bet MSS and FSB have firmware rewriters that have not been discovered yet. Isn't it really time for antivirus that scans firmware, and firmware signing, or even a physical r/w switch to update firmware?

E:V:A wrote at 3 Mar 2015, 12.27:

BTW. I assume you've probed for additional serial interfaces? Because all M3's are specified to use both JTAG and SW (serial) interfaces for debug purposes, which probably mean you should see some dmesg-like output during bootup, somwhere...

Casey wrote at 1 Mar 2015, 20.33:

Interesting article. Sounds like you had some fun working all this out. My laptop has killed two HD's so far in less than a year. The errors reported by the drive is confusing if not crashing the USB modules in Linux making standard recovery rather difficult. I'm thinking that your code might help in recovering some of the data off the drives.

Leave a comment:

Your name:

What does this picture say?
Sorry, this is a captcha

Your comment:

© 2006-2014 Sprite_tm - Contact