Hard disk hacking
spritesmods.com
spritesmods.com
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).
Thanks for the read!
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.
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.)
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.
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.
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.
Although they're largely obsolete today, for many years the most well-documented and open storage device that could be connected to a standard PC was the floppy drive. The physical format was standardised by ECMA, the electrical interface to the drive nothing more than analog read/write data and "dumb" head-positioning commands, the controller ICs (uPD765 and compatible) interfacing it to the PC were based on simple gate arrays (no need for any firmware), and all the processing was otherwise handled in software. The documentation for the earliest PCs included the schematics for the drive, and the ICs on it were documented elsewhere too - e.g. https://archive.org/details/bitsavers_westernDigorageManagem... A lot of the technical details of early HDDs were relatively open too. I've interfaced a floppy drive to a microcontroller before, and being able to see how the whole system works, to understand and control how data is read/written all the way down to the level of the magnetic pulses on the disk, is a very good feeling.
(Many earlier systems that came before the PC, like the C64, also had more-or-less completely open storage devices, enabling such interesting things as http://www.linusakesson.net/programming/gcr-decoding/index.p... )
- laziness: publishing quality documentation costs money - fear of competition: publishing info also helps your competitors - latency: given that far more computing power can be fitted on a chip, and the relative cost of sending some data versus processing it locally has changed dramatically, a modern computer is a distributed system cooperating over network-like links.
http://events.ccc.de/congress/2013/Fahrplan/events/5294.html
and I think there were at least two others that I can't find right now (plus recent stuff on USB devices that attack their hosts in various ways). In light of these and other firmware and hardware-borne threats, a good overview of the bigger verification and transparency problems is
http://www.slideshare.net/hashdays/why-johnny-cant-tell-if-h...
"An Arduino, with its 8-bit 16 MHz microcontroller, will set you back around $20. A microSD card with several gigabytes of memory and a microcontroller with several times the performance could be purchased for a fraction of the price. While SD cards are admittedly I/O-limited, some clever hacking of the microcontroller in an SD card could make for a very economical and compact data logging solution for I2C or SPI-based sensors."
"The embedded microcontroller is typically a heavily modified 8051 or ARM CPU. In modern implementations, the microcontroller will approach 100 MHz performance levels, and also have several hardware accelerators on-die."
Was discussed on HN, but Algolia search looks to be down at the moment.
This is why if your machine is compromised, and you have a threat model that involves serious (state or otherwise well funded) attackers, you really should just send it off to be recycled.
Webserver in the NorthBridge springs to mind.
https://en.wikipedia.org/wiki/Robert_Morris_%28cryptographer...
http://en.wikipedia.org/wiki/J%E2%80%93Machine
"cheap and multitudinous commodity parts, each with a processor, memory, and a fast communication interface"
This reminds me of when I first went into business and bought some machinery. It actually surprised me (at that young age) to learn that the production machine I bought used standard parts that I could buy anywhere (bolts, screws and the like) and that if I needed one I didn't have to order it from the company that I bought the machine from. That seems obvious to me today but it wasn't obvious back then ("back then" was way before the web of course where info was not readily available)
https://webcache.googleusercontent.com/search?q=cache:V9xiN-...
The high point for me is where he installs Linux on the hard drive. In the sense that the hard drive itself is running Linux.
There are quite a few venues for attacks like these: A single computer is sprawling with processors.
https://github.com/scanlime/coastermelt/
very cool live hack video diary
>Warning: mysql_connect(): Can't connect to MySQL server on '127.0.0.1' (111) in /var/www/spritesmods/connectdb.php on line 2
Edit: seems to work again!
DSP is used in hard drive control. From wikipedia [1],
"Typically a DSP in the electronics inside the hard drive takes the raw analog voltages from the read head and uses PRML and Reed–Solomon error correction to decode the sector boundaries and sector data, then sends that data out the standard interface.
That DSP also watches the error rate detected by error detection and correction, and performs bad sector remapping, data collection for Self-Monitoring, Analysis, and Reporting Technology, and other internal tasks."
And one of the comments on the blog[2] mentions "...whereas the Cortex's ID turns up relevant boundary scan file..."
[1]: http://en.wikipedia.org/wiki/Hard_disk_drive_interface [2]: http://spritesmods.com/?art=hddhack&page=8&showall=true
So SMART and bad sector remapping, perhaps. But not decoding.
https://privatecore.com/solution-overview/attacks/index.html
(That page is mostly focused on someone coming into your data center and seizing or tampering with your device, but they've also talked about the idea of counterfeit or backdoored hardware components, and they do allude to that a bit there.)
I find this kind of sad, because it adds overhead (for people designing systems, for people building and setting up systems, for people administering systems, and in terms of computational and memory overhead) and maybe reduces flexibility, but it seems like a well-justified threat model.