This is a common problem. There was a long thread on it on a tech writers' mailing list
http://web.techwr-l.com/pipermail/techwr-l/2008-November/033870.htmlHere's one of my posts in that thread:
Nancy Allison <maker at verizon.net> wrote:
> I thought that reformatting the hard drive removes all data except for
> the most determined forensic investigator. If you have, or can borrow,
> someone's installation disk for your operating system, you can reformat
> the hard drive. If you have any doubt, reformat it a couple of times.
Unless you need to defend against professionals, that should do it.
Beware of a "quick format" which leaves most of the disk untouched,
though. Change the partitions to avoid that.
I'd use a different OS than what you are running; just download a free
Linux or one of the BSD's
ubuntu.com, freebsd.org, netbsd.org, etc.
An easier way is to just download a free utility. That's what I'd do:
http://freshmeat.net/projects/dban/The classic paper on recovering data from allegedly erased disks
is
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.htmlIt recommends 35 writes with particular patterns of bits.
However, it is for defending against people who do things like
dismantling the disk and using custom-programmed disk
controllers to look for traces of data. Also, it was written in
1996, so it is probably out of date now.
Here's something I wrote on the topic in a newsgroup 10 years ago:
This comes up often enough to be a FAQ, but I'm not sure which FAQ
document would have it.
To do it really well is difficult.
For example, suppose the file is written & then a disk-check program
finds a bad block in it, copies data elsewhere & maps the bad block out.
Now nothing running on your OS sees that bad block, but it may contain
data which an attacker bypassing the OS could recover. You cannot defend
against that without bypassing the OS yourself to overwrite the block. Even
then, are you sure your overwrite worked, given that the block has problems?
This gets even harder if the disk drive is smart enough to map out bad blocks.
Does it even tell the controller about that?
You also have to be careful that everything gets physically written to the
disk. 20 overwrites are pretty ineffective if all they're doing is changing
data in a RAM cache.
There are also papers around on sophisticated attacks using specialised
hardware & measuring small differences in disk magnetism & . . . I don't
think there's a certain defense against them short of destroying the disk.
At one point, I had a copy of a US gov't standard for clearing off disks
with mildly secure stuff on them. The hard part was as above; dealing
with bad blocks & providing guarantees they'd been dealt with.
Also, little details. Suppose you have a six-block file that gets truncated
to 3.5 blocks by some user action. When it's later deleted, should your
overwrite do 3.5 blocks or 4? What about the other two blocks?
The easy part was just overwriting files. as I recall (this was years back),
that needed at least three writes, one all-0s, one all-1s & one random.
Two points I recall from the code I wrote:
for( i = 0; i < 256 ; i += 85)
puts a byte through binary values:
00000000
0101010101
1010101010
11111111
which is handy.
You do the loops inside out. For any other application you might
do the file stuff in the outer loop & bit-fiddling in the inner. For this,
you write a function that writes the same byte to every byte of a
file, with frequent fflush()s & an fclose() at the end.
You then call that inside the for() loop above, four times with
different bytes each time, & a time or two with random data.