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 


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.

Black wrote at 28 Feb 2015, 15.07:

"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" How dangerously ignorant. Such unknown-ness is *exactly* the reason why groups like the NSA would use such evil 'patches'. And as it is known now, they've been using it for 15 or more years. (If not just from the start, when harddisks where common devices.)

Steve Dupuis wrote at 20 Feb 2015, 20.34:

Hi .. The disk drive hacking is so far my favorite article on your site. It has helped me learn a lot more about storage and file systems. What is your background? Do you have a CV online? I'm just curious to know how you got into this. Regards, Steve Dupuis Ottawa, Canada

Sokolum wrote at 20 Feb 2015, 16.11:

One question, can an modified HD firmware prevent, when doing a full format: 'darik's boot and nuke', some hardrive sectors to be formated (beeing skipped during format)?

byteme wrote at 19 Feb 2015, 13.17:

<<<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 in the wild, I believe the firmware, of eleven major Hard Drive Makers, has been hacked already by a group known as Equation. http://threatpost.com/inside-nls_933w-dll-the-equation-apt-persistence-module/111128 http://www.zdnet.com/article/beyond-stuxnet-and-flame-equation-group-most-advanced-cybercriminal-gang-recorded/?tag=nl.e539&s_cid=e539&ttag=e539&ftag=TRE17cfd61

CraigB wrote at 19 Feb 2015, 9.56:

use PPM / PWM to make the SATA port give you audio directly. Just add a cap to remove the DC and you have music!

vimtut0r wrote at 18 Feb 2015, 18.48:


@Disceater wrote at 18 Feb 2015, 14.46:

@Disceater, ofcourse, the cost will be performance.

Mr. Smith wrote at 18 Feb 2015, 8.53:

We would be very interested in learning how to do this. Just kidding, we've been using this for ages. Great site, thoug. Love, NSA.

NSA wrote at 18 Feb 2015, 4.44:

https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/

ajawamnet wrote at 18 Feb 2015, 3.51:

Have you tried FreeRTOS on it?

Grunion wrote at 18 Feb 2015, 0.01:

From your description it sounds like you trigger your hacks by scanning the buffer RAM with the drive's CPU for trigger strings. As you said at the start of your analysis, if the CPU has to read or move the data in the buffer it actually slows down the performance of the disk drive. If this scanning of the buffer RAM by the CPU is going on all the time, the degradation in performance would be a dead give away that something is wrong. Or am I missing something?

binx wrote at 17 Feb 2015, 17.19:

Would it possible to use your hack to lock out the ability to update the drive's firmware? preventing your fwtool or any other standard tool for that matter from updating the firmware?

xorxor wrote at 7 Jan 2015, 13.18:

one addition, this independent foftware for the third wheel.. core has been commercially available for many years already *f*in some places*, ehm and it has been known to mysteriously brick SSD drives; I guess it was due to the whole boot firmware incompatibility thing. what is even more amazing that I heard it happening inside of that big country that is exempt from it happening there...; so no guarantee as to who had it put it there. anyway, the tool to install it is in the catalog as published by der german mirror newspaper.

xorxor wrote at 7 Jan 2015, 13.12:

I've been thinking about the disk-only MP3 player ever since there were 400GB hard drives with the TI-430 or something like that... it is time we finally built a primitive audio/video player/recorder. imagine security or logging system with just a camera and a hard drive; no external SATA or operating system to worry about/maintain.

0xafad wrote at 5 Jan 2015, 9.06:

Does this mean it's a race to the first HD-only music player?

Disceater wrote at 4 Jan 2015, 22.45:

If you wrote a patch to do simple data compression/decompression on the fly, could a hdd store more than eg its rated 2TB?

Sigrunen wrote at 2 Jan 2015, 23.12:

LOVE your site, and your initiative. Stumbled across this while trying to research a way to change the TLER timeouts, now that WD Red drives no longer support RAID. ZFS and NAS systems are still workable, as they have a longer timeout threshold. Would love to see if this is the right approach for such a project.....Thanks

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

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

