Категория метаданных

  Категория метаданных объединяет все данные с описаниями других данных. Например, к ней принадлежит время последнего обращения и адреса блоков данных, выделенных файлу. Лишь немногие программы выделяют анализ метаданных как отдельную операцию; чаще он объединяется с анализом категории имени файла. Однако в книге я буду различать их, чтобы показать, откуда поступают данные и почему некоторые удаленные файлы невозможно восстановить.
Многие структуры метаданных хранятся в таблицах фиксированной или динамической длины; каждой записи таблицы назначается адрес. При удалении файла его запись метаданных переводится в свободное состояние, и ОС может стереть часть содержащейся в ней информации.
Анализ в категории метаданных проводится с целью получения дополнительной информации о конкретном файле или поиске файла, удовлетворяющего некоторому критерию. Обычно в этой категории присутствует больше вспомогательных данных, чем в других категориях. Например, время последнего обращения или записи может оказаться неточным, или ОС может не соблюдать права доступа к файлу; следовательно, эксперт не может сделать вывод относительно того, имел ли пользователь доступ к файлу для чтения. Для поддержки заключений, касающихся вспомогательных данных этой категории, необходимы дополнительные доказательства.
Общая информация
Данный раздел посвящен основным концепциям категории метаданных. В частности, мы рассмотрим новую схему адресации, резервное пространство, восстановление удаленных файлов, сжатие и шифрование.
Логическая адресация файлов
Ранее я упоминал о логических адресах файловой системы, назначаемых блокам данных. Блок данных, выделенный файлу, также обладает логическим адресом файла, который отсчитывается от начала файла, которому выделен данный блок. Например, если файлу выделены два блока данных, то первому блоку назначается логический адрес файла 0, а второму — логический адрес файла 1. Для формирования уникального логического адреса файла необходимо задействовать имя или адрес метаданных файла. Пример показан на рис. 8.8, дополняющем предыдущий пример. На рисунке изображены два файла с пятью выделенными блоками данных. Обратите внимание: логический адрес файловой системы 1 не выделен файлу, поэтому он не имеет логического адреса файла.

Резервное пространство
Резервное пространство (slack space) — один из модных терминов цифровой экспертизы, который наверняка приходилось слышать читателю. Резервное пространство возникает в ситуации, когда размер файла не кратен размеру блока данных. Система обязана выделить файлу полный блок данных, даже если реально задействована будет лишь малая его часть; неиспользуемые байты в последнем блоке данных называются резервным пространством. Например, если размер файла составляет 100 байт, система должна выделить ему полный блок данных размером 2048 байт, а последние 1948 байт попадают в резервное пространство.
Почему резервное пространство представляет интерес для эксперта? Потому что компьютеры «ленивы». Некоторые из них не стирают содержимое неиспользуемых байтов, и резервное пространство содержит данные, оставшиеся от предыдущих файлов или содержимого памяти. Вследствие архитектуры, используемой в большинстве компьютеров, в резервном пространстве имеется две интересные области. Первая находится между концом файла и концом сектора, в котором этот файл заканчивается. Вторая состоит из секторов, не содержащих данных файлов. Наличие этих двух областей объясняется тем, что жесткие диски имеют блочную структуру, а запись в них может осуществляться только фрагментами, кратными 512 байт (размер сектора). В предыдущем примере ОС не может записать на диск только 100 байт, она должна записать все 512 байт. По этой причине 100 байт приходится дополнять 412 байтами данных. Представьте, что вы покупаете товар в магазине, в котором имеются коробки только одного размера; чем меньше товар, тем больше упаковочного материала придется положить в коробку, чтобы она была полной.
Первая область резервного пространства интересна тем, что способ заполнения неиспользуемой части сектора определяется операционной системой. Наиболее очевидный метод заключается в заполнении сектора нулями, что и происходит в большинстве ОС. Некоторые старые ОС (а именно, DOS и ранние версии Windows) заполняли остаток сектора данными из памяти. Эта область резервного пространства называлась резервом RAM [NTI, 2004], а теперь она обычно заполняется нулями. Резервное пространство с содержимым памяти может содержать пароли и другие данные, не предназначенные для записи на диск.

