Часто при расследованиях преступлений  в качестве доказательства невиновности или вины используются видеозаписи, полученные с помощью систем видеонаблюдения. О том, как восстановить запись из памяти видеорегистратора без специальных криминалистических программ рассказал специалист Лаборатории цифровой криминалистики и исследования вредоносного кода компании F.A.C.C.T. Андрей Кравцов.

Какое-то время назад я столкнулся с непростой, но интересной  задачей, суть которой заключалась в восстановлении видеозаписей из памяти видеорегистратора. Конечно, существует множество разнообразных криминалистических программ, в которых заложено решение подобных задач без особых усилий — в два счета! Но на тот момент о подобном ПО можно было только мечтать. В этой статье я попробую объяснить основные шаги решения задачи с помощью «подручных» средств и как я в итоге к нему пришел.

А теперь немного предыстории. В одном из «далеких, далеких офисов» входе ревизии обнаружили пропажу материальных ценностей со склада. Во время проведения внутреннего расследования ответственному сотруднику понадобилось скопировать видеозаписи из памяти видеорегистратора, так как они могли содержать изображения лиц, которые вывозили пропавшие материальные ценности. Копирование с помощью самого видеорегистратора занимало много времени, что могло сказаться на получении желаемого результата. Еще одна важная деталь, которую необходимо учесть, — видеорегистратор был настроен на цикличную запись, из‑за чего необходимые фрагменты видео могли быть безвозвратно утрачены. Так возникла идея ускорить копирование, подключив жесткий диск видеорегистратора к компьютеру с ОС Microsoft Windows. Однако в итоге произошла инициализация подключенного жесткого диска, и видеозаписи стали недоступны к просмотру никакими доступными для этого средствами. Дело в том, что процесс инициализации в ОС Microsoft Windows подразумевает подготовку подключённого накопителя информации к форматированию и хранению данных через  создание таблицы разделов «MBR» или «GPT».

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

Первым делом с помощью Hex-редактора я решил просмотреть, что хранится в памяти диска. Как и ожидалось, там было большое количество данных, из которых мне была известна только сигнатура «55 AA». Эта сигнатура указывала на то, что сектор № 0 теперь стал загрузочным и рассматривать его как источник информации для анализа данных не стоит (см. Рисунок 1).

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

Исследуя содержимое файлов с помощью Hex-редактора мне открылась непонятная картина: каждый файл имел сигнатуру "DHAV". Эта сигнатура была для меня новой, а структура файлов не соответствовала структурам медиаконтейнеров, с которыми я был знаком ранее (см. Рисунок 2).

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

Как известно, стандарт данного кодека описывает несколько типов кадров – это I-кадры, P-кадры и B-кадры, которые объединены в GOP-последовательность (Group of Pictures, группу кадров), а видеопоток организован в иерархическую структуру.

– I-кадры кодируются независимо от других кадров. Это означает, что для декодирования I-кадра не требуется информация из других кадров.

– P-кадры используют предсказание из предыдущих кадров для кодирования текущего кадра.

– B-кадры используют предсказание как из предыдущих, так и из последующих кадров.

Таким образом, структуру видеозаписи можно представить как множество GOP-последовательностей

Одной из особенностей кодека H.265 является то, что в отличие от H.264, он не использует фиксированную сигнатуру для идентификации I-кадров и производить поиск I-кадров будет проблематично, поэтому было решено проанализировать видеопоток с помощью «ffprobe. Результаты анализа порадовали меня как никогда, так как «ffprobe» распознал формат файла, а это означало только одно – чтение исходного кода.

Исходный код «ffmpeg» содержал описание заголовка кадра исследуемого видеофайла, который включал в себя важные данные, а именно размеры и расположение сигнатуры начала кадра, тип кадра, номер камеры, а также структуру даты и времени создания видеопотока. Стоит учитывать, что для определения номера камеры необходимо прибавлять 1 к числу, указанному в байте. Еще одна особенность структуры кадра это то, что каждый кадр начинался с сигнатуры «DHAV» в верхнем регистре, а заканчивался сигнатурой «dhav» в нижнем регистре плюс 4 байта. Особое внимание стоит уделить дате и времени, так как для ее определения используются битовые поля в следующем порядке:

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

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

Завершающим этапом решения стало написание небольшого python-скрипта, который копировал из памяти диска видеозаписи за необходимый период времени. Вот такие незамысловатые действия позволили мне восстановить видеозаписи после инициализации диска из видеорегистратора в ОС Microsoft Windows.

Заключение

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

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