Olivier wrote at 31 Dec 2013, 19.35:

@Michael Renner : he's talking about the HDD cache (internal memory chip of 8MB to 64MB), so not the OS cache.

nes wrote at 31 Dec 2013, 18.52:

Very interesting work. I too am wondering how you deduced the identity of the two identical cores from their JTAG id. Googling them doesn't appear to return anything useful, whereas the Cortex's ID turns up relevant boundary scan file. Perhaps the third core is used for low level formatting and factory testing, it being cheaper to include an otherwise redundant processor on the die rather than build a test rig with some intelligence that presumably would need to be tied up for some time per drive manufactured.

Bad.Spock wrote at 31 Dec 2013, 5.54:

Really cool. Seems like anti-forensic self-destruct HDD is plausible

Barb wrote at 30 Dec 2013, 1.11:

Brings a whole new meaning to "I installed Linux on my hard drive"...

Lamine wrote at 29 Dec 2013, 12.54:

Very interesting work. If I well understand, could this be used to read data from a WD drive encrypted using smartware encryption? if it's the case, it would resolve a lot of problems. Greetings from Algeria.

Paul wrote at 22 Dec 2013, 23.02:

Wow, just awesome. the extra cortex-m3 could do ethernet connected to spi to have a network drive. Did it have any spare io to use it as a mcu ? it would be extra scary if you somehow could connect to it wirelessly.

joe schmoe wrote at 22 Dec 2013, 11.47:

Interesting read.

juice wrote at 17 Dec 2013, 13.16:

Beautiful hack, shows how often overlooked pieces of embedded equipment can be an everlasting source of fun & learning :)

Michael Renner wrote at 12 Dec 2013, 11.45:

You could speed up the cache dropping by a sync && echo 3 > /proc/sys/vm/drop_caches if it's only the Linux cache. Not too sure about the read cache of the Hard disk if there's any. See https://www.kernel.org/doc/Documentation/sysctl/vm.txt for details.

bubo wrote at 8 Dec 2013, 6.01:

this is cool! two thumbs up! thanks for sharing!

kretschi wrote at 18 Nov 2013, 15.52:

I've collected several harddisk-PCBs (very old and pretty new ones) over the last years with the idea of using them as embedded systems in mind. None of my experiments got to the point of possible communication with the PCB, but with your great project it seems to be worth another chance. One little question: How do you translate from the JTAG-ID to the actual device? Are their any lists available? Keep up your excellent projects! :) Greetings from Germany

Rapper_skull wrote at 14 Nov 2013, 21.26:

Sorry, it's a WD too. Model WD5000LPVT

Rapper_skull wrote at 14 Nov 2013, 21.09:

I need something more simple, just changing model number in Samsung HDD, is there something for this?

Michael_H_Germany wrote at 12 Nov 2013, 15.28:

Awesome hack! I'd like to read those things. In times of the NSA/GHCQ spy scandal this will increase the importance of transparency!

Peter wrote at 19 Oct 2013, 0.13:

Awsome piece of work! The projects you develop are incredible and I would really look forward to hear some more talks from you.

vaL wrote at 23 Sep 2013, 16.45:

Hell of a paper! Phrack-school hack!

zoobab wrote at 11 Sep 2013, 14.49:

Hi, I got one of such HD with 8MB of RAM (WD10EAVS). Could you publish a more detailed pinout of the JTAG connector? Which toolchain have you used to cross-compile a linux kernel for it?

Gongzhu wrote at 29 Aug 2013, 17.02:

The protocol appears to work on some older drives (e.g. WD740) but not on some newer ones. For example, I can enable vendor specific commands on a WD7500AACS drive but none of the other VSC seem to work. Is there perhaps a command checksum that the older drives ignore, or else different protocol versions?

SomeGuy wrote at 28 Aug 2013, 18.07:

Would something like ZFS and checksumming prevent something like this? Or would it be just a question of manipulating the checksums which should also be saved on the disk?

Jason Ozolins wrote at 21 Aug 2013, 9.54:

