永久删除Android文件 [英] Permanently delete files Android

问题描述

我找到了一个名为超级擦除的Android应用从android设备永久删除文件和文件夹，以便删除的文件无法再恢复..这是我正在谈论的应用程序...但是我想知道如何做到这一点，我知道它是由android studio制作的.删除 file.delete()的常规方法，但仍可以恢复该文件.我能帮上什么忙吗?

I found an android app named Super Erase that deletes files and folder permanently from android device so that the file deleted cant be recovered anymore..here is the application i am talking about ...but i was wondering how to that and i know it is made with android studio ..i tried the regular way to delete file.delete() but still the file can be recovered.can i have any help .

推荐答案

对于初学者，安全删除文件在Flash媒体上是一个复杂的问题，没有快速简便的答案.论文从基于闪存的固态驱动器中可靠地擦除数据很好地概述了问题，潜在的解决方案及其局限性.他们得出结论

For starters, secure file deletion on flash media is a complex problem, with no quick and easy answers. The paper Reliably Erasing Data From Flash-Based Solid State Drives gives a good overview of the problems, the potential solutions, and their limitations. They conclude that

为清理整个磁盘，...软件技术最有效，但无效所有的时间.我们发现没有可用的软件清理单个文件的技术很有效.[加重]

For sanitizing entire disks, ... software techniques work most, but not all, of the time. We found that none of the available software techniques for sanitizing individual files were effective. [emphasis added]

NIST 800-88 也有很好的概述了导致该问题的技术趋势，以及针对Android设备的一些最低建议(附录A).但是，它们倾向于要么是整个磁盘擦除(恢复出厂设置)，要么是依赖于加密擦除(CE)，而不是通用的文件擦除方法.

NIST 800-88 also has a good overview of the technology trends contributing to the problem, along with some minimum recommendations (appendix A) for Android devices. However they tend to be either whole-disk erasure (factory reset), or rely on cryptographic erasure (CE), rather than being general file erasure methods.

但是一切并没有丢失.即使无法清理单个文件，也可以希望在删除文件后擦除所有未分配的空间.文章安全删除日志结构文件系统(Reardon等)等人)描述了一种在用户模式软件中实现此目标的相当有前途的方法.Android的内存使用(总是?)日志结构的文件系统.

But all is not lost. Even if you can't sanitize individual files, you could hope to wipe all the unallocated space after deleting files. The article Secure Deletion on Log-structured File Systems (Reardon, et al.) describes a fairly promising way to do that in user-mode software. Android's internal memory uses (always?) a log-structured file system.

本文的清除"方法不需要内核级访问，并且在Android上似乎不需要任何本机代码.(请注意，清除"一词在NIST 800-88之类的文档中使用时有所不同.)基本思想是删除所有敏感数据，然后用垃圾数据文件填充驱动器上的剩余空间，最后删除垃圾数据文件.

This paper's "purging" method does not require kernel-level access, and doesn't seem to require any native code on Android. (Note that the term "purging" is used a little differently in documents like NIST 800-88.) The basic idea is to delete all the sensitive data, then fill in the remaining space on the drive with a junk data file, and finally delete the junk data file.

虽然不仅要覆盖已删除的文件本身(数次，以不同的模式)还需要更多的时间和精力，但即使必须处理损耗平衡和日志结构FS的可能性，它也似乎非常强大.

While that takes more time and effort than just overwriting the deleted files themselves (several times in different patterns), it seems to be very robust even when you have to deal with the possibility of wear-leveling and log-structure FS.

对我来说，主要警告是有关Reardon等人提到的情况.在以上论文中:

The main caveat for me is about the conditions mentioned by Reardon et al. in the above paper:

清除功能适用于任何日志结构的文件系统，但前提是用户的磁盘配额没有限制，并且文件系统始终会执行垃圾收集甚至可以回收单个内存声明驱动器不可写.[强调我的]

