Восстановление данных с камеры Canon

Обратился к нам клиент с банальной, казалось бы, проблемой – удалил с карты памяти отснятый видеокамерой Canon LEGRIA материал. Большинство сразу скажет: «да воспользуйся любой программой по восстановлению удаленных файлов, в чем проблема?». А проблема, оказывается, есть, и существенная. Все современные камеры, с которыми мы сталкивались – создают на носителе файлы в фрагментированном виде.

Это касается всех камер, сохраняющих видео в формате Apple QuickTime (mov/mp4). Примеры на слуху – зеркальные фотокамеры Canon, экшн-камеры GoPro и их безымянные аналоги, автомобильные видеорегистраторы.

Короткая ремарка по содержимому файлов в указанном формате: файл состоит из сложной вложенной структуры, каждый элемент данных называется атомом. Более подробную информацию можно найти по ссылке, здесь оставлю лишь картинку с обобщённой структурой:

Продолжим. После банального удаления файлов теряется самое важное – информация о расположении фрагментов (кластерная цепочка) файлов. Сразу оговорюсь – ситуация, о которой я говорю, верна для файловой системы FAT32. Для NTFS или ExFAT ситуация может быть другой. И в случае с FAT32 и удалёнными фрагментированными файлами существует всего два метода их восстановления:

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

Мы уже неоднократно работали с разными видеоформатами, и знаем, что далеко не каждый поток видео/аудио данных можно восстановить и воспроизвести без сопроводительных служебных метаданных. Например, простой формат MPEG-2 – является потоковым, и для его воспроизведения не нужны никакие дополнительные служебные данные – просто сырой поток данных, выровнянный по границе фрейма.

Такой поток можно восстановить первым методом и не тратить время на служебные данные. Также первым методом можно восстанавливать сырой видеопоток без служебных данных, даже если он был в Apple QuickTime контейнере (mov/mp4), при условии использования определенного видеокодека. Однако данная видеокамера создает файлы с видеопотоком, который не оставляет шансов на восстановление первым методом:

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

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

Однако, изучив в HEX-редакторе несколько примеров видеофайла с подопытной камеры, был придуман алгоритм сборки «фрагментов» по маркерам из содержимого файла.  Для решения задачи необходимо полностью проанализировать пример файла, понять какие атомы используются, какую информацию из них мы можем использовать, и как затем, находя содержимое этих атомов на носителе, соединить найденные фрагменты в единое целое. Для понимания первичной структуры используем MP4 Explorer:

Структура стандартная. Атом mvhd с временем создания файла оказался для нас очень важным – по времени создания можно связать найденный на диске фрагмент с атомами trak с началом файла, фрагментом ftyp. Глянем на начало файла в HEX виде:

Здесь в служебном атоме CNTH->CNDA  находится картинка-превью файла, в которой очень удачно для нас есть дата создания файла в текстовом виде. Эта информация очень пригодится далее. Как оказалось, камера при формировании метаданных резервирует фиксированное место под превью-картинку, а также для пользовательской информации, которую можно поместить в служебный атом udta. Ну а самое главное, что атом с непосредсвенно медиапотоком, mdat – записывается камерой нефрагментированно. И снова очень удачно – в этом атоме есть за что зацепиться для поиска соответсвующего ему атома mhvd и ftyp.