I am writing a script to wipe my hard disk, in a relatively secure manner by over-writing the disk with 3 patterns. So, I run the dd/dcfldd command 3 times with a sync call in between each command call in the script.
I want to know if the above code would in fact,result in my hard disk being over-written with the given patterns in that order? Since I have introduced a sync in between each command call, any remaining buffers to be written onto the disk would have been physically written before the next pattern is being copied to the disk by dcfldd.
Please help me. I really want to understand the impact.
If this is a hard drive and not some solid-state storage device, overwriting the entire disk with plain ordinary zeroes will prevent anyone except NSA men in cleanroom spacesuits from reading the previous data. If your data thieves are that motivated, all bets are off anyway.
I'd make your patterns prime number lengths, perhaps 5, 7, and 11 characters, to give maximum annoyance to the cleanroom spacesuit people since this will make a very long-interval thing for them to have to predict and compensate for.
If you've got /dev/urandom (or some similar source or "randomness") dd that to your disk. If it's not available, choose any pattern, and overwrite a second time using the complement number.
If you've got to delete HDDs often and/or want to be extra sure, DBAN is very recommendable.
Even after random data has been written to the drive it maybe possible to recover data using special tools that government agencies have access to.
If this is a problem for you and you really think that the government is out to get you, then you should simply destroy the drive and buy a new one.
Exactly how you destroy it is up to you but I read that the US government has a system for destroying computer equipment by cross cut, crush, grind, burn and then spread on the roads as grit in winter.
Thanks everyone for the responses.
Actually my doubt is if I am doing 2 swipes over the disk with a pattern and its compliment, using either dd/dcfldd for the purpose in a script, then the first swipe should have actually ended up physically on the sectors on disk before the second swipe.
With the script I have pasted in my first post, is the sync in between 2 swipes sufficient to ensure that?
Can anyone help me with some pointers on the impact of OS/disk caches on the way to disk sectors?
The sync is useful, but not really necessary (IMO). It does tell the kernel to write it's caches and metadata to disk, but you can't force the HDD cache. But even with a 64MB on-disk cache: that will be full & written to disc 2 seconds after you started writing the second pass.
Thanks.. That helped. So I am guessing writing to the device file for the HDD, opened with (O_SYNC) coupled with an extra sync command and a sleep, between the 2 swipes should be enough to ensure what I am asking to be written to disk actually does get there.
That helped. So I am guessing writing to the device file for the HDD, opened with (O_SYNC) coupled with an extra sync command and a sleep, between the 2 swipes should be enough to ensure what I am asking to be written to disk actually does get there.