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

inawe wrote at 3 Aug 2014, 15.13:

You sir are a fucking genius. Well done I enjoyed the read.

Pinery wrote at 8 May 2014, 17.24:

help? cable VTAR,nTRST,TDI,TMS,TCK,RTCK,TDO my.cfg interface ft2232 ft2232_device_desc "TIAO USB Multi-Protocol Adapter A" ft2232_layout jtagkey ft2232_vid_pid 0x0403 0x8A98 adapter_khz 1000 reset_config trst_only separate trst_push_pull feroceon.cfg ... #reset_config trst_and_srst openocd -f my.cfg -f feroceon.cfg telnet localhost 4444 >halt Halt timed out,wake up GDB. timed out while waitting for target halted in procedure 'halt' ????

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'.

Leave a comment:

Your name:

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

Your comment:

© 2006-2014 Sprite_tm - Contact