Мой коллега Viktor-Flash проводил тесты бесплатных программ для восстановления данных (первая и вторая части). В этой статье я разберу второй тест, в котором был переформатирован раздел. Надеюсь, что после прочтения у читателя сложится понимание того, что делают/пытаются_делать/могли_бы_сделать программы для восстановления данных. Существенная часть статьи посвящена тому, как можно восстановить файлы не анализируя метаданные ФС.
(Про устройство FAT32 и метод восстановления при затертом Boot я рассказал в предыдущей статье, поэтому предполагаю что читатель с ними знаком)
«Быстрое форматирование» в FAT32 обычно заключается в том, что записывается новый набор метаданных, для «чистой» ФС. А именно, будут записаны новые Boot'ы, таблицы FAT и Root. Если предположить, что старая и новая ФС были форматированы одним и тем же драйвером с одними и теми же настройками, то перечисленные метаданные будут затерты новыми. В других случаях может быть что-то останется от старых метаданных, а может и наоборот — будет переписана еще какая-то часть данных.
Что можно сделать? Наиболее правильно в этом случае убрать из рассмотрения все новые метаданные, найти парочку FAT Folder, которые остались от старой системы и с помощью них определить размер кластера и начало кластеризации старой ФС. Также, мы сможем построить большую часть дерева каталогов и файлов. Т.к. root стерт, информация о лежащих непосредственно в нем файлах пропадет совсем. Каталоги же потеряют имя и атрибуты, но мы узнаем что они есть и что содержат, поскольку найдем дальше соответствующие им FAT Folder. Таким «оторванным» каталогам обычно дают новые имена вроде Folder000020, где 20 — номер кластера c FAT Folder.
Обратите внимание на результаты некоторых программ — они полностью подходят под это описание.
Продолжим подсчитывать потери. В FAT Folder указан первый кластер файла и его размер. Для непрерывно размещенных файлов этого хватит, но чтобы собрать фрагментированный файл, нам нужна таблица FAT, а обе ее копии стерты. Поэтому к пострадавшим добавляются фрагментированные файлы.
Подведем промежуточный итог. Анализ оставшихся метаданных от первоначальной ФС позволяет построить почти все дерево файловой системы и размещение непрерывных файлов. Файлы в корневом каталоге будут утрачены. Фрагментированные в исходной ФС файлы будут иметь неправильное размещение (например, jpeg'и будут открываться не полностью).
Ранее я рассмотрел подходы, которые основаны на поиске и анализе структур файловой системы. Но есть и альтернативный подход, суть которого в поиске непосредственно файлов. Он основан на том, что многие типы файлов имеют в начале некоторую сигнатуру, которую можно искать.
Например, файлы bmp начинаются с «BM», jpeg'и начинаются с 0xFFD8FF, zip-архивы с 0x504B0304.
Наиболее академическое название такого метода, на мой взгляд, File Carving. Конкретные режимы в конкретных программах могут называться по-разному (в PC3000 DataExtractor — «Черновое восстановление»). Есть также множество подходов к реализации карвера, в зависимости от того, как ищутся заголовки, как определяется размер файла, как проверяется (если вообще проверяется) его целостность и пр.
Для примера, рассмотрим очень простой и «тупой» подход — Header/MaximumSize. Такой карвер ищет заголовок файла по сигнатуре и сохраняет его с заранее заданным одинаковым размером (исходим из того, что реальный файл будет всегда меньше и мусор не помешает открыть файл). Очень просто, но может оказаться очень эффективно, например, при восстановлении фотографий с цифромыльницы — заголовок jpeg известен, файлы обычно непрерывные и их размер редко превышает, скажем, 10мб.
Однозначным минусом любого карвера является невозможность восстановить дерево каталогов и файлов, их имена и атрибуты. Т.к. эта информация хранится в метаданных ФС. Затем карвер ищет только те файлы, которые он знает. Также остается открытой проблема фрагментированных файлов. Частные случаи для некоторых типов файлов решаются, но общего решения для дисков современного объема, на мой взгляд, нет. Описанный выше абстрактный карвер наделен еще и своими личными недостатками. Он будет часто ошибаться, не сможет отличить «живой» файл от «неживого». Не сможет определить точный размер файла и точный тип файла (знаете ли вы, что doc, xls, ppt и другие имеют общий формат? А docx, pptx, odt, ods, jar,… — это все zip архивы?)
Многие программы во втором тесте, а некоторые даже и в первом, выполнили именно карвинг файлов. Это очень легко понять по результатам — нет никакого намека на исходное дерево каталогов и файлов, все файлы сгруппированы по в типам и названы по какому-нибудь шаблону. Яркий пример — PhotoRec (отдельно от TestDisk). Если заглянуть его в исходники, то можно отметить некоторые особенности: реализованы процедуры поиска заголовка файла и, там где это возможно, сигнатуры конца файла. Некоторые типы файлов разбираются более глубоко, используются знания об их внутренней структуре, что уменьшает число ложных срабатываний.
В PC3000 DataExtractor тоже есть файловый карвер, в котором заголовки ищутся с помощью регулярных выражений и с помощью анализа формата файла.
На мой взгляд, наиболее качественный результат во втором тесте должна дать комбинация анализа файловой системы и file carving.
В общем и целом, результат восстановления данных в каждом конкретном случае может быть разным. Иногда легко и быстро можно вернуть «все как было», а иногда возможности восстановления ограничены в принципе. Поэтому хочу повторить 2 совета:
Тест второй: переформатирование
(Про устройство FAT32 и метод восстановления при затертом Boot я рассказал в предыдущей статье, поэтому предполагаю что читатель с ними знаком)
«Быстрое форматирование» в FAT32 обычно заключается в том, что записывается новый набор метаданных, для «чистой» ФС. А именно, будут записаны новые Boot'ы, таблицы FAT и Root. Если предположить, что старая и новая ФС были форматированы одним и тем же драйвером с одними и теми же настройками, то перечисленные метаданные будут затерты новыми. В других случаях может быть что-то останется от старых метаданных, а может и наоборот — будет переписана еще какая-то часть данных.
Что можно сделать? Наиболее правильно в этом случае убрать из рассмотрения все новые метаданные, найти парочку FAT Folder, которые остались от старой системы и с помощью них определить размер кластера и начало кластеризации старой ФС. Также, мы сможем построить большую часть дерева каталогов и файлов. Т.к. root стерт, информация о лежащих непосредственно в нем файлах пропадет совсем. Каталоги же потеряют имя и атрибуты, но мы узнаем что они есть и что содержат, поскольку найдем дальше соответствующие им FAT Folder. Таким «оторванным» каталогам обычно дают новые имена вроде Folder000020, где 20 — номер кластера c FAT Folder.
Обратите внимание на результаты некоторых программ — они полностью подходят под это описание.
Продолжим подсчитывать потери. В FAT Folder указан первый кластер файла и его размер. Для непрерывно размещенных файлов этого хватит, но чтобы собрать фрагментированный файл, нам нужна таблица FAT, а обе ее копии стерты. Поэтому к пострадавшим добавляются фрагментированные файлы.
Подведем промежуточный итог. Анализ оставшихся метаданных от первоначальной ФС позволяет построить почти все дерево файловой системы и размещение непрерывных файлов. Файлы в корневом каталоге будут утрачены. Фрагментированные в исходной ФС файлы будут иметь неправильное размещение (например, jpeg'и будут открываться не полностью).
Альтернативный метод — file carving
Ранее я рассмотрел подходы, которые основаны на поиске и анализе структур файловой системы. Но есть и альтернативный подход, суть которого в поиске непосредственно файлов. Он основан на том, что многие типы файлов имеют в начале некоторую сигнатуру, которую можно искать.
Например, файлы bmp начинаются с «BM», jpeg'и начинаются с 0xFFD8FF, zip-архивы с 0x504B0304.
Наиболее академическое название такого метода, на мой взгляд, File Carving. Конкретные режимы в конкретных программах могут называться по-разному (в PC3000 DataExtractor — «Черновое восстановление»). Есть также множество подходов к реализации карвера, в зависимости от того, как ищутся заголовки, как определяется размер файла, как проверяется (если вообще проверяется) его целостность и пр.
Для примера, рассмотрим очень простой и «тупой» подход — Header/MaximumSize. Такой карвер ищет заголовок файла по сигнатуре и сохраняет его с заранее заданным одинаковым размером (исходим из того, что реальный файл будет всегда меньше и мусор не помешает открыть файл). Очень просто, но может оказаться очень эффективно, например, при восстановлении фотографий с цифромыльницы — заголовок jpeg известен, файлы обычно непрерывные и их размер редко превышает, скажем, 10мб.
Однозначным минусом любого карвера является невозможность восстановить дерево каталогов и файлов, их имена и атрибуты. Т.к. эта информация хранится в метаданных ФС. Затем карвер ищет только те файлы, которые он знает. Также остается открытой проблема фрагментированных файлов. Частные случаи для некоторых типов файлов решаются, но общего решения для дисков современного объема, на мой взгляд, нет. Описанный выше абстрактный карвер наделен еще и своими личными недостатками. Он будет часто ошибаться, не сможет отличить «живой» файл от «неживого». Не сможет определить точный размер файла и точный тип файла (знаете ли вы, что doc, xls, ppt и другие имеют общий формат? А docx, pptx, odt, ods, jar,… — это все zip архивы?)
Многие программы во втором тесте, а некоторые даже и в первом, выполнили именно карвинг файлов. Это очень легко понять по результатам — нет никакого намека на исходное дерево каталогов и файлов, все файлы сгруппированы по в типам и названы по какому-нибудь шаблону. Яркий пример — PhotoRec (отдельно от TestDisk). Если заглянуть его в исходники, то можно отметить некоторые особенности: реализованы процедуры поиска заголовка файла и, там где это возможно, сигнатуры конца файла. Некоторые типы файлов разбираются более глубоко, используются знания об их внутренней структуре, что уменьшает число ложных срабатываний.
В PC3000 DataExtractor тоже есть файловый карвер, в котором заголовки ищутся с помощью регулярных выражений и с помощью анализа формата файла.
На мой взгляд, наиболее качественный результат во втором тесте должна дать комбинация анализа файловой системы и file carving.
Заключение
В общем и целом, результат восстановления данных в каждом конкретном случае может быть разным. Иногда легко и быстро можно вернуть «все как было», а иногда возможности восстановления ограничены в принципе. Поэтому хочу повторить 2 совета:
- делайте бэкапы;
- если вы потеряли важные данные — ничего не трогайте и несите к профессионалам.
