«Черновое восстановление» (Часть 2: Анализ форматов)

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

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

Формат BMP

Описание формата можно найти, например, на сайте Microsoft или в Wikipedia (русская и английская). Если оставить только значимые для нас подробности, то файл BMP выглядит следующим образом:

Файл BMP

Упрощенная структура файл BMP

Где Bitmap File Header – это структура следующего вида:

Здесь важно, что

  • поле bfType должно всегда иметь значение «BM» — это та самая сигнатура на основе которой мы задавали шаблон GREP в прошлой статье;
  • bfSize содержит полный размер файла;
  • bfReserved1 и bfReserved2 должны содержать нули в текущих версиях формата;
  • bfOffBits — содержит смещение к данным изображения.

Благодаря заголовку мы можем:

  • определить начало BMP файла, проверив значение bfType, bfReserved1 и bfReserved2;
  • узнать полный размер файла из поля bfSize;

Далее идет DIB Header. В зависимости от версии формата это могут быть разные структуры, но все они достаточно похожи, рассмотрим BITMAPINFOHEADER:


С помощью полей этой структуры можно выполнить дополнительные проверки, которые снизят шанс ложного срабатывания:

  • biSize — содержит точный размер структуры BITMAPINFOHEADER;
  • biBitCount – количество бит используемых для хранения одного пикселя, не может быть произвольным, а только из множества [0, 1, 4, 8, 16, 24, 32];

и так далее.

Большую часть файла занимают данные изображения. В большинстве случаев, это несжатые данные. Цвет каждого пикселя кодируется определенным числом бит, а затем они записывают последовательно друг за другом. Это, к сожалению, означает, что данные могут быть произвольными и их проверить никак нельзя.

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

Формат PNG

PNG – еще один формат хранения растровых изображений, но уже со сжатием (но без потери качества как в jpeg). Его спецификацию можно найти на сайте W3C. Она занимает не один десяток печатных страниц. Однако, для восстановления данных достаточно знать совсем немного.

Любой файл PNG начинается с последовательности из 8 байт: 89 50 4E 47 0D 0A 1A 0A.

Затем идет последовательность chunk’ов — кусочков на которые разбит весь png файл.

Файл PNG

Упрощенная структура файла PNG

Структура chunk’а:

Структура PNG Chunk

Структура PNG Chunk

То есть, для каждого chunk’а указаны:

  • размер данных chunk, если пустой, то это 0;
  • тип – 4 ASCII символа;
  • собственно данные chunk’а, если есть;
  • контрольная сумма, которая рассчитывается для Chunk Type и Chunk Data.

И последнее, что нужно знать —последовательность chunk’ов не может быть произвольной. В спецификации приведены 2 схемы следования chunk’ов друг за другом:

Последовательность chunk'ов с PLTE

Последовательность chunk’ов с PLTE

Последовательность chunk'ов без PLTE

Последовательность chunk’ов без PLTE

Внутри прямоугольника записан тип chunk’а. Черта «|» означает, что должен быть или один или другой chunk. А символы сверху обозначают сколько раз он может встречаться:
А символы имеют следующие значения:

  • + – один или несколько раз;
  • 1 – только один раз;
  • ? – ноль или один раз;
  • * – ноль или несколько раз.

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

  • легко определить начало файла по первым 8 байтам;
  • файл целый, если собралась корректная последовательность chunk’ов с корректными контрольными суммами, иначе файл поврежден;
  • если файл целый, то мы знаем его размер — от начала до IEND включительно;
  • если последовательность не собралась – файл поврежден, но размер его валидной части больше или равен смещению до конца последнего валидного chunk’а.

В отличии же от формата BMP, для поврежденного файла нельзя узнать его полный размер.

С каким размером сохранять найденные файлы?

Мы разобрались с тем, какие возможности для восстановления данных заложены в форматах BMP и PNG. Рассмотрим теперь различные случаи с целыми и поврежденными файлами. Это поможет нам правильно интерпретировать результаты поиска.

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

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

Файл BMP

Файл BMP

Нельзя ручаться за данные, которые находятся после проверенного размера. Если файл, например, фрагментирован, то следующий заголовок может быть найден уже внутри «полного размера»:

Поврежденный файл BMP

Поврежденный файл BMP

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

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

Целый файл BMP

Целый файл BMP

Если мы нашли целый PNG файл, то все очень просто. Мы проверили его от начала до конца, знаем его размер и уверены, что он целый.

Целый файл PNG

Целый файл PNG

Более сложная ситуация, если PNG файл поврежден.

Поврежденный файл PNG

Поврежденный файл PNG

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

Форма «чернового восстановления»

Форма режима "черновое восстановление"

Форма режима «черновое восстановление»

С помощью анализа структуры мы можем получить значительно больше информации чем при простом поиске по шаблонам GREP. Рассмотрим как она отображается на форме чернового восстановления.

Панель категорий

Панель категорий

В «черновом восстановлении» файлы ищутся как с помощью шаблонов GREP, так и с помощью анализа структуры. Поле GREP на панели с категориями заполнено только у первых.

Панель с результатами

Панель с результатами

Записи на панели с результатами тоже отличаются.

  • Если мы можем ответить целый файл или нет, то возле него будет отображена цветная отметка: зеленая — для целых, красная — для поврежденных.
  • В поле Size хранится размер, с которым файл будет сохранятся («размер при сохранении»). Выше мы рассмотрели как он выбирается для разных случаев.
  • Поле Checked Size содержит «проверенный размер». В дальнейшем мы рассмотрим где можно применять эту информацию.
  • Поле Comment содержит комментарий, содержание которого зависит от конкретного формата файла. Для изображений BMP и JPG отображается высота и ширина картинки, а для загрузочного сектора NTFS (Boot NTFS) размер раздела и кластера.
Панель метаданных

Панель метаданных

В режиме есть панель «метаданные», в нее попадает различная полезная информация, полученная при анализе файла по структуре. Например, для Boot NTFS (на скриншоте) можно узнать размер раздела, размер кластера, кластер с MFT0 и его копией.

Пример с картой памяти из фотоаппарата

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

Результаты выполнения "чернового восстановления"

Результаты выполнения «чернового восстановления»

Мы нашли такое же количество файлов JPEG. Однако результата стал намного более наглядным и точным:

  • у файлов появилась отметка целостности; с помощью фильтра можно отобрать и сохранить только целые файлы;
  • у целых jpeg’ов размер определен с точный размер до байта, а не до следующего заголовка как при поиске GREP;
  • заполнено поле comment и появились «Метаданные», из них можно узнать размер изображения, модель камеры, дату съемки и пр.

Заключение

На примере форматов BMP и PNG мы разобрали как в «черновом восстановлении» ищутся файлы на основе знаний о структуре. Очевидно, что такой подход дает намного более качественный результат, чем поиск с помощью регулярных выражений. Но алгоритмы проверки — это часть комплекса, и их нельзя добавить также легко как очередной шаблон GREP.

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

Леоненко Александр
Разработчик Data Extractor

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (2 голосов, средний: 5,00)
Loading...Loading...

Об авторе Александр Леоненко

Разработчик Data Extractor и Data Extractor RAID Edition
Запись опубликована в рубрике Data Extractor с метками , , , , . Добавьте в закладки постоянную ссылку.

Один комментарий на ««Черновое восстановление» (Часть 2: Анализ форматов)»

  1. Уведомление: «Черновое восстановление» (Часть 1: Регулярные выражения) | Блог разработчиков Data Extractor

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>