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

Mike74 wrote at 5 Apr 2014, 14.44:

Do you have the password for this site http://www.griol.com/ftp/?

dencee wrote at 1 Apr 2014, 4.41:

I'm very curious how you managed to deduce the firmware vendor command to read and write the flash via SATA. A trial and error method would run the risk of false positives and even worse, destroying the drive's firmware. Care to share? Here's the statement I'm referring to: "After some messing around and guessing VSC parameters, fwtool could all of a sudden also read and write the flash of a HD attached to the PC it's run on." Great work BTW!

11th-Hourô wrote at 10 Mar 2014, 14.24:

This is really cool stuff

Alan wrote at 7 Feb 2014, 3.05:

Have you considered trying to alter a WD firmware to see if TLER can be re-enabled on consumer drives like the WDXXEARS drives?

Sprite_tm wrote at 10 Jan 2014, 12.12:

Sam: Yes, I know that. WD doesn't have a shell running on that port, and WD is the only manufacturer I know the JTAG-port of. For this purpose, having a JTAG port is better than having access to a (restricted) shell.

Sam wrote at 10 Jan 2014, 1.50:

You're making it way too complicated. The unused "jumper" pins on most disks are a TTL or CMOS level RS-232 port. There is a shell used for debug and manufacturing on it, people have discovered and documented commands.

no_so_nosee_nsa wrote at 2 Jan 2014, 18.03:

Thanks for sharing. Seems things in the world are going to get a lot worse, maybe never get any better.

ein wrote at 2 Jan 2014, 9.55:

Great job mate! Keep goin'.

Thomas wrote at 2 Jan 2014, 4.11:

I wonder if the Cortex-M3 has access to the same memory map as the arm cores. Having access to the M3 would give you the ability to run persistently, and not rely soley on hooks from the original firmware.

JJ wrote at 1 Jan 2014, 1.14:

Awesome detective work. You are so right it was possible. http://cryptome.org/2013/12/nsa-catalog.zip

Leave a comment:

Your name:

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

Your comment:

© 2006-2013 Sprite_tm - Contact