Вторая область резервного пространства складывается из секторов, оставшихся неиспользованными в блоке данных. Одни ОС стирают содержимое таких секторов, другие игнорируют их. Во втором случае секторы будут содержать данные того файла, которому ранее принадлежал данный сектор.
Рассмотрим файловую систему NTFS с 2048-байтовым кластером и 512-байтовым сектором. Файл состоит из 612 байт, поэтому он использует весь первый сектор и 100 байт второго сектора в кластере. Оставшиеся 412 байт второго сектора заполняются данными по усмотрению ОС. Третий и четвертый секторы ОС может заполнить нулями, а может и оставить в них данные из удаленного файла. Это показано на рис. 8.9: серым цветом помечено содержимое файла, а белым — резервное пространство.
Кластер 4910
Сектор 1 Сектор 2 Сектор 3 Сектор 4 Рис. 8.9. Резервное пространство 612-байтового файла с 2048-байтовым кластером
При описании резервного пространства часто приводится аналогия с видеомагнитофоном [Kruse, 2003]. Представьте, что вы ночью записываете 60-минутный эпизод нового сериала. Вы смотрите записанную программу и перематываете ленту в начало. Позднее на ленту записывается 30-минутная программа. После записи лента «выделяется» под 30-минутную программу, однако в конце остаются еще 30 минут от предыдущей передачи.
Все файловые системы содержат резервное пространство, потому что дисковое пространство выделяется многобайтовыми фрагментами, а не отдельными байтами. Резервное пространство представляет интерес для аналитика не из-за файловой системы, а из-за ОС и тех данных, которые она записывает. Важно заметить, что резервное пространство относится к выделенным данным. Оно может содержать остатки ранее удаленного файла, но его память выделена некоторому файлу. Если извлечь содержимое свободных блоков данных файловой системы, в него не войдет содержимое резервного пространства.
Восстановление файлов по метаданным
В некоторых ситуациях улики приходится искать в удаленных файлах. Существует два основных способа восстановления удаленных файлов: на уровне метаданных и на прикладном уровне. Методы анализа прикладного уровня рассматриваются в конце главы, а сейчас мы обсудим восстановление на уровне метаданных. Восстановление по метаданным работает только в том случае, если метаданные удаленного файла еще существуют. Если метаданные были стерты или их структура была выделена новому файлу, придется использовать методы прикладного уровня.

После того как структура метаданных файла будет найдена, восстановление проходит просто. Фактически оно не отличается от чтения содержимого существующего файла. В примере на рис. 8.10 (А) в записи метаданных удаленного файла остались адреса блоков данных, что позволяет легко прочитать его содержимое. На рис. 8.10 (В) показан пример, в котором ОС стерла адреса после удаления
файла. Практические методы восстановления будут рассмотрены далее, в главах с описаниями конкретных файловых систем.
А)
Запись метаданных 67



9 009

10 003


Блок


Блок



Блок


Блок

данных


данных



данных


данных

9 009


10 003



9 009


10 003

Рис. 8.10. Два сценария: (А) — указатели на данные не были стерты при освобождении записи, (В) — указатели на данные потеряны


При восстановлении файлов по метаданным необходима осторожность, потому что структуры метаданных и блоки данных могут быть десинхронизированы из-за того, что блоки были выделены новым файлам. Рассмотрим пример на рис. 8.10. Содержимое блока данных 9009 будет перезаписано, если этот блок будет выделен записи метаданных 70 — несмотря на то, что запись 67 продолжает ссылаться на него. При попытке восстановить содержимое метаданных 67 мы получим данные из файла, использующего запись метаданных 70.
Связь между блоком данных и метаданными напоминает связь постояльца с номером отеля, в котором он остановился. После того как постоялец уедет, в книгах может остаться запись о том, что он останавливался в номере 427, однако к текущему обитателю комнаты он уже не имеет никакого отношения.
При восстановлении удаленных файлов иногда бывает трудно выявить факт повторного выделения блока данных. Чтобы причина стала более понятной, рассмотрим серию выделений и удалений. Запись метаданных 100 выделяет блок данных 1000 и сохраняет в нем данные. Затем файл, связанный с записью метаданных 100, удаляется; запись 100 и блок данных 1000 освобождаются. В записи метаданных 200 создается новый файл, которому также выделяется блок данных 1000. Позднее и этот файл удаляется. Проанализировав систему, мы обнаружим в ней две свободные записи метаданных с одинаковыми адресами блока данных (рис. 8.11 (А».
Даже если удастся определить, что запись 200 выделила блок данных позднее записи 100, мы не знаем, была ли она последней в цепочке выделений. Допустим, запись 300 выделила блок данных 1000 после того, как он был освобожден записью 200. После этого файл был удален. Возникает ситуация, показанная на рис. 8.11 (В): три свободные записи метаданных ссылаются на один адрес блока данных.
Затем в системе создается новый файл, которому выделяется запись 300 с новым блоком данных 2000. Если проанализировать систему в этом состоянии, мы не найдем никаких доказательств, что запись 300 когда-то была связана с блоком данных 1000, хотя содержимое блока данных относится именно к записи 300. Мы узнаем лишь то, что блок выделялся записям 100 и 200 (рис. 8.11 (С)).

А)              В)

