这是一个创建于 1630 天前的主题，其中的信息可能已经有所发展或是发生改变。
市面上有一些文件粉碎机软件，但是从来没有仔细研究过，也不知道这些粉碎机粉碎以后的文件能否保证 100%无法恢复。不过我倒是有个想法，也许可以保证 100% 无法找回被销毁的文件，原理就是：修改(清空) => 保存 => 删除。
比如我有个 TXT 文档，里面保存一个密码，如果我直接删除这个文档，那么用一些文件恢复软件可以把他恢复回来，密码自然也被找回来。但是如果我先把文档里面的密码删除了，然后保存，然后再删除文件，那么即便用文件恢复软件把这个文档恢复了，也看不到密码。
所以我现在养成一个习惯，平时删除文件的时候，不管重要不重要，都会拖到二进制编辑器（比如frhed）里面，然后 ctrl + A, 再 delete 。
那么重点来了，这种方法是否是能保证 100%无法恢复的文件？ 如果是的话，我想写一个开源软件，可以用这个原理批量删除文件。
 |
1
gamexg 2020-06-10 14:56:42 +08:00  1
据我所知，
目前粉碎机的原理是，覆盖写入随机内容多遍，然后再删除。 原理是，修改文件时，很多文件系统会直接再原扇区上面修改，之前的内容会被覆盖。 多次覆盖后，即使开盘也难以获取内容了。 不过这个其实有个缺陷，一些文件系统修改操作不再是直接对原扇区修改了，而是直接使用新扇区保存修改后的内容。 这种文件粉碎机效果应该不太好了。 楼主的清空文件内容后再次删除文件操作，理论上扇区上保存的文件数据并未删除，可能普通文件恢复软件无法找到，但是全盘查找应该还是能够看到部分内容。 |
 |
2
krixaar 2020-06-10 15:01:04 +08:00 1
理论上不能 100%无法恢复。视存储介质（尤其是机械硬盘）和文件系统实现而定，此部分留给读者自行思考。
比较 paranoid 的做法是针对文件存储的原始位置写几遍 0 再写几遍随机数据再写几遍零。 相关的软件或者脚本应该有一大把，应该不需要重复造轮子。 |
 |
3
chairuosen 2020-06-10 15:05:02 +08:00 1
可以实验一下就知道了
time dd if=/dev/zero of=test bs=1m count=1000 time echo 1 > test |
 |
4
takemeaway 2020-06-10 15:06:28 +08:00
你是不是弄反了？ 100%想要恢复被改的文件本身就不可能。TXT 的文档你用二进制打开，随便改几个地方，看看还怎么恢复。
|
 |
5
hakono 2020-06-10 15:14:14 +08:00 via Android 1
如果是 ssd 的话用不着文件粉碎机，删了文件基本就没有找回的可能了
|
 |
6
msg7086 2020-06-10 19:44:53 +08:00 via Android 1
一句话结论：不能。
文件内容存储在扇区中。你全选删除保存，文件变成了零字节，也就不占用扇区了，那你之前存储文件的扇区就会原样保留下来，没有被覆盖或修改。 另外是否覆盖原始扇区是看具体硬件软件实现的，硬件和操作系统不同，结果都不一样。比如你说的粉碎机在 zfs 下可能就没用，在 SSD 下可能就没用。 建议多了解底层的知识先。 另外，为啥要重复编写开源软件？开源的文件粉碎工具又不是没有。 |
 |
7
DSLAM 2020-06-10 21:45:54 +08:00 via Android
ssd trim
|
 |
8
sudoy OP @msg7086 ssd 删除文件以后就恢复不了吗？还是说恢复的几率比较小而已？我有时候会在 AWS EC2 上保存我的重要信息，那我销毁 EC2 以后，如果下一个人租用，岂不是能找回？
|
|
9
msg7086 2020-06-16 14:49:11 +08:00 1
@sudoy EC2 这种企业用的环境怎么可能会在生成机器的时候不抹盘？
要真像你说的，市值几百亿的公司在上面租了服务器，过两天全让人给看光了……赔多少都赔不起啊。 这你大可放心。 至于 SSD 删除文件能否恢复的问题，这个很复杂。SSD 本身有很多层控制器，每一层都可能漏网。最安全的方式是 SSD Secure Erase，这种方式是先给 SSD 加密，然后抹除秘钥，然后再做一次格式化。因为抹除秘钥的时候数据已经无法恢复了，所以这样做是相对最放心的方法。 TRIM 法是相对乐观的一种做法，Secure Erase 则算是悲观做法。 |
 |
11
ryansvn 2020-07-14 17:14:29 +08:00
平时使用加密保存文件，不要的时候直接删除即可。
|
Select Language