Видеорегистратор, лобовое столкновение и восстановление данных

Третьего дня обратился к нам в лабораторию мужчина с довольно любопытной проблемой. Произошел у него на дороге неприятный инцидент – ехал он по одной из улиц нашего замечательного города, был легкий снежок и уже стемнело (примерно половина седьмого вечера), скоростной режим соблюдал неукоснительно, в общем – ехал спокойно и аккуратно. И тут ему в лоб въезжает маленькая машинка Daewoo Matizz (мужчина ехал на Nissan Patrol). Естественно, лобовое столкновение – даже для большой машины – это серьезный ущерб. Так еще и владелец матиза в несознанку ударился – мол, ничего не знаю, это ты на мою встречку выехал и там меня ударил, плати ущерб!

На счастье, у нашего героя в автомобиле стоит видеорегистратор. Замечу – весьма удобное устройство, которое обязательно нужно поставить каждому автолюбителю в нашем городе. Да что там – в стране! Позволяет однозначно определить, кто виноват в ДТП. Был у нас случай, когда такое же ДТП, но уже со смертельным исходом, случилось около торгового центра VEFA – так это наш специалист данные из неисправного регистратора вытащил и было доказано, что виновник – владелец мерседеса черного цвета, который не только вылетел на встречку и ударил машину, так еще и несся со скоростью не меньше 120 км в час по городу, да еще и ночью.
Но мы отвлеклись. Видеорегистратор то есть, а вот данные в нем куда-то исчезли. Как оказалось, запись с регистратора была видна при первоначальном просмотре, но не проигрывалась. Естественно, хозяин регистратора решил, что наиболее надежный вариант просмотреть запись – это перенести ее на компьютер. И при подключении карты памяти к машине система затребовала провести проверку (checkdisk). Тут мы следуем лирическое отступление.
Чекдиск (checkdisk) – это штатная программа Windows для проверки и исправления ошибок файловой системы. Алгоритм ее работы довольно примитивен, и именно поэтому она представляет огромную опасность для данных. Программа проверяет файловую систему (таблицы расположения файлов – file allocation table, главную файловую таблицу – master file table, и другие структуры) на предмет целостности, и если обнаруживает какие-то ошибки, то их исправляет. И вот в методах исправления и кроется засада. Программа просто «отрезает» невалидные (по ее оценке) записи, а невалидные файлы в виде полных кластеров (т.е., как правило, больше, чем файл был) помещает в особые папки. Эти файлы программа обычно переименовывает, после чего понять, что было в первоначальном файле, уже нельзя, и каждый файл приходится просматривать отдельно. Если вам нужны ваши данные, и, если система предлагает проверку файловой системы – сначала скопируйте все важные данные на другой диск, и уже после этого разрешайте системе провести проверку. Иначе может случиться то же самое, что случилось с нашим видеорегистратором.
А случилось вот что. В ходе проверки программа обнаружила, что один из видеофайлов (по закону подлости, именно тот, который нужен) не финализирован, и запись о нем была из файловых таблиц удалена. Тут следует объяснить, что карты памяти обычно используют файловую систему FAT32, в которой удаление из файловых таблиц данных о файле означает, что найти файл на диске уже не получится, и восстанавливать его требуется вручную. Чем мы и занялись.
Задача оказалась нетривиальной, так как на видеорегистраторе, очевидно, никогда не производилось форматирование карты памяти, кроме самого первого раза, когда эта карта вставлялась в регистратор. Чем больше данных записывалось на карту памяти, тем больше они становились фрагментированными: файлы делились на куски, стирались (ведь регистратор ведет непрерывную запись «по кругу»), снова записывались кусками, которые снова стирались, и так – многие сотни циклов. Нам удалось обнаружить на карте памяти куски видеоизображений, записанные больше года назад – при этом регистратор ведет запись с качеством full HD, и 1 минута записи занимает от 140 до 160 Мбайт, т.е. полностью карта памяти (32 Гбайт) должна перезаписываться примерно за 3 часа. Однако отдельные фрагменты поверхности не использовались (за счет сильной фрагментации и некомпенсированных ошибок файловой системы), что приводило к еще большей фрагментации файлов. Результатом стало то, что средний размер фрагмента файла на карте памяти составил около 20 Мбайт.
Что это значит на практике? Представьте себе, что у вас имеется запись видеорегистратора, которая вам необходима как воздух. Эта запись – одна минута. 160 Мбайт. Система разделила ее на фрагменты по 20 Мбайт, т.е. на 8 фрагментов. В файловых таблицах содержится информация о каждом фрагменте, то есть при исправной файловой системе, содержащей корректные данные о файле, фрагменты будут считаны в правильном порядке и файл будет работать. А теперь представьте ситуацию, когда записи о файле удалены. Сам файл на диске имеется, но надежно идентифицировать можно только первый его фрагмент, у которого есть заголовок. Все остальные фрагменты заголовков не имеют, они расположены на диске в неизвестных нам местах, но для того, чтобы файл заработал, нам нужно найти их все и соединить в правильном порядке.
И на диске емкостью 32 Гбайт таких 20-мегабайтных фрагментов будет около 1600. Вы представляете себе количество возможных комбинаций?
Как же нам достать данные? Мы пошли самым оптимальным путем. Поскольку чекдиск удалил записи о тех данных, которые нам нужны, следовательно, он же пометил в файловой системе места, где потенциально могут храниться эти данные, как свободные. Мы создали карту секторов на диске, в которых, согласно файловой системе, нет данных (карта свободных секторов) и сделали ее образ. Оказалось уже не так много – 2 Гбайт с небольшим для анализа. После этого в полученном образе мы произвели поиск всех заголовков видеофайлов и нашли несколько штук с нужным нам таймштампом (видеорегистратор рисует на картинке время и дату, их называют таймштамп и их можно посмотреть). После того, как был найден первый фрагмент с интересующей нас датой и временем (заголовок файла), мы проанализировали содержащуюся в заголовке информацию (так называемый индекс видеофайла), и уже по этой информации произвели подбор фрагментов из имеющегося у нас в наличии образа. Индекс очень важен, он предоставляет информацию о раскадровке файла, без него видео не будет работать, и по нему можно узнать, сколько в целом кадров должно быть в видеопотоке, как они расположены, их тайминг (т.е. переменные времени); если в наши руки попали заголовок и индекс файла, то мы соберем остальные фрагменты без каких-либо сомнений по этим сведениям. Дело в том, что каждый видеофайл уникален, он содержит строго определенный набор кадров, расположенный со строго определенными значениями таймингов и в строго определенном порядке. Совмещая кадры, мы получаем целостную картину. Вот так и происходит сборка файла =).
В итоге нам удалось собрать файл с ДТП, так нужный нашему клиенту. Daewoo Matiz решил, что у него больше прав на дороге, чем у других участников движения, и пересек двойную сплошную линию, ударив нашего клиента в лоб. Как результат – серьезные повреждения автомобиля, но теперь, благодаря специалистам компании «КомпМастер», виновнику ДТП уже не уйти от ответственности.

 

-5%