, , , , , , , , , , , ,

After chatting to someone about disk wiping and data recovery, I decided to try a few things myself. Primarily I wanted to know whether a storage device could be securely wiped using just native Linux OS features.
Before going further, I should mention that one method here will recover almost anything and everything, and I strongly recommend against practising on some random device that you bought from some guy in a pub – the last thing you want are nasty surprises.

Which drive?
Obviously it’s important to ensure we’re wiping the correct filesystem. With modern Linux distros, the /media directory contains pointers to the volumes’ actual mountpoints in /dev, and the latter must be determined using the $df command:


The USB drive I’m using for the following experiments is labelled ‘SFF-KEY’, and its mountpoint is /dev/sbd1. It had a number of images, document files and other data I stored there several months ago.

First I simulated a conventional file deletion and overwriting of the USB drive’s contents, so the drive showed as blank in file managers. First by removing all the files on the device (SFF-KEY):
#rm /media/SFF-KEY/* -r

Then for good measure I piped output from /dev/urandom to a single 2GB file that apparently occupied the whole storage volume:
#cat /dev/urandom >> /media/SFF-KEY/all

The USB drive was flashing like mad during this stage, which took 12 minutes on an outdated laptop with other stuff running in the background. Finally I deleted the file using the same command as before. The autopsy/sleuthkit utility still managed to recover all the files that were deleted:


I repeated the operations for the second time, and the files were again recovered by autopsy.

Wiping the volume with two simple commands
To some extent the dd command is useful for wiping a drive, as it enables us to zero a target filesystem and overwrite it with random bytes. Since this works with the underlying filesystem, it’s definitely worth testing.

My first command overwrites the entire storage volume with zero bites, which in theory should completely wipe everything. Later I’ll demonstrate why this isn’t the case in practice:
#dd if=/dev/zero of=/dev/sdb1

Things are different for magnetic storage because of hysteresis, relative magnetic field strengths, etc. etc. So we follow up the zeroing with another command that overwrites the volume with random bytes from /dev/urandom:
#dd if=/dev/urandom of=/dev/sdb1


There are technical reasons for choosing /dev/urandom: Disk wiping software commonly works by overwriting files or partitions several times with pseudo-random bitstreams, and the bitstreams should have enough entropy to prevent them being sifted from the bytes that made up the original files we’re trying to erase. I chose /dev/urandom because it’s random enough, and unlike /dev/random (which might be a choice for the really paranoid), doesn’t wait for an entropy pool to be repopulated.

As before, I tested the method by imaging the filesystem and loading it into autopsy/sleuthkit. The first sign that the volume was successfully and properly wiped is autopsy was unable to determine the original filesystem type.


The Analysis view in Sleuthkit revealed there was a complete absence of files to analyse, and autopsy had failed to recover anything recognisable. Apparently it’s a clean slate without a filesystem, requiring a low-level reformat.

Deep Recovery
But I’m a little more thorough than this. When the method is tested against software that’s specifically developed for data recovery, then we could determine whether the volume was truly wiped. Here I ran the foremost file carving utility, which ignores the filesystem and scours the drive for header bytes, on the volume itself. It’s a good idea to run foremost with root privileges in verbose mode, and pipe the status messages to a log file:
#foremost -i /dev/sdb1 -o /home/michael/frecover -T -v >> /home/michael/foremost-log.txt

The outcome was interesting. Despite the data being hidden from autopsy (and perhaps EnCase as well), foremost managed to reconstruct several hundred files that were stored on the drive by its previous owner, and even .rar archives of exploit kits. Roughly 70% of the files were fully reconstructed, about 20% had fragments missing and the rest were misinterpreted signatures. Data carving turned out to be a surprisingly effective method of recovering data here, and therefore a recommended way to check if file erasing programs actually do what they say on the tin.