Write Bits Directly Onto a Hard Drive Platter?

kidcharles writes "I'm working on a project that requires writing bits to a magnetic hard drive platter in a completely controlled fashion. I need to be able to control exactly where 1s and 0s will appear physically on the platter. Normally when data is written to a drive the actual bits that get written are determined by the file system being used, as modified by whatever kind of error handling the drive itself is using (e.g. Reed-Solomon). All of the modern innovations in file systems and error handling are great for reliable and efficient data storage, but they are making my particular task quite daunting. My question for Slashdot: is there a way to get down to the 'bare metal' and write these bits? Any good utilities out there to do this? Obviously a free and open source solution would be preferable, but I'm open to anything at this point."

Comments

That is gonna be hard

[PaulIsTheName]

You would need to replace the firmware inside the drive or use an undocumented manufacturer mode. Whatever they use to write the servo tracks would be interesting to you. You will be in the situation of the firmware writer: There will be problems all the way. Be prepared to find a way to position the heads (ever tried to find a servo track?). Most likely you also need to at least parametrize the amplifiers in the DSP part of the firmware that does the analog-to-something-to-digital so you can have direct influence on the "bits". Good luck

Slashdot trolled

[dotgain]

The submitter appears to know enough about what he's asking to know that it's also impossible / completely impractical. Recording ones and zeros directly isn't done for a reason, submitter appears to understand this.

Re:Slashdot trolled

[vadeskoc]

If I had to guess, I'd say this is a physics grad student who is looking to use this hard drive for something other than data storage. Where I work (in academia) we repurpose hardware all the time for purposes other than it's intended one, in order to do science, since commercial stuff is often engineered way beyond our capability to build it from scratch. That is, provided we can overcome details of its implementation that arise from its original (true) purpose. This may be one of those cases where the thing is engineered beyond hope of hacking, but I'm kind of disappointed at the "you're-an-idiot-because-hard-drives-aren't-meant-to-do-that" attitude in these posts. Is this really indicative of the level of imagination and curiosity on Slashdot?

Wrong.

[feepness]

Your requirements are wrong, sorry.

Yes, I don't what they are. Still wrong.

Hm ...

[garry_g]

This kind of copy protection has been outdated for quite some while and should have died with floppy disks ...

Tell us your project?

[marcansoft]

These kinds of questions are stupid: "I need to do XYZ for a project, how do I do XYZ?", where XYZ is one or more of complicated, ridiculous, vague, nonsensical, etc. Try telling us what your project is, and then we might be able to suggest a useful solution, possibly not involving XYZ at all, or involving a very particular/practical version of XYZ.

Re:Tell us your project?

[Scutter]

These kinds of questions are stupid: "I need to do XYZ for a project, how do I do XYZ?", where XYZ is one or more of complicated, ridiculous, vague, nonsensical, etc. Try telling us what your project is, and then we might be able to suggest a useful solution, possibly not involving XYZ at all, or involving a very particular/practical version of XYZ.

Except he doesn't want your alternate solution. He wants the solution he requested. If you don't know of a way to do it, then move on.

Re:Tell us your project?

[Lehk228]

nobody has the solution he requested, because the solution he requested is stupid.

If you have to ask, it's hopeless

[vadim_t]

"I'm working on a project to build a nuclear powerplant. Is there documentation on how to do it? Obviously a free and open source solution would be preferable, but I'm open to anything at this point."

It seems to me that if you're involved in such a project and have to ask how to do it, it's doomed.

Also, the whole idea of it seems rather impossible. Why would you want to do this in the first place? Have in mind that hard disks don't write bits as is, not just because of ECC. They use an encoding to ensure that there are no long strings of 1s or 0s. If you just wrote some data without regards to that you'd run into a sequence you'd be unable to read later, due to not having a clock signal to figure out where a bit ends and the next begins.

Modern hard disks require using special encodings and servo data in order to be readable at those densities. It just makes little sense to me to want to bypass it. Unless you're working for a disk manufacturer this just seems very odd, but in that case you'd have access to the required equipment and information.

Re:If you have to ask, it's hopeless

[vlm]

It seems to me that if you're involved in such a project and have to ask how to do it, it's doomed.

Agreed, except that he may only need that initial kick to find terms to google.

For example, I know that to do what he wants, he needs to learn about the MFM vs RLL interfaces from the mid 80s, not because he will emulate either, but if he doesn't understand both and how they worked and relate to each other, he's has no chance. He is more or less trying to make a hard drive version of the catweasel floppy controller. If he never heard of a catweasel he would have a hard time figuring out he needs to learn about it.

Image scans from the very detailed technical manuals for DEC's minicomputer hard drives are available online. This is from the era of individual TTL chips, he's basically going to replicate / emulate / reverse engineer that hardware into his microcontroller in order to write individual 1/0, after all they had a solution that worked 40-50 years ago. If he didn't already know that, he would have a hard time figuring out he needed to know that.

Now if he already knows that stuff, and is really asking how to get MPLAB working so he can program his PIC, well yeah then he's well and truely lost.

But given those first steps/hints, I think a reasonably experienced EE/CE type could probably figure out the rest of it.