@Rena: disk companies have wanted to sell smarter, (and more expensive!) disks for ages - it's a big reason why the T10 SCSI standards committee developed OSD (object storage device) extensions to SCSI. To store objects instead of blocks, you need most of a filesystem, except the name space (no files sitting in a directory tree, just a database of object IDs and where the objects are stored.) The problem is that nobody has really made a compelling performance case why OSD on each disk is any better than putting the intelligence in the server they connect to. For the extra money you'd probably pay for four fancy OSD drives, you could put a much faster processor/RAM/flash in front of four simple drives, and hey presto, you've got a Hadoop-style object storage node with Ethernet on it. Then have lots and lots of those in a rack and run your parallel searches on those.

Paul wrote at 19 Aug 2013, 17.05:

People running RAID arrays larger than a handful of disks often upgrade firmware to get bug fixes that would otherwise eat their data, that's the main reason for this convenience feature. Security is an afterthought as it always is outside of explicitly multi-user systems.

/dev/null wrote at 19 Aug 2013, 11.48:

An excellent article! Awesome hack.

Richard_M wrote at 18 Aug 2013, 18.21:

A great piece of deduction and a great hack. Well done, I enjoyed reading this very much.

Sprite_tm wrote at 15 Aug 2013, 19.04:

Marko: not if you don't have root access...

Marko wrote at 15 Aug 2013, 13.06:

just curious, wouldn't sync ; sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' be enough to clear the cache?

Rena wrote at 15 Aug 2013, 6.00:

A modified drive could also be useful for things that need to save a lot of data very quickly, like high-speed video. Hook a camera right up to the hard drive and write directly to it at thousands of frames per second.

Rena wrote at 15 Aug 2013, 5.59:

On the flip side, you could make smarter disks, that handle the filesystem themselves, and can do things like search at lightning speeds. (But the cynic in me can see them only supporting FAT and NTFS/whatever new FS Windows uses, and obviously encryption would prevent this from being useful...)

Raipat wrote at 8 Aug 2013, 17.06:

awesome hack, and one of the best talks at OHM2013 :)

Pavel wrote at 7 Aug 2013, 11.47:

This gives even more meaning to the "Don't trust your drive" idea behind modern filesystems. Until your firmware can detect this and recalculate the checksums on the fly, that is.

Sprite_tm wrote at 7 Aug 2013, 10.59:

Haltec: Thanks! I had an inkling he came from the GSM community, but couldn't find more about him. Do you happen to know a way to contact him? I'd like to thank him; after all, his post was the start of it all. Sam: Hard disk manufacturers sometimes do have firmware updates. I know of at least Seagate and Western Digital having bugs in some of their HDs, and issuing firmware updates for them. A simple jumper may indeed be the best way to fix this, although I'm not sure if reprogramming the flash is the only way to get this hack to work.

Sam wrote at 7 Aug 2013, 0.51:

While it may require specific code for each model of hard drive, this revelation is still worrying! Given a bit more time, it'll be possible to work out the details for different models, and maybe there's more in common between models than you think. You can't really say from just one example. Even if it only works on a few million of the millions of hard drives out there, it's still way more trouble than anyone needs! The best solution I can think of is for manufacturers to put a jumper on each drive to enable flash reprogramming. Practically nobody upgrades their drive BIOS (I never heard of it, at least), or needs to. So either disabling it altogether, or requiring a jumper setting, would be sensible. I wonder if the world's HDD manufacturers have heard of this, and also why one of them didn't think of this before!

Haltec wrote at 6 Aug 2013, 23.00:

Beautiful article, kind thanks for it. And the guy you are reffering to is well known reverser in GSM field. His name is Dejan Kaljevi&#263;. Brilliant minded neighbour. Best regards

Ez wrote at 6 Aug 2013, 21.33:

Great hack well explained. Congratulations

Jack wrote at 6 Aug 2013, 14.46:

Is it possible to get a clearer pic of your setup at "http://meuk.spritesserver.nl/foto/foto/hdhack/IMG_2294c.JPG" with an overlay of which pin you used for what? Seeing as it is different to the photos on "http://forum.hddguru.com/viewtopic.php?t=20324&start=" and I have the same drive.

