100%无法恢复的文件粉碎机原理

[sudoy]

市面上有一些文件粉碎机软件，但是从来没有仔细研究过，也不知道这些粉碎机粉碎以后的文件能否保证 100%无法恢复。不过我倒是有个想法，也许可以保证 100% 无法找回被销毁的文件，原理就是：修改(清空) => 保存 => 删除。

比如我有个 TXT 文档，里面保存一个密码，如果我直接删除这个文档，那么用一些文件恢复软件可以把他恢复回来，密码自然也被找回来。但是如果我先把文档里面的密码删除了，然后保存，然后再删除文件，那么即便用文件恢复软件把这个文档恢复了，也看不到密码。

所以我现在养成一个习惯，平时删除文件的时候，不管重要不重要，都会拖到二进制编辑器（比如frhed）里面，然后 ctrl + A, 再 delete 。

那么重点来了，这种方法是否是能保证 100%无法恢复的文件？ 如果是的话，我想写一个开源软件，可以用这个原理批量删除文件。

[gamexg]

据我所知，
目前粉碎机的原理是，覆盖写入随机内容多遍，然后再删除。

原理是，修改文件时，很多文件系统会直接再原扇区上面修改，之前的内容会被覆盖。
多次覆盖后，即使开盘也难以获取内容了。


不过这个其实有个缺陷，一些文件系统修改操作不再是直接对原扇区修改了，而是直接使用新扇区保存修改后的内容。
这种文件粉碎机效果应该不太好了。


楼主的清空文件内容后再次删除文件操作，理论上扇区上保存的文件数据并未删除，可能普通文件恢复软件无法找到，但是全盘查找应该还是能够看到部分内容。

[krixaar]

理论上不能 100%无法恢复。视存储介质（尤其是机械硬盘）和文件系统实现而定，此部分留给读者自行思考。
比较 paranoid 的做法是针对文件存储的原始位置写几遍 0 再写几遍随机数据再写几遍零。
相关的软件或者脚本应该有一大把，应该不需要重复造轮子。

[chairuosen]

可以实验一下就知道了
time dd if=/dev/zero of=test bs=1m count=1000
time echo 1 > test

[takemeaway]

你是不是弄反了？ 100%想要恢复被改的文件本身就不可能。TXT 的文档你用二进制打开，随便改几个地方，看看还怎么恢复。

[hakono]

如果是 ssd 的话用不着文件粉碎机，删了文件基本就没有找回的可能了

[msg7086]

一句话结论：不能。
文件内容存储在扇区中。你全选删除保存，文件变成了零字节，也就不占用扇区了，那你之前存储文件的扇区就会原样保留下来，没有被覆盖或修改。
另外是否覆盖原始扇区是看具体硬件软件实现的，硬件和操作系统不同，结果都不一样。比如你说的粉碎机在 zfs 下可能就没用，在 SSD 下可能就没用。
建议多了解底层的知识先。

另外，为啥要重复编写开源软件？开源的文件粉碎工具又不是没有。

[DSLAM]

ssd trim

[sudoy]

@msg7086 ssd 删除文件以后就恢复不了吗？还是说恢复的几率比较小而已？我有时候会在 AWS EC2 上保存我的重要信息，那我销毁 EC2 以后，如果下一个人租用，岂不是能找回？

[msg7086]

@sudoy EC2 这种企业用的环境怎么可能会在生成机器的时候不抹盘？
要真像你说的，市值几百亿的公司在上面租了服务器，过两天全让人给看光了……赔多少都赔不起啊。
这你大可放心。

至于 SSD 删除文件能否恢复的问题，这个很复杂。SSD 本身有很多层控制器，每一层都可能漏网。最安全的方式是 SSD Secure Erase，这种方式是先给 SSD 加密，然后抹除秘钥，然后再做一次格式化。因为抹除秘钥的时候数据已经无法恢复了，所以这样做是相对最放心的方法。

TRIM 法是相对乐观的一种做法，Secure Erase 则算是悲观做法。

[sudoy]

@msg7086 谢谢~👍👍

[ryansvn]

平时使用加密保存文件，不要的时候直接删除即可。