Adding to your nuclear analogy, if someone went back in time and told folks after 1920 to play with neutrons and U-235, they would get quite the head start on the rest of the world that didn't get that idea to try that until much later. They had all the prerequisites by 1920 but it took many years to get the right combination of ideas...

Re:DD

[dotgain]

Read the summary - there's a lot more going on with the data after 'dd' has done with it. Even if I write a continuous stream of zeroes to the disk, that's not what will wind up on the disk. For some reason we've yet to establish, he wants direct control over exactly what bits are recorded where. Unfortunately, doing this will mean it'll be damn near impossible to read the data back, as there will now be no reliable way to determine what track / sector we're located at. There'll be no means to detect errors, let alone correct them. He probably won't even be able to verify what he's just written.

I'm actually more interested in why the fuck he wants to do this, much less how it would be achieved.

Hmmm. The twisted, it is strong in this one.

[Noryungi]

Short answer: no, it's not possible to do that. It's not impossible, simply incredibly hard to do. Unless you happen to be very handy with a soldering iron and go dumpster-diving in the backyard of an HDD company (as many others have pointed out).

Longer answer: how about creating a 'virtual' hard drive? There are utilities out there that probably let you create (a) a virtual interface (let's say IDE) and (b) a virtual hard drive, attached to said interface. The next step, of course, is to hack these (VirtualBox?) in order to make them do whatever it is you want them to do. This being said, I strongly suspect it involves non-trivial virtual machine hacking and that it probably does not respond to whatever your needs are.

Other than this (very twisted) idea, sorry, bare metal writing has been disabled a long time ago, and for good reasons, too.

Re:Sure

[adolf]

A whole chip? Really? That sounds hard.

Just Ebay an old 20MB Seagate ST-225 MFM drive, and write whatever bits you want.

It doesn't know any better.

Re:Sure

[Smidge204]

The custom controller would REPLACE the the on-drive controller, not sit on top of it.

=Smidge=

Re:You're doing it wrong!

[Goaway]

And if he's trying to see if he can read data patterns off platters by hand from a dismantled drive, and needs a known test pattern to calibrate his equipment with?

Headlines are superfluous

[thasmudyan]

Don't you hate it when people refuse to accept the premise of a technical question and write long monologues why the submitter is working with false assumptions even though they don't know what exactly they are dealing with? Yeah, me too. Makes them look arrogant, ignorant and smug. I'm going to go ahead though and reject the submitter's premise: there is no chance in hell that you're on the right track with whatever project you're attempting to do. But instead of merely dissing you for incompetence, I'll lay out a few scenarios (might as well, since you didn't supply any of your own).

If the actual physical bits matter to you...
you're either a hard drive manufacturer or a clueless person who should read up on how drives actually work. And we both know you're not working for a manufacturer. What you need to know is that there are several layers of indirection between the write call from within an OS down to the actual magnetic platter. These layers are there for a reason. At the very least, the onboard controller of the drive abstracts away the physical block allocation, and the drive won't work without the controller at all. Since the intricacies of the drive's physical address space are not accessible from the outside, there will never never never be a reason to try and fiddle with it directly. Because you can't.

If you are looking for disk I/O without a filesystem...
we're finally in saner territory. There are valid reasons to do this, e.g. speed and overhead considerations. Some database vendors actually have features like these. In this scenario, you're using the entire drive as one big addressable blob. A good starting point would be to have a look at the source code of a simple filesystem, such as ext2. Strip away all the actual file handling stuff and learn what you can from the disk I/O routines. On the other hand, if you didn't arrive at this conclusion yourself, that's not a very encouraging sign.

If you simply want a drive without error correction...
you're not developing software that will run on any modern system. If you accept this caveat, you can buy an ancient drive off ebay and use that. However, keep the first scenario firmly in mind: there is simply no reason to control the exact placement of every single byte if you don't plan on literally putting the drive under a microscope afterwards. Otherwise, this has no practical implications and, again, you are on the wrong track.

If you're a DRM/malware/virus developer...
I will sleep very comfortably tonight, because you had to ask about this on Slashdot, signaling once more that you're doing it wrong.

Re:Headlines are superfluous

[Idaho]

Don't you hate it when people refuse to accept the premise of a technical question and write long monologues why the submitter is working with false assumptions even though they don't know what exactly they are dealing with?

In fact no, I hate it more when people do not state their actual purpose, especially in cases where what they are asking combined with the fact that they *need* to ask, cannot prevent one from wondering whether they really understand what they're doing, or whether they are addressing the right problem from the right angle (which, in this case, appears extremely unlikely).

The problem with this topic is *exactly* that we don't know what we're dealing with, and the first thing any decent engineer would do is to try and figure that out (in fact, you started out to do just that). Surely the stated goal doesn't stop at writing bits in exact locations just for the sake of it, right?

In fact, if I asked this to a 100 engineers, I'd really expect that at least 99 of them will immediately ask "why the fuck would you want to do that!?". And the one who doesn't probably works at a harddisk manufacturer.

Re:Sure

[CharlieG]

That was my first idea too "Find an old MFM/RLL drive, and have at it" - then I realized, "You know, I'll bet that more than 1/2 of the readers of /. don't even remember them"