Comment by mojoe | Hacker News Reader

Comment by mojoe | Hacker News Reader

I am very curious about how long this hack took to complete. I write firmware for SSD controllers for a living, and this would probably take me many months of full-time work to pull off with an unknown controller (granted, I generally work on algorithms at a slightly higher abstraction layer in the firmware, and some of my colleagues who are more focused on the hardware interfaces could figure something like this out much faster than me). I am incredibly impressed by this effort.

Also, I want to mention that it's common to have multiple processors in storage controllers. I can't talk about the specifics of the drives that I work on, but for SSDs at least there are several layers of abstraction: the host interface to receive the data, a middle layer to perform management of the data (SSDs require things like wear leveling, garbage collection etc in the background, to ensure long life and higher I/O speeds), and a low level media interface layer to actually write to the media. These tasks are often done by different processors (and custom ASICs).

It took about half a year, mostly slaving away in the evenings and my day off. That was mostly because the WD firmware is pretty complex: you gotta remember almost 20 years of ATA/SATA/... cruft is stored away in the firmware, and the firmware doesn't help you by having any strings embedded in it.

Any plans to open it all up now (after badusb folks opened their code at https://github.com/adamcaudill/Psychson ) ?

At this point mechanical drives are pretty much dinosaurs, it would be only useful to tinkerers.

"At this point mechanical drives are pretty much dinosaurs, it would be only useful to tinkerers"

That may be true for end users / consumers, but I think that the advent of ZFS makes this particularly interesting for anyone that uses that filesystem.

The reason is, unlike most "RAID" that we've all used these past 20 years, ZFS does not want you to give it a raid set, or to put a raid controller between the disks and the OS.

Instead, the best practice is to present the raw disk to ZFS and let it do all the work. But that means you're more exposed to funny business on the part of the drive, etc.

I have, mostly. All my code, minus the directly-applicable shadow-password-hack thing ((to thwart script kiddies, if you're a bit knowledgable ytou should be able to re-implement it yourself) can be gotten from http://spritesmods.com/hddhack/hddhack.tgz

Yep, I know guys who worked at WD and they mentioned how cluttered their firmware is. They have an incredibly rigorous code check-in process, which means not a lot of code gets cleaned up, only more code gets added. It sounds like a mess.

Thanks for the read!

If you were looking at uncommented C with meaningless variable and function names, do you think you'd be faster? I think part of what makes it seem daunting is being familiar enough with the disassembly to read it quickly and easily.

If you already knew roughly how a HDD controller would need to work - what kind of I/O it would need to do, both at the controller end and the head movement end, couldn't you work backwards from there?

Reversing something like GC as needed in an SSD I can see as being harder, but again, wouldn't it largely be a matter of knowing that a certain number of parts of particular shapes - whether it's marking, tracing, copying / compacting, etc. - need to exist, and and finding them?

I think that if you really got stuck into the problem, it wouldn't take as long as you think. A lot of it is familiarity and fluency with the disassembly, I reckon.

(The closest I've gotten to this professionally was in reversing the Windows kernel and related user-side DLLs to debug a particularly thorny issue we had with the Delphi compiler, when I was at Borland. Not quite the same, but still a lot of staring at disassembly with not a huge amount of help. Ultimately, it only took a few hours of effort, in large part because there's so much tooling support, and things like messages and public symbols were available.)

Being more familiar with assembly would definitely help. The only time I look at assembly is when I'm using a JTAG debugger, which is not my primary activity.

Our firmware has a lot of ASIC pathways that are only accessible through register reads/writes, and in some circumstances only statuses are available through the registers, so I believe reverse engineering an SSD would be more difficult than it first appears.

I work on storage systems employing SSDs at a higher level still, hearing and learning more details on how things are working underneath is immensely useful and gets rarely discussed with the FSEs which is a shame. If there are things that you can share from your experience it would be great to learn more about the inner workings of SSD firmwares.

So far I only get to learn through the (few) failures that we actually see. That's the only time I get sufficient access to technical folks to ask the pointed questions and get a sensible response.

I emailed you, but my answer will probably be unsatisfactory. Too many IP rules.

Request: Please add a "bypass mode" so operating systems that want to can use the flash blocks directly (in other words, a /dev/mmcblk-like interface).

The business problem with this is that the vendor will no longer be able to provide any guarantee on the product since it will strongly depend on the user handling. It will also lose most if not all traceability to be able to say that the user did something wrong or didn't do something that was ought to be done to maintain reliability.

If some enterprising hardware folks wanted to create a PCIe or SATA attached flash with minimal interference for external control it would be very interesting to me too. I wanted to buy OpenSSD device for experimenting but at a price tag of $3000 it is well beyond reach for me for pure experimentation.

I wonder if crowd-funding can help bring such a thing to life.

There's nothing wrong with the SSD storing information on the handling of the device, even when it is in raw mode.

This could be solved with a simple fuze or lockout bit that is set. "if you enable this mode you void your warranty, your drive will be marked as such"

I appreciate the spirit of the request, but to be blunt any large company would probably never spend resources on this. Basically large SSD manufacturers are focused on billion dollar markets, and the demographic who would appreciate a "bypass mode" is probably so small that the company would never recoup money spent on implementing the feature.

Reply on news.ycombinator.com