В нашей работе бывают кейсы, которые не отпускают даже спустя годы. Как будто кто-то оставил след в твоей памяти, который невозможно стереть. Меня зовут Андрей Кравцов, я специалист Лаборатории цифровой криминалистики F6, и сегодня я хочу рассказать об одном таком случае из моей практики.

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

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

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

Для того, чтобы восстановить видеозаписи я выбрал специализированное криминалистическое программное обеспечение, в характеристиках которого заявлялась поддержка данной файловой системы. Однако в процессе анализа выяснилось, что на тот момент программное обеспечение могло работать только с теми видеозаписями, которые не были удалены. Это вызвало закономерный вопрос: «Каким образом можно проверить наличие удалённых видеозаписей?».  

Поскольку файловая система «QVFS» является проприетарной, а сведения о её внутреннем устройстве отсутствуют в открытом доступе, то для решения данного вопроса я обратился к утилитам, предоставленным вместе с диском.

Запустив утилиту для копирования видеозаписей и видеоплеер, стало ясно, что видеозаписи можно скопировать в проприетарном формате «DAV» или сохранить кадр в формате JPG. 

Опыт успешного восстановления по структуре видеофайлов сначала вселил уверенность. Но стоило скопировать файл, как появились следующие проблемы: ffmpeg не знает этот формат, а в HEX-редакторе не видно какой-либо отличительной структуры. 

Анализ файловой системы не давал четкого понимания организации хранения видеозаписей, поэтому я сосредоточился на исследовании компонентов, используемых предоставленными утилитами. Интересной находкой оказались две версии QVFS.dll - при идентичных именах их размеры различались, что наводило на мысль о наличии в более крупной версии отладочной информации.

Используя утилиту Sysinternals Strings, предназначенную для поиска строк в бинарных образах, я проанализировал обе библиотеки. В библиотеке видеоплеера была строка "DISK HEAD". Это могло быть просто меткой, но следом шли строки форматированного вывода, что подогрело мой интерес.

 Я открыл DebugView и запустил видеоплеер. Как только в логе появилась «DISK HEAD», сразу за ней последовали строки, которые открыли завесу тайны структуры файловой системы. Это было именно то, что нужно: данные о заголовке, без которых восстановление было бы невозможным.

Изучив полученные данные, стало ясно, что сведения о размещении видеозаписей начинаются в секторе № 8. Каждая запись имеет размер 64 байта, сигнатуру «QVBK» и даты начала и конца записи.  

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

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

Так как точное время, содержащееся в метаданных, было неизвестно, поиск производился только по дням.

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

Записав новую таблицу на диск, я запустил утилиту для копирования видеозаписей. Результат работы превзошел все мои ожидания. Кроме необходимых видеозаписей, обнаружились еще более 500 видеозаписей за разные периоды времени. 

Таким образом, простое техническое решение с применением доступных инструментов, таких как Strings и DebugView, позволило восстановить видеозаписи из памяти видеорегистратора, избежав трудоёмкого анализа кода библиотеки QVFS.dll видеоплеера. Но остался вопрос: «Почему первая таблица была пуста?» Сбой... или чей-то злой умысел? Очевидно, что DebugView уже не ответит на такой вопрос.