Навсегда удалить файлы Android

Я нашел приложение Android с именем Super Erase, которое навсегда удаляет файлы и папки с устройства Android, чтобы файл не удалялся, возможно, он будет восстановлен. .. Я имею в виду приложение, о котором я говорю … но мне было интересно, как это сделать, и я знаю это Сделан с android studio ..i пробовал обычный способ удаления file.delete() но все же файл может быть восстановлен. Может, у меня есть какая-нибудь помощь.

Solutions Collecting From Web of "Навсегда удалить файлы Android"

Во-первых, безопасное удаление файлов на флэш-носителях является сложной проблемой без быстрых и простых ответов. Статья « Надежное стирание данных с твердотельных накопителей на основе флэш-памяти» дает хороший обзор проблем, потенциальных решений и их ограничений. Они заключают, что

Для дезинфекции целых дисков … программные методы работают больше всего, но не все, времени. Мы обнаружили, что ни один из доступных программных методов для дезинфекции отдельных файлов не был эффективным. [Выделено курсивом]

NIST 800-88 также имеет хороший обзор технологических тенденций, способствующих проблеме, а также некоторые минимальные рекомендации (приложение A) для устройств Android. Однако они имеют тенденцию быть либо стиранием всего диска (сброс настроек), либо полагаться на криптографическое стирание (CE), а не на общие методы стирания файлов.

Но еще не все потеряно. Даже если вы не можете дезинфицировать отдельные файлы, вы можете надеяться стереть все нераспределенное пространство после удаления файлов. В статье Secure Deletion on Log-structured File Systems (Reardon и др.) Описывается довольно многообещающий способ сделать это в программном обеспечении пользовательского режима. Внутренняя память Android использует (всегда?) Файловую систему с журнальной структурой.

Метод «очистки» этой статьи не требует доступа на уровне ядра и, похоже, не требует какого-либо собственного кода на Android. (Обратите внимание, что термин «чистка» используется немного иначе в таких документах, как NIST 800-88.) Основная идея состоит в том, чтобы удалить все конфиденциальные данные, а затем заполнить оставшееся пространство на диске файлом данных мусора и, наконец, Удалите файл мусорных файлов.

Хотя это требует больше времени и усилий, чем просто перезаписывать удаленные файлы (несколько раз в разных шаблонах), это кажется очень надежным даже тогда, когда вам приходится иметь дело с возможностью выравнивания по высоте и логарифмической структуры FS.

Предостережение и дальнейшие меры

Главное предостережение для меня – об условиях, упомянутых Reardon et al. В приведенном выше документе:

Очистка будет работать для любой файловой системы с журнальной структурой, при условии, что дисковая квота пользователя не ограничена, и файловая система всегда выполняет сборку мусора, чтобы вернуть хотя бы один кусок памяти, прежде чем объявить, что диск является ненаписанным. [Внимание мое]

Второе условие кажется вполне вероятным, но я не знаю о первом. Поддерживает ли Android (или некоторые версии этого производителя) квоты на дисковое пространство, используемое приложениями? Я не нашел информации о пользовательских квотах, но есть квоты для других ниш, таких как постоянное хранилище браузера. Поддерживает ли Android некоторое пространство для использования системы или, например, для кеширования каждого приложения, которое нельзя использовать для других вещей? Если это так, он должен помочь (хотя и без каких-либо гарантий), если мы начнем чистку сразу после удаления конфиденциальных файлов, поэтому мало времени для другой активности файловой системы, чтобы претендовать на недавно освобожденное пространство.