Dr wrote at 6 Aug 2013, 0.53:

You have JTAG and clear code. Not bad

Rmy wrote at 5 Aug 2013, 16.39:

So impressive !

Frédéric Bourla wrote at 5 Aug 2013, 12.44:

Very good research. Congrats.

Roger Wolff wrote at 5 Aug 2013, 11.00:

Oh. Discussions over the weekend resulted in the insight that the "unused" processor is probably only unused on THIS version of the harddisk. On the "enterprise" edition drives they probably have a use for it. And it's cheaper to just buy two million of the three-core chips than it is to buy 1 million each of the two-core and three-core chips.

Roger Wolff wrote at 5 Aug 2013, 10.56:

The "persistent hack" is the twist you need to get attention from "blackhat" and the likes. But the normal use for this knowledge is also very interesting. For example, if you need to search a large dataset... No use in filling up the SATA bus. Just tell the harddisk to do the searching. I implemented that on the 6502 processor of my commodore floppy drive back around 1984 (the link to the computer was 9600bps, while internally in the floppy you had a whopping 37kB/sec or something like that!.... ) Talking about this, my brother said it'd be nice to run the webserver on the harddisk.... Annoying it has a sata connection and not a gigabit ethernet. For all the static content... Why not let the harddisk serve it directly?

Sprite_tm wrote at 5 Aug 2013, 10.32:

CMP: Huh, that's weird, I saw quite a few when I looked a few weeks ago. I use the Tiao TUMPA for my hacking, perhaps you can source it somewhere else. If not, the breakout boards will probably work too but miss the nice level-conversion chip on the Tumpa.

CMP wrote at 5 Aug 2013, 10.02:

Can you tell me where to get this FT2232H board? I can only find breakout boards that just all pins, but without connectors.

CMP wrote at 5 Aug 2013, 9.46:

Wow! You got my respect for this work. It kept me all night up thinking of the possibilities of these embedded controller after I read this. Pretty serious reverse engeneering you did here. I think this should show us that we can't trust anyone in the IT world. Not only in the software, but also in the hardware section. You may have already heard of infected bios roms or so. You don't know if the industry has a backdoor in their hardware, like found in some NAS. This is the way to Big Brother is watching you. We all should store our data in the Cloud, so they have easier access to it.

Moth wrote at 5 Aug 2013, 2.43:

This is cool article for a cool hack. Thanks.

Jai wrote at 4 Aug 2013, 23.59:

Ei it's posible to make a standalone MP3 player out of bare hard disk: cortex m0 is powerfull enougth and mass data storage and ram is present, a dac out of spi and screen on serial port

DMM wrote at 4 Aug 2013, 22.37:

Just amazing!

alon wrote at 4 Aug 2013, 22.21:

Really impressive work. Would be happy to hear your comment about encrypted filesystems, are they solving this pain completely? Also, were you able to communicate with the host's drivers? For example the SATA driver? is it possible to generate arbitrary SATA packets?

mickflemm wrote at 4 Aug 2013, 16.13:

Thanks a lot for sharing, amazing work ! Keep it up !

dontgetit wrote at 4 Aug 2013, 12.43:

"As you can see ... otherwise unused bit of ram at address 0xFFE3F000" (page4) can't find the address 0xFFE3F000 in the two code linstings on page 4 " echo "HD, live" > tst " (video on page6) do you just write "HD, live" to a file called tst? "The write of the magic string 'HD, lnx!' finally ..." (page7) how do I know that one have to use 'HD, lnx!' and what does that mean? I'm a complete noob, so sorry if that is already answered in the text and I just did not get it.

Yann wrote at 4 Aug 2013, 5.00:

yes problem with apostrophes my message was : wahhhhh.... magnifique travail tu es un maitre

Yann wrote at 4 Aug 2013, 4.59:

comment problem ?

Yann wrote at 4 Aug 2013, 4.57:

Rena wrote at 4 Aug 2013, 4.13:

