Зачем перезаписывать файл более одного раза, чтобы безопасно удалить все следы файла?

Программы стирания, такие как Eraser, рекомендуют перезаписывать данные примерно 36 раз.

Насколько я понимаю, все данные хранятся на жестком диске как 1 или 0.

Если перезапись случайных единиц и нулей выполняется один раз по всему файлу, то почему этого недостаточно для удаления всех следов исходного файла?


person kjack    schedule 12.09.2008    source источник
comment
Действительно ли возможно любой ценой восстановить данные с точностью 90%-100% с магнитного диска, который был перезаписан много раз 20-30 и более? Да или нет? пожалуйста помоги.   -  person Govind Totla    schedule 03.01.2014


Ответы (13)


Бит жесткого диска, который раньше был равен 0, а затем изменился на «1», имеет немного более слабое магнитное поле, чем бит, который раньше был равен 1, а затем был снова записан в 1. С помощью чувствительного оборудования предыдущее содержимое каждого бита можно различить с разумной степенью точности, измеряя небольшие отклонения в силе. Результат будет не совсем правильным, и будут ошибки, но значительную часть предыдущего содержимого можно восстановить.

К тому времени, когда вы перечеркнете биты 35 раз, уже практически невозможно различить, что там было раньше.

Изменить: Современный анализ показывает, что один перезаписанный бит может быть восстановлен только с точностью 56%. Попытка восстановить весь байт верна только в 0,97% случаев. Так что я просто повторял городскую легенду. При работе с гибкими дисками или каким-либо другим носителем может потребоваться многократная перезапись, но жесткие диски в этом не нуждаются.

person DGentry    schedule 12.09.2008
comment
Спасибо, это объяснило то, что раньше казалось мне непонятным - person kjack; 12.09.2008
comment
На самом деле я не уверен, что это верная информация. Нет зарегистрированных случаев восстановления после перезаписи, в результате которых было получено более 1 % достоверных данных. - person Bruce the Hoon; 12.09.2008
comment
Правительства с большими деньгами обычно не публикуют свои результаты. - person Adam Davis; 12.09.2008
comment
Позвольте мне оставить лучший комментарий. Исследователи показали, что можно восстановить важную информацию с магнитного диска, который был перезаписан более одного раза. Это не означает, что это легко или что это происходит регулярно, но это возможно, поэтому стоит проявлять особую осторожность. - person Adam Davis; 13.09.2008

Дэниел Финберг (экономист частного Национального бюро экономических исследований) утверждает, что вероятность восстановления перезаписанных данных с современного жесткого диска равна «городской легенде»:

Могут ли спецслужбы читать перезаписанные данные?

Так что теоретически достаточно один раз перезаписать файл нулями.

person Ron    schedule 15.09.2008

Говоря обычным языком, когда на диск записывается единица, носитель записывает единицу, а когда записывается ноль, носитель записывает ноль. Однако фактический эффект ближе к получению 0,95, когда ноль заменяется единицей, и 1,05, когда единица заменяется единицей. Обычная схема диска настроена так, что оба эти значения считываются как единицы, но с помощью специальной схемы можно определить, что содержали предыдущие «слои». Восстановление по крайней мере одного или двух слоев перезаписанных данных не слишком сложно выполнить путем считывания сигнала с аналоговой головной электроники с помощью высококачественного цифрового стробоскопического осциллографа, загрузки дискретизированного сигнала на ПК и его анализа в программном обеспечении. для восстановления ранее записанного сигнала. Что делает программное обеспечение, так это генерирует «идеальный» сигнал чтения и вычитает его из того, что было фактически прочитано, оставляя в качестве разницы остаток предыдущего сигнала. Поскольку аналоговая схема в коммерческом жестком диске далеко не соответствует качеству схемы в осциллографе, используемом для выборки сигнала, существует возможность восстановить много дополнительной информации, которая не используется электроникой жесткого диска (хотя и с более новыми технологиями). технологии канального кодирования, такие как PRML (поясняется далее), которые требуют обширной обработки сигналов, использование простых инструментов, таких как осциллограф, для непосредственного восстановления данных больше невозможно)

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

