Часто при просмотре видеозаписей кажется, что всё на своих местах: события, люди, действия. Всё выглядит логично — до тех пор, пока не обращаешь внимания на время. Когда дата на видео не совпадает с реальностью, это меняет всё. В этой статье Андрей Кравцов, специалист Лаборатории цифровой криминалистики F6, расскажет о случае из практики, когда именно нестыковка во времени стала ключом решения. Истину помогли установить не кадры, а скрытые от глаз журналы событий, которые хранят больше, чем кажется на первый взгляд.
Изначально задача казалась тривиальной: провести криминалистический анализ, в рамках которого восстановить видеозаписи с жёсткого диска видеорегистратора. Заказчик сообщил, что самостоятельно найти и просмотреть видеозаписи за определённый период не получилось, это и стало причиной обращения к нам в Лабораторию.
Не нарушая принципов компьютерной криминалистики, был создан образ диска. После просмотра образа в HEX-редакторе стало ясно, что в видеорегистраторе использовалась проприетарная файловая система «HIKVISION» (см. рис. 1). Эта файловая система встречается довольно часто, поэтому криминалистическое программное обеспечение в достаточной мере может восстанавливать удаленные записи.
Проведя анализ файловой системы, стало ясно, почему заказчик самостоятельно не смог обнаружить необходимые видеозаписи. На всех видеозаписях отображалась дата из будущего, которая опережала момент исследования почти на ~16 лет. Это привело к тому, что все файлы имели временные метки, не соответствующие реальной дате.
После выяснения всех обстоятельств стало очевидно, что причиной возникновения такой ситуации послужило отсутствие в плате видеорегистратора элемента питания, который отвечает за работу системных часов. Причину его отсутствия также никто не мог объяснить. Так как вопрос по получению видеозаписей был решен, оставалось решить еще один вопрос: «Какова реальная дата создания видеозаписей?»
Как известно, видеорегистраторы, использующие файловую систему «HIKVISION», ведут журналы событий, которые сохраняются на жёстком диске. В штатных условиях доступ к ним осуществляется через сам видеорегистратор, который позволяет выгружать данные в текстовом формате для последующего анализа. Однако в нашем случае устройства под рукой не оказалось, что потребовало поиска альтернативных методов.
Чтобы прочитать записи из журналов событий, мы воспользовались утилитой «Hikvision MVA», но результат ее работы разочаровал. При выборе временного диапазона для поиска записей утилита отображает сообщение о том, что выбор можно осуществить только за 30 дней (рис. 2), а сократив диапазон до одного дня, отображается сообщение, что данных слишком много (рис. 3).
Ответ на оставшийся вопрос требовал более глубокого изучения файловой системы видеорегистратора. Несмотря на то, что она является проприетарной и доступной публичной информации немного, данные, полученные на этом этапе исследования, оказались весьма полезными. Особенно важными для последующего анализа являются следующие элементы:
формат представления даты и времени;
дата инициализации файловой системы;
место хранения системных журналов;
объём этих журналов;
внутренняя структура записей журналов.
Теперь подробнее о том, где они хранятся и как их интерпретировать. Основная часть необходимых данных содержится в заголовке файловой системы. Размер заголовка файловой системы составляет 256 байт и начинается со второго сектора. Время и дата хранятся в 32-битном числе в формате Unix-time. Также заголовок содержит смещение начала системных журналов и их объём (рис. 4).
Структура записи журнала событий содержит сигнатуру, время и дату в 32-битном числе в формате Unix-time, код журнала, код события журнала и данные, характерные для события (рис. 5).
В материалах, которые удалось найти по данному вопросу, достаточно подробно описывался заголовок файловой системы, однако внутренняя структура записей журналов была раскрыта не полностью. Упоминалась общая схема хранения данных и отмечалось, что видеорегистратор ведёт четыре отдельных журнала, каждый из которых фиксирует определённый класс событий. Этих сведений оказалось недостаточно для полноценного анализа, поэтому было решено продолжить поиск дополнительных источников информации. На просторах интернета удалось найти описание событий, которые видеорегистратор ведет в своих журналах, а также то, что журналов 5 (рис. 6), которые содержат 2295 событий.
В нашей задаче требовалось просмотреть события из журналов 0х02 и 0х03, которые содержат данные об входе/выходе пользователей и манипуляции с настройками видеорегистратора.
Оставалось разобраться, как интерпретировать поле, содержащее описание события, так как прямое чтение текста не давало ясного результата. Анализ логов показал, что записи имеют различный размер: от 68 байт до 1168 байт. Самое большое описание выделено для записи с параметрами S.M.A.R.T. В этом описании можно напрямую прочитать модель диска, серийный номер и версию микропрограммы (рис. 7). Все остальные данные представлены как таблица параметров с кодами, значения которых определяются производителем диска.
Постоянными были поля в событиях об входе/выходе пользователей. В каждой такой записи первые 16 байт содержат имя пользователя, вторые 16 байт – IP-адрес, использованный при удаленном подключении (рис. 8).
Изначально было решено выбрать необходимые события из общего массива записей, но предварительная оценка показала, что получить требуемый результат таким способом быстро не получится (рис. 9).
Программирование — мощный инструмент, расширяющий возможности эксперта. Поэтому, вооружившись C++, мы разработали небольшую утилиту, которая позволяет парсить образ диска видеорегистратора, находить в нём журналы и преобразовывать их записи в читаемый вид. Утилита выложена в нашем репозитории GitHub — там доступны готовые скомпилированные файлы для Windows.
Получив хронологию событий работы видеорегистратора, наше внимание привлекли несколько записей с кодами (рис. 10).
Эти записи раскрывали весьма интересную картину. Итак, события разворачивались следующим образом:
Диск видеорегистратора был отформатирован;
Был осуществлен локальный выход пользователя из панели управления видеорегистратора;
Произведены неудачные попытки локального входа в панель управления видеорегистратора (за день до изъятия);
Локальный вход в момент изъятия диска;
Видеорегистратор был отключен, завершая цепочку событий.
Сопоставление данных журналов с реальной датой извлечения диска позволило восстановить последовательность событий: форматирование диска, неоднократные попытки несанкционированного входа, последующий локальный вход и окончательное отключение устройства.
Из журналов стало очевидно, что некто в организации, пытаясь скрыть следы своих действий, произвел форматирование диска видеорегистратора. Когда же ему стало известно о предстоящем исследовании носителя, он предпринял попытку повторного входа в систему, однако доступ уже не был получен.
Ключевым моментом стало событие отключения видеорегистратора — именно оно позволило установить реальные даты записей, после чего вся картина стала логически завершённой.
Первоначально видеозаписи могли ввести в заблуждение из-за смещённого времени, но именно системные журналы позволили восстановить подлинную последовательность событий. Иногда истина скрыта не в кадрах, а в цифровых следах, которые остаются в кодах и записях системы.