Достаточно ли перезаписать файл несколько раз, чтобы стереть его данные?

В Уничтожение файлов в .NET рекомендуется использовать Eraser или этот код здесь, в CodeProject, чтобы безопасно стереть файл в .NET.

Я пытался сделать свой собственный метод, так как код из CodeProject вызывал у меня некоторые проблемы. Вот что я придумал:

        public static void secureDelete(string file, bool deleteFile = true)
    {
        string nfName = "deleted" + rnd.Next(1000000000, 2147483647) + ".del";
        string fName = Path.GetFileName(file);
        System.IO.File.Move(file, file.Replace(fName, nfName));
        file = file.Replace(fName, nfName);
        int overWritten = 0;
        while (overWritten <= 7)
        {
            byte[] data = new byte[1 * 1024 * 1024];
            rnd.NextBytes(data);
            File.WriteAllBytes(file, data);
            overWritten += 1;
        }
        if (deleteFile) { File.Delete(file); }
    }

Кажется, это работает нормально. Он случайным образом переименовывает файл, а затем перезаписывает его 1 МБ случайных данных 7 раз. Однако мне было интересно, насколько это безопасно на самом деле, и если бы я мог сделать его безопаснее?


person Justin G    schedule 13.08.2016    source источник
comment
Достаточно написать все нули один раз. Но вы должны перезаписать старые сектора. Ваш код никогда не будет работать, версия CodeProj, по крайней мере, использует FileMode.Open, что крайне важно для стирания на жестком диске. Очистить SSD гораздо сложнее, вам придется перезаписать Диск .   -  person Henk Holterman    schedule 13.08.2016


Ответы (1)


Файловая система, особенно при доступе через высокоуровневый API, такой как в System.IO, представляет собой настолько много уровней абстракции над фактической реализацией хранилища, что этот подход не имеет большого смысла для современных дисков.

Для ясности: статья CodeProject, которая продвигает перезапись файла по имени несколько раз, является абсолютной чушью — по крайней мере, для SSD. Нет никакой гарантии, что запись в файл по какому-то пути несколько раз приведет к тому, что каждый раз запись будет выполняться в одно и то же физическое место на диске.

Конечно, открывая файл с доступом для чтения и записи и перезаписывая его с самого начала, концептуально запись выполняется в то же место. Но это место довольно абстрактно.

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

Из Кодирование для твердотельных накопителей — часть 3: страницы, блоки и уровень преобразования флэш-памяти | Кодовая капсула:

Страницы не могут быть перезаписаны

Страница NAND-flash может быть записана только в том случае, если она находится в «свободном» состоянии. Когда данные изменяются, содержимое страницы копируется во внутренний регистр, данные обновляются, и новая версия сохраняется на «свободной» странице, операция называется «чтение-изменение-запись». Данные не обновляются на месте, так как «бесплатная» страница отличается от страницы, изначально содержащей данные. Как только данные сохраняются на диске, исходная страница помечается как «устаревшая» и остается такой до тех пор, пока не будет стерта.

Это означает, что где-то на диске исходные данные все еще доступны для чтения, а именно в кластере M, в который была запрошена запись. То есть до тех пор, пока он не будет перезаписан. Кластер теперь помечен как свободный, но вам потребуется очень низкоуровневый доступ к диску, чтобы получить доступ к этому кластеру, чтобы перезаписать его, и я не уверен, что это возможно с твердотельными накопителями.

Даже если вы перезапишете весь SSD или жесткий диск несколько раз, есть вероятность, что некоторые из ваших очень личных данных скрыты в ныне несуществующем секторе или странице на диске или SSD, потому что в момент перезаписи или очистки диск определил это место должно быть дефектным. Команда криминалистов сможет прочитать эти данные (хотя и поврежденные). Итак, если у вас есть данные на жестком диске, которые могут быть использованы против вас: бросьте диск в огонь.

См. также Получить смещение файла на диске/номере кластера, чтобы узнать больше ( ссылки на) информацию об API файловой системы более низкого уровня.

Но все это следует воспринимать с долей скептицизма, поскольку все это слухи, и у меня нет реального опыта работы с таким уровнем доступа к диску.

person CodeCaster    schedule 13.08.2016
comment
Итак, какой метод вы предлагаете использовать для безопасного удаления файла? - person Justin G; 13.08.2016
comment
Я ни в коем случае не эксперт по файловой системе или безопасности, но общие средства таковы: найти физические места на диске, которые в настоящее время используются файлом (если это вообще возможно), перезаписать эти , затем удалите все упоминания файла из файловой системы. Обратите внимание, что File.Delete() также не делает последнего, он просто помечает записи файловой системы как удаленные. - person CodeCaster; 13.08.2016
comment
Но даже если бы они знали, где находится файл, неужели у них очень мало шансов восстановить его? Я читал из этой темы file/60193#60193" title="зачем перезаписывать файл более одного раза, чтобы безопасно удалить все следы файла"> stackoverflow.com/questions/59656/ что Попытка восстановить весь байт имеет точность только 0,97% времени. так есть ли вообще смысл пытаться перезаписать его? - person Justin G; 13.08.2016
comment
См. редактирование. Прежде всего, это информация об остаточной намагниченности жестких дисков. Твердотельные накопители добавляют еще один уровень абстракции: то, что вы запрашиваете, может быть, а может и не быть тем, что на самом деле делает накопитель. - person CodeCaster; 13.08.2016
comment
@JustinG единственный безопасный способ удалить файл - это отсутствие файла на диске. Рассмотрите возможность переключения на хранение файла в зашифрованном контейнере. Байты останутся на диске после удаления, но это усложнит восстановление данных, особенно если они имеют только неполное представление зашифрованного контейнера. - person Scott Chamberlain; 13.08.2016
comment
Я создаю шифровальщик файлов, поэтому, естественно, файл, который вы будете шифровать, еще не зашифрован. Я решил использовать это — microsoftwinanyhelper.codeplex.com — так как я считаю, что это относительно безопасно, пока Я использую сильный алгоритм. - person Justin G; 13.08.2016
comment
Это такая же устаревшая ерунда, как и другие библиотеки, и совершенно неэффективная для SSD. - person Henk Holterman; 14.08.2016
comment
@CodeCaster - образец CodeProject имеет разумную вероятность перезаписи секторов на жестком диске. Не полная ерунда, но и не реальное решение. - person Henk Holterman; 14.08.2016
comment
SSD — не единственная проблема. файловая система с копированием при записи сделает перезапись данные файла практически невозможны через доступ к файловой системе. - person Andrew Henle; 14.08.2016