-1

In Shredding files in .NET it is recommended to use Eraser or this code here on CodeProject to securely erase a file in .NET.

I was trying to make my own method of doing so, as the code from CodeProject had some problems for me. Here's what I came up with:

        public static void secureDelete(string file, bool deleteFile = true)
    {
        string nfName = "deleted" + rnd.Next(1000000000, 2147483647) + ".del";
        string fName = Path.GetFileName(file);
        System.IO.File.Move(file, file.Replace(fName, nfName));
        file = file.Replace(fName, nfName);
        int overWritten = 0;
        while (overWritten <= 7)
        {
            byte[] data = new byte[1 * 1024 * 1024];
            rnd.NextBytes(data);
            File.WriteAllBytes(file, data);
            overWritten += 1;
        }
        if (deleteFile) { File.Delete(file); }
    }

It seems to work fine. It renames the file randomly and then overwrites it with 1 mb of random data 7 times. However, I was wondering how safe it actually is, and if there was anyway I could make it safer?

Community
  • 1
  • 1
Justin G
  • 172
  • 3
  • 19
  • 1
    Writing all zeroes one time is enough. But you have to overwrite the old sectors. Your code will never work, the CodeProj version at least uses FileMode.Open, that is crucial to erase on an HDD. Wiping from a SSD is much harder, you'd have to overwrite the _Disk_ . – H H Aug 13 '16 at 19:28

1 Answers1

6

A file system, especially when accessed through a higher-level API such as the ones found in System.IO is so many levels of abstraction above the actual storage implementation that this approach makes little sense for modern drives.

To be clear: the CodeProject article, which promotes overwriting a file by name multiple times, is absolute nonsense - for SSDs at least. There is no guarantee whatsoever that writing to a file at some path multiple times writes to the same physical location on disk every time.

Of course, opening a file with read-write access and overwriting it from the beginning, conceptually writes to the same "location". But that location is pretty abstract.

See it like this: hard disks, but especially solid state drives, might take a write, such as "set byte N of cluster M to O", and actually write an entire new cluster to an entirely different location on the drive, to prolong the drive's lifetime (as repeated writes to the same memory cells may damage the drive).

From Coding for SSDs – Part 3: Pages, Blocks, and the Flash Translation Layer | Code Capsule:

Pages cannot be overwritten

A NAND-flash page can be written to only if it is in the “free” state. When data is changed, the content of the page is copied into an internal register, the data is updated, and the new version is stored in a “free” page, an operation called “read-modify-write”. The data is not updated in-place, as the “free” page is a different page than the page that originally contained the data. Once the data is persisted to the drive, the original page is marked as being “stale”, and will remain as such until it is erased.

This means that somewhere on the drive, the original data is still readable, namely in the cluster M to which a write was requested. That is, until it is overwritten. The cluster is now marked as "free", but you'll need very low-level access to the disk to access that cluster in order to overwrite it, and I'm not sure that's possible with SSDs.

Even if you would overwrite the entire SSD or hard drive multiple times, chances are that some of your very private data is hidden in a now defunct sector or page on the disk or SSD, because at the moment of overwriting or clearing it the drive determined that location to be defective. A forensics team will be able to read this data (albeit damaged). So, if you have data on a hard drive that can be used against you: toss the drive into a fire.

See also Get file offset on disk/cluster number for some more (links to) information about lower-level file system APIs.

But all of this is to be taken with quite a grain of salt, as all of this is hearsay and I have no actual experience with this level of disk access.

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • Alright, so what method do you propose i use to securely delete a file? – Justin G Aug 13 '16 at 18:17
  • I'm by no means a file system nor security expert, but the general means are: find the physical locations on disk currently in use by the file (_if_ that's even possible), overwrite _those_, then erase every mention of the file from the file system. Note that `File.Delete()` also doesn't do the latter, it merely _marks_ a file system records as deleted. – CodeCaster Aug 13 '16 at 18:19
  • But even if they knew where the file was, isn't there a very low chance of them actually recovering it? I read from this thread http://stackoverflow.com/questions/59656/why-overwrite-a-file-more-than-once-to-securely-delete-all-traces-of-a-file/60193#60193 that "Trying to recover an entire byte is only accurate 0.97% of the time." so is there really even a point of me trying to overwrite it? – Justin G Aug 13 '16 at 18:23
  • See edit. First and foremost, that information is about magnetic remanence on hard drives. Solid state drives add another layer of abstraction: what you request may or may not be what the drive actually does. – CodeCaster Aug 13 '16 at 18:27
  • 2
    @JustinG the only secure way to delete a file is not have the file on the disk. Consider switching to storing the file in a encrypted container, The bytes will be still on disk after a delete but it will increase the difficulty of restoring the data especially if they only have a incomplete view of the encrypted container. – Scott Chamberlain Aug 13 '16 at 19:55
  • I'm creating a file encrypter, so naturally the file you'll be encrypting isn't already encrypted. I've decided to use this - http://microsoftwinanyhelper.codeplex.com/ - as I feel it's relatively safe as long as I use a strong algorithm. – Justin G Aug 13 '16 at 20:22
  • Which is just as much outdated nonsense as the other libs and totally ineffective for SSDs. – H H Aug 13 '16 at 23:16
  • @CodeCaster - the CodeProject sample has a reasonable chance of overwriting the sectors on a HDD. Not total nonsense but not a real solution either. – H H Aug 14 '16 at 14:43
  • 2
    SSDs aren't the only problem. A [copy-on-write filesystem](https://en.wikipedia.org/wiki/Copy-on-write#Copy-on-write_in_computer_storage) will make overwriting the file's data pretty much impossible via filesystem accesses. – Andrew Henle Aug 14 '16 at 16:23