Comments 73
Класс! Я только не понял вот этого: «На SSD-дисках мы можем воспользоваться методом считывания остаточной намагниченности.»
На SSD действительно есть намагниченность? Всегда думал, что там FLASH память, которая просто хранит заряд.
На SSD действительно есть намагниченность? Всегда думал, что там FLASH память, которая просто хранит заряд.
Добавлю свои 5 копеек. У шефа перестал работать жесткий диск на старом MBP 17 дюймов. Причем гостевая учетка работает. Плюс индикатор здоровья диска тоже говорил, что все ок. Как не бились с помощью спец ПО, ничего вытущить не получалось. За 900 евро в Германии нашли контору, которая смогла все восстановить. Разговорились — рассказали что в нашем и 90 процентов случаях (HDD) вся работа заключается в замене механики. У нас поменяли головку считывающую и все решилось само. Про термовоздействие не догодался спросить. Зато был давно другой случай, когда жесткий диск по-байтово считали с помощью магнитного микросокпа (MFM). К счастью диск был всего на 40 гигов. Learn Backup the hard way!
Если MFM, то, наиболее вероятно, 40 мегабайт.
Что-то дорого вы заплатили, как мне кажется.
Это обычно самый простой способ — найти на ебее или в ином хламовнике аналогичный жесткий диск, купить за условные 50 баксов, и отдать в мастерскую чтобы в чистой камере перекинули блины. Стоит такая услуга условные пять тыс рублей.
Второй на моей памяти по распространенности случай — когда сдыхает контролер, лечится перепайкой с донора.
Это обычно самый простой способ — найти на ебее или в ином хламовнике аналогичный жесткий диск, купить за условные 50 баксов, и отдать в мастерскую чтобы в чистой камере перекинули блины. Стоит такая услуга условные пять тыс рублей.
Второй на моей памяти по распространенности случай — когда сдыхает контролер, лечится перепайкой с донора.
Цена там просто не играла роли. Если делать через фирму то в Германии это столько стоит для юр лиц. Естественно, если знать что и как, то можно и дешевле найти, но см. пункт 1…
За пять тысяч рублей «чистая комната» будет совмещенным санузлом.
На самом деле, к каждому диску нужен свой подход. К комплексу PC3000 шло довольно объемное руководство.
p.s. Помню как восстановил данные с диска на 120 мегабайт, просто перемещая вручную блок головок.
p.p.s. Если головки прокорябали диск, восстанавливать нечего. Интересно, что сейчас на тему SSD? Может NAND «вспомнить все» на программаторе, с повышенным напряжением или еще как? Помогает ли «прикладная комбинаторика» собрать из считаных NAND чипов образ диска?
На самом деле, к каждому диску нужен свой подход. К комплексу PC3000 шло довольно объемное руководство.
p.s. Помню как восстановил данные с диска на 120 мегабайт, просто перемещая вручную блок головок.
p.p.s. Если головки прокорябали диск, восстанавливать нечего. Интересно, что сейчас на тему SSD? Может NAND «вспомнить все» на программаторе, с повышенным напряжением или еще как? Помогает ли «прикладная комбинаторика» собрать из считаных NAND чипов образ диска?
А ведь могло так оказаться, новая механика или контроллер наоборот, окончательно «запилили» бы диск, и считать что-то уже было бы невозможно, и винить некого, кроме себя.
По мне, так лучше уж обратиться к компетентным специалистам.
По мне, так лучше уж обратиться к компетентным специалистам.
Можете посоветовать конкретную контору куда обратиться? Лежат два жестких диска с важными данными, в своей Тюмени не нашёл компетентного специалиста, думаю отправлять в Москву или даже ехать туда самому.
Это не реклама. Точно знаю 2 ситуации (2015, 2013) с успешным восстановлением вот в этой фирме storelab-rc.ru (Москва). Один раз — внешний диск — не определялся ни под какими операционками на разных компах, в том числе и при попытках запитаться от сдвоенных USB-хвостиков. Пластины раскручивались, щелчков не было. Второй раз — внутренний диск ноутбука — шумы были настораживающие. Но тут мне непонятны подробности лечения — знакомый пошел туда прямо с ноутом (нам некогда было встречаться, извлекать диск для перестановки в бокс и проверок), через пару дней все было ок, но он не может объяснить (не понимает сути вопроса) — то ли исправили логическую ошибку, то ли спасли инфу и заменили диск в ноуте. Настораживающих шумов больше не было.
В Самаре есть отличный специалист, к нему из других стран отправляют диски для восстановления. Полная комната дисков — доноров. Если нужно контакты — пишите в личку, пришлю номер телефона.
Существует несколько способов деформировать данные так, чтобы никакая лаборатория не получила их. Среди них:
- полное механическое уничтожение — разрушение диска до мельчайших частиц;
- воздействие мощного магнитного поля;
- кислота.
Ну и термит не стоит забывать :) Только в бОльших количествах, чем показано в видео
Такое использование термита даже корпус может не разрушить, о пластинах можно вообще не беспокоиться. На DefCon было исследование различных способов уничтожения данных.
В данном видео нету целенаправленного уничтожения диска, думаю если бы была такая цель, то диск стоял бы в отдельной коробке из армированного гипса, где заряд термита был бы прямо над блинами винчестера. Чел с DefCon-а предпологал использование диска в датацентрах, а там особо не развернешься, а вот если делать уничтожитель дома, то диск вполне можно превратить в груду расплавленного метала и стекла, помня про пожарную безопасность.
Если жесткий диск вышел из строя, но спасать информацию не требуется, что у меня случалось уже раз 4-5 за… дцать лет, просто из-за старения дисков, я, чтобы не думать об удалении информации, поступаю так:
— на деревянном пеньке — несколько ударов молотком, несильно, для некоторой деформации корпуса, появления трещин; из диска пока ничего не высыпается;
— деформированный диск укладываем в 2-3 пакета (полиэтилен, тоненькие, для завтраков) — это для того, чтобы потом мелкие осколки не разлетались;
— на том же пеньке — несколько очень сильных ударов топором — корпус разваливается, про плату и привод головок и говорить нечего, пластины — если «керамические» — то превращаются в мелкую «зеркальную» пыль, если «металлические — то гнутся, разваливаются на много частей, трескаются; пакеты тоже рвутся, но не дают разлетаться;
— крошево аккуратно делим на две части — в разные пакетики; один пакетик выбрасываю в мусор около дома; другой — через несколько дней в другую мусорку — у магазина и т.п.
Думаю что вероятность восстановления крайне мала. Или я маньяк?
— на деревянном пеньке — несколько ударов молотком, несильно, для некоторой деформации корпуса, появления трещин; из диска пока ничего не высыпается;
— деформированный диск укладываем в 2-3 пакета (полиэтилен, тоненькие, для завтраков) — это для того, чтобы потом мелкие осколки не разлетались;
— на том же пеньке — несколько очень сильных ударов топором — корпус разваливается, про плату и привод головок и говорить нечего, пластины — если «керамические» — то превращаются в мелкую «зеркальную» пыль, если «металлические — то гнутся, разваливаются на много частей, трескаются; пакеты тоже рвутся, но не дают разлетаться;
— крошево аккуратно делим на две части — в разные пакетики; один пакетик выбрасываю в мусор около дома; другой — через несколько дней в другую мусорку — у магазина и т.п.
Думаю что вероятность восстановления крайне мала. Или я маньяк?
Как обычно после прочтения подобных статей я стандартно вздрагиваю и регламентно напрягаюсь — а достаточно ли у меня распределенных физических копий файлов? в достаточном ли количестве логических форматов я их храню? с достаточной ли частотой я делаю копии? а давно ли я проверял бэкапы?
Еще интересно — в печатной статье (ссылку не нашел) про Ontrack была интересная история как им пришлось восстанавливать данные из кассет ленточной библиотеки — оборудование было расположено в подвальном помещении, залило водой. Так им пришлось разматывать ленту на длинном столе, через какие-то роликовые механизмы, как-то это читать.
Про ценник уровня 900 евро — вполне по божески за подобную работу, с учетом ценности информации. Как-то ко мне обратились с просьбой помочь дизайнеру, у которого сломался диск на котором хранились все дизайнерские проекты за много лет, собственность стоимость — десятки тысяч долларов, как и положено — никаких резервных копий. Ноутбучный диск жутко щелкал и скрежетал — гм, я провел «диагностику» по телефону — попросил поднести телефон к ноуту — и сразу соскочил с этой темы, рекомендовал выключить и бежать в пару специализированных московских фирм. Насколько я понял, там не решились взяться (ну или дизайнер не доверял соотечественникам) — отправил в Европу или Штаты, так с учетом ценности инфы с него только за страховку перевозки несколько сотен взяли. Концовки истории не знаю.
Еще не перестаю удивляться — на сайтах фирм по восстановлению информации — много благодарностей в том числе и от крупнейших контор, со своими ИТ-службами и прочим. Ну как же вот там не регламентировано тотальное резервное копирование?
Еще интересное умозаключение — прочитал где-то про утрату электронных копий архивных документов крупной европейской больницы. Смысл примерно такой — 50+ лет бумажные документы накапливались и успешно хранились, с появлением ксероксов сохранность первичных документов повысилась — в большинстве случаев требовались только отдельные страницы документов, поэтому первичные документы из защищенного помещения не выносились, там был копировальный аппарат. В конце 80-х перевели все на микропленку и приняли регламентное решение о постепенном уничтожении бумажных архивов. В начале века перегнали все в электронный вид, а с учетом устаревания оборудования для микропленок и постепенного увольнения кадров, умеющих этим оборудованием работать, компактный архив на микропленках забыли и конце-концов таки потеряли — скорее всего выкинули при ремонте. А потом, уже в этом десятилетии, при реорганизации серверов хранения, грохнули и первичную копию и резервную. В чем басня? Инфа отлично пережила десятилетние бумажный и микропленочный периоды (оба — с ограниченным кол-вом физических экземпляров!), а вот цифровой период — не смогла. Цитата типа: «для того, чтобы погубить архив на аналоговых носителях, нужно принять существенное (иногда — коллективное) решение, актуальное для физического мира (ну или ошибочно не принять нужное решение) — решить уничтожить архив, сжечь коробки, или забыть архив перед ремонтом, или не продумать противопожарные меры; а для того, чтобы утратить цифровой архив, достаточно пары неловких движений мышью, сделанных одним человеком».
Еще интересно — в печатной статье (ссылку не нашел) про Ontrack была интересная история как им пришлось восстанавливать данные из кассет ленточной библиотеки — оборудование было расположено в подвальном помещении, залило водой. Так им пришлось разматывать ленту на длинном столе, через какие-то роликовые механизмы, как-то это читать.
Про ценник уровня 900 евро — вполне по божески за подобную работу, с учетом ценности информации. Как-то ко мне обратились с просьбой помочь дизайнеру, у которого сломался диск на котором хранились все дизайнерские проекты за много лет, собственность стоимость — десятки тысяч долларов, как и положено — никаких резервных копий. Ноутбучный диск жутко щелкал и скрежетал — гм, я провел «диагностику» по телефону — попросил поднести телефон к ноуту — и сразу соскочил с этой темы, рекомендовал выключить и бежать в пару специализированных московских фирм. Насколько я понял, там не решились взяться (ну или дизайнер не доверял соотечественникам) — отправил в Европу или Штаты, так с учетом ценности инфы с него только за страховку перевозки несколько сотен взяли. Концовки истории не знаю.
Еще не перестаю удивляться — на сайтах фирм по восстановлению информации — много благодарностей в том числе и от крупнейших контор, со своими ИТ-службами и прочим. Ну как же вот там не регламентировано тотальное резервное копирование?
Еще интересное умозаключение — прочитал где-то про утрату электронных копий архивных документов крупной европейской больницы. Смысл примерно такой — 50+ лет бумажные документы накапливались и успешно хранились, с появлением ксероксов сохранность первичных документов повысилась — в большинстве случаев требовались только отдельные страницы документов, поэтому первичные документы из защищенного помещения не выносились, там был копировальный аппарат. В конце 80-х перевели все на микропленку и приняли регламентное решение о постепенном уничтожении бумажных архивов. В начале века перегнали все в электронный вид, а с учетом устаревания оборудования для микропленок и постепенного увольнения кадров, умеющих этим оборудованием работать, компактный архив на микропленках забыли и конце-концов таки потеряли — скорее всего выкинули при ремонте. А потом, уже в этом десятилетии, при реорганизации серверов хранения, грохнули и первичную копию и резервную. В чем басня? Инфа отлично пережила десятилетние бумажный и микропленочный периоды (оба — с ограниченным кол-вом физических экземпляров!), а вот цифровой период — не смогла. Цитата типа: «для того, чтобы погубить архив на аналоговых носителях, нужно принять существенное (иногда — коллективное) решение, актуальное для физического мира (ну или ошибочно не принять нужное решение) — решить уничтожить архив, сжечь коробки, или забыть архив перед ремонтом, или не продумать противопожарные меры; а для того, чтобы утратить цифровой архив, достаточно пары неловких движений мышью, сделанных одним человеком».
Знакомо: два мёртвых диска лежат (по знакомым оборудования не нашёл). А когда-то думал «Как можно быть таким криворуким, чтобы случайно поломать железку?» Human reliability will save humanity :3
Архив на бумаге потерять довольно просто — пожар+потоп, трудно и дорого бакапить, а главное — поиск отвратительный (а если дорого или некому искать — считайте что его и нет). Цифровой архив бакапится очень легко и дешево.
Да это я так, философствую… Однако не могу не поделиться продолжением философских наблюдений — архив фотографий начиная от прабабушек-прадедушек — с начала прошлого века — вот он, в прочном чемодане, сохранился (100+ лет!!!), полностью актуален/пригоден для аналогового восприятия (глазами), ограниченное кол-во людей способны осуществить очень быстрый поиск в нем (5-7 человек в основном старшего возраста, и, видимо, по объективным причинам, кол-во таких людей будет уменьшаться). Само собой, для защиты от пожаров-потопов — отсканирован и кратно зарезервирован — то есть имеется отображение одной и той же информации и в аналоговом и в цифровом мире. Причем в цифровом мире поиск могу осуществить только я.
А теперь про информацию, которая сразу порождалась в цифровом мире. Ну и что, что я с 1989 года не потерял ни байта? (Документы, чуток графики). С дискет все перенесено на оптику, а кое-что и на внешние харды. Само собой, еще достаточно длительное время не будет проблем с:
— доступам к файлам архивов на оптических носителях (приводы пока доступны, парочку внешних можно сохранить еще на десятилетия) и на внешних хардах (USB — надолго);
— извлечением файлов из архивов arj и zip;
— просмотром файлов в ряде форматов (bmp — жив, ну и т.п.)
НО!
— но вот что делать с файлами в форматах уже почивших инструментов — текстовые редакторы Слово и Дело" (Word&Deed) и ChiWriter — тут же придется поднапрячься и с установкой и т.п.; да и с Лексиконом… и с простыми текстами, где пораскиданы управляющие символы для печати...;
А теперь про информацию, которая сразу порождалась в цифровом мире. Ну и что, что я с 1989 года не потерял ни байта? (Документы, чуток графики). С дискет все перенесено на оптику, а кое-что и на внешние харды. Само собой, еще достаточно длительное время не будет проблем с:
— доступам к файлам архивов на оптических носителях (приводы пока доступны, парочку внешних можно сохранить еще на десятилетия) и на внешних хардах (USB — надолго);
— извлечением файлов из архивов arj и zip;
— просмотром файлов в ряде форматов (bmp — жив, ну и т.п.)
НО!
— но вот что делать с файлами в форматах уже почивших инструментов — текстовые редакторы Слово и Дело" (Word&Deed) и ChiWriter — тут же придется поднапрячься и с установкой и т.п.; да и с Лексиконом… и с простыми текстами, где пораскиданы управляющие символы для печати...;
на сайтах фирм по восстановлению информации — много благодарностей в том числе и от крупнейших контор, со своими ИТ-службами и прочим. Ну как же вот там не регламентировано тотальное резервное копирование?
Разгильдяйство. Приходит ко мне как-то девушка (дело было 10 лет назад, сейчас я бы такого даже в теории не допустил) с ноутбуком и просит восстановить месяц работы до совещания через 15 минут. На вопрос почему, при наличии сетевой папки, она хранила всё на локальном диске я ответа не получил. Пошёл и задал этот вопрос её непосредственному начальнику.
Тут просто когнитивные искажения сказываются.
Архивы бумажные большие и ценность очевидна. А цифровые архивы «виртуальные» и стороннему человеку ценность не очевидна, особенно в век когда такой информации много, очень много.
Архивы бумажные большие и ценность очевидна. А цифровые архивы «виртуальные» и стороннему человеку ценность не очевидна, особенно в век когда такой информации много, очень много.
Интересно, а сколько раз надо перезаписать HDD рандомными данными, чтобы метод остаточной намагниченности не дал результата? Интуитивно кажется, что немного (2-3 цикла), т.к. иначе эту технологию использовали бы для увеличения плотности записи. Кто-нибудь встречал толковые исследования?
Это городская легенда и достаточно перезаписать диск нулями или сменить ключ шифрования.
Возможно было актуально для старых дисков, когда плотность информации была низкой дорожка с новыми данными могла быть геометрически смещена от дорожки со старыми данными. Или проявиться остаточная намагниченность сквозь новую запись, если писать нули или единицы.
Сейчас плотность информации высока и считывание и так идет на пределе возможностей физических. Если еще и рандомными данными записать… вероятно такие данные и теоретически не восстановить, остаточные данные будут не отличимы от естественного шума.
Сейчас плотность информации высока и считывание и так идет на пределе возможностей физических. Если еще и рандомными данными записать… вероятно такие данные и теоретически не восстановить, остаточные данные будут не отличимы от естественного шума.
Ок, но всё же с головки мы получаем аналоговый сигнал, который оцифровывается в соответствии с порогами лог. единицы и нуля. Интересно было бы провести следующий эксперимент:
1. записать много раз (1000 раз) в один домен значение 0
2. однократно записать единицу в тот же домен
3. считать аналоговое значение из этого домена
4. записать ещё раз единицу
5. снова считать и сравнить значения
Но для этого потребуется сделать свой контроллер жесткого диска и много свободного времени)
1. записать много раз (1000 раз) в один домен значение 0
2. однократно записать единицу в тот же домен
3. считать аналоговое значение из этого домена
4. записать ещё раз единицу
5. снова считать и сравнить значения
Но для этого потребуется сделать свой контроллер жесткого диска и много свободного времени)
Да эта информация должна быть в открытом доступе. Ключевая информация: уровень сигнала и уровень шума. На данный момент плотность информации так высока, что уровень сигнала и так снижен до уровня сравнимого с уровнем шума, есть битовые ошибки чтения «сырой» информации и они на лету корректируются алгоритмами восстановления данных по заранее записанным избыточным данным. Причем количество ошибок чтения можно на лету брать с контроллера утилитами от производителя, например чтобы следить за состоянием диска. Есть ролик на Ютубе, где даже речь громкая в серверной приводит к росту ошибок чтения, всплески на графиках.
Влияние ранее записанной информации будет скорее статистическим, чем измеримым, тем более это не даст возможности восстановления, так как алгоритмы восстановления уже не сработают, из-за превышения числа ошибок чтения за все разумные пределы. Да и информация пишется не в сыром виде, а после кодирования, как минимум убираются длинные последовательности нулей и единиц. Так что записывая файл из нулей, на диске что будет физически определяется алгоритмом контроллера.
Ваш эксперимент можно упростить, использовать дисковод с дискетами, там простые понятные сигналы во всех цепях. Можно осциллографом считать данные сразу с головки.
Влияние ранее записанной информации будет скорее статистическим, чем измеримым, тем более это не даст возможности восстановления, так как алгоритмы восстановления уже не сработают, из-за превышения числа ошибок чтения за все разумные пределы. Да и информация пишется не в сыром виде, а после кодирования, как минимум убираются длинные последовательности нулей и единиц. Так что записывая файл из нулей, на диске что будет физически определяется алгоритмом контроллера.
Ваш эксперимент можно упростить, использовать дисковод с дискетами, там простые понятные сигналы во всех цепях. Можно осциллографом считать данные сразу с головки.
В статье много упоминаний про то, что для ремонта нужно просто купить такой же диск и переставить плату электроники/БМГ или что-то ещё. Но это ведь не совсем так. Раньше, действительно, в служебных зонах диска записывалась индивидуальная калибровочная информация и поменяв контроллер с диском можно было спокойно работать. Но ведь сейчас её частично разнесли — что-то осталось на диске, а что-то записывают в память на плате. И просто поменяв плату электроники единого массива адаптивных данных уже не будет — ничего путнего уже не получится.
А вот есть реальный интерес: в смартфоне перестала определяться SD-карта. Вне смартфона она тоже не определяется.
Есть "хард", "софт" или фирмы, которые реанимируют подобное? Или хотя бы извлечь данные, без восстановления функционала.
В будущем могут добавиться восстановление звука по видео без звука, чтение по губам и примерный голос говорящего по форме головы/лица/шеи…
Вспоминается история про восстановление Доктора Кто.
Ну и у меня есть одна, про то, как я спалил электронику харда без бекапов. Потом долго искал аналог, нашёл, и запустил хард каким-то магическим "елозеньем" платы по контактам гермозоны. Хард грелся, но читался. До сих пор не понимаю, что это за магия. На кулере выкопировал все данные. До сих пор модель помню — ST3250820AS. Вроде бы, там должен был быть ром на плате, хз)
Интересно а многократная перезапись помогает?
Т.е. за 20 лет с диска, на котором хранились результаты эксперимента, никто никогда резервной копии не делал? Ну так очень жаль, что он не сгорел в атмосфере.
Или аффтырь брешет?
Или аффтырь брешет?
Это и был бакап, оригинал остался на орбите… Таки поработать над восстановлением было дешевле, чем запустить еще один шаттл.
Мне вот куда больше интересно, как удалось найти и собрать все такие обломки, в том числе из водоема. Помню еще коробочку червей нашли, которые пережили тот полет.
Мне вот куда больше интересно, как удалось найти и собрать все такие обломки, в том числе из водоема. Помню еще коробочку червей нашли, которые пережили тот полет.
Перезапись данных в один проход уничтожает старые данные на HDD надежнее, чем гравитация или молоток с отверткой.
Это довольно долго. Ходила байка про сервер с мишенью на боковой стенке, которую должен был расстрелять из АКМ охранник, в случае угрозы захвата банка налоговой. Лично видел и электромагнитный «дисккиллер», но как в реале, что после него можно найти микроскопом, думаю никто не заморачивался.
UFO just landed and posted this here
Возможно тогда была проблема в производительности зашифрованных дисков. Плюс ключ может утечь, а при физическом уничтожении вопроса предоставления ключа даже не возникнет.
Все так, ключ надо хранить/бакапить/защищать от кражи и копирования. Скорость работы с шифрованным томом скорее всего сильно падала, годы были примерно 99-2000. Ну и сложно получить гарантию отсутствия бекдора в ПО и новых открытий в математике на тему стойкости алгоритма даже при честной реализации его. А может владельцу банка, рожок из АКМ виделся куда убедительнее листа формул.
UFO just landed and posted this here
При чем быстрее. Особенно если алгоритм проработать заранее.
Вот тут интересный случай, быстро уничтожить данные программно, при ограниченном времени, причем неизвестно какое ограничение, 1 секунда или несколько минут.
Сначала уничтожать MFT, заголовки файлов, потом содержимое файлов пользователя от маленьких к крупным. Суть такова что в первую секунду будет уничтожено 50% информации, через секунду 90%, через минуту 99%, остальное минут за 15, причем каждый момент времени будет экспоненциально увеличивать сложность восстановления. Так как просто данные без заголовков и перемежанные блоками случайных данных анализировать достаточно сложно.
Пример мультимедийные данные, убрать заголовок и данные внутри контейнера тщательно сжатая информация что достаточно сложно декодируется. Со стороны наблюдателя просто случайные данные, не за что зацепиться. Вторым этапом можно удалить ключевые кадры в H.264 и подобные внутренние признаки специфических файлов.
Далее если SSD записать случайные данные по секторам, например сначала каждый сотый сектор, потом 2 из 100 и так по мере наличия времени все сектора. С SSD всё проще, достаточно заранее держать карту ключевых секторов для перезаписи.
Если HDD, то записывать блоки данных сравнимых по размеру с размером дорожки цилиндрической, чтобы не терять время 10-15 мС на позиционирование головок, на глазок от 2 до 30 мегабайт блоки. И тут лучше, если данные пользователя будут дефрагментированы и заранее сгруппированы по важности именно физически. А лучше на отдельных логических дисках. Так как позиционировать головки на 1 млн. небольших файлов, каждый из которых еще и фрагментирован на десяток частей по всему диску это очень долго.
То же самое с архивами в режиме solid, без заголовка просто рандомные данные (иначе теряется смысл работы архиватора). Jpeg картинками, возможно mp3 файлами (но тут может всплыть стандартный последовательный паттерн, формат все же простой).
Но если заранее планировать такой сложный сценарий, проще и надежнее поставить шифрование диска.
Или ограничится все же более простым алгоритмом, уничтожение MFT, заголовков и далее запись блоками по 50 мб в случайные области до полного заполнения диска случайными данными. Даже если что-то прервет такой процесс, восстановить можно будет не значительную часть информации.
И еще затруднить считывание можно заполняя диск не случайными данными, а имитирующие ложные данные, бесконечные вариации фотографий домашних питомцев, архивы статей случайных из интернета, данные имитирующие поврежденные данные (архив с ошибкой CRC или картинки с артефактами), чужеродная MFT. Даже если времени не хватит перезаписать все данные, информационный мусор в десятки раз затруднит анализ содержимого. Например остался один ценный документ, размером в мегабайт. Но на фоне 2 000 000 мегабайт информационного мусора найти эти сектора будет очень сложно. Причем информационный мусор так же можно записывать заранее, в пространство не занятое файлами. Обратный процесс утилите Sdelete в ОС Windows (в Linux утилита ZeroFree), что заполняет пустое пространство нулями, это уничтожает удаленные файлы, но облегчает последующий анализ диска, файлы что не успеет удалить пользователь среди нулей будут видны как на ладони.
Вот тут интересный случай, быстро уничтожить данные программно, при ограниченном времени, причем неизвестно какое ограничение, 1 секунда или несколько минут.
Сначала уничтожать MFT, заголовки файлов, потом содержимое файлов пользователя от маленьких к крупным. Суть такова что в первую секунду будет уничтожено 50% информации, через секунду 90%, через минуту 99%, остальное минут за 15, причем каждый момент времени будет экспоненциально увеличивать сложность восстановления. Так как просто данные без заголовков и перемежанные блоками случайных данных анализировать достаточно сложно.
Пример мультимедийные данные, убрать заголовок и данные внутри контейнера тщательно сжатая информация что достаточно сложно декодируется. Со стороны наблюдателя просто случайные данные, не за что зацепиться. Вторым этапом можно удалить ключевые кадры в H.264 и подобные внутренние признаки специфических файлов.
Далее если SSD записать случайные данные по секторам, например сначала каждый сотый сектор, потом 2 из 100 и так по мере наличия времени все сектора. С SSD всё проще, достаточно заранее держать карту ключевых секторов для перезаписи.
Если HDD, то записывать блоки данных сравнимых по размеру с размером дорожки цилиндрической, чтобы не терять время 10-15 мС на позиционирование головок, на глазок от 2 до 30 мегабайт блоки. И тут лучше, если данные пользователя будут дефрагментированы и заранее сгруппированы по важности именно физически. А лучше на отдельных логических дисках. Так как позиционировать головки на 1 млн. небольших файлов, каждый из которых еще и фрагментирован на десяток частей по всему диску это очень долго.
То же самое с архивами в режиме solid, без заголовка просто рандомные данные (иначе теряется смысл работы архиватора). Jpeg картинками, возможно mp3 файлами (но тут может всплыть стандартный последовательный паттерн, формат все же простой).
Но если заранее планировать такой сложный сценарий, проще и надежнее поставить шифрование диска.
Или ограничится все же более простым алгоритмом, уничтожение MFT, заголовков и далее запись блоками по 50 мб в случайные области до полного заполнения диска случайными данными. Даже если что-то прервет такой процесс, восстановить можно будет не значительную часть информации.
И еще затруднить считывание можно заполняя диск не случайными данными, а имитирующие ложные данные, бесконечные вариации фотографий домашних питомцев, архивы статей случайных из интернета, данные имитирующие поврежденные данные (архив с ошибкой CRC или картинки с артефактами), чужеродная MFT. Даже если времени не хватит перезаписать все данные, информационный мусор в десятки раз затруднит анализ содержимого. Например остался один ценный документ, размером в мегабайт. Но на фоне 2 000 000 мегабайт информационного мусора найти эти сектора будет очень сложно. Причем информационный мусор так же можно записывать заранее, в пространство не занятое файлами. Обратный процесс утилите Sdelete в ОС Windows (в Linux утилита ZeroFree), что заполняет пустое пространство нулями, это уничтожает удаленные файлы, но облегчает последующий анализ диска, файлы что не успеет удалить пользователь среди нулей будут видны как на ладони.
разве для SSD применимо понятие перезаписи сектора? Попытка записать 4096 байт на n*размер блока от начала диска будет расценена контроллером, как «записать в ту часть nand, которая сейчас отвечает за n*m». Даже попытка пристрелить этот кусок через TRIM обречена на фейл.
для обычных HDD — аналогично, если работа идет через ATA, а не вендорские команды — reallocated/бедблоки.
для обычных HDD — аналогично, если работа идет через ATA, а не вендорские команды — reallocated/бедблоки.
Все равно это лучше, чем писать в случайные области или линейно при ограниченном времени на уничтожении. Например, все равно будет удалена MFT, а остатки будут сложно восстановимы, так как нет никакой информации о том, какая часть nand отвечала за ранее использованную область под данные.
Если бы была информация о всех предыдущих состояниях системы переназначения, можно было бы собрать предыдущую версию MFT или любого файла из фрагментов по диску при низкоуровневом чтении. Но этого нет.
При наличии времени, все куски будут все равно «пристрелены», но чуть позже. На перезапись 500-1000 Гб нужно некоторое время.
Думаю вы согласитесь, что при ограниченном времени на уничтожение данных можно выбирать первоочередные цели для перезаписи?
Если бы была информация о всех предыдущих состояниях системы переназначения, можно было бы собрать предыдущую версию MFT или любого файла из фрагментов по диску при низкоуровневом чтении. Но этого нет.
При наличии времени, все куски будут все равно «пристрелены», но чуть позже. На перезапись 500-1000 Гб нужно некоторое время.
Думаю вы согласитесь, что при ограниченном времени на уничтожение данных можно выбирать первоочередные цели для перезаписи?
Да, спасибо — что-то в этих сценариях есть… Особенно насчет идеи с быстрым удалением.
Может придумаю как это реализовать — но, правда это алармистский сценарий.
Пока когда я провожу предпродажную подготовку техники то после форматирования несистемного логического или физического диска я записываю некоторое (насколько времени и терпения хватит) количество мусора — папками типа НашиКоты_20NN, общедоступными скачанными документами и т.п. — это к фразе «А лучше на отдельных логических дисках.» — это вообще очень удобно, особенно в ситуациях системный SSD + рабочий HDD.
С системными дисками сложнее — само собой элементарное — из-под нового admin1 удаляю прежнего admin c удалением файлов этого пользователя (ну так и с учетками других пользователей если были), потом немного ручной чистки, потом дефрагментация, деинсталляция,… но все равно много чего может пооставаться. Тут вот какая проблема — чтобы продать (минимизировать сопротивление покупателя) нужно чтобы комп был с более-менее свежей виндой. А возврат к заводским установкам, например, ноута — это откат к 8.1 или 7. Покупателю может не понравится, да и чисто по инженерному жалко усилий и времени покупателя на актуализацию софта. Просьба поделиться какие тут могут быть варианты?
Может придумаю как это реализовать — но, правда это алармистский сценарий.
Пока когда я провожу предпродажную подготовку техники то после форматирования несистемного логического или физического диска я записываю некоторое (насколько времени и терпения хватит) количество мусора — папками типа НашиКоты_20NN, общедоступными скачанными документами и т.п. — это к фразе «А лучше на отдельных логических дисках.» — это вообще очень удобно, особенно в ситуациях системный SSD + рабочий HDD.
С системными дисками сложнее — само собой элементарное — из-под нового admin1 удаляю прежнего admin c удалением файлов этого пользователя (ну так и с учетками других пользователей если были), потом немного ручной чистки, потом дефрагментация, деинсталляция,… но все равно много чего может пооставаться. Тут вот какая проблема — чтобы продать (минимизировать сопротивление покупателя) нужно чтобы комп был с более-менее свежей виндой. А возврат к заводским установкам, например, ноута — это откат к 8.1 или 7. Покупателю может не понравится, да и чисто по инженерному жалко усилий и времени покупателя на актуализацию софта. Просьба поделиться какие тут могут быть варианты?
Если есть время, то используйте типичные программы
руками делать ничего не нужно, будет абсолютно чистый диск.
Другое дело что диск 2 терабайта может 8 часов перезаписываться, тут бы хотелось возможность ускорить процесс. Как минимум исключить из перезаписи области без данных, осложнять работу программ по восстановлению и т.п. Такой утилиты я не видел. По очистке рабочей винды, тоже непонятно, похоже у вас и так оптимальный вариант, но можно опять же не перезаписывать файлы сторонние, а Sdelete запустить, утилита чистит аккуратно пространство между файлами.
утилите Sdelete в ОС Windows (в Linux утилита ZeroFree)
руками делать ничего не нужно, будет абсолютно чистый диск.
Другое дело что диск 2 терабайта может 8 часов перезаписываться, тут бы хотелось возможность ускорить процесс. Как минимум исключить из перезаписи области без данных, осложнять работу программ по восстановлению и т.п. Такой утилиты я не видел. По очистке рабочей винды, тоже непонятно, похоже у вас и так оптимальный вариант, но можно опять же не перезаписывать файлы сторонние, а Sdelete запустить, утилита чистит аккуратно пространство между файлами.
Алгоритм кажется мне излишне сложным, с учетом возможности просто зашифровать диск или раздел. Но в качестве мысленного упражнения попробую найти в нем несколько недостатков:
Чтобы перетереть заголовки и тела файлов, вам нужно знать где эти файлы начинаются, а для этого вам нужна таблица MFT, которую вы удалили на предыдущем шаге. Не забудьте закэшировать размещение файлов =)
Поточные видео и аудио будут очень устойчивы к стиранию заголовка и мелким пакостям внутри, потому что они поточные и формат файла предполагает воспроизведение с любого места и возможные потери. Это, например, относится к mp3 и mpeg. Попробуйте испортить файлы и воспроизвести их потом.
Если ваши jpeg'и с одной фотокамеры, то очень вероятно что будут использовать одни и те же настройки сжатия (таблицы квантования и т.д.). Т.е. можно «пересадить» заголовок (область от начала до маркера SOS) от любого другого живого файла. Более того, в начале фото-jpeg'а обычно лежит бесполезный для распаковки exif, который занимает несколько килобайт, т.е. есть высокий шанс найти «свои» ключевые структуры.
Т.е. надо из всех jpeg'ов поудалять exif и пережать их с включенной оптимизацией таблиц Хаффмана, в этом случае перезапись первого килобайта будет очень эффективна.
Мусорить тоже надо уметь. Картинки можно отсортировать по дате и модели камеры (если вы не убрали exif). По документам можно выполнить текстовый поиск по ключевым фразам. Целостность многих файлов можно проверить и отбросить битые.
Это я все к чему. Если параноить по-настоящему, то шифрование выглядит надежней. Но только помните про обратную сторону этой «надежности», если что-то сломается, то шансы потерять данные насовсем значительно возрастают.
Чтобы перетереть заголовки и тела файлов, вам нужно знать где эти файлы начинаются, а для этого вам нужна таблица MFT, которую вы удалили на предыдущем шаге. Не забудьте закэшировать размещение файлов =)
Поточные видео и аудио будут очень устойчивы к стиранию заголовка и мелким пакостям внутри, потому что они поточные и формат файла предполагает воспроизведение с любого места и возможные потери. Это, например, относится к mp3 и mpeg. Попробуйте испортить файлы и воспроизвести их потом.
Если ваши jpeg'и с одной фотокамеры, то очень вероятно что будут использовать одни и те же настройки сжатия (таблицы квантования и т.д.). Т.е. можно «пересадить» заголовок (область от начала до маркера SOS) от любого другого живого файла. Более того, в начале фото-jpeg'а обычно лежит бесполезный для распаковки exif, который занимает несколько килобайт, т.е. есть высокий шанс найти «свои» ключевые структуры.
Т.е. надо из всех jpeg'ов поудалять exif и пережать их с включенной оптимизацией таблиц Хаффмана, в этом случае перезапись первого килобайта будет очень эффективна.
Мусорить тоже надо уметь. Картинки можно отсортировать по дате и модели камеры (если вы не убрали exif). По документам можно выполнить текстовый поиск по ключевым фразам. Целостность многих файлов можно проверить и отбросить битые.
Это я все к чему. Если параноить по-настоящему, то шифрование выглядит надежней. Но только помните про обратную сторону этой «надежности», если что-то сломается, то шансы потерять данные насовсем значительно возрастают.
Зашифрованный раздел несколько снижает быстродействие, если шифрование не аппаратное. Если есть гарантированное время для уничтожения, или при предпродажной подготовке нет никаких проблем стереть всю информацию (кроме 8 часов времени на полную перезапись, или 100 часов при USB подключении для 2 Тб диска).
Таблицу MFT, естественно нужно держать в памяти, или на том же диске в зашифрованном виде.
Поточные файлы все разные, есть mp3, mjpeg, есть контейнеры .mkv c H.264 внутри, где почти нет избыточной информации. Стираем заголовок и ни один плеер не понимает что делать с гигабайтами псевдослучайных данных. Тегов, по аналогии с заголовкам в середине файла я тоже не вижу. Возможно, будут выделены ключевые кадры, но это не точно. Так как при воспроизведении плеер знает в каком месте ключевой кадр, а если нет заголовка, то все сектора примерно одинаковая сжатая информация или шум. Когда я качаю видео через torrent, если нет заголовка, ни один плеер ничего не воспроизводит. Когда есть заголовок будет воспроизведено всё, даже если скачены случайные части и 1% от общего размера, на ходу индексируется информация.
Предобработка jpeg вот это реально сложно. Все таки для меня не очевидно, что псевдослучайную информацию без явно видимой структуры можно ассоциировать с jpeg файлом. Там даже файла нет, просто сектора с цифровым шумом. Это может быть что угодно, и нет ни каких предпосылок предположить что сектора №32423..0000-№32423..0999 связаны с jpeg файлом, так как нет файловой таблицы и нет заголовка файла, ничего нет. Если брать сектора наугад, это будут части разных файлов перемежанные случайной информацией. Восстановление что вы предложили, требует информации из MFT, чтобы получить хотя бы файл известного размера, только без заголовка. Если взять jpeg файл размером стандартные 5 Мб и обрезать заголовок и еще 0.1 Мб и попытаться восстановить, это 0.01% от сложности восстановления на диске размером 2 000 000 Мб и без MFT. Весь диск по сути шумовые секторы и псевдо файлы умышленно записанные для осложнения анализа, нужно искать статистическими методами отклонения от чистого шума, сложнейшая задача.
exif в заголовке, если есть время, то удаляем, на SSD диске, для 1000 файлов это менее чем 0.1 секунда времени. Далее сортировка мало чем поможет, при восстановлении данных просто отсеется часть ложных файлов, не приблизив к расшифровке ни одного ценного файла. Что собственно и требовалось, осложнить работу при расшифровке.
Это очень сложный труд! Пример почитайте внутренний формат MS Word файлов
habr.com/post/110019
Теперь представляем что у вордовского файла убрали заголовок, как у jpeg файла. А если файл большой, то может быть фрагментирован по 2000 Гб пространства. Для восстановления сложность уровня адова жесть, даже если знать где у него начало и конец. А без MFT это не известно.
Есть еще открытые OOXML файлы, но там ZIP архив, в котором без заголовка тоже особо ловить нечего.
Шифрование хороший метод обеспечения безопасности. Но и метод быстрого уничтожения информации тоже может пригодится, как в случае предпродажной подготовки, так и как запасной вариант «на всякий случай». Если это будет утилита, то её существование кажется логичным. Я же не утверждаю что 2 секунд работы над диском достаточно для 100% уничтожения информации, я предполагаю, что использование моего алгоритма за несколько секунд может уничтожить 90% информации. Через минуту 99%, а все 100% будут уничтожены только после полной перезаписи диска.
Обратный пример утилита типа SDelete, она идет от от начала диска к концу записывая пустое пространство нулями. Даже через 30 минут работы она может не добраться до MFT и будет уничтожено всего 1/16 информации. Плюс очень простой анализ диска, сразу видно очищенную область и сохранившуюся, такие файлы восстановимы стандартными утилитами, что на лету подхватят MFT и покажут структуру диска.
По моему очевидно, что мой вариант дает принципиально иной подход к уничтожению. А вопросы только к теоретической возможности восстановления после нескольких секунд работы программы, когда перезаписано 100-200 Мб из 2 000 000 Мб на диске. Тут вопрос открыт, что лучше уничтожать и приоритет перезаписи файлов. Тут кажется что лучше портить самые уязвимые большие мультмедийные файлы, что дадут замечательный фон из псевдослучайных секторов, будучи лишенных заголовков, потом заголовки word, PDF и подобных файлов, потом мелкие txt файлы. Далее перезаписать все файлы блоками по 10-50 Мб, потом и пустое пространство, где могут быть следы ранее удаленных файлов.
Таблицу MFT, естественно нужно держать в памяти, или на том же диске в зашифрованном виде.
Поточные файлы все разные, есть mp3, mjpeg, есть контейнеры .mkv c H.264 внутри, где почти нет избыточной информации. Стираем заголовок и ни один плеер не понимает что делать с гигабайтами псевдослучайных данных. Тегов, по аналогии с заголовкам в середине файла я тоже не вижу. Возможно, будут выделены ключевые кадры, но это не точно. Так как при воспроизведении плеер знает в каком месте ключевой кадр, а если нет заголовка, то все сектора примерно одинаковая сжатая информация или шум. Когда я качаю видео через torrent, если нет заголовка, ни один плеер ничего не воспроизводит. Когда есть заголовок будет воспроизведено всё, даже если скачены случайные части и 1% от общего размера, на ходу индексируется информация.
Предобработка jpeg вот это реально сложно. Все таки для меня не очевидно, что псевдослучайную информацию без явно видимой структуры можно ассоциировать с jpeg файлом. Там даже файла нет, просто сектора с цифровым шумом. Это может быть что угодно, и нет ни каких предпосылок предположить что сектора №32423..0000-№32423..0999 связаны с jpeg файлом, так как нет файловой таблицы и нет заголовка файла, ничего нет. Если брать сектора наугад, это будут части разных файлов перемежанные случайной информацией. Восстановление что вы предложили, требует информации из MFT, чтобы получить хотя бы файл известного размера, только без заголовка. Если взять jpeg файл размером стандартные 5 Мб и обрезать заголовок и еще 0.1 Мб и попытаться восстановить, это 0.01% от сложности восстановления на диске размером 2 000 000 Мб и без MFT. Весь диск по сути шумовые секторы и псевдо файлы умышленно записанные для осложнения анализа, нужно искать статистическими методами отклонения от чистого шума, сложнейшая задача.
Мусорить тоже надо уметь. Картинки можно отсортировать по дате и модели камеры (если вы не убрали exif). По документам можно выполнить текстовый поиск по ключевым фразам. Целостность многих файлов можно проверить и отбросить битые.
exif в заголовке, если есть время, то удаляем, на SSD диске, для 1000 файлов это менее чем 0.1 секунда времени. Далее сортировка мало чем поможет, при восстановлении данных просто отсеется часть ложных файлов, не приблизив к расшифровке ни одного ценного файла. Что собственно и требовалось, осложнить работу при расшифровке.
По документам можно выполнить текстовый поиск по ключевым фразам.
Это очень сложный труд! Пример почитайте внутренний формат MS Word файлов
habr.com/post/110019
О сложности и жуткости вордовских файлов давно ходили легенды. Известно было, что формат этот крайне запутанный, а к тому же еще и полностью засекреченный, так что о половине тамошних полей можно было только догадываться.
Теперь представляем что у вордовского файла убрали заголовок, как у jpeg файла. А если файл большой, то может быть фрагментирован по 2000 Гб пространства. Для восстановления сложность уровня адова жесть, даже если знать где у него начало и конец. А без MFT это не известно.
Есть еще открытые OOXML файлы, но там ZIP архив, в котором без заголовка тоже особо ловить нечего.
Шифрование хороший метод обеспечения безопасности. Но и метод быстрого уничтожения информации тоже может пригодится, как в случае предпродажной подготовки, так и как запасной вариант «на всякий случай». Если это будет утилита, то её существование кажется логичным. Я же не утверждаю что 2 секунд работы над диском достаточно для 100% уничтожения информации, я предполагаю, что использование моего алгоритма за несколько секунд может уничтожить 90% информации. Через минуту 99%, а все 100% будут уничтожены только после полной перезаписи диска.
Обратный пример утилита типа SDelete, она идет от от начала диска к концу записывая пустое пространство нулями. Даже через 30 минут работы она может не добраться до MFT и будет уничтожено всего 1/16 информации. Плюс очень простой анализ диска, сразу видно очищенную область и сохранившуюся, такие файлы восстановимы стандартными утилитами, что на лету подхватят MFT и покажут структуру диска.
По моему очевидно, что мой вариант дает принципиально иной подход к уничтожению. А вопросы только к теоретической возможности восстановления после нескольких секунд работы программы, когда перезаписано 100-200 Мб из 2 000 000 Мб на диске. Тут вопрос открыт, что лучше уничтожать и приоритет перезаписи файлов. Тут кажется что лучше портить самые уязвимые большие мультмедийные файлы, что дадут замечательный фон из псевдослучайных секторов, будучи лишенных заголовков, потом заголовки word, PDF и подобных файлов, потом мелкие txt файлы. Далее перезаписать все файлы блоками по 10-50 Мб, потом и пустое пространство, где могут быть следы ранее удаленных файлов.
Безусловный плюс этого подхода в его необычности. На практике задача восстановления файла без заголовка встречается крайне редко, либо шансы чрезвычайно малы, т.к. поврежденный «заголовок» — это половина файла. Поэтому стандартные инструменты не заточены под такой тип проблемы. И человек который будет разбираться с диском вряд ли будет предполагать такой алгоритм порчи данных. И еще важный вопрос от кого защищаемся?
От покупателя с авито такой подход сработает на отлично. Но если рассматривать серьезного противника и если ему стал известен алгоритм работы утилиты, то тут не все так хорошо.
Самое слабое место ваших рассуждений — это преувеличение важности заголовка. Поиск по заголовку — это просто наиболее простой и быстрый способ, но не единственный. Конечно есть типы для которых начало содержит критически важные данные, но я не уверен, что таких типов большинство.
Например. Вы правильно заметили, что современный документы вроде docx, pptx, odt, и тд — это zip архивы, В них хранятся какие-то «под-файлы»: стили, связи, сам текст и еще что-то. Каждый под-файл сжат отдельно и перед ним есть сигнатура 0x04034b50.
Я провел эксперимент, взял несколько документов docx, текст там хранится в под-файле /word/document.xml (и это тоже сигнатура для поиска). В одном файле смещение этого под-файла было около 1700 байт, в другом около 3000. Я удалил все что было до этого смещения и сохранил это как новый zip архив. WinRAR прекрасно распаковал все оставшиеся под-файлы.
Вывод: если размер уничтожаемого заголовка будет небольшим (1Кб например), то элементарный сигнатурный поиск и подручные инструменты позволят увидеть текст всех ваших документов. И не нужно тут статистических методов и машинного обучения.
К другим типам файлов тоже можно найти свой подход, хоть и не ко всем. Можно конечно портить больше чем 1Кб, но это скажется на скорости.
Что касается живых документов, то их анализ сложный труд для разработчиков алгоритмов анализа, но не для экспертов криминалистов со специальным ПО.
От покупателя с авито такой подход сработает на отлично. Но если рассматривать серьезного противника и если ему стал известен алгоритм работы утилиты, то тут не все так хорошо.
Самое слабое место ваших рассуждений — это преувеличение важности заголовка. Поиск по заголовку — это просто наиболее простой и быстрый способ, но не единственный. Конечно есть типы для которых начало содержит критически важные данные, но я не уверен, что таких типов большинство.
Например. Вы правильно заметили, что современный документы вроде docx, pptx, odt, и тд — это zip архивы, В них хранятся какие-то «под-файлы»: стили, связи, сам текст и еще что-то. Каждый под-файл сжат отдельно и перед ним есть сигнатура 0x04034b50.
Я провел эксперимент, взял несколько документов docx, текст там хранится в под-файле /word/document.xml (и это тоже сигнатура для поиска). В одном файле смещение этого под-файла было около 1700 байт, в другом около 3000. Я удалил все что было до этого смещения и сохранил это как новый zip архив. WinRAR прекрасно распаковал все оставшиеся под-файлы.
Вывод: если размер уничтожаемого заголовка будет небольшим (1Кб например), то элементарный сигнатурный поиск и подручные инструменты позволят увидеть текст всех ваших документов. И не нужно тут статистических методов и машинного обучения.
К другим типам файлов тоже можно найти свой подход, хоть и не ко всем. Можно конечно портить больше чем 1Кб, но это скажется на скорости.
Что касается живых документов, то их анализ сложный труд для разработчиков алгоритмов анализа, но не для экспертов криминалистов со специальным ПО.
Очень интересное исследование, на основе таких наблюдений можно усовершенствовать алгоритм быстрого уничтожения данных.
По поводу размера, минимальный размер уничтожаемого заголовка определен сектором или кластером на диске, это 512 или 4096 байт, в последнем случае даже перезапись одного сектора наносит тяжелые повреждения файлу.
При скорости записи 100 Мб/с перезапись 4096 займет всего 40 микросекунд. За одну секунду будут повреждены 25000 файлов.
Соответственно за вторую секунду можно пройти по 8192 байтам заголовка. При размере некоторых документов более 10 Мб это существенная экономия времени, по сравнению с полной перезаписью всех файлов. Но при наличии пары минут времени, все равно все документы будут перезаписаны.
На обычном диске пользователя больше вопросов к мультимедийной информации, где файлы в 10 Гб никого не удивляют. Вот с ними сложнее, из-за объема. Удаление заголовка может и не помочь, если там легко читаемые внутренние фрагменты (хотя можно по ключевым кадрам пройти). Но можно рассортировать файлы по значимости и уязвимости. Сначала пройтись по уязвимым файлам, где заголовок критически важен, потом по мультимедийным файлам полностью, потом по всем остальным файлам полностью и по пустому пространству, уничтожая следы дисковой активности. Системные файлы, кроме реестра, похоже можно перезаписывать в последнюю очередь.
Если на диске файлы обычного пользователя, то можно и не ждать 8 часов на полную перезапись, а ограничиться несколькими минутами. Для восстановления останутся мультимедийные файлы без заголовка, фрагментированные, если у кого-то хватит терпения считывать посекторно гигабайты данных.
В .docx файле поиска, сигнатуры 0x04034b50 не нашел. Визуально видно заголовок до 0x0920 смещения, далее с виду случайный набор данных. Но по сигнатуре 00 00 00 00 00 можно найти составные части документа внутри
«word/media/image50.png%PNG» со смещением уже 0x0250С0. Вероятно так можно восстановить некоторые иллюстрации. Но не весь файл. Самое интересное там текст «document.xml» и в 13-мегабайтном файле упоминание встречается несколько раз, в основном в заголовке. Как я понимаю перезапись заголовка и еще немного с запасом уничтожает основное тело документа.
Криминалисты тоже люди. И появление такой утилиты их не порадует. Это обратная утилита их программному обеспечению. На примере ролика, похоже что на диске сохранена MFT, так как есть имена файлов, не повреждены заголовки файлов. И даже такой простой случай наверняка обойдется заказчику в 1000$. Более сложный случай, который мы разбираем, это труд коллектива аналитиков, математиков и программистов, кроме того что дорого, информации для восстановления может не быть в принципе, смотря какая части информации будет завязана на заголовок и структуру файла, которые как-раз пропадают.
По поводу размера, минимальный размер уничтожаемого заголовка определен сектором или кластером на диске, это 512 или 4096 байт, в последнем случае даже перезапись одного сектора наносит тяжелые повреждения файлу.
При скорости записи 100 Мб/с перезапись 4096 займет всего 40 микросекунд. За одну секунду будут повреждены 25000 файлов.
Соответственно за вторую секунду можно пройти по 8192 байтам заголовка. При размере некоторых документов более 10 Мб это существенная экономия времени, по сравнению с полной перезаписью всех файлов. Но при наличии пары минут времени, все равно все документы будут перезаписаны.
На обычном диске пользователя больше вопросов к мультимедийной информации, где файлы в 10 Гб никого не удивляют. Вот с ними сложнее, из-за объема. Удаление заголовка может и не помочь, если там легко читаемые внутренние фрагменты (хотя можно по ключевым кадрам пройти). Но можно рассортировать файлы по значимости и уязвимости. Сначала пройтись по уязвимым файлам, где заголовок критически важен, потом по мультимедийным файлам полностью, потом по всем остальным файлам полностью и по пустому пространству, уничтожая следы дисковой активности. Системные файлы, кроме реестра, похоже можно перезаписывать в последнюю очередь.
Если на диске файлы обычного пользователя, то можно и не ждать 8 часов на полную перезапись, а ограничиться несколькими минутами. Для восстановления останутся мультимедийные файлы без заголовка, фрагментированные, если у кого-то хватит терпения считывать посекторно гигабайты данных.
В .docx файле поиска, сигнатуры 0x04034b50 не нашел. Визуально видно заголовок до 0x0920 смещения, далее с виду случайный набор данных. Но по сигнатуре 00 00 00 00 00 можно найти составные части документа внутри
«word/media/image50.png%PNG» со смещением уже 0x0250С0. Вероятно так можно восстановить некоторые иллюстрации. Но не весь файл. Самое интересное там текст «document.xml» и в 13-мегабайтном файле упоминание встречается несколько раз, в основном в заголовке. Как я понимаю перезапись заголовка и еще немного с запасом уничтожает основное тело документа.
Криминалисты тоже люди. И появление такой утилиты их не порадует. Это обратная утилита их программному обеспечению. На примере ролика, похоже что на диске сохранена MFT, так как есть имена файлов, не повреждены заголовки файлов. И даже такой простой случай наверняка обойдется заказчику в 1000$. Более сложный случай, который мы разбираем, это труд коллектива аналитиков, математиков и программистов, кроме того что дорого, информации для восстановления может не быть в принципе, смотря какая части информации будет завязана на заголовок и структуру файла, которые как-раз пропадают.
Я когда отсылал в Китай дефектный SSD на 512G по гарантии, то его просто забил нулями (не помню какой программой), а потом в ДОСе с помощью diskedit в начале написал Hi China. Поменяли кстати без вопросов.
Внутренний параноик говорит что SSD может сохранить ваши самые важные данные. Например диск SSD 512G на самом деле 1024G, и в теневой копии хранит выборку из самых интересных файлов. Но это дорого для массового применения. Можно сделать избыток 5-10% от объема диска и поработать над алгоритмом выборки информации. Хотя бы по расширению.
Или на лету подменять загрузочный сектор ОС на модифицированный…
А можно теневую копию использовать для продления ресурса диска. Периодически меняя местами теневую копию и активно перезаписываемые сектора. И ресурс увеличивается, и слежение за пользователем, возврат по гарантии очень удобный повод считать всё.
Или еще один момент, нули легко архивируются. Диск мог просто пометить «виртуально» что записаны нули на всем пространстве диске, ничего по сути не перезаписывая. На верхнем уровне диск имитирует запись нулями, при обращении к любому сектору вернет 0. На нижнем уровне файлы пользователя остаются в сохранности. Чтобы избежать такого сценария, нужно забить диск случайными данными и проверить что диск не придумывает их при считывании.
Или на лету подменять загрузочный сектор ОС на модифицированный…
А можно теневую копию использовать для продления ресурса диска. Периодически меняя местами теневую копию и активно перезаписываемые сектора. И ресурс увеличивается, и слежение за пользователем, возврат по гарантии очень удобный повод считать всё.
Или еще один момент, нули легко архивируются. Диск мог просто пометить «виртуально» что записаны нули на всем пространстве диске, ничего по сути не перезаписывая. На верхнем уровне диск имитирует запись нулями, при обращении к любому сектору вернет 0. На нижнем уровне файлы пользователя остаются в сохранности. Чтобы избежать такого сценария, нужно забить диск случайными данными и проверить что диск не придумывает их при считывании.
Например диск SSD 512G на самом деле 1024G… Но это дорого для массового применения. Можно сделать избыток 5-10% от объема диска
Так они и так имеют объём больше. Сами «микрухи-флешки» (но, похоже, не все) имеют объём больше чем кратный «1024». А ещё, очень хорошо заметно — лежит диск на 256 Гигабайт, а рядом на 240, куда делись 16 гектаров? Правильно это и есть запас на выравнивание износа и продление жизни, иногда это дополнительный запас к «техническому».
Несколько не в тему, но, думаю, сообщество меня простит. Что вы, как специалист, думаете об эффективности программ типа Eraser для «надежного» удаления файлов?
Если нужно очистить целиком весь диск (например, перед продажей), то лучше использовать что-то наподобие VeraCrypt. Достаточно удалить все разделы, преобразовать диск в MBR (оснастка управления дисками) и создать зашифрованный том (с полным форматированием) на основе устройства.
Во-первых, получается быстрее, чем затирание в несколько проходов. Во-вторых, злоумышленнику кроме перезаписанного диска придётся разбираться ещё и с шифрованием. А для операционной системы такой диск выглядит как обычный неразмеченный, что не создаст проблем новому владельцу.
Во-первых, получается быстрее, чем затирание в несколько проходов. Во-вторых, злоумышленнику кроме перезаписанного диска придётся разбираться ещё и с шифрованием. А для операционной системы такой диск выглядит как обычный неразмеченный, что не создаст проблем новому владельцу.
Странно, что в статье ни слова о шифровании — это же самый очевидный способ, чтобы «после тебя» не прочитали. Терморектальный криптоанализ это не отменяет, но мы ведь пока о «посмертном» восстановлении говорим, либо о краденной информации.
AFAIK, многие энтерпрайз модели HDD и SSD шифруют на лету, так что достаточно уничтожить EPROM с ключамим каким-либо способом. Например, чипы на плате тщательно раскрошить молотком, а блины просто сдать в металлолом как есть.
А если помимо этого еще и ФС шифрованную применять, так и вообще любое восстановление малореальным кажется.
AFAIK, многие энтерпрайз модели HDD и SSD шифруют на лету, так что достаточно уничтожить EPROM с ключамим каким-либо способом. Например, чипы на плате тщательно раскрошить молотком, а блины просто сдать в металлолом как есть.
А если помимо этого еще и ФС шифрованную применять, так и вообще любое восстановление малореальным кажется.
Одного так и не понял: разве сильный нагрев блинов( как рассказано о первом случае, мол, даже металлические корпуса поплавились ) не приводит к размагничиванию?
А нет информации, как прочитать пятидюймовые дискеты, которые не читались уже лет 25? Лежат в коробках. Внутри целлулоидный диск с магнитным покрытием. Вся информация упакована утилитой PC Tools (если кто такую помнит, под MS DOS). Вот очень хочется почитать. Там у меня архивы с фидонет, моя первая работа, и даже музыка, написанная в ассемблере) Да много чего ностальгического… А как прочитать теперь, не знаю. PC Tools и дисковод я найду. Но боюсь, что вставленные диски просто испортятся, если их начать вращать внутри пластиковых конвертов.
Странно: когда по работе понадобилось добыть данные с диска, у которого повреждена поверхность блинов без вскрытия корпуса, ни кто и ни за какие деньги не захотел даже попробовать.
Sign up to leave a comment.
Темное искусство воскрешения: как восстанавливают данные с поврежденных носителей