Возможно, мы могли бы смягчить эти риски путем циклической очистки:

  • Определите оставшееся свободное пространство (назовите его S) в соответствующем разделе, например, используя File.getUsableSpace()
  • Напишите серию файлов в раздел; Каждый из них, скажем, составляет 20% от начального S (при условии ограничения размера файла).
  • Когда нам не хватает места, удалите первые пару файлов, которые мы создали, а затем напишем другой файл или два, как позволяет пространство.
  • Повторите этот последний шаг несколько раз, пока вы не достигли порога, которым вы удовлетворены. Возможно, до того момента, когда вы написали 2 * S файлов наполнителя; Настройте это число, чтобы сбалансировать скорость от тщательности. Насколько вам на самом деле нужно это делать, это была бы область для большего количества исследований.
  • Удалите оставшиеся файлы наполнителя.

Идея с циклической очисткой заключается в том, что если у нас закончится квота, чтобы перезаписать все свободное пространство, удаление только что написанных файлов наполнителей освободит больше квот; А затем способ, которым лог-структурированные файловые системы выделяют новые блоки, должен позволить нам продолжать переписывать оставшиеся блоки свободного пространства в последовательности, а не переписывать одно и то же пространство снова.

Я реализую этот метод в тестовом приложении и опубликую его, когда он работает.

Как насчет FAT-форматированных карт microSD?

Будут ли такие же методы работать на внешних накопителях или картах microSD? FAT является блочно-структурированным, и применим ли метод очистки к SD-картам формата FAT?