Рис. 8.11. Последовательность состояний при выделении и освобождении блоков данных: в состоянии (С) неясно, к какой записи метаданных относятся данные в блоке 1000


Этот пример показывает, что, даже если свободная структура метаданных по- прежнему содержит адрес блока данных, очень трудно определить, относится ли содержимое блока к этому файлу или другому, созданному после освобождения структуры метаданных. Чтобы проверить правильность восстановления, можно попытаться открыть файл в том приложении, в котором (по вашим предположениям) он был создан. Если новый файл занял один из блоков удаленного файла и записал в него свои данные, скорее всего, внутренняя структура файла будет повреждена и открыть его не удастся.
Многие программы предоставляют функции восстановления файлов. К сожалению, информация о процедурах, используемых для восстановления при отсутствии метаданных, практически не публикуется, поэтому вы должны протестировать и сравнить программы из своего инструментария. В этом вам помогут тестовые образы на сайте DFIT (Digital Forensic Tool Testing).
Сжатые и разреженные файлы
Некоторые файловые системы позволяют хранить данные в сжатом формате, чтобы они занимали меньше места на диске. Сжатие файлов может происходить как минимум на трех уровнях. На самом высоком уровне данные сжимаются в файловом формате. В качестве примера можно привести файлы JPEG: данные графического изображения хранятся в сжатом виде, а заголовок файла — нет. На следующем уровне внешняя программа сжимает все содержимое файла и создает новый файл[4]. Перед использованием сжатый файл необходимо распаковать в другой файл.

Последний и самый низкий уровень сжатия — сжатие данных на уровне файловой системы. В этом случае приложение, записывающее данные, не знает, что файл будет храниться в сжатом виде. В файловых системах используются два стандартных метода сжатия. Наиболее очевидное решение — применение к блокам данных стандартных алгоритмов сжатия, используемых для файлов. Во втором методе файловая система не выделяет физический блок данных, который должен быть заполнен одними нулями. Файлы, в которых пропускаются блоки данных, заполненные одними нулями, называются разреженными файлами; пример показан на рис. 8.12. Существует несколько способов реализации разреженных файлов. Например, UFS (Unix File System) записывает 0 в поле, в котором обычно хранится адрес блока. Ни одному файлу не может быть выделен блок 0; ОС знает, что ноль означает блок, заполненный одними нулями.
Сжатые файлы затрудняют процесс анализа, потому что программа анализа должна поддерживать тот же алгоритм сжатия. Кроме того, некоторые формы поиска по ключевым словам и восстановления файлов теряют эффективность, потому что они просматривают сжатые данные вместо исходных.
Содержимое файла 2938270192837              0000000000000              0081927314514
Сохраненные данные 2938270192837              0081927314514
Рис. 8.12. Файл хранится в сжатом формате: блоки данных, заполненные одними нулями, не записываются на диск
<< | >>
Источник: Кэрриэ Б.. Криминалистический анализ файловых систем. 2007

Еще по теме Категория метаданных:

  1. Категория метаданных
  2. Категория метаданных
  3. Категория метаданных
  4. Категория метаданных
  5. Файлы метаданных файловой системы
  6. КАТЕГОРИИ ПРАКТИКИ И КАТЕГОРИИ АНАЛИЗА
  7. Категория имен файлов
  8. Категория данных файловой системы
  9. Категории данных
  10. Категория прикладных данных
  11. Методы анализа и категории данных
  12. 2.6. КАТЕГОРИИ КУЛЬТУРЫ