Purging will work for any log-structured file system provided both the user’s disk quota is unlimited and the file system always performs garbage collection to reclaim even a single chunk of memory before declaring that the drive is unwritable. [emphasis mine]

似乎很可能满足第二个条件，但是我不知道第一个条件.Android(或某些制造商的版本)是否对应用程序使用的磁盘空间实施配额?我没有找到有关用户配额的任何信息，但是还有其他细分市场的配额，例如浏览器持久性存储.Android是否为系统使用或每个应用程序的缓存保留了一些空间，例如，这些空间不能用于其他用途?如果是这样，如果我们在删除敏感文件后立即开始清除，那将有帮助(尽管没有保证)，因此其他文件系统活动几乎没有时间对最近释放的空间提出主张.

The second condition seems pretty likely to be fulfilled, but I don't know about the first one. Does Android (or some manufacturers' versions of it) enforce quotas on disk space used by apps? I have not found any info about user quotas, but there are quotas for other niches like browser persistent storage. Does Android reserve some space for system use, or for each app's caching, for example, that can't be used for other things? If so, it should help (albeit with no guarantees) if we begin purging immediately after the sensitive files are deleted, so there is little time for other filesystem activity to stake a claim to the recently freed space.

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

Maybe we could mitigate these risks by cyclical purging:

• 确定相关分区(例如，分区)上的可用剩余空间(称为S).使用 File.getUsableSpace()
• 将一系列文件写入分区；例如，每个文件都是初始S的20％(受文件大小限制).
• 如果空间不足，请删除我们创建的前几个文件，然后在空间允许的情况下再写入一个或两个文件.
• 重复最后一步，直到达到满意的阈值.也许到您编写了价值2 * S的填充文件为止；调整该数字以平衡速度与完整性.您实际需要多少才能进行更多研究.
• 删除其余填充文件.

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

The idea with cyclical purging is that if we run out of quota to overwrite all free space, deleting the filler files just written will free up more quota; and then the way log-structured filesystems allocate new blocks should allow us to continue overwriting the remaining blocks of free space in sequence, rather than rewriting the same space again.

我正在测试应用程序中实现此方法，并将在其运行时将其发布.

I'm implementing this method in a test app, and will post it when it's working.

在外部存储或microSD卡上是否可以使用相同的方法?FAT是块结构的，那么清除方法是否适用于FAT格式的SD卡?

Would the same methods work on external storage or microSD cards? FAT is block-structured, so would the purge method apply to FAT-formatted SD cards?

在大多数当代闪存设备上，例如CompactFlash和安全数字卡的[损耗平衡]技术在内置微控制器的硬件.在此类设备上，磨损均衡是透明的，并且可以在它们上使用大多数常规文件系统照原样.( https://en.wikipedia.org/wiki/Wear_leveling )

...这向我暗示，即使在FAT格式的SD卡上，损耗平衡也意味着传统的

...which suggests to me that even on a FAT-formatted SD card, wear leveling means that the traditional Gutmann methods would not work (see his "Even Further Epilogue") and that a method like "purging" would be necessary.

清除是否足够，取决于您的安全性参数.损耗均衡似乎意味着随时可能淘汰"一个块，在这种情况下，没有绕过微控制器的损耗均衡就无法擦除它的方法.AFAIK，即使您具有内核特权，也无法在软件中完成；您必须设计特殊的硬件.

Whether purging is sufficient, depends on your security parameters. Wear leveling seems to imply that a block could potentially be "retired" at any time, in which case there is no way to erase it without bypassing the microcontroller's wear leveling. AFAIK this can't be done in software, even if you had kernel privileges; you'd have to design special hardware.

但是，相对于媒体的寿命，退役"坏块应该是相当罕见的事件，因此在许多情况下，清除方法将足够安全.

However, "retiring" a bad block should be a fairly rare event relative to the life of the media, so for many scenarios, a purging method would be secure enough.

请注意，古特曼的方法具有重要的优势，即删除可能的旧数据痕迹即使在新数据覆盖一个块之后仍可能保留的存储介质上.理论上，确定的攻击者可以使用很多资源来读取这些痕迹.一种真正彻底的安全删除方法将 augment 与Gutmann's一样，采用清除方法，而不是替换它.

Note that Gutmann's method has an important strength, namely, to erase possible traces of old data on the storage media that could remain even after a block is overwritten with new data. These traces could theoretically be read by a determined attacker with lots of resources. A truly thorough approach to secure deletion would augment a method like Gutmann's with purging, rather than replacing it.

但是，在日志结构和耗损级别的文件系统上，更大的问题是试图确保敏感块完全被覆盖.

However, on log-structured and wear-leveled filesystems, the much bigger problem is trying to ensure that the sensitive blocks get overwritten at all.

我在应用商店中没有关于应用的内部信息，但正在查看有关 一次擦除32GB的可用空间.

I don't have any inside information about apps in the app store, but looking at reviews for apps like iShredder would suggest that at best, they use methods like Reardon's "purging." For example, they can take several hours to do a single-pass wipe of 32GB of free space.

还请注意限制:对某些安全删除应用程序的评论说，在某些情况下，运行安全删除"操作后仍可以访问已删除"文件.当然，我们对这些评论会有所保留-用户可能会出错.但是，如果没有良好的测试，我不会认为这些应用程序是有效的.

Also note limitations: The reviews on some of the secure deletion apps say that in some cases, the "deleted" files were still accessible after running the "secure delete" operation. Of course we take these reviews with a grain of salt -- there is a possibility of user error. Nevertheless, I wouldn't assume these apps are effective, without good testing.

iShredder 4 Enterprise 有助于命名一些应用说明中使用的算法类型:

iShredder 4 Enterprise helpfully names some of the algorithms they use, in their app description:

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

Depending on the edition, the iShredder™ package comes with deletion algorithms such as DoD 5220.22-M E, US Air Force (AFSSI-5020), US Army AR380-19, DoD 5220.22-M ECE, BSI/VS-ITR TL-03423 Standard, BSI-VS-2011, NATO Standard, Gutmann, HMG InfoSec No.5, DoD 5220.22 SSD and others.

这个令人印象深刻的清单为我们提供了一些进一步研究的指示.目前尚不清楚如何单独或组合使用这些方法，尤其是其中的任何一种是否被认为有效.我们知道古特曼的方法不会.类似地，DoD 5220.22-M，AFSSI-5020，AR380-19和Infosec No.5指定了类似Gutmann的过程来覆盖硬盘驱动器上的扇区，这对于基于闪存的媒体无效.实际上，"美国mod不再引用DoD 5220.22-M作为安全擦除HDD的方法"，更不用说基于Flash的媒体了，因此此引用误导了不了解情况的人.(据说mod参考了 NIST 800-88 而是"DoD 5220.22 SSD"听起来很有希望，但我找不到任何有用的参考资料.我没有追踪列出的其他算法，但是到目前为止结果并不令人鼓舞.

This impressive-sounding list gives us some pointers for further research. It's not clear how these methods are used -- singly or in combination -- and in particular whether any of them are represented as being effective on their own. We know that Gutmann's method would not be. Similarly, DoD 5220.22-M, AFSSI-5020, AR380-19, and Infosec No. 5 specify Gutmann-like procedures for overwriting sectors on hard drives, which would not be effective for flash-based media. In fact, "The U.S. Department of Defense no longer references DoD 5220.22-M as a method for secure HDD erasure", let alone for flash-based media, so this reference is misleading to the uninformed. (The DoD is said to reference NIST 800-88 instead.) "DoD 5220.22 SSD" sounds promising, but I can't find any informative references for it. I haven't chased down the other algorithms listed, but the results so far are not encouraging.

这篇关于永久删除Android文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！