永久删除Android

时间:2015-10-24 19:39:27

标签: android

我发现了一个名为Super Erase的Android应用程序,它永久地从Android设备中删除文件和文件夹,以便删除的文件不能再恢复了......我正在谈论的应用程序......但我想知道如何到那个,我知道它是用android studio ..i尝试了常规方式删除file.delete()但仍然可以恢复文件。我有任何帮助。

4 个答案:

答案 0 :(得分:10)

对于初学者来说,secure file deletion on flash media是一个复杂的问题,没有快速简单的答案。论文Reliably Erasing Data From Flash-Based Solid State Drives概述了问题,潜在的解决方案及其局限性。他们得出结论

  

为了清理整个磁盘,...软件技术最有效,但不是   所有的时间。我们发现没有可用的软件   清理单个文件的技术是有效的。 [强调补充]

NIST 800-88也很好地概述了导致该问题的技术趋势,以及针对Android设备的一些最低建议(附录A)。但是它们往往是全磁盘擦除(工厂重置),或者依赖于加密擦除(CE),而不是一般的文件擦除方法。

但并非一切都没有丢失。即使您无法清理单个文件,也可以在删除文件后擦除所有未分配的空间。文章Secure Deletion on Log-structured File Systems(Reardon等人)描述了一种在用户模式软件中做到这一点的相当有前途的方法。 Android的内部存储器使用(总是?)一个日志结构的文件系统。

本文"清除"方法不需要内核级访问,并且似乎不需要Android上的任何本机代码。 (请注意,术语"清除"在NIST 800-88等文档中的使用方式略有不同。)基本思路是删除所有敏感数据,然后用垃圾填写驱动器上的剩余空间数据文件,最后删除垃圾数据文件。

虽然这比仅仅覆盖已删除的文件(在不同模式中多次)需要更多的时间和精力,但即使你必须处理耗损均衡和日志结构FS的可能性,它似乎也非常强大。

警告和进一步措施

对我来说,主要的警告是关于Reardon等人提到的条件。在上面的论文中:

  

清除将适用于同时提供的任何日志结构文件系统   用户的磁盘配额无限制,文件系统始终执行   垃圾收集以前回收甚至一块内存   声明驱动器是不可写的。 [强调我的]

第二种情况似乎很有可能实现,但我不知道第一种情况。 Android(或其某些制造商及其版本)是否对应用程序使用的磁盘空间强制实施配额?我没有找到任何关于用户配额的信息,但是有其他利基的配额,如浏览器持久存储。 Android是否为系统使用或每个应用程序的缓存保留了一些空间,例如,那些不能用于其他事情的应用程序?如果是这样,如果我们在删除敏感文件后立即开始清除,它应该有帮助(尽管没有保证),因此其他文件系统活动几乎没有时间将声明放入最近释放的空间。

也许我们可以通过周期性清除来缓解这些风险:

  • 确定相关分区上的剩余可用空间(称为S),例如使用File.getUsableSpace()
  • 将一系列文件写入分区;例如,每一个是初始S的20%(取决于文件大小限制)。
  • 当我们用完空间时,删除我们创建的前几个文件,然后在空间允许的情况下写另一个或两个文件。
  • 重复最后一步,直到达到您满意的阈值。也许你已经写了2 * S的填充文件;调整这个数字以平衡速度与彻底性。你真正需要做多少就是进行更多研究的领域。
  • 删除剩余的填充文件。

周期性清除的想法是,如果我们用完配额来覆盖所有可用空间,删除刚刚写入的填充文件将释放更多配额;然后,日志结构文件系统分配新块的方式应该允许我们继续按顺序覆盖剩余的可用空间块,而不是再次重写相同的空间。

我在测试应用中实施此方法,并在其工作时发布。

FAT格式的microSD卡怎么样?

相同的方法是否适用于外部存储或microSD卡? FAT是块结构的,清除方法也适用于FAT格式的SD卡吗?

  

在大多数现代闪存设备上,例如CompactFlash和   安全数字卡,[磨损均衡]技术实施于   硬件由内置微控制器组成。在这样的设备上,磨损均衡   是透明的,大多数传统的文件系统都可以在它们上面使用   原样。 (https://en.wikipedia.org/wiki/Wear_leveling

...这对我来说,即使在FAT格式的SD卡上,磨损均衡也意味着传统的Gutmann methods不起作用(参见他的" Even Further Epilogue" )和#34; purging"是必要的。

清除是否足够,取决于您的安全参数。磨损均衡似乎意味着一个块可能会退役"在任何时候,在这种情况下,没有办法擦除它而不绕过微控制器的磨损均衡。即使您拥有内核权限,AFAIK也无法在软件中完成;你必须设计特殊的硬件。

然而,"退休"相对于媒体的生命,坏块应该是相当罕见的事件,因此对于许多场景,清除方法足够安全。

删除痕迹

请注意,Gutmann的方法具有重要的优势,即擦除存储介质上的possible traces of old data,即使在用新数据覆盖块之后也可能保留该iShredder。从理论上讲,这些跟踪可以由具有大量资源的坚定的攻击者读取。一个真正彻底的安全删除方法是增加像Gutmann这样的方法,而不是替换它。

然而,在日志结构和磨损级别的文件系统上,更大的问题是试图确保敏感块被覆盖。

现有应用程序是否使用这些方法?

我没有关于应用商店中应用的任何内幕信息,但查看iShredder 4 Enterprise等应用的评论会表明他们充其量只使用Reardon"&#34等方法;吹扫&#34。例如,他们可以花费几个小时来进行32GB可用空间的单遍擦除。

另请注意限制:对某些安全删除应用的评论表明,在某些情况下,"已删除"运行"安全删除"后仍然可以访问文件。操作。当然,我们会对这些评论进行评判 - 可能会出现用户错误。然而,如果没有良好的测试,我不会认为这些应用程序是有效的。

The U.S. Department of Defense no longer references DoD 5220.22-M as a method for secure HDD erasure在他们的应用说明中有用地命名了他们使用的一些算法:

  

根据版本的不同,iShredder™软件包附带删除   算法如DoD 5220.22-M E,美国空军(AFSSI-5020),美国陆军   AR380-19,DoD 5220.22-M ECE,BSI / VS-ITR TL-03423标准,   BSI-VS-2011,北约标准,Gutmann,HMG InfoSec No.5,DoD 5220.22 SSD   和其他人。

这个令人印象深刻的名单为我们提供了进一步研究的一些指示。目前尚不清楚如何使用这些方法 - 单独使用或组合使用 - 特别是它们中的任何一种是否表现为单独有效。我们知道Gutmann的方法不会。类似地,DoD 5220.22-M,AFSSI-5020,AR380-19和Infosec No.5指定用于覆盖硬盘驱动器上的扇区的类似Gutmann的程序,这对于基于闪存的介质是无效的。事实上," NIST 800-88",更不用说基于闪存的媒体了,所以这个参考对于不知情的人来说是误导性的。 (据说国防部会引用{{3}}。)" DoD 5220.22 SSD"听起来很有希望,但我找不到任何有用的参考资料。我还没有追查列出的其他算法,但到目前为止的结果并不令人鼓舞。

答案 1 :(得分:5)

使用标准方法(如file.delete()runtime.exec("rm -f my_file")删除文件时,内核所做的唯一工作是从辅助文件系统结构中删除有关文件的信息。但是包含实际数据的存储扇区保持不变。因为这种恢复是可能的。

这给出了我们如何尝试完全删除文件的想法 - 我们应该以某种方式擦除所有扇区。最简单的方法是用随机数据重写所有文件内容几次。每次传递后,我们必须刷新文件缓冲区以确保将新内容写入存储。所有现有的安全文件删除方法都围绕着上述原则。例如this one。请注意,没有适用于所有存储类型和文件系统的通用方法。我想你应该自己试验并尝试实现一些现有的方法或设计自己的方法。例如。你可以从下一个开始:

  1. 使用随机数据覆盖并刷新文件10次(使用FileOutputStream方法)。注意!!!不要使用零或其他低熵数据。一些文件系统可以优化这种稀疏文件并使一些扇区具有原始内容。您可以使用/dev/urandom文件作为随机数据的来源(这是一个虚拟文件,它是无穷无尽的)。它提供了更好的结果,并且比着名的Random类更快地工作。
  2. 重命名并移动文件10次。随机选择新文件名。
  3. 然后使用FileChannel.truncate()截断文件。
  4. 最后使用File.delete()删除文件。
  5. 当然,您可以在本机代码中编写所有逻辑,它甚至可能比在Java中更容易。描述的算法只是一个例子。试着这样做。

答案 2 :(得分:2)

标准文件系统API不会为您提供简单的函数调用。

您必须使用FileIO的底层原生API。虽然我从来没有使用它,但是有一个库:

https://github.com/johanneslumpe/react-native-fs

答案 3 :(得分:1)

这个问题有两个答案。

首先,回答这些应用程序中某些应用程序可能正在执行安全单个文件删除的直接问题:您所做的实际上是打开文件并用零替换内容多次。这个方法听起来很愚蠢,但过去我在Android上使用过文件系统级加密,我发现上述内容适用于许多安全文件删除解决方案。对于看似合规的安全性,您可以重复写入0次(或者NIST标准为您的硬件类型指定的任何内容)。

Charset charset = StandardCharsets.UTF_8;
String content = new String(Files.readAllBytes(path), charset);
content = content.replaceAll("*", "0");
Files.write(path, content.getBytes(charset));

然而,这个问题的正确答案是不同的。 在现代SSD驱动器和操作系统上,删除单个文件是不安全的。因此,这些应用程序并不真正提供引人注目的产品。现代操作系统将文件的片段存储在不同的位置,即使在您逐块清除了最新版本的文件并覆盖了所有元数据之后,也可能是旧版本的片段。文件可能会留在驱动器的另一部分。

从磁盘删除敏感内容的唯一安全方法是在丢弃磁盘之前将整个磁盘清零多次。

@ LarsH关于在删除文件后擦除所有未分配空间的答案令人信服,但可能不切实际。如果您只想保护删除文件,以便没有人可以扫描磁盘来恢复它,那么更好的解决方案是全盘加密。这实际上是全盘加密的全部吸引力。这就是为什么Apple停止在Mac OSX和iOS中支持安全文件删除,并在所有iPhone上默认切换到全盘加密的原因。 Android手机现在也有全盘加密功能。

修改

如果您正在为客户寻找真正的解决方案,最好的办法是使用单文件加密。一旦你销毁了你的应用程序只知道的密钥,即使有人在磁盘上找到它,也无法解密文件。

在SSD上安全删除文件没有真正的解决方案。你只能给仍然记得旧硬盘驱动器时代的非技术人员带来虚假的安全感。