Nice, I always figured this kind of thing was possible, but never heard of anyone actually trying it. Probably many other components have reprogrammable firmware too; NICs, CPUs (microcode), maybe even RAM? Can you trust your hardware?

Rena wrote at 4 Aug 2013, 4.12:

Nice, I always figured this kind of thing was possible, but never heard of anyone actually trying it. Probably many other components have reprogrammable firmware too; NICs, CPUs (microcode), maybe even RAM? Can you trust your hardware?

Orion Lawlor wrote at 3 Aug 2013, 23.03:

Scary but cool! If you've got an encrypted filesystem, anything passing over SATA is going to be encrypted and so resilient against both reads or unauthorized writes. But the kernel and encrypted filesystem drivers themselves are still vulnerable to a turncoat hard drive, because they of course can't be encrypted.

peevo wrote at 3 Aug 2013, 21.52:

Jah bless you. you made my day

anon wrote at 3 Aug 2013, 21.13:

fuck off, your something else. Booting linux using the controller of the HD? jesus christ are you for real? Nice work, wtf.

locu wrote at 3 Aug 2013, 20.49:

Amazing! You are very skilled thanks for sharing your study!

kang wrote at 3 Aug 2013, 19.19:

time to make a beowulf cluster of these boards.

Whistl wrote at 3 Aug 2013, 17.25:

Well done!

snoopybrown wrote at 3 Aug 2013, 15.21:


Jacek wrote at 3 Aug 2013, 14.57:


med berdai wrote at 3 Aug 2013, 13.57:

Interesting. Will this work even with filesystem-level data encryption ?

che wrote at 3 Aug 2013, 12.42:

this's so fucking awesome,cheers

salaami wrote at 3 Aug 2013, 6.56:

I guess we should just assume that anything in the pc is as vulnerable as any whole pc would be to the net without a firewall. As a solution, Can a computation with encrypted data work? In other words, if there is an encryption function (X), can a computer contain a set of operations that will work on tha encrypted data with the same result as a normal OS works on the the unencrypted data? If such an algoritm exists, then data could be encrypted at the input (think hardware encryption built into keyboards, NICs, microphones,etc. The data could be processed. The result would then be transmitted and decrypted at the destination (think hardware key decryption at the video card, sound card, or other output device)This way, any data taken off the pc is useless-even if it's taken off the ram, the hd controller, the usb or keyboard bus, etc. Of course the user would have to 'mate' his devices to the pc so that a unique encryption key is established and flashed to the rom of the input and output devices.

Abhi wrote at 3 Aug 2013, 6.45:

Thanks for writing this, it's been a while since I read something that was this interesting!

Yup wrote at 3 Aug 2013, 6.36:

And here, we see an example of the kind of "hardware backdoor" that I suspect provoked stories like these: http://www.geek.com/chips/spy-agencies-shun-lenovo-finding-backdoors-built-into-the-hardware-1563801/ http://www.theverge.com/2013/7/30/4570780/lenovo-reportedly-banned-by-mi6-cia-over-chinese-hacking-fears Even though, it isn't exactly simple to use these firmware hacks as backdoors, they certainly carry the potential to enable such behavior, which Mr. Domburg has demonstrated here.

Janos wrote at 3 Aug 2013, 6.17:

Awesome, and well, scary stuff. Thanks a lot! Hey, you might like this hacking contest on a live cd: http://sourceforge.net/projects/ctfomatic/files/ Granted, too easy for you, but perhaps you can find some interesting use for it still.

hellekin wrote at 3 Aug 2013, 5.22:

ROTFL! That was a great article, and a fantastic hack. Now I can look at that huge pile of bork HDDs in the dust garden of the hacklab with a renewed interest.

Michael wrote at 3 Aug 2013, 5.07:

Thanks! I just wonder why the HDD manufacturers don't set the "disable JTAG" bit when they flash the firmware in the plant. It's quite a common requirement in automotive.

tom wrote at 3 Aug 2013, 4.43:

Very cool writeup.

PodeCoet wrote at 3 Aug 2013, 2.56:

Absolutely amazing work! This is this first write-up I've read word-for-word in quite a while

dan wrote at 3 Aug 2013, 1.04:

Very interesting. I wonder if a dac cld be interfaced somehow and fw modified turning an hdd into a music player with very little in way of extra hw. I doubt there is an i2s but if the uart cld run fast enough the hw required to translate to i2s wld probably still be simpler than a sata/usb-sata bridge and additional mcu.

sineer wrote at 3 Aug 2013, 0.07:

*VERY* Impressive! I always wondered how someone would implement this exact hack. Thank you very much for this post!

Damon wrote at 3 Aug 2013, 0.00:

Aaaawesome. I have always wondered why there aren't any "open" HDD controllers. So much potential in that. I'd like to see an OpenHardware HDD PCB some day. You could write your own Firmware, or use modules to do funky stuff (crypto, data manipulation, control caching etc.), or simply buy these cheap or make them yourself (HDD PCBs are relatively expensive). Unfortunately, I don't have the knowledge... yet. Is anybody up to hardware yet?

rasz_pl wrote at 2 Aug 2013, 23.46:

Have you dug into other side of the connection? How does the data from the head land in the cache chip? Is there a dedicated ADC block inside this triple ARM? Basically would it be possible to quickly (at least 50-100MB/s) inject your own data and use this chip as a generic something-to-SATA bridge? My side project for last ~two months was disassembling GL3220 USB3.0 Card Reader (8051 core) firmware and trying to figure out a way to reuse it as a generic 16bit-to usb3.0 using its CompactFlash port. Chip itself easily pumps 120MB/s and readers that use it cost ~$17 (Transcend RDF8). Ordinary USB 3.0 bridges start at ~$25 for BGA Cypress part.

nly wrote at 2 Aug 2013, 23.26:

Most SMART enabled drives keep track of their total runtime in hours and power cycle count. You could use that to add a little key system so the password used to acquire root can change with time.

arj wrote at 2 Aug 2013, 22.12:

Another reason to run full disk encryption then I guess :)

