Question

在Shredding files in .NET中，建议使用Eraser或此代码here on CodeProject来安全删除.NET中的文件。

我试图制作自己的方法，因为CodeProject的代码对我来说有些问题。这就是我想出的：

        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); }
    }

似乎工作正常。它随机重命名文件，然后用1 mb的随机数据覆盖7次。但是，我想知道它到底有多安全，如果有的话，我可以让它更安全吗？

Answer 1

文件系统，特别是当通过更高级别的API（例如System.IO中的API）访问时，实际存储实现之上的抽象级别如此之多，以至于这种方法对现代驱动器毫无意义。

要明确：CodeProject文章，它促进多次覆盖文件按名称，绝对是无稽之谈 - 至少对于SSD而言。无法保证每次在某个路径上写入文件都会写入磁盘上的同一物理位置。

当然，打开具有读写访问权限的文件并从头开始覆盖它，从概念上写入相同的“位置”。但那个位置非常抽象。

看起来像这样：硬盘，特别是固态硬盘，可能需要写入，例如“将集群M的字节N设置为O”，并实际写入一个新的集群到驱动器上完全不同的位置，以延长驱动器的使用寿命（因为重复写入相同的存储器单元可能会损坏驱动器）。

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

页面无法覆盖

NAND闪存页面只有在处于“空闲”状态时才能写入。当数据改变时，页面内容被复制到内部寄存器中，数据被更新，新版本被存储在“空闲”页面中，这个操作称为“读 - 修改 - 写”。数据未就地更新，因为“免费”页面与最初包含数据的页面不同。一旦数据持久保存到驱动器，原始页面将被标记为“陈旧”，并将保持原样，直到它被删除。

这意味着在驱动器的某个位置，原始数据仍然可读，即在请求写入的群集M中。也就是说，直到它被覆盖。群集现在标记为“免费”，但您需要对磁盘进行非常低级别的访问才能访问该群集以覆盖它，我不确定SSD是否可以使用。

即使您多次覆盖整个SSD或硬盘驱动器，很可能您的某些非常隐私的数据隐藏在磁盘或SSD上现已不存在的扇区或页面中，因为在覆盖或清除它时驱动器确定该位置有缺陷。取证团队将能够读取此数据（尽管已损坏）。因此，如果您的硬盘驱动器上有数据可以用来对付您：将驱动器投入火中。

另请参阅Get file offset on disk/cluster number以获取有关较低级别文件系统API的更多信息（链接）。

但所有这些都需要花费很多，因为所有这些都是道听途说，而且我对这种级别的磁盘访问没有实际经验。

是否多次覆盖文件以擦除其数据？

1 个答案: