Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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; ("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.

share|improve this question
I'm pretty sure that doing that will not make the file totally irrecoverable. Not 100% sure though. –  Terry Chia Jun 7 '12 at 3:10
@TerryChia: So you are saying that the file might still be recoverable? How can I improve on this? –  Thomas Jun 7 '12 at 3:13
You might also consider writing each bit or byte with actual binary data instead of ASCII through the whole thing. –  Matt Jun 7 '12 at 4:29
Can you clarify, are you doing this for an exercise, or are you trying to make a real tool? (Because best practice for secure file destruction involves a wider approach than your question covers.) –  Graham Hill Jun 7 '12 at 8:44
This is "toy code", unsuitable for real use. It writes data character by character, it seeks before each write even though the file position is right where it's seeking, it assumes the file size will fit in an int, and so on. So even if the method was sound, the code (at best) just demonstrates the method. –  David Schwartz Jun 7 '12 at 8:47

4 Answers 4

up vote 6 down vote accepted

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.

share|improve this answer
Thanks for the answer. So you are saying that if I want to just focus on the software version (1) overwriting with new "random" data should be done (2) Including overwriting with non-random data as a decoy. So if I do that, will I then get the best that one can do with software alone? How do I check if a program like what I suggest written in c++ will actually overwrite the bytes and not just do "copy on write"? –  Thomas Jun 7 '12 at 13:17
I think that would be sufficient, esp. for a "simple" project. Determine the filesystem programmatically. I doubt you'll encounter "copy-on-write" file systems often, if at all, for normal use... one I'd be more concerned with is a journaling file system like EXT3 or EXT4, used frequently by Linux. I forgot to mention that in my answer, but the linked articles should fill you in. Anyway, if the file system you detect uses journaling or revision control, perhaps you can take steps to mitigate any risk... someone else may know better how to do that. –  Matt Jun 7 '12 at 13:46
Nice exploration of what's about! Just: In order to install a decoy, you have to: .1 shred all blocks, .2 fill all block with 0 (0x00) and finaly .3 install a fake. For ensuring not to leave suspect random data in the last block! –  F. Hauri Mar 30 '13 at 6:45

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.

share|improve this answer
Thanks for the answer. After researching the issue a bit on my own, I have come to the same conclusion: That my suggested program will not really be that secure. But at least it should be better than simply deleting the file with "del finlename" (or rm or whatever). Oon… that it seems that shred also only overwrites the data like I suggest. Do you have a link to the source code for shred? (I guess I could download the whole coreutils package, but...) –  Thomas Jun 8 '12 at 17:37
@Thomas, Yes, I recommend that you download the coreutils package. Alternatively, look here for the source to shred. –  D.W. Jun 8 '12 at 17:42
P.S. Be warned that some of the comments in the code are out of date and no longer accurate about modern disk technology. –  D.W. Jun 8 '12 at 17:44

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:

share|improve this answer
Thanks for the answer. –  Thomas Jun 8 '12 at 18:07

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.

share|improve this answer
Thanks for the answer. –  Thomas Jun 8 '12 at 18:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.