On Sunday, February 6, 2005, at 07:22 AM, Florian Stoehr wrote:

> Hi all,
>
> I didn't know about any existing eraser tool under NetBSD,
> so I played around and wrote my own, capable of erasing
> single partitions (or whole disks of course). Now I have some 
> questions about this task.
>
> I implemented a 35-pass pattern eraser, like Gutmann requested
> in
>
> http://www.linux-kurser.dk/secure_del_peter_gutmann.html
>
> The goal of this program is not to stop any freak with special
> controller or oscilloscope - 3 times with random data might be
> enough here - but to raise time needed to restore data or
> make it too expensive for government authorities (at least
> if you're not involved in serious crime).
>
I just read that paper recently.  There is gnu shred in gnu diskutils 
btw,
GPL'ed of course.  I don't know about too expensive, or time, I figure
if they're using those techniques, they'll take the time...  At any 
rate, as I
understand it those  bit patterns were designed to clear off-track data.
The magnetic pattern of a sector, is transferred somewhat into the 
space around,
you clear the drive, block by block with dd if=/dev/zero etc, but 
there's still
a ghost image in the gaps between tracks, which is what they read.  The 
longer the data was in place on those tracks, the stronger the ghost 
image, and since you don't write directly to it, some of it still 
there.   I wish the paper and gone into more detail on the scientific 
side of it, as to why, alternating bit patterns (010101,1010101), seem
to affect the surrounding more than random data -- does the produce a 
stronger field? Or was it canceling existing field?  I remember when I 
was writing patterns to a old 10 meg
PC hardisk, and some floppy disks to try to 'revive bad sectors', and 
it worked sometimes,
though half the time it would fade and go bad again in a week.  Are 
these the same patterns?

I did a wipe on 2 drives, a few weeks ago, though I was more concerned 
with what could happen if I  give the drives away, and an enterprising 
hacker reprograms a controller to read what's in the gaps (perhaps by 
using bogus geometry, the article alludes to this, if I remember), 
rather than government stuff.  I figure if they're taking your drive 
apart in the a clean room, its only a question of how many years, you'd 
get, at that point ;-]  So, as shred would take way to long,  I just 
wiped once with dd if=/dev/zero, and then hacked out a program to write 
large blocks of a repeating hex pattern, to pipe to dd.   Then did 4 
passes, each way faster than shred, which I think would have taken 10 - 
12 hours, a pass.  (And, I just blindly assumed 4 passes would be 
enough, a comprise of peace of mind, vs. expediency. ) At any rate, I 
just looked at the bit patterns, in the doc, noticed some were same 
left after drive formating, and picked 4. A655, then 55A6, then 2AC9, 
then 2AC9.

As to how effective any of this, is well, it would seem the only way to 
tell would be to have the equipment needed to grab the data, and see.  
Low-level formatting might be more effective than any of this, as it 
writes to more of the disk.

I think your program should, have an option to skip random data, the 
article made random
sound nearly pointless, as it was all about writing, and having it 
bleeding into the surrounding magnetic substrate on the disk.  Some 
patterns are more likely induce a neighboring  bit' to flip, than 
others.  AND, have user configurable buffer sizes.

Originally, I tried to do it all with 'yes', but the trailing newline, 
was problematic.
My prog, is shorter than this email, so I'll include in case anyone is 
interested.
Its designed to be used from shell, with dd.  My block size isn't 
user-configurable,
either, and I can only use the 2 byte sequences, but I can tune output 
with dd.
I found obs=128k was good for my machine,
ex: repeathex 55A6 | dd of=/dev/rdisk0s15  ibs=64k obs=128k
This was on  macosx, which will try vainly to recover data from zero'ed
hfs partitions, slowing boot time, though won't bother if filled with 
one of the patterns
I used, so one can make a drive look like it was just formatted if one 
knows the
pattern the format program writes.  Its also sometimes useful to know 
that one is looking
at data from unused parts of the disk.

---- repeathex.c -----------------------
#include <sys/types.h>
#include <sys/uio.h>
#include <stdlib.h>
#include <unistd.h>
#include <limits.h>
#include <stdio.h>

int main ( int argc, char * argv[] )
{
   const int len= 64 * 1024;
   int  num = (len/sizeof(short));
   int i;
   long l=0;
   unsigned short s;
   unsigned short sbuf[num];

   if ( argc >= 2 ) {
     l=strtol(argv[1],NULL,16);
   };
   s=(unsigned short)l;
   for ( i=0; i < num; i++ ) {
     sbuf[i]=s;
   }
   LOOP:
   if( 0 < (write(1,sbuf,len)))
     goto LOOP;
   perror("write()");
   return 1;
}