ИССЛЕДОВАНИЕ ФАЙЛОВОЙ СИСТЕМЫ HDD DVR QCM-08DL
ИССЛЕДОВАНИЕ ФАЙЛОВОЙ СИСТЕМЫ ЖЁСТКОГО ДИСКА ВИДЕОРЕГИСТРАТОРА QCM-08DL
Видеорегистратор (сокращённо DVR) QCM-08DL применяется в системах видеонаблюдения и позволяет производить восьмиканальную запись видео и аудио. Данная модель – одна из самых дешёвых и надёжных в эксплуатации. Форматом сжатия видео является популярный формат H264. Для аудио применяется формат сжатия ADPCM. Видео и аудио записываются на стандартный компьютерный SATA жёсткий диск (HDD), устанавливаемый во внутрь DVR. С помощью самого DVR имеется возможность просматривать записи, производя их поиск по дате и времени. Также, имеется возможность извлекать данные в файл на внешний носитель. Во-первых – на USB накопитель, который подключается к USB интерфейсу DVR. Во-вторых – на компьютер через WEB-интерфейс DVR. Имя получающегося файла длинное, и в него входит дата записи, время начала и конца, канал записи и прочая дополнительная информация. Расширение файла – «.264». Исследование содержимого такого файла дало мне понять, что медиа контейнер, в который запакованы аудио и видео потоки, далеко не стандартный. Такой файл можно открыть с помощью плеера, который прилагается вместе с видеорегистратором. Плеер очень неудобный. Но также, можно воспользоваться программой-перепаковщиком в контейнер AVI, которая также прилагается. Данная программа перепаковывает видеопоток, оставляя его в формате H264. А звуковой поток преобразует из ADMCM в PCM, увеличивая его в 4 раза по размеру. В итоге получается .avi файл, воспроизводимый любым стандартным плеером. Отмечу сразу, что данная программа-перепаковщик весьма неудобная. Она позволяет совершать операции только над одним файлом. Для перепаковки множества файлом приходиться открывать их по очереди.
Были поставлены следующие задачи.
1. Получить с жёсткого диска видеорегистратора доступ ко всем файлам .264, подключив жёсткий диск к компьютеру.
2. Изучить алгоритм, по которому работает штатная программа-перепаковщик 264-avi и создать такую же программу, которая выполняла бы те же операции, но уже не над одним, а над целой группой файлов, причём одним нажатием.
Первая задача, на первый взгляд, может показаться очень простой: нужно просто подключить HDD к компьютеру и открыть разделы в проводнике. Однако здесь имеются свои подводные камни. Данная статья посвящена именно первой задаче.
Я уже заранее знал, что программная оболочка микроконтроллера видеорегистратора основана на операционной системе, подобной Linux. Поэтому, разметка жёсткого диска также будет Linux-подобной. Следовательно, потребуется компьютер с ОС Linux. В моём случае ёмкость HDD – 1TB, компьютер с ОС Xubuntu. Подключив HDD к компьютеру, мне удалось увидеть всего один раздел на несколько гигабайт. Это явно не то, что нужно. Внутри раздела находится множество папок формата имени «YYYY-MM-DD», соответствующие датам записей. Внутри каждой папки – множество файлов, соответствующие записям. Файлы одноимённые с теми, которые получаются при извлечении с DVR. Однако, их размер в разы меньше и расширение не .264, а .nvr. Стоит предположить, что эти самые файлы nvr являются ключами для соответствующих файлов 264 (или их медиа потоков), содержимое которых находится на основном пространстве HDD. Данные папки с файлами я скопировал на отдельный носитель для дальнейшего исследования.
Не долго думая, я приступил к исследованию HDD. Для исследования использовал множество программных инструментов: дисковый редактор (он же и файловый бинарный редактор) DiskExplorer, MS Excel для вспомогательных расчётов и фиксации результатов, среда программирования Dev-C++ для написания вспомогательных и окончательных консольных программ и прочее.
Сначала посмотрим на самый первый сектор HDD (один сектор (1 LBA) занимает 512 Байт). Данный сектор, как правило, содержит MBR структуру. В неё входит загрузчик и базовое оглавление разделов. Структура этого сектора, а также, структура описания раздела, приведены ниже (взято из Википедии).
В случае с исследуемым HDD имеем следующее. Глядя на рисунок ниже и руководствуясь таблицами выше, мы видим, что загрузчик отсутствует. Это вполне логично, ибо диск не содержит ОС. Но нас интересует больше таблица разделов. Она выделена в красную рамку. Последние два байта (синяя заливка) – сигнатура MBR. Из таблицы разделов видно, диск поделён на два раздела. Код типа первого раздела (жёлтая заливка) – 0x08. Это раздел FAT32-Ex. Код типа второго (оранжевая заливка) – 0x83. Это один из разделов Linux. Байты кода типа раздела обведены в синюю рамку.
Полная расшифровка сектора MBR с таблицей разделов и их параметрами приведена ниже.
Обращая внимание на размеры разделов (пересчитывая число секторов в гигабайты), несложно догадаться, что на компьютере с ОС Xubuntu отображался именно первый раздел, занимающий незначительную часть дискового пространства. Кстати говоря, в Windows XP также отобразился только первый раздел, но из проводника не открылся. Стало быть, тип раздела 0x08 (FAT-32-Ex) Windows XP воспринимает некорректно. А почему же тогда второй раздел Linux (EXT2) не отобразился в ОС Xubuntu?
Изучив структуру и организацию файловой системы EXT2, я приступил к исследованию второго раздела.
Как видно из таблицы разделов, второй раздел начинается с сектора 16016805. Руководство по файловой системе EXT2 свидетельствует о наличии так называемого суперблока, которых располагается в 1024 байтах от начала раздела (то есть в двух секторах от начала). Однако сектор 16016805+2=16016807 оказался пустым. Зато первый сектор 16016805 по своей структуре напоминал суперблок. Но его содержимое полностью не соответствовало описанию содержимого суперблока из руководства. Суперблок – это основной блок, в котором содержится своеобразная таблица различных констант и параметров для функционирования файловой системы: адреса положений и размеры других необходимых блоков, в частности, заголовков файловых записей и директорий. Дальнейшие исследования этого раздела привели меня только к одному выводу: DVR использует свою уникальную файловую систему.
В дальнейшем решил взглянуть на первый сектор первого раздела (сектор 63) и пролистать вниз. Было обнаружено на секторе 65 (двумя секторами ниже) содержимое, полностью похожее на содержимое суперблока ФС EXT2, которое описано в руководстве. Дальнейшие исследования привели к выводу, что первым разделом HDD DVR является раздел EXT2, который и отображался в ОС Xubuntu, невзирая на ошибочную метку 0x08 в оглавлении раздела! Таким образом, первый раздел жёсткого диска видеорегистратора – раздел EXT2, на котором записаны файлы nvr, являющиеся ключами к требуемым видеозаписям.
Напишу кратко о структуре файлов .264, которые я также предварительно исследовал. Данная информация в дальнейшем будет необходима для исследования второго раздела HDD. Как и в любом медиа контейнере, в «264» присутствует заголовок со служебной информацией и медиа тегами, а также потоки аудио и видео, которые следуют небольшими блоками один за другим. По смещению 0x84 байта от начала файла прописано ключевое слово «MDVR96NT_2_R». Перед этим словом расположены байты, относящиеся к дате и времени записи. Но эта информация содержится в имени файла, поэтому, особого внимания она здесь не заслуживает. После идёт множество байтов нулей. Основная информация с аудио и видео потоками берёт начало по смещению 65536 байт. Блоки видеопотока начинаются с 8-байтового заголовка «01dcH264». Следующие за ним 4 байта описывают размер текущего блока видеопотока в байтах. Через 4 байта нулей (00 00 00 00) начинается сам блок видеопотока. Блоки аудиопотоков имеют заголовок «03wb» (хотя, по моим наблюдениям, первый символ заголовка в некоторых случаях был необязательно «0»). После – 12 байт информации, которую я пока не разгадал. А начиная с 17-ого байта – аудиопоток фиксированной длины 160 байт. Какие-либо метки в конце файла отсутствуют.
Приступим к исследованию структуры файлов и каталогов, расположенных на первом разделе HDD. Как уже говорилось выше, содержимое раздела было скопировано на отдельный носитель через обычный проводник в ОС Xununtu. В каждом каталоге (директории), помимо файлов nvr содерджится один бинарный файл с именем «file_list». Судя по имени, в нём содержится информация о списке файлов в текущем каталоге. Откроем этот файл в бинарном редакторе (см. рис. ниже). Я исследовал структуру данного файла, и здесь нет в принципе ничего интересного. Файл не имеет никакой информации, касающейся расположения искомых медиа потоков. Тем не менее, кратко напишу о данной структуре. Первые 32 байта – заголовок с какими-то константами. Следующие 16 байт имеют отношение к дате и времени и количеству файлов в текущем каталоге. Далее следуют 48 байт констант. Далее – 8 байт констант, свидетельствующих о начале файловой записи. Далее – 96 байт, указывающие полный путь к файлу nvr, включая его имя. Далее – 24 байта, относящиеся к времени (число секунд, прошедших от начала суток, начала и конца видеозаписи) и прочим атрибутам видеозаписи. И так далее, по аналогии, для всех файлов nvr в текущем каталоге. Их число равняется числу видеозаписей за текущие сутки, на которые указывает имя текущего каталога.
Перейдём к изучению структуры самих файлов nvr. Вид одного такого файла в бинарном (точнее, в 16-ричном) редакторе приведён на рисунке ниже. Не вдаваясь в подробности описания структуры содержимого (часть которой так и осталась для меня загадкой), выделим самые основные параметры, которые и являются искомым ключом. Это 32-битные (4-байтное) значения, располагающиеся через каждые 32 байта, начиная с байта по смещению 40. На рисунке они выделены красным прямоугольником. В дальнейшем я убедился, что этого вполне достаточно для ключа к видеозаписям. Напоминаю, что 4 байта значения этого ключевого параметра располагаются от младшего к старшему, но не наоборот! В приведённом на рисунке примере изображён первый nvr файл первого каталога. Он соответствует первой видеозаписи, сделанной видеорегистратором. Очевидно, что значения параметров, которые я назвал ключевыми, в приведённом примере образуют последовательность целых чисел, начиная с нуля и идущие по порядку по возрастанию. Исследуя другие nvr файлы, и просматривая в них именно эти указанные байты, были также замечены целые числа, идущие по возрастанию. Но данная последовательность начиналась естественно уже не с нуля, и в некоторых случаях местами наблюдались пропуски по одному или два числа. Например: 435, 436, 438, 439, 442,…, или в 16-ричном виде: B3010000, B4010000, B6010000, B7010000, BA010000,….
Такая последовательность с пропусками приходилась на nvr файлы, соответствующие видеозаписям, которые DVR записывал одновременно с двух и более каналов. То есть, например, если последовательность «435, 436, 438, 439, 442,…» относится к видеозаписи с одного канала, то пропущенные значения (437, 440, 441) будут относиться к видеозаписи с другого канала, которая осуществлялась в тот же момент времени. В этом я сам убедился, просмотрев и сравнив соответствующие nvr файлы. Не остаётся и сомнений, что приведённые выше числа образуют номера каких-то частей, имеющих отношение к видеозаписям. Остаётся только разгадать связь между этими числами и координатами дискового пространства, на котором размещены данные.
Также, предстояло выяснить, какие именно данные делятся на вышесказанные нумерованные сегменты? Первый вариант – данными являются потоки аудио и видео, которые в контейнере 264 представлены короткими блоками, причём, как было сказано, блоки видеопотока имеют разный размер. При этом DVR на этапе извлечения видеозаписи на внешний носитель собирает эти потоки и упаковывает в контейнер 264. Второй вариант – потоки аудио и видео DVR упаковывает в контейнер 264 в начале и во время видеозахвата. И при этом на HDD записываются уже сформированные данные файла .264, который бы получился в результате его извлечения на внешний носитель. Исследуя пространство HDD где-то в середине второго раздела, наряду с байтами потоков аудио и видео и с их заголовками того же вида, что и в контейнере 264, мне также попадались и заголовки самого контейнера: MDVR96NT_2_R.
После данного заголовка также присутствовало множество байтов нулей. В целом, исследование показало, что имеет место второй вариант из двух вышеприведённых. Поэтому, для получения нужного файла .264, вероятнее всего, нужно просто соединить вместе все сегменты, номера которых содержатся в соответствующем файле nvr.
Приступим к поиску зависимости между номером сегмента и координатами на HDD.
Начало данных контейнера 264, соответствующего самой первой видеозаписи (там, где нумерация сегментов начинается с нуля) я нашёл на секторе 16046629 (29824 сектора от начала раздела). Можно сделать предположение о параметре начального смещения, который будет участвовать в формуле, описывающей искомую зависимость.
Теперь возьмём два nvr файла, соответствующие видеозаписям с разных каналов, которые DVR захватывал одновременно. Для этого взглянем на имена файлов. Например, видеозаписи, на которые указывают файлы «ch00000000000001-150330-160937-161035-02p101000000.nvr» и «ch00000000000004-150330-160000-163000-00p004000000.nvr» велись одновременно. Первая запись – запись с 1-ого канала с 16:09:37 по 16:10:35 времени. Вторая запись – запись с 4-ого канала с 16:00:00 по 16:30:00 времени. Обе записи сделаны 30.03.2015 г. На временной шкале, очевидно, временной интервал первой записи является подмножеством временного интервала второй записи. Принимаю во внимание также тот факт, что в меньшем интервале времени (в пересечении двух интервалов) DVR не осуществлял видеозахват ни с одного из остальных 6-ти каналов. Просмотрим содержимое этих nvr файлов. Убедимся, что отсутствующие те самые числа (номера сегментов) во втором длинном файле обязательно присутствуют в первом коротком файле, целиком и полностью. С помощью DVR требуется заранее извлечь хотя бы один из файлов .264, на которые ссылаются исследуемые файлы nvr. Допустим, извлекли «ch00000000000001-150330-160937-161035-02p101000000.264». Откроем его в бинарном редакторе. Как уже было сказано, в начале данного файла до ключевого слова «MDVR96NT_2_R» присутствуют уникальные байты, соответствующие дате и времени видеозаписи, содержащейся в данном файле. Списываем все эти байты, начиная от ненулевого и кончая заголовком (чем короче цепочка байт, уникальная для данной видеозаписи, тем лучше). Также, записываем смещение этой цепочки байт от начала файла. Следует обратить особое внимание, что в начале извлечённого файла .264 присутствуют лишние 4 байта нулей. Это стало заметно, сравнивая первые 512 байт файла .264 и сектор дискового пространства, с которого начинаются данные содержимого одного из файлов .264 (файл любой ФС всегда начинается в начале сектора). То есть, информация в файле .264 сдвинута заранее на 4 байта вправо. Размер (в байтах) любого файла .264 кратен 512 только после предварительного вычитания числа 4 из размера. Приступим к поиску сектора, с которого начинается исследуемый файл .264. В дисковом редакторе запускаем функцию поиска. В поле искомого значения вписываем уникальную цепочку байт, списанную заранее. Для ускорения поиска вписываем в поле «искать по смещению» значение смещения, предварительно вычитая 4. Запускаем поиск. Через несколько часов поиск завершился удачно. Записываем номер сектора, в котором найден уникальный заголовок. Пусть это будет значение s. Смотрим содержимое файла nvr для этой видеозаписи. Списываем номер первого сегмента (4 байта по смещению 40). Пусть это будет значение b. Итого, пока у нас известны номер сектора диска (16046629) для нулевого номера сегмента (в самой первой видеозаписи) и номер найденного сектора диска s для только что списанного номера сегмента b. Можно вычислить предполагаемый размер сегмента: (s-16046629)/(b-0). Вычислив, получил значение 128. Таким образом, размер сегмента равен 128 дисковым секторам (LBA), или 128*512=65536 байт!
От начала сектора s выделим область на диске, размером, сравнимым с размером файла .264, который начинается с данного сектора. В выделенную область попадут сегменты другого файла .264, который захватывался на HDD одновременно с первым. Сохраним эту область в файл (создадим образ). Порежем получившийся образ на файлы по 65536 байт (размер сегмента). Это можно сделать с помощью функции «Разбить файл» в Total Commander. Пусть это будут куски M1, M2, M3,…. Точно также порежем исследуемый файл .264, но убрав предварительно 4 байта нулей вначале. Пусть это будут куски K1, K2, K3,…. С помощью функции «Сравнить по содержимому» в Total Commander сравним по очереди куски образа и куски от файла .264. (M1 с K1, M2 с K2 и т.д.), руководствуясь номерами сегментов из соответствующего файла nvr. При этом получается следующее. Допустим, цепочка чисел в nvr следующая: 435, 436, 438, 439, 442,… При таком раскладе M1=K1, M2=K2, M4=K3, M5=K4, M8=K5,…. То есть, кусочки, на которые разбивался файл-образ и файл .264 оказываются равными между собой, учитывая соответствующее опережение по номерам кусков файла-образа, согласно пропускам чисел в последовательности.
Итого, мы получили предполагаемую зависимость: S=16046629+128*d, где d – номер сегмента в файле nvr, а S – номер сектора на HDD, начиная от самого начала диска, с которого начинаются данные содержимого сегмента. Размер сегмента – 128 секторов. Приведённая выше формула не берёт во внимание существование второго раздела. Зависимость найдена только для конкретного примера с HDD на 1TB. Возможно, если поставить в DVR HDD другой ёмкости, константы примут иной вид.
Чтобы убедиться в справедливости формулы, вычислим позицию первого сегмента какого-либо другого произвольного файла .264, руководствуясь соответствующим файлом nvr. Обращая внимание на дату и время в имени файла, сравним их с первыми байтами в заголовке .264, находящемся на вычисленном секторе. Байты, кодирующие по отдельности число, месяц, год, часы, минуты, секунды, соответствуют временным данным в названии файла. Подсчитаем в файле nvr, соответствующем извлечённому заранее файлу .264, количество сегментов cs. Вообще, их число равно cs = sf/32-1, где sf – размер файла nvr. Если файл .264 состоит из cs сегментов, то его размер должен быть равен cs*65536+4 (число сегментов, умноженное на размер сегмента в байтах, плюс 4 тех самых байта нулей). И это действительно так.
Всё-таки, попытаемся исследовать второй раздел. Как уже отмечалось ранее, нечто похожее на суперблок находится прямо в первом секторе раздела (16016805). А его точная копия была обнаружена семью секторами ниже (16016812). Очевидно, ненулевая основная информация находится в первом секторе суперблока. Его вид в дисковом редакторе приведён на рисунке ниже.
Часть 4-байтных параметров я сумел расшифровать. Голубым цветом выделены дата и время монтирования раздела. Дата и время представлены в специальной нотации «Unix time» (число секунд, прошедших с полуночи 1 января 1970 года). В приведённом примере «03 7E 74 54» (десятичное значение 1416920579) соответствует «Tue, 25 Nov 2014 13:02:59 GMT». Для перевода значений я пользовался специальным онлайн калькулятором. В фиолетовой рамке обведено значение 65536. Возможно, именно на эту позицию суперблока ссылается интерпретатор файловой системы внутри программы DVR, когда рассчитывается размер блока (в предыдущем контексте я называл блоки сегментами). В зелёную рамку выделено значение 1. Одно из них наверняка обозначает положение начала битовой карты (в количествах блоков от начала раздела). Действительно, заранее было обнаружено начало битовой карты на секторе 16016933 (16016805+128*1). Каждый бит битовой карты характеризует занятость соответствующего блока. В красную рамку выделено значение 233. Это как раз и есть позиция начала данных видеозаписей .264 от начала раздела: 16016805+128*233=16046629.
То есть, второй раздел можно назвать урезанным и немного видоизменённым разделом EXT2. В нём есть суперблок, его копия, битовая карта. Но отсутствуют т. н. информационные узлы, соответствующие файловым записям. Раздел содержит данные файлов .264 (аудио и видео потоки), но информационные узлы для этих данных размещены в nvr файлах на первом разделе.
За пару часов была создана небольшая программа. Она сканирует все файлы nvr, скопированные заранее на раздел 1TB нового HDD. Анализируя их, программа создаёт файл .264 с тем же именем в том же каталоге, используя обращение к секторам оригинального HDD. На старом компьютере с процессором Pentium 4 и PCI контроллером SATA программа успешно переложила до конца заполненный HDD несколькими тысячами файлов .264 в среднем за 7 часов. |
| Категория: Компьютеры | Добавил: RV3EEQ (27.01.2016)
|
| Просмотров: 3121
|
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ] |
