Writing file shredder

Question

I want to write a simple file shredder in c++, i.e. a program that deletes a file so that it is not recoverable. Would the following be a secure and correct way to do that?

(1) Open the file with

ofstream myfile;
myfile.open ("deleteme.txt", ios::out | ios::binary); 

(2) Then run through 10 rounds of something like

unsigned int x = 0;
for (int i =0; i <= filesize -1; i++)
    {
    myfile.seekg (i, ios::beg);
    myfile << (char)x;
       [put new random character in x]
        }

(3) Then simply delete the file

  if( remove( "deleteme.txt" ) != 0 ) {
       cout << "Error deleting file";
       }
  else {cout << "File successfully deleted";
       }

(I guess one could simply also just delete the file in a console.)

Would it add extra security to rename the file before deletion?

Is there anything else that should be done to completely remove a file so that it cannot recovered or is this enough?

EDIT1: Just to clarify, the above code is sime-pseudo. My main concern is if overwriting a file byte by byte and the deleting the file will be a good way to make it irrecoverable.

EDIT2: I am just interested in the best way to do this by using software alone.

Edit3: Adding one more thing: I am mostly interested in a level of security that prevents recovery by methods of software.

Answer 1

Sounds like a fun project. I know you said "simple," but here are my thoughts anyway.

The data you're writing the file over with isn't random, and one pass will still leave traces of the original data. It depends on the storage medium. For example, with magnetic devices, there's magnetic force microscopy. Even after ten rounds of the same thing, I'm not sure you're adding any extra benefits.

Renaming and deleting files won't add robust protection because, on most file systems, it simply changes the pointer to the location on the disk where the data is. Deleting a file only removes the pointer, so the disk sees the blocks as "available" even though the file is actually there. (This is why recovery software works.)

Thorough, secure deletes have the following features (software-based, not considering hardware solutions):

• PRNG (Pseudorandom number generator) which generates random values to write at every byte of the file's allocated space (also see the encryption feature below).

• Multiple passes (careful here, depends on the medium)

• A run with all 0s then all 1s couldn't hurt, either. It may help interrupt a predictable, yet subtle, pattern of randomness (because computers aren't truly random).

• Some file systems are "Copy-on-write", which is like a type of "revision control." These try to avoid overwriting data already in place. That protection would have to be circumvented.

• RAID devices mirror changes to a disk onto another disk.

• Fragmented files may start at one sector and finish at an entirely other part of the disk. Alternatively, anti-fragmentation features may keep redundant copies of the data or relocate them in real time.

• Solid-state drives manage the disk space differently than magnetic drives. Coupled with wear-leveling, there are technical reasons that make secure wiping a little tricky. (See Wikipedia link below)

• Encrypting a file before wiping it will help fill it with "random" bits... but really the best answer to secure shredding is to encrypt it before it ever hits the disk.

Don't miss this great question which talks about wiping info on solid-state drives, particularly flash drives. Remember that SSDs wear out after being written enough times.

Look at this article on Wikipedia for some more detailed background info.

By the way...

I'd really like to see a shredder that grants some plausible deniability. It would securely erase the file, then plop remnants of a decoy file in its place, perhaps a file chosen by the user that exists elsewhere on the hard drive. It would appear to be the remnants of a copy of that file which at one time was pointed to by the file system, was deleted by the user, and, depending on the size, was potentially being gradually overwritten by regular use.

If a forensics agent were to examine the portion of a disk where a regular shredder was run, it's easy to tell that it was wiped with random data. But if a decoy file was put in its place, I imagine it would be harder to tell.

Answer 2

Secure file deletion is more a factor of the filesystem rather than the application. Several filesystems use copy-on-write mechanics, including most famously ZFS and BTRFS, but also to some extent even NTFS with shadow copies. So overwriting a file with random data just allocates some previously-blank space and fills it with randomness. Somewhat pointless in all practicality.

A secure delete program would have to be filesystem-aware, if not even a filesystem driver itself, in order to directly seek out and overwrite the relevant blocks. And even then there's the possibility that even the filesystem doesn't have the final word as to whether data gets overwritten. For example, LVM snapshots and SSD wear-leveling can prevent you from actually overwriting your data, again simply allocating otherwise blank sectors and writing your random data there instead.

You're much better off, much safer off, wiping the whole drive in one go using DBAN or something similar.

Also, while technically, theoretically, you can recover previously overwritten bits using a magnetic force microscope or what have you, the chances of that even being a possibility, even in the most extreme circumstances, are approximately zero. Every bit would have to be manually, individually reconstructed at a comparatively low rate of success and an extremely high cost per bit if it's even possible at all, which with today's high areal density drives, appears impossibly unlikely. The original magnetic traces even before being overwritten are so weak that modern drives rely heavily on ECC bits just to reliably retrive your data.

See also: http://www.anti-forensics.com/disk-wiping-one-pass-is-enough

Answer 3

You shouldn't write your own shredder programmer. Instead, grab an existing well-vetted shredder.

• For hard-disk shredding, I recommend ATA Secure Erase or DBAN (search this site for details). DBAN is open-source, so you can look at its source.

• For file shredding, I recommend GNU's shred program (comes with Coreutils). shred is open-source, so you can look at its source, too.

Do understand that file-level shredding is inherently insecure in many circumstances, no matter how carefully written the program is. Given how modern filesystems, overwriting a file with different bytes does not mean that all copies of the original data on disk will necessarily be overwritten. In some cases, overwriting a file may cause the filesystem to make a copy and modify the copy, leaving the original data stored elsewhere in the hard disk (in "free space") where a file-level shredder cannot delete it. In other cases, remnants of the old data may be left around on the hard disk for other reasons.

Answer 4

As you are aware simply deleting a file leaves data on the filesystem, which may later be overwritten or not.

However, a single overwrite of a file prevents recovering the data in practice, though there's a small theoretical threat of partial data recovery by analyzing bit by bit with an electron microscope. This threat has never been demonstrated in practice to recover any significant amount (e.g., 1 kb+ ~ 8192 bits) of data as opposed to a few bits under idealized conditions. See [1], [2].

The major problem with secure deletion by overwriting is not the number of wipes, its that you do not know exactly how your operating system/hardware is handling your data. E.g., you may have initially saved a file to a given sector, but that block was later determined to be bad, so it mapped the data to a different sector. The problem gets worse with solid state drives (SSD) that due to limitations of flash technology (limited overwrites of a given block; must first zero out entire block before writing; then rewrites entire block), the hardware tries to avoid rewriting sectors whenever possible for optimal operation.

Solution: if your data needs to be kept secret, use full disk encryption. If the encryption key is compromised, write over the entire disk (though data may still exist in bad sectors) or physically destroy the disk.