市面上有一些文件粉碎机软件,但是从来没有仔细研究过,也不知道这些粉碎机粉碎以后的文件能否保证 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
平时使用加密保存文件,不要的时候直接删除即可。
|