person dotmad    schedule 12.09.2008

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

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

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

person Wedge    schedule 12.09.2008

Причина, по которой вам это нужно, заключается в не жестких дисках, а в SSD. Они переназначают кластеры, не сообщая ОС или драйверам файловой системы. Это делается для выравнивания износа. Таким образом, вероятность того, что записанный 0 бит находится в другом месте, чем предыдущая 1, довольно высока. Удаление контроллера SSD и чтение необработанных микросхем флэш-памяти вполне доступно даже для корпоративного шпионажа. Но с 36 полными перезаписями диска выравнивание износа, скорее всего, несколько раз пройдет через все запасные блоки.

person MSalters    schedule 11.03.2009
comment
Не могли бы вы немного расширить это? Я думал, что ластик просто перезаписал файл, а не весь диск. 36 перезаписей всего диска заняли бы гораздо больше времени, чем время, которое я видел с помощью ластика. - person kjack; 13.03.2009
comment
Хм, похоже, разработчик Eraser не понимает SSD. Если вы сотрете один файл на SSD 36 раз, вы, скорее всего, получите 36*sizeof(file) нулей и исходный файл в других блоках. - person MSalters; 23.03.2009

«Остаток данных» В Википедии есть довольно хороший набор ссылок о возможных атаках и их фактической осуществимости. Там же цитируются стандарты и рекомендации DoD и NIST. Суть в том, что восстановить перезаписанные данные с магнитных носителей становится все труднее, но это возможно. Тем не менее, некоторые (государственные) стандарты по-прежнему требуют как минимум многократной перезаписи. Между тем внутреннее устройство устройства продолжает становиться все более сложным, и даже после перезаписи накопитель или твердотельное устройство могут неожиданно иметь копии (подумайте об обработке поврежденных блоков или выравнивании износа флэш-памяти (см. Peter Gutmann). Так что по-настоящему беспокоящиеся по-прежнему уничтожают диски.

person Liudvikas Bukys    schedule 12.09.2008

То, на что мы здесь обращаем внимание, называется «остаточностью данных». На самом деле, большинство технологий, которые постоянно перезаписывают данные, (безвредно) делают больше, чем это действительно необходимо. Были попытки восстановить данные с дисков, на которых данные были перезаписаны, и, за исключением нескольких лабораторных случаев, действительно нет примеров успешного использования такого метода.

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

Наконец, 36 (на самом деле 35) перезаписей, о которых вы говорите, сегодня признаны устаревшими и ненужными, поскольку метод (известный как метод Гутмана) был разработан для использования различных - и обычно неизвестных пользователю - методов кодирования, используемых в технологиях. например, RLL и MFM, с которыми вы вряд ли столкнетесь. Даже в руководящих принципах правительства США говорится, что одной перезаписи достаточно для удаления данных, хотя в административных целях они не считают это приемлемым для «санации». Предполагаемая причина этого несоответствия заключается в том, что «плохие» сектора могут быть помечены аппаратным обеспечением диска как плохие и не перезаписаны должным образом, когда придет время выполнить перезапись, поэтому остается открытой возможность того, что визуальный осмотр диска сможет восстановить эти сектора. регионы.

В конце концов, записи с использованием 1010101010101010 или довольно случайного шаблона достаточно, чтобы стереть данные до такой степени, что известные методы не могут их восстановить.

person Bruce the Hoon    schedule 12.09.2008

Меня всегда удивляло, почему возможность того, что файл ранее хранился в другом физическом месте на диске, не рассматривается.

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

person Sam Hasler    schedule 12.09.2008
comment
Основная причина, по которой это не рассматривается, заключается в том, что эти инструменты (при правильном использовании) перезаписывают целые диски. Тем не менее, с твердотельными накопителями это реальная проблема, поскольку они переназначают блоки стирания, не сообщая об этом хосту, для выравнивания износа. - person MSalters; 11.03.2009

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

public static void DeleteGutmann(string fileName)
{
    var fi = new FileInfo(fileName);

    if (!fi.Exists)
    {
        return;
    }

    const int GutmannPasses = 35;
    var gutmanns = new byte[GutmannPasses][];

    for (var i = 0; i < gutmanns.Length; i++)
    {
        if ((i == 14) || (i == 19) || (i == 25) || (i == 26) || (i == 27))
        {
            continue;
        }

        gutmanns[i] = new byte[fi.Length];
    }

    using (var rnd = new RNGCryptoServiceProvider())
    {
        for (var i = 0L; i < 4; i++)
        {
            rnd.GetBytes(gutmanns[i]);
            rnd.GetBytes(gutmanns[31 + i]);
        }
    }

    for (var i = 0L; i < fi.Length;)
    {
        gutmanns[4][i] = 0x55;
        gutmanns[5][i] = 0xAA;
        gutmanns[6][i] = 0x92;
        gutmanns[7][i] = 0x49;
        gutmanns[8][i] = 0x24;
        gutmanns[10][i] = 0x11;
        gutmanns[11][i] = 0x22;
        gutmanns[12][i] = 0x33;
        gutmanns[13][i] = 0x44;
        gutmanns[15][i] = 0x66;
        gutmanns[16][i] = 0x77;
        gutmanns[17][i] = 0x88;
        gutmanns[18][i] = 0x99;
        gutmanns[20][i] = 0xBB;
        gutmanns[21][i] = 0xCC;
        gutmanns[22][i] = 0xDD;
        gutmanns[23][i] = 0xEE;
        gutmanns[24][i] = 0xFF;
        gutmanns[28][i] = 0x6D;
        gutmanns[29][i] = 0xB6;
        gutmanns[30][i++] = 0xDB;
        if (i >= fi.Length)
        {
            continue;
        }

        gutmanns[4][i] = 0x55;
        gutmanns[5][i] = 0xAA;
        gutmanns[6][i] = 0x49;
        gutmanns[7][i] = 0x24;
        gutmanns[8][i] = 0x92;
        gutmanns[10][i] = 0x11;
        gutmanns[11][i] = 0x22;
        gutmanns[12][i] = 0x33;
        gutmanns[13][i] = 0x44;
        gutmanns[15][i] = 0x66;
        gutmanns[16][i] = 0x77;
        gutmanns[17][i] = 0x88;
        gutmanns[18][i] = 0x99;
        gutmanns[20][i] = 0xBB;
        gutmanns[21][i] = 0xCC;
        gutmanns[22][i] = 0xDD;
        gutmanns[23][i] = 0xEE;
        gutmanns[24][i] = 0xFF;
        gutmanns[28][i] = 0xB6;
        gutmanns[29][i] = 0xDB;
        gutmanns[30][i++] = 0x6D;
        if (i >= fi.Length)
        {
            continue;
        }

        gutmanns[4][i] = 0x55;
        gutmanns[5][i] = 0xAA;
        gutmanns[6][i] = 0x24;
        gutmanns[7][i] = 0x92;
        gutmanns[8][i] = 0x49;
        gutmanns[10][i] = 0x11;
        gutmanns[11][i] = 0x22;
        gutmanns[12][i] = 0x33;
        gutmanns[13][i] = 0x44;
        gutmanns[15][i] = 0x66;
        gutmanns[16][i] = 0x77;
        gutmanns[17][i] = 0x88;
        gutmanns[18][i] = 0x99;
        gutmanns[20][i] = 0xBB;
        gutmanns[21][i] = 0xCC;
        gutmanns[22][i] = 0xDD;
        gutmanns[23][i] = 0xEE;
        gutmanns[24][i] = 0xFF;
        gutmanns[28][i] = 0xDB;
        gutmanns[29][i] = 0x6D;
        gutmanns[30][i++] = 0xB6;
    }

    gutmanns[14] = gutmanns[4];
    gutmanns[19] = gutmanns[5];
    gutmanns[25] = gutmanns[6];
    gutmanns[26] = gutmanns[7];
    gutmanns[27] = gutmanns[8];

    Stream s;

    try
    {
        s = new FileStream(
            fi.FullName,
            FileMode.Open,
            FileAccess.Write,
            FileShare.None,
            (int)fi.Length,
            FileOptions.DeleteOnClose | FileOptions.RandomAccess | FileOptions.WriteThrough);
    }
    catch (UnauthorizedAccessException)
    {
        return;
    }
    catch (IOException)
    {
        return;
    }

    using (s)
    {
        if (!s.CanSeek || !s.CanWrite)
        {
            return;
        }

        for (var i = 0L; i < gutmanns.Length; i++)
        {
            s.Seek(0, SeekOrigin.Begin);
            s.Write(gutmanns[i], 0, gutmanns[i].Length);
            s.Flush();
        }
    }
}
person Jesse C. Slicer    schedule 13.09.2008
comment
Ну, сэр, один вопрос. В приведенном выше примере ОС не выделит свободное пространство для новых данных, которые вы записываете в файл? Следовательно, это может оставить старые / дераспределенные кластеры открытыми для инструментов восстановления. Я могу ошибаться, но просто хотел убедиться в этом :-) - person Nadeem Ullah; 31.07.2013
comment
Нет, не должно, так как я заблокировал весь файл (и его содержимое) для записи во время процесса перезаписи. Ничто не освобождается, пока поток не будет закрыт и файл не будет удален. В этот момент теперь свободные кластеры доступны, но перезаписаны мусором Гутмана. - person Jesse C. Slicer; 31.07.2013
comment
Одна проблема с этой реализацией. Если размер файла большой, он использует много памяти (поскольку он хранит в памяти объем данных, в 36 раз превышающий размер файла). Как насчет того, чтобы изменить его, чтобы он не хранил случайные байты в памяти и продолжал сбрасывать их в файл, как только мы их генерируем? - person Nadeem Ullah; 03.09.2013
comment
Вы, безусловно, можете использовать любой вариант, который вам нравится :) Это классический компромисс компьютерной науки между скоростью и пространством. - person Jesse C. Slicer; 03.09.2013
comment
Я изменил код, чтобы за один раз в файл записывалось 16К мусора. Но когда файл большой (в моем случае 730M), я получаю исключение OutOfMemoryException в строке s.Write(). Не уверен, почему я получаю это, даже если я не держу в памяти большое количество байтов (всего 16 КБ за раз). Я ничего не менял в вашем коде, кроме того, как я генерирую случайные байты. - person Nadeem Ullah; 24.09.2013
comment
Что ж, разобрался :-) Это размер буфера, который вы передаете как равный длине файла. Поэтому, когда размер файла больше, он выдает ошибку нехватки памяти. Я уменьшил размер буфера (параметр в конструкторе FileStream), и это сработало :-) - person Nadeem Ullah; 24.09.2013

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

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

person Scott Dorman    schedule 12.09.2008
comment
Форматирование отличается от первого стирания. Форматирование просто перезаписывает таблицу размещения файлов (иногда только первую копию, а не избыточные копии). Вот почему большинство людей (и восстанавливают/не форматируют) могут восстанавливать файлы. - person Matthew Whited; 14.01.2010

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

person Bryan Rehbein    schedule 12.09.2008

См. это: статья Гуттмана

person Will M    schedule 13.09.2008

Просто инвертируйте биты так, чтобы 1 записывались во все 0, а 0 записывались во все 1, а затем обнуляйте все это, что должно избавиться от любой переменной в магнитном поле и занимает всего 2 прохода.

person Jim Mulder    schedule 04.10.2014