Welcome

Conclusion

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

david wrote at 10 Dec 2014, 8.11:

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

HDD Firmware Guy wrote at 30 Nov 2014, 16.57:

This is why any embedded system should always have its JTAG port disabled and all firmware-update mechanisms requiring digitally signed firmware images. Your HDD vendor screwed up.

Jaztec wrote at 28 Nov 2014, 0.52:

This is one great article! Awesome man.

koala_man wrote at 27 Nov 2014, 22.49:

This is pure awesome.

indu wrote at 27 Nov 2014, 18.52:

thank you for your time! low level of literacy for this kind of stuff, but I love utilizing abandoned hardware for projects like this and learning a bit more each time. great to see someone with more knowledge use the technique to greater effect.

Chris wrote at 27 Nov 2014, 16.55:

We've gone from programmable cpus, to programmable components (e.g. flash and controllers on disks, disk controllers, USB controllers, or video), to programmable cables (e.g. HDMI or thunderbolt). Imagine the hackability (and trustworthiness [lack of]) of a machine with re-programmable everything ... like my Mac: the CPU, the disk drive, the video cable, the disk-drive cable, ... TPM isn't going to protect anything ... And we thought DLL hell was bad: we now have to do firmware upgrades to our disk drives [see Seagate's website], and even our Thunderbolt cables... who's going to do all that administration?

xor007 wrote at 27 Nov 2014, 16.18:

I bow to you man!

jes wrote at 24 Nov 2014, 15.30:

f****ing incredible man, I loved the reading having debugged hardware keys for years. go on like this! +1

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

Leave a comment:

Your name:

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

Your comment:


© 2006-2014 Sprite_tm - Contact