Sprite_tm wrote at 2 Aug 2013, 21.19:

Chris: Yes, but I have to be root to do that, and getting root is the whole point of the excercise.

Chris wrote at 2 Aug 2013, 21.18:

Amazing work! <blockquote>Because Linux caches the shadow file (like all files recently accessed), I have to generate a lot of disk activity for the file to be 'pushed out' of the cache; that way, when I try to login again, Linux will be forced to fetch the shadow file from disk again.</blockquote> You could also just say "# echo 3 > /proc/sys/vm/drop_caches", if I understood your setup correctly.

matt venn wrote at 2 Aug 2013, 20.25:


Gdogg wrote at 2 Aug 2013, 19.53:

As usual your hacks make me feel like a stupid piece of shit. Well done!

Riffer wrote at 2 Aug 2013, 19.36:

I just want to thank you for this very deep insight into whats just called a harddisk. Really great pice of research!

george wrote at 2 Aug 2013, 14.45:

Just wondering if the Cortex-M3 which did not seem to matter if enabled or disabled could be related to the green-ness of the drive, hibernation and power saving. In my Nas4Free I have several settings for drive power saving and while the simplest would spin down the motor, there are very deep ways of hibernation that also power off most of the drive electronics. Shutting down the 2 Feroceon cores and keeping the Cortex-M3 seem like an ideal way. but of course it is also fully possible the M3 to be entirely vestigial or to have landed in the chip to support features not implemented in this particular model. (not drive encryption, I suppose)

george wrote at 2 Aug 2013, 11.51:

I'm flabbergasted as is usually the case with your hacks. I have about 50 Cdrom drives (52x Aopen) from 2000-2001 (got them for free) and I was fantasizing to use their innards in several Domotica projects (instead of some Arduino boards, they also contain nice step-motors), they have a Mediatek chip used as controller, obviously no documentation to be found and I'm not of Jeroen caliber to be able to reverse-engineer it myself.

Zmaster wrote at 2 Aug 2013, 11.40:


Leave a comment:

Your name:

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

Your comment:

© 2006-2014 Sprite_tm - Contact