Secure wipe(ing) of files and drives

I had two identical hard drives (about 500GB each) which I wanted to donate to my kid’s local school and before doing that, I wanted to make sure they are delivered ‘as clean as possible’ in the sense that almost no recovery software could restore any files that were previously “removed” by either deletion or formatting.

“Removed” because when you “delete” a file, a file isn’t really deleted but its reference is. There’s plenty of meta data left lying around so that restoring a file (best case scenario: immediately after it has been “deleted”!) is a mere child’s play (and there are plenty of software options out there, but I personally prefer those on offer from the Linux eco system!).

There are cases when software just won’t do, and one has to resort to using specialized hardware, but I doubt most of us will ever see such hardware unless they work for the department of defense or some cyber security contractor out there or what not.

Anyway, back to my topic…

The first recommendation you would receive if you’re in a similar situation as I was, is to use DBAN (or Darik’s Boot and Nuke).

But, as I already stated – I like using tools from the Linux eco system – so this is why I wanted to give shred a try.

From the above ArchWiki (securely wipe disk), shred:

“is a Unix command that can be used to securely delete individual files or full devices so that they can be recovered only with great difficulty with specialized hardware, if at all!”

There are some limitation to shred though, as pointed out in this Wikipedia article and in this one on FSM.

Anyhow, I first opened the USB’s device file with hexeditor:

hexeditor -d /dev/sdd1


Do you see the data in the far right column!? Even though this USB was formatted (at least a dozen times and just prior to this exercise!).

Running photorec with the option to look for ‘*.txt’ files, resulted with 4550 text files (!!!) (none of which had the original file name):


I decided to go with single pass of random values and then a final pass of zeroes. The command hence is:

time shred -vfz -n1 /dev/sdb

The time before shred was to see how long it would take to ‘shred’ the entire partition on the USB. The result was surprisingly ‘high’ – just above half an hour! I certainly expected half of that.


But then when I reopened the USB’s device file with hexeditor:


… and I scrolled further down just to make sure the device file is clean!

After, I re-ran photorec (with a filter to look for all supported files – not just ‘*.txt’ ones!):


Hmm… seems to work just fine with single pass of random values. BTW, I have high respect for photorec and testdisk and for the guy (Cristophe GRENIER) who developed and maintains them. They have helped on more than one occasion!

Finally, I ran shred on one of the HDDs with the default option of 3 passes with random values and a final pass with zeroes, while for the second HDD, I ran shred with a single pass with random values and a final one with zeroes – and of course – timed both runs.

Close to 5 hours for the first run and around 3.5 hours for the second one!? Which as you might see and conclude – running shred with a single pass is faster (and secure enough for most users, but not too much faster, which is why I’m suspecting my trials…). Then again, running it with the default option (3 passes with random values) – especially if you’re paranoid – is more secure for sure!