Slashdot Mirror
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."
It works for me. http://www.staples.com/Staples-Dry-Erase-Markers-Chisel-Tip-Black-4-Pack/product_607101?cmArea=FEATURED:SC1:CG11:DP1101 Now that someone has said it no one else can be a smart ass and they have to be informative.
May I suggest a magnetic needle and a steady hand? http://xkcd.com/378/
Regards, Boyan
Just make your own controller chip for the drive.
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
If you don't need lots of bytes, you should use an old disk. I mean very old, maybe going back to those 300-400MB disks we had on 486 computers or even older.
Recent disks have embedded error-handling mechanisms which will prevent you from writing what you want, where you want (physically speaking of course). The disk controller translates your "physical" disk addresses into its own internal mappings. The only way to bypass this would be to remove the disk controller's chip and put your own in place.
Maybe your question would be: "how hard is it to create my own disk controller's chipset?"
They (the bits you write to your typical /dev/sd* device) would still be wrapped up in sectors, the sectors be enhanced with error correction, then encoded (NRZ, Manchester or whatever is appropriate to the magnetic storage) and then written out. What OP wanted is to manipulate the bit that comes out of encoding. Given the usual stack of SCSI-like commands (and not direct access to the write head signal as early HDD controllers had) this does not seem feasible.
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.
Besides the fact that Flash doesn't have a hard disk platter (his problem obviously isn't just to save data), Flash chips also contain internal logic to map out defective blocks, and in addition they remap in order to avoid writing single blocks too often in order to prevent them from failing early. So even if the HDD platter isn't really needed, he won't get exact control on Flash either.
If you had at least suggested a floppy. There you can indeed control exactly where your bits go, and it's even a magnetic medium.
The Tao of math: The numbers you can count are not the real numbers.
Your requirements are wrong, sorry.
Yes, I don't what they are. Still wrong.
I can't help directly, but can give one important advice - careful how you distribute the bits! If too many ones get on the same side of the platter this will destabilize it, causing it to wobble due to the weight difference ( a one weighs quite a bit more than a zero, you know!) and potentially tearing the platter in two!
This kind of copy protection has been outdated for quite some while and should have died with floppy disks ...
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.
"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.
I'm actually more interested in why the fuck he wants to do this, much less how it would be achieved.
dd only bypasses the filesystem. It doesn't override the HDD firmware, which has to avoid bad sectors and write ECC information to the platter as well.
I would love to hear why the submitter thinks he needs to write directly to the platter.
RTFS
Knowing everything there is to know about dd isn't going to tell you where on a physical disk your data is stored. dd only sees a long string of zeros and ones that are a far abstruction from what physically happens on the drive.
There doesn't seem to be any way to be sure exactly where the data is written except by a deep understanding and maybe a replacement of the drive firmware.
First thought was - WoW! Somebody wants to defeat disk caching, ECC and make life bloody difficult to boot. The best way, if you really want to do direct disk RMW operations - is to use Flash. Its fast, reasonably portable, and won't fail you if you use it properly.
You still won't know where the data is actually written. Flash does wear leveling.
Actually that's the best suggestion yet. After he's spent a week banging bits into the 82072A, he'll either have gone insane, or will have realised he's well and truly barking up the wrong tree. Once again, OP: I'd love to know what you're up to, if it's not trolling Ask Slashdot.
The stuff Spinrite does stopped working 15 years ago. On modern drives you're pretty much doomed. Considering Gibson has been known to rip off SYN cookies and spout such nonsense as "Windows RAW sockets are going to destroy the internet", I wouldn't go anywhere near him for advice.
No you don't. Rethink what it is that you're actually trying to achieve and try again.
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
Got myself a disk editor, and wrote something on the very first sector.
After that I can't use the HD anymore.
The computer can't even recognize it anymore.
Muchas Gracias, Señor Edward Snowden !
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.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Old MFM hard drive should do the work. The entire device was controlled via software in dos. I have one lying around. A whopping 5 MB!
http://en.wikipedia.org/wiki/Modified_Frequency_Modulation
Now all you need is a 8 bit ISA slot and you are set.
RES PUBLICA NON DOMINETUR
The cynic in me wonders if he is working for some hack start-up company trying to develop a DRM scheme for a hard drive, similar to the crap the studios do to DVD's to make them difficult to rip. Typically this involves creating some sort of currupt/invalid area on the disk that your particular device will know to ignore, but will lock up anyone else trying to read the data off the drive.
The optimist in me wonders if he is trying to defeat such a scheme.
It can not be done with off-the shelf equipment and software for many reasons, some of which are:
Line Codes
Error Correcting Codes
PRML
SMART
LBA
etc.
Specialist Mac support for creative pros, Melbourne
No it doesn't.
If I read it correctly (it was a couple of years ago) all Spinrite does is move the head to different tracks before trying to read the data. The theory is that a seek from different distances might align the drive head slightly differently to the data.
As far as I know there's no way to position drive heads directly via IDE/SATA, much less write individual bits. IDE/SATA are high level protocols, all the low-level logic is inside the drive controller.
No sig today...
NOR flash doesn't require or use wear leveling, error correction, or bad sector management (as long as your wear pattern isn't ridiculously unbalanced) - use that if you want true "write raw bits" style functionality. Most microcontrollers use this type of flash, and chips are readily available, though they are expensive compared to NAND flash and only exist in smaller sizes.
NAND flash requires you do your own wear leveling, error correction, and bad sector management. You can still control all the bits, but be prepared to have the chip eat some of them.
Only "cooked" NAND flash devices such as SSDs and SD cards actually do all that on a built-in controller.
>Any good utilities out there to do this?
Yes. My solution involves a screwdriver and a sharpie. And you can write bits of information to the bare metal, like "this drive is broken, dont waste your time trying to fix it".
My colleague was not happy finding the drive on his desk and told me its a low level joke. Well, yes.
We don't need to work like that any more.
Get yourself an old, totally unintelligent S412/506 MFM controller from out of an IBM PC or PC/XT. These were fairly dumb devices (g=c800:5 in debug, anyone?) for which you were meant to enter a "bad sectors list" printed on the front of the drive after performing the low-level format yourself. The earlier the drive, the closer to bare metal, so you might want to look for any of the 2, 5, or 10MB (yes, MB) full-height (2 x 5.25" drive bays stacked on top of one another) drives that were floating around then. You'll also want to get yourself a set of ribbon cables.
You should be able to use a drive/controller combination like this with any machine with ISA bus slots up through about the 386/486 era, and that would let you also go back and grab an early Linux distro (say, kernel 1.2.13 days, like Slackware 3 or so) that included drivers for such a controller that were actually in use and known to work at the time, giving you a base on which to build more code.
If 10MB is too small, you might just have luck going up to the largest of the MFM (80MB) or even RLL drives (160-200MB, just get an RLL controller instead) drives. I don't remember whether there were any ESDI drives back in the day that didn't remap their own sectors, but if there were, these controllers were 16-bit ISA and somewhat smarter (also with Linux drivers from the period available) and went up to 680MB or so.
But if you're looking for the best chance of success for your purposes and don't need tons of storage, my educated guess would be that the MFM controller out of an IBM 5150 PC plugged into a 5MB ST506 hard drive and connected to a SIMM-based 80386DX mainboard with 8 SIMM slots (for 8MB ram) might be the easiest combo to find and get working in practical terms that has a chance of doing what you want.
STOP . AMERICA . NOW
Once you can read, you can also write. I've learned it at schools some 20 years ago
this post contain no useful information, no need to mod it down
Good. Go write "Paulatz wuz here" next to the HOLLYWOOD sign.
The Cloud - because you don't care if your apps and data are up in the air.
I don't think what you want to do is possible, because I don't think modern drives actually write the 1s and 0s in the way that earlier ones did. They use Viterbi coding, which means that the exact change to the magnetic field to encode a 1 or 0 depends on what the preceding pattern of 1s and 0s is. They literally can only write sectors at a time.
Then again, what is meant by a sector has changed with time with different servo technologies. With the embedded servos in current drives, you would need to know a lot about the particular geometry of the particular drive you are using.
And to do any of this, you would have to bypass the controller completely - which, I am pretty certain, cannot be done without serious hardware modifications
Consciousness is an illusion caused by an excess of self consciousness.
I'm working on a project that requires writing protons to an atom nucleus in a completely controlled fashion. I need to be able to control exactly where protons will appear physically on the nucleus. Normally when atoms are created during fusion the actual atoms that get created are determined by the energy input of the fusion reaction as modified by whatever kind of atoms are being fused (e.g. hydrogen into helium). All of the modern innovations in nucleosynthesis and alchemy are great for particle colliders and crackpots from the Middle Ages, 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 transmute lead into gold in a cost-effective manner? 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.
Finally had enough. Come see us over at https://soylentnews.org/
You know how data restoration companies do it?
They take out the spindle with the platters, and put it in their own reading device with its own controller. And with that you can read and write the exact bits (as long as quantum physics allow it). But the head has to be compatible (e.g. perpendicular recording needs entirely different heads).
I bet those devices can be bought, and I bet their controller is actually just software on the computer (for flexibility). I also bet they come with different head configurations.
But they are definitely not going to be cheap.
Hey, at least it is a real solution. :)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
"I'm working on a project that requires writing bits to a magnetic hard drive platter in a completely controlled fashion."
Are you sure?
The reason I ask is I'm working on a project that requires me to move data faster than light. At least that's what I spent last Monday working up the math to prove that data replication between our different data centers has an upper bound enforced by the fabric of the universe and that it was impossible for me to achieve the project's stated goals without essentially inventing warp drive. As it turns out after a meeting it was determined that the goal was just a stated guideline. It also turns out the price of faster data transfer rates is prohibitive and after a further meeting the stated project goal was total baloney. Yes. Baloney. We had sandwiches. It was a nice meeting.
[signature]
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.
No less then *7* posts to the SAME XKCD COMIC?!? Christ, bad enough people don't RTFA, at LEAST read the fine comments!
"Gratuitous complexity is akin to chaos" - True Vox
Some operating systems have volume management tools that do let you get a great deal more specific about where data is written. Normally, I'm a Linux or Wintel guy, but I have managed some AIX boxes a few times and from setting up a large one once I recall that it's logical volume manager allowed you to create volumes on the SCSI drive systems that were very specific about how and what part of the drive was used. You could specific, for example, that a particular volume use only the outer tracks (or inner or middle I suppose) of the drives -- in addition to a great many options for raid striping and transaction logs and so on.
The idea is that the outer edges of the platters travel faster under the read/write heads than the inner and so performed differently. Also, you could keep the head from having to jump around as much by keeping all the data that tended to be used at the same time on the same tracks -- reducing your average seek time when reading randomly from that pool of data.
In practice, I think this mattered a great deal more when us old guys were dealing with 80+ millisecond random seek times on 5 1/4" wide full height (what would now be considered two bays) drives -- or larger disk-pack based drives (aka washing machines) with the massive physical movement necessary for those read/write heads.
Today, I think the admin is better focused on distributing the data load better across different drives/arrays to even the load out and also focused on reducing overall disk i/o in creating database schema and applications. Focusing on very fine details like this is likely to have only marginal benefit next to those key areas --- but I can't presume to know for sure what this project has in mind.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
Randall Munroe
http://outcampaign.org/
You will need a reasonably sized HD, like this one where ones and zeros occupy a space of about postage stamp size.
Wow, nice contribution. You totally miss the point, which is that writing arbitrary magnetic fields to an arbitrary physical location on the platter is the very last thing you want to do during data recovery. Now, if you just want to write arbitrary data at arbitrary logical locations on the disk, then you can already do that with the disk in it's current state.
Neither of these scenarios are remotely data recovery, since by definition, you are overwriting data.
For what it's worth, I'd disagree that once you can read a human language, that you can also write it since there are visual and linguistic cues in written language that you have to provide when writing. In most people, the two are closely linked, but I'd be willing to bet that while learning to read/write, your reading aptitude probably has a slight lead over your writing aptitude.
"Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves
if you describe your requirements so abstractly? It sounds to me like you've come up with a solution ("Let's write the bits directly to the hard disk") and now you want pointers on how to make it work without explaining why.
If you just want to get around the file system, then use raw block I/O to the device. However it *sounds* to me like for some reason you've decided the *actual physical* layout of bits on the drive is important, in which case you are going to have to write your own disk driver -- if the drive electronics themselves don't defeat your attempt to know where bit is physically written.
It's inconceivable to me that you'd actually need to know this. Since you only *read* the data through an interface, it should make no difference if you *write* though the same interface, as long as it's consistent. In other words, unless you are going to disassemble the drive and examine it with an atomic force microscope, you have no way of telling the difference between a physical layout and an equivalent *model* of a "physical layout".
If you can't say *why* you need to do this, at least explain the parameters (how much storage, how fast, what kind of retreival etc.). My first reaction was that you should not use a magnetic disk at all, but an MTD flash device. Even so, you're dealing with an abstraction. You have no idea whether the device itself has mapped a bad bit to a different location at the hardware level. However short of tearing the device apart and putting the flash chips in a special circuit, you'd have no way of telling.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
It's been posted and modded to oblivion multiple times.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
Nice, 'course there's an emacs command to do that, good old C-x M-c M-modintooblivion...
Considering he's asking this question to begin with, what makes you think he hasn't gone insane already? This isn't something that most people technically inclined enough to program would be silly enough to even consider asking.
The GP is right, Spinrite does not and can not do most of what it claims on a modern HD. The only potentially useful thing it does is re-read sectors up to hundreds of times, but there is safer software that does the same thing.
More importantly, Spinrite can be downright dangerous to your data. Spinrite writes any data it recovers TO THE SAME DRIVE! It can very easily overwrite other data you want to keep and/or lose the recovered data again because the drive isn't stable enough to hold it reliably. Not writing to the damaged media is data recovery 101 and Spinrite fails badly.
I'm surprised by the number of people who seem hostile to this question, mostly because they can't imagine any circumstances where they would want to do this. I can think of several. In fact, I was thinking about something similar with optical disks just earlier today. (I'm curious whether small holograms could be created by writing an interference pattern directly onto a CD or DVD, but I would need exact control over how the tracks lined up to achieve this.)
Here's some concepts just off the top of my head:
* He's come up with a new disk encoding scheme, and wants to try it out.
* He's doing research into how long disks retain data, and is questioning basic assumptions like whether surface bits permanently magnetize the platter underneath, affecting later bits in the same location. Or how far the domains spread.
* He's working with self-assembling molecules and needs to give them a patterned magnetic surface to build on.
* He wants to 'print' a 2-D picture onto a small portion of the hard drive, and bounce a laser off it. (The magnetic alignment of the surface domains would polarize the photons slightly.)
* He's making a high-resolution rotational position encoder, so by reading across 32 tracks knows the rotation of the platter down to a few nanoarcminutes.
* He wants to totally destroy the contents of a disk. (I assume this is what most of the hostile people think is the intention, presumably as the payload of some virus)
Those are just the ones off the top of my head.
However, the ranting people do have a point that without knowing WHY you want to do this, we can't really suggest the best solutions. A lot of people have recommended going back to super-old MFM hard drives that allowed this, but we don't know if you require the density of modern hard drives.
To do this with a modern drive, you're basically going to have to rebuild the controller. Either totally remove the controller board (leaving handy raw connections to the stepper motors and drive heads) or cut the connections between the microcontroller and the low-level electrical functions of the drive, and substitute your own. Here's where knowing your accuracy requirements could have help, because if you want relatively large bits, you can get away with fairly low-frequency components. A 20Mhz microcontroller can, with say an external high-speed shift register, push out an 80mbit/s serial stream, which equates to >120,000 bits around the track of a 6,000RPM drive. Not quite the same density as the manufacturer, but better than the old MFM drives.
Your next problem is going to be this: It's really, really hard to tell where the head is on a platter. I've no idea how modern drives do it, but it used to be done with 'marker' bits either in the track, or on a nearby 'index' track, plus a little timing. Preserving these location marker bits is actually the most important job of the drive controller.
It's not impossible, merely very difficult. I could probably make one with only several weeks of hard work.
Alternately, you could try getting into the firmware and re-writing it to your specifications, but that might take longer. You would have to reverse-engineer a lot of stuff that is specifically hardened against this, but at least the hardware would be stable.
Jeremy Lee | Orinoco
I'll give the direct/short answer to the question you're asking.
No.
The reason is that hard drives only write data in precise locations so they can find it later. You can't write anywhere other than those locations because the drive won't do it... not even with new firmware. The read/write heads may not even be capable of addressing the locations you want to write. The only way to write in an arbitrary location is to remove the disks from the drive in a clean room, and use a very precise CNC read/write head to address the locations you want. Disk manufacturers have machines that do this.
If you confine your request to only writing arbitrary locations within the physically addressable areas of the disk, then you can do what you want if and only if you write new firmware for the drive... it used to be firmware was in EPROM and couldn't be altered, but you can flash it nowadays. So you A) Buy a drive then B) Re-flash the eprom with code to do what you want (custom developed after reverse engineering the original firmware) and then you can write wherever, without worrying about niceties like the end of sector marks the drive uses to keep track of data locations. You'll have to do that sort of thing yourself.
So, confining our discussion to disk areas that the default drive firmware will write to, If you're looking for a way to ignore/override the OS I/O code, the disk controller firmware and the disk firmware in order to "talk to the bare metal" it may be possible depending on the particular combination of OS, controller, and disk, and assuming you have the right privileges in the OS. But there's no standard way to do it, nor API. You have to know exactly how the hardware in question works, down to the chip level and in some cases below. If the computer you're interested in has a different drive, controller or OS I/O code than you wrote your program for, then you have to re-write it.
I'm sure a lot of us here would be curious to know what you're trying to do... accessing non data sectors on a disk hasn't been done commonly for years, and when it was it was used for some awful copy protection methods (awful as in they created compatibility issues, even with "standard" PC hardware and also they could still be broken).
Erik
Remember this next time you are struggling getting requirements out of a non-technical manager or user. The submitter obviously has the technical background, but is making a common mistake.
What is it you want to do? "I want to write bits directly..."
Really? That's your final goal? Just to write bits? No, there's some other task you want to complete, and you've determined the best way to complete that task is to write bits directly to the platter.
But if you can't write bits directly to the platter, or you don't know what additional issues may arise when you do so, how can you determine that is the best course to take?
So slow down, back up a step, let us know what your real goal is. You want X, and you think the best way to X is to write bits to the platter.
You would need to completely bypass the drive firmware in a way that would make the drive quite unusable afterwards
"Afterwards" wasn't part of the spec. He just wants to write the 1s and 0s. Reading them wasn't part of the spec that he gave us.
Seriously, if he just wanted to use a HD for data storage and retrieval, he already knows how to do that. Maybe he just wants a magnetic platter decorated with his logo printed in magnetic domains, a la lightscribe. Or something entirely different. Since he didn't tell us, but yet wants to do something so unusual, we can't make assumptions.
Almost every time someone asks a question where they obviously have made an implementation decision that depends on "doing it differently than everyone else on the planet" while providing no information about what they are trying to actually accomplish, the problem can usually be solved in a much simpler way. While it is possible you are doing something exotic like trying to turn a hard drive platter into a meta-material by patterning high density magnetic patterns on it and so you really do need to be able to control the bits at the hardware level, odds are low.
You provided no information about what you are trying to do. There are pretty good odds that if you provide information about what you are trying to do instead of trying to get people to come up with a way for you to do it 'the hard way' you, will get an answer that will work for you.
First, ones and zeros on a harddisk platter are not magnetic north and south, they are different frequencies of an FM sine wave. Second, the formatted tracks on a harddisk don't line up physically. The start of the track is wherever the head was when the controller was told to format that track. Third, Sectors aren't written in precise places inside their formatting. The low-level formatting process writes headers across the track that are used later to find the data. There's enough extra space between those headers that a sector of data will fit there, based on the ability of the controller to read where the sector starts and be able to write it. If you really need to write magnetic north & south to specific spots, you should look at Floppies. Floppy disks have a hole to mark one spot on the disk, so the start of track comes much closer to lining up. You can even write ones and zeroes instead of FM patterns if you have an old Apple II, which didn't use FM encoding.
If you want an exact image of 1's and 0's that you determine, forget it. Bits these days are encoded as transitions between magnetic phase boundaries. They also encode the clock data needed to recover the data along with the data. As a result, what's put down on the disk has to guarantee a certain number of these transitions or you loose sync. In other words, you may think you're writing '0000000' but on the disk it's a bunch of magnetic transitions, not a constant stream of the same magnetic polarity. It's not even that a single phase transition translates into either a 1 or a 0; groups of these transitions translate into a group of the actual data bits. Some patterns of phase transitions can simply never be written onto the media by the write electronics in the first place because they would not result in reliable data recovery by the read electronics.