На большинстве современных устройств флэш-памяти, таких как CompactFlash и Secure Digital, методы [изнашивания] реализованы на аппаратных средствах с помощью встроенного микроконтроллера. На таких устройствах выравнивание износа является прозрачным, и большинство обычных файловых систем могут использоваться на них как есть. ( https://en.wikipedia.org/wiki/Wear_leveling )

… что мне кажется, что даже на SD-карте формата FAT износ выравнивания означает, что традиционные методы Гутмана не будут работать (см. Его « Еще дополнительный эпилог ») и что такой метод, как «очистка», будет необходим.

Достаточно ли очистки, зависит от ваших параметров безопасности. Понижение износа, по-видимому, означает, что блок может быть «удален» в любое время, и в этом случае нет возможности стереть его без обхода уровня износа микроконтроллера. AFAIK это не может быть сделано в программном обеспечении, даже если у вас есть привилегии ядра; Вам придется разрабатывать специальное оборудование.

Тем не менее, «выход на пенсию» плохого блока должен быть довольно редким событием относительно жизни СМИ, поэтому для многих сценариев метод очистки будет достаточно безопасным.

Стирание следов

Обратите внимание, что метод Gutmann имеет важную силу, а именно, стереть возможные следы старых данных на носителе данных, которые могут остаться даже после того, как блок будет перезаписан новыми данными. Эти следы теоретически могут быть прочитаны определенным злоумышленником с большим количеством ресурсов. Поистине тщательный подход к безопасному удалению увеличил бы такой метод, как Gutmann с очисткой, а не заменял его.

Однако при работе с файловыми системами с разбивкой на лог-структуру и с износом гораздо более серьезная проблема заключается в том, чтобы блокировать чувствительные блоки вообще.

Используют ли существующие приложения эти методы?

У меня нет внутренней информации о приложениях в магазине приложений, но просмотр отзывов для таких приложений, как iShredder , предполагает, что в лучшем случае они используют такие методы, как «очистка» Рирддона. Например, они могут занять несколько часов, чтобы выполнить однократное протирание 32 ГБ свободного места.

Также обратите внимание на ограничения. В обзорах некоторых приложений безопасного удаления говорится, что в некоторых случаях «удаленные» файлы по-прежнему доступны после запуска операции «безопасного удаления». Конечно, мы берем эти обзоры с большим количеством соли – есть вероятность ошибки пользователя. Тем не менее, я бы не предполагал, что эти приложения эффективны, без хорошего тестирования.

IShredder 4 Enterprise помогает использовать некоторые из алгоритмов, которые они используют, в описании своего приложения:

В зависимости от выпуска iShredder ™ поставляется с алгоритмами удаления, такими как DoD 5220.22-ME, ВВС США (AFSSI-5020), Армия США AR380-19, DoD 5220.22-M ECE, BSI / VS-ITR TL-03423 Стандарт , BSI-VS-2011, Стандарт НАТО, Gutmann, HMG InfoSec No.5, SSD DoD 5220.22 и другие.

Этот впечатляющий список дает нам несколько указаний на дальнейшие исследования. Неясно, как эти методы используются – по отдельности или в сочетании – и в частности, представляется ли кто-либо из них эффективным как самостоятельно. Мы знаем, что метода Гутмана не было бы. Аналогичным образом, DoD 5220.22-M, AFSSI-5020, AR380-19 и Infosec № 5 указывают процедуры, аналогичные Gutmann для перезаписи секторов на жестких дисках, что неэффективно для флэш-носителей. Фактически, « Министерство обороны США больше не ссылается на DoD 5220.22-M как метод безопасного стирания жестких дисков », не говоря уже о флэш-носителях, поэтому эта ссылка вводит в заблуждение для неосведомленных. (Говорят, что DoD ссылается на NIST 800-88 .) «DoD 5220.22 SSD» звучит многообещающе, но я не могу найти никаких информационных ссылок для него. Я не преследовал остальных перечисленных алгоритмов, но результаты пока не обнадеживают.

Когда вы удаляете файл со стандартными методами, такими как file.delete() или runtime.exec("rm -f my_file") единственное задание, которое делает ядро, – это удаление информации о файле из вспомогательных структур файловой системы. Но сектора хранения, содержащие фактические данные, остаются нетронутыми. И из-за этого восстановление возможно.

Это дает представление о том, как мы можем полностью удалить файл – мы должны каким-то образом стереть все сектора. Самый простой подход – переписать все содержимое файла со случайными данными несколько раз. После каждого прохода мы должны очищать буферы файлов, чтобы гарантировать, что новый контент будет записан на хранение. Все существующие методы безопасного удаления файлов вращаются вокруг принципа выше. Например, этот . Обратите внимание: универсальный метод не работает во всех типах хранения и файловых системах. Я думаю, вы должны поэкспериментировать самостоятельно и попытаться реализовать некоторые из существующих подходов или разработать свои собственные. Например, вы можете начать со следующего:

  1. Перезаписывайте и очищайте файл 10 раз со случайными данными (используйте методы FileOutputStream ). Заметка!!! Не используйте нули или другие данные с низкой энтропией. Некоторые файловые системы могут оптимизировать такие разреженные файлы и оставлять некоторые сектора с исходным контентом. Вы можете использовать /dev/urandom файл как источник случайных данных (это виртуальный файл, и он бесконечен). Это дает лучшие результаты и работает быстрее, чем хорошо известный Random класс.
  2. Переименуйте и переместите файл 10 раз. Выбирайте новые имена файлов случайным образом.
  3. Затем FileChannel.truncate() файл с помощью FileChannel.truncate() .
  4. И, наконец, удалите файл с File.delete() .

Конечно, вы можете написать всю логику в собственном коде, это может быть даже несколько проще, чем в Java. Описанный алгоритм является лишь примером. Попробуйте сделать так.

Стандартный API файловой системы не даст вам простой вызов функции для этого.

Вам придется использовать встроенный API-интерфейс для FileIO. Хотя я никогда не использовал его, theres библиотека для этого:

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

На этот вопрос есть два ответа.

Во-первых, чтобы ответить на прямой вопрос о том, как некоторые из этих приложений могут выполнять безопасное удаление одного файла: то, что вы делаете, фактически открывает файл и многократно заменяет содержимое нулями. Метод звучит глупо, но в прошлом я работал с шифрованием на уровне файловой системы на Android, и я обнаружил, что вышеуказанное верно для многих безопасных решений для удаления файлов. Для кажущейся совместимой безопасности вы можете повторять записи нулей 7 раз (или независимо от того, какие стандарты 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. Вы можете дать ложное ощущение безопасности нетехническим людям, которые все еще помнят старые дни HDD.