3

I keep hearing about these statements that "a hard drive is like a cassette tape because it is a magnetic medium". That got me thinking...

Back in the day when I used to play DJ as a young lad, I would record music off the radio while played as the announcer to each song. Sometimes I would mess up and would have to rerecord of the flubbed portion of the tape, and upon reviewing, there was a noticable quatlity difference. Later in life I would learn that quality difference came from the fact the of the previous recording still existed on the tape, at least enough to distort the sound. It's the same idea as bending a steel fork or spoon; if you bend it and then bend it back, you will always have a small indentation where the original bend had occured.

Does this characteristic exist in magnetic base hard drives, and if so, is it detectable? Please consider the scenario that it has only been overwritten once.

sawdust
  • 17,383
  • 2
  • 36
  • 47
Chad Harrison
  • 6,069
  • 13
  • 44
  • 60
  • Previous "bit" can be detected with an electron scanning microscope, previous bit has no effect on the bit that overwrites it. – Moab May 22 '12 at 20:32
  • 1
    http://security.stackexchange.com/questions/8965/how-to-recover-securely-deleted-data – Canadian Luke May 22 '12 at 20:36

3 Answers3

7

Does this characteristic exist in magnetic base hard drives, and if so, is it detectable?

No, because the poor technique of re-recording that you mention is completely avoided in digital data devices such as hard disk drives and magnetic tape. The differences between recording analog information versus digital information is not the major issue. It really boils down to the recording mechanism.

Magnetic recorders have at least two heads: an erase head and a write (or read/write) head. The purpose of the erase head is to lower the noise floor of the magnetic medium (the tape or disk) prior to writing a signal. When you backup the tape in your example, there is some length (the distance between the erase head and the write heads) of recorded tape that will not be affected by the erase head when you begin re-recording. You are relying solely on the write head to "erase" and overwrite the previous recording. At some point (depending on tape speed and the head distance), you will be recording on tape that has been erased by the erase head.

Digital magnetic media completely avoid this issue by always writing data in complete records. The area between the records is called an inter-record gap, or simply gap. Within that gap is a special area called the write splice. The erase & write heads must turn on or turn off only within these write splice areas, so as to never damage any existing recorded data (including the gap data immediately before and after each record). If you need an analogy, think of each record as a song (or recorded track) with gaps between each song. Instead of re-recording in the middle of the song, the proper technique would to always record the entire song starting within the gap. Note: the process of (physically) formatting a hard drive is the process of writing an address mark, ID record, (blank) data record and all necessary gaps for each sector on every track of the HDD. When a sector is "written", only the data record of the sector is rewritten. The address mark and ID record are never rewritten after the format.

Writing in chunks called records and having gaps and write splices is not done solely because of the distance between the erase & write heads. There is also the issue of proper reading of the digital information. Your tape recorder used amplitude modulation to record the audio onto magnetic tape. Digital data recorders use MFM or its variants, which rely on flux changes (not voltage levels) to indicate changes in bit state. Note that flux changes indicate bit reversal, not absolute bit value. So on the start of a read, the bit state is initialized to a zero, and "0"s will be clocked in until a flux change is read. Therefore the read head has to be turned on where there were zeros written, which is the gap that precedes every record.

sawdust
  • 17,383
  • 2
  • 36
  • 47
1

While I am no expert, I believe the main difference is that cassette tape records an analog signal while hard-drives are digital. The analog signals on a tape would be much harder to perfectly zero out before rewriting, while the digital signal would be much simpler to get close to the "true" 0 or 1 signal.

Godric Seer
  • 359
  • 1
  • 5
  • 18
  • 3
    The 'digitality' of any record or transmission is purely an abstract thought-construction. There is no such thing as digital signal or digital bit on any electric or magnetic media. The interpretation of such signal _makes_ it digital... – Pavel Oct 15 '14 at 14:46
0

Now, I believe that the issue here, is can magnetic traces still be recovered or have an affect on the data that you overwrite it with?

If it has been overwritten at least twice, it's very doubtful.

As Godric states, hard drive data is digital. The media it is recorded on is magnetic, but we are dealing with 0's and 1's. You can't have a 0.5. So the previously recorded data has no impact on the currently recorded data.

In your example, your dealing with ANALOG data. The previously recorded magnetic data wasn't erased, so it partially cancelled out or amplified your new data, since it wasn't virgin media.

Since we are dealing with digital data, the drive mechanism writes the chunk of data, and a checksum. That checksum is used to verify that no data integrity has been lost, and if necessary is used to help rebuild the data, if it has been damaged.

If during read, that Checksum doesn't match the freshly generated checksum of the read data, then the data is silently repaired using the existing checksum. So you can't get distorted data due to the previously recorded & overwritten data.

The issue also occurs with data recovery. Once the data is overwritten once or twice, it will be nigh impossible to recover... (See http://www.schollnick.net/wordpress/2009/04/oh-my-gosh-they-are-stealing-my-data/ ).

Benjamin Schollnick
  • 4,409
  • 18
  • 19
  • 1
    No one has Ever recovered data from 1 overwrite. – Moab May 22 '12 at 20:31
  • Moab, I would tend to agree... (That no one has ever recovered data from 1 overwrite). But I think *never* is too far reaching of a statement. As a general rule, if the drive doesn't contain sensitive data, I go a for a single pass erase. If it contains sensitive data, I generally perform a 3 pass erase. The time difference is noticeable, but generally not prohibitive. – Benjamin Schollnick May 25 '12 at 02:46
  • @BenjaminSchollnick: In the ancient days of stepper-motor-based head control, asking a drive to move to track #492 on a hot day might cause the head to move to a slightly different spot from where it would go on a cold day. If a drive is written once on a cold day and once on a hot day, one edge of the track written on the cold day might not get overwritten. If the later write covered 90% of the original track, the fact that a read on a cold day might have a 10%-strength signal from the cold-day write mixed in with the hot-day write wouldn't cause trouble... – supercat Oct 15 '14 at 17:14
  • ...since the hot-day signal would be much stronger, but someone with a much narrower read head might be able to extract the earlier "cold-day" information. Note that if one write on a hot day wouldn't erase the data, repeated writes wouldn't help either. Newer hard drives have feedback mechanisms to help their heads follow tracks much more closely, so residual information is less likely to remain at track boundaries than with older drives. – supercat Oct 15 '14 at 17:18
  • @supercat, you are technically correct. In fact, that is partially the technical basis for Spinrite (http://www.grc.com). But in modern drives, I very much doubt this is very probable. Once again, if your worried, then perform a 7 pass overwrite, with each pass the drive will be at a different temperature (due to the length of time running), and help prevent this thermal scenario you describe. – Benjamin Schollnick Oct 16 '14 at 00:41
  • @BenjaminSchollnick: I'm not worried; it's worth noting, however, that some newer drives might have a different issue: if a drive decides an area of the disk seems to be "going bad" it might copy all the data off that area somewhere else, and then never touch that area again no matter how many times code asks to overwrite the blocks in question. – supercat Oct 16 '14 at 00:47
  • @supercat True. In that case, only a *TRUE* low level format of the drive could possibly resolve that, and most IDE / SATA drives will ignore a low level format request, unless you use the manufacturers software. On the other hand, that sector was swapped out for a reason. Recovering data from it may take some service along the lines of Drivesavers (or a specialized software like spinrite). – Benjamin Schollnick Oct 16 '14 at 00:55
  • @BenjaminSchollnick: The purpose of overwriting sectors multiple times is to ensure that the data will be unrecoverable even with special equipment. The fact that a sector seemed to be going bad doesn't mean the data won't be largely or even 100% recoverable, particularly if the drive controller is trying to avoid data loss. – supercat Oct 16 '14 at 01:18
  • @supercat We may need to agree to disagree here. I agree with your core argument. Where we seem to disagree is that your stating that a bad sector maybe easily readable. My argument is that sector was flagged as bad, thus it will be hard to read. 1) Since it is flagged as bad, then you will need specialized software or hardware to read it. I am referring to the drive setting the block bad, and not the OS. If the OS flagged it, then it could very well be a slow sector (and not a bad sector). – Benjamin Schollnick Oct 16 '14 at 02:13
  • Whereas if the drive electronics marked the sector bad, and remapped in a replacement sector, Chkdsk /r or /f shouldn't be able to read the mapped out sector. So I would believe that non-trivial to attempt to recover data from a mapped out sector. – Benjamin Schollnick Oct 16 '14 at 02:15
  • The only real answer to this would be to full drive encrypt the hard drive before it was used (or right after the Base OS install), allowing it to be encrypted completely. And then when you want to wipe the system, repartition / overwrite the drive. If the entire drive is encrypted, then even any mapped out sectors would be encrypted, and when the drive was wiped, and the encryption key unavailable, then the raw drive data is useless due to the fact that it had been encrypted. – Benjamin Schollnick Oct 16 '14 at 02:23
  • @BenjaminSchollnick: Most drives include error-correcting code. A track which has recoverable read errors won't necessarily be "hard to read"; we're in agreement that "normal" means won't allow the data to be read, but the only potential difference between overwriting once versus multiple times is whether *someone with specialized equipment* would be able to extract the data. Recovering data which has a few somewhat marginal bits that were recoverable via ECC is probably among the easiest scenarios if one is using specialized equipment. – supercat Oct 16 '14 at 02:28
  • @BenjaminSchollnick: If you've encrypted the drive with a decent algorithm (say AES256), you dont need to wipe it. All you have to do is "lose" the encryption key. The drive contains random bits at that point. – Jamie Hanrahan Oct 16 '14 at 22:20
  • @JamieHanrahan, you are correct. I should of said, that you wipe it by destroying the key. I did not elaborate as well as I should have. – Benjamin Schollnick Oct 17 '14 at 03:20
  • @supercat, We could debate this forever going back over minuta. Instead I recommend Checking out Security Now podcast #419, where Steve Gibson discusses this issue in regards to Wear Leveling (specifically over SSDs). The point made is if the drive is whole disk encrypted before the wear leveling occurs, then the remapped sectors are still encrypted, and thus when the encryption key is "wiped" / erased, etc, the sectors are unrecoverable. Security Now Podcast 284 (https://www.grc.com/sn/sn-284.txt) also covers a bit of this too. – Benjamin Schollnick Oct 17 '14 at 03:22