Computers > Digital forensics > Data sterilization >

If in doubt, don’t try to sterilize a file by overwriting it.

Overwriting a file isn’t always trustworthy. Caching and other mechanisms (e.g. S.M.A.R.T.) may silently write the file to any other location. There is no guarantee that a file you write will actually be written overtop of the old one.

man shred ∞

This is what man shred from GNU coreutils 8.5 has to say:

CAUTION: Note that shred relies on a very important assumption: That the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file system modes:

• Log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

  • and Btrfs
• File systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems
• File systems that make snapshots, such as Network Appliance’s NFS server
• File systems that cache in temporary locations, such as NFS version 3 clients

• Compressed file systems

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab (fstab) file, as documented in the mount man page (man mount ).

In addition, file system backups and remote mirrors may contain copies of the file that cannot be removed, and that will allow a shredded file to be recovered later.

Some other examples ∞

• Disk S.M.A.R.T.

  • A block detected as bad will have its data migrated transparently and the old unreadable block will be marked as bad. That old block may yet be readable or partially readable through better technologies, and its data remains unsterilized.
• Low-level disk caching.
• NAS / network drive caching.

• Operating system-level caching.

  • Swap files.

• RAID mechanisms and redundant filesystems.

  • One example is that bad block migration will leave deposits of partially-readable unsterilized data.
• Data can also be kept around in memory by various means like an open file handle.

• Other weirdness such as caching done by VMware for a guest.

Most importantly, log-structured or journaled filesystems do all sorts of things and can be suspected. Luckily I use ext4 (under Linux), and mount -t ext2 will work to mount the partition as ext2 (i.e. without journaling). Other journaling filesystems include AIX and Solaris filesystems and JFS, ReiserFS, XFS, Ext3, and probably more. (Btrfs)

It is for these reasons that I prefer to encrypt the entirety of a filesystem and not individual files.