Резервное пространство (slack space) - один из модных терминов цифровой экспертизы, который наверняка приходилось слышать читателю. Резервное пространство возникает в ситуации, когда размер файла не кратен размеру блока данных. Система обязана выделить файлу полный блок данных, даже если реально задействована будет лишь малая его часть; неиспользуемые байты в последнем блоке данных называются резервным пространством. Например, если размер файла составляет 100 байт, система должна выделить ему полный блок данных размером 2048 байт, а последние 1948 байт попадают в резервное пространство.

Почему резервное пространство представляет интерес для эксперта? Потому что компьютеры «ленивы». Некоторые из них не стирают содержимое неиспользуемых байтов, и резервное пространство содержит данные, оставшиеся от предыдущих файлов или содержимого памяти. Вследствие архитектуры, используемой в большинстве компьютеров, в резервном пространстве имеется две интересные области. Первая находится между концом файла и концом сектора, в котором этот файл заканчивается. Вторая состоит из секторов, не содержащих данных файлов. Наличие этих двух областей объясняется тем, что жесткие диски имеют блочную структуру, а запись в них может осуществляться только фрагментами, кратными 512 байт (размер сектора). В предыдущем примере ОС не может записать на диск только 100 байт, она должна записать все 512 байт. По этой причине 100 байт приходится дополнять 412 байтами данных. Представьте, что вы покупаете товар в магазине, в котором имеются коробки только одного размера; чем меньше товар, тем больше упаковочного материала придется положить в коробку, чтобы она была полной.

Первая область резервного пространства интересна тем, что способ заполнения неиспользуемой части сектора определяется операционной системой. Наиболее очевидный метод заключается в заполнении сектора нулями, что и происходит в большинстве ОС. Некоторые старые ОС (а именно, DOS и ранние версии Windows) заполняли остаток сектора данными из памяти. Эта область резервного пространства называлась резервом RAM [NTI, 2004], а теперь она обычно заполняется нулями. Резервное пространство с содержимым памяти может содержать пароли и другие данные, не предназначенные для записи на диск.

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

Рассмотрим файловую систему NTFS с 2048-байтовым кластером и 512-байтовым сектором. Файл состоит из 612 байт, поэтому он использует весь первый сектор и 100 байт второго сектора в кластере. Оставшиеся 412 байт второго сектора заполняются данными по усмотрению ОС. Третий и четвертый секторы ОС может заполнить нулями, а может и оставить в них данные из удаленного файла. Это показано на рис. 8.9: серым цветом помечено содержимое файла, а белым - резервное пространство.

Рис. 8.9. Резервное пространство 612-байтового файла с 2048-байтовым кластером

При описании резервного пространства часто приводится аналогия с видеомагнитофоном [Kruse, 2003]. Представьте, что вы ночью записываете 60-минутный эпизод нового сериала. Вы смотрите записанную программу и перематываете ленту в начало. Позднее на ленту записывается 30-минутная программа. После записи лента «выделяется» под 30-минутную программу, однако в конце остаются еще 30 минут от предыдущей передачи.

Все файловые системы содержат резервное пространство, потому что дисковое пространство выделяется многобайтовыми фрагментами, а не отдельными байтами. Резервное пространство представляет интерес для аналитика не из-за файловой системы, а из-за ОС и тех данных, которые она записывает. Важно заметить, что резервное пространство относится к выделенным данным. Оно может содержать остатки ранее удаленного файла, но его память выделена некоторому файлу. Если извлечь содержимое свободных блоков данных файловой системы, в него не войдет содержимое резервного пространства.

Восстановление файлов по метаданным

В некоторых ситуациях улики приходится искать в удаленных файлах. Существует два основных способа восстановления удаленных файлов: на уровне метаданных и на прикладном уровне. Методы анализа прикладного уровня рассматриваются в конце главы, а сейчас мы обсудим восстановление на уровне метаданных. Восстановление по метаданным работает только в том случае, если метаданные удаленного файла еще существуют. Если метаданные были стерты или их структура была выделена новому файлу, придется использовать методы прикладного уровня.

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

Рис. 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

Этот пример показывает, что, даже если свободная структура метаданных по-прежнему содержит адрес блока данных, очень трудно определить, относится ли содержимое блока к этому файлу или другому, созданному после освобождения структуры метаданных. Чтобы проверить правильность восстановления, можно попытаться открыть файл в том приложении, в котором (по вашим предположениям) он был создан. Если новый файл занял один из блоков удаленного файла и записал в него свои данные, скорее всего, внутренняя структура файла будет повреждена и открыть его не удастся.

Многие программы предоставляют функции восстановления файлов. К сожалению, информация о процедурах, используемых для восстановления при отсутствии метаданных, практически не публикуется, поэтому вы должны протестировать и сравнить программы из своего инструментария. В этом вам помогут тестовые образы на сайте DFÏT (Digital Forensic Tool Testing).

Логическая адресация файлов | Криминалистический анализ файловых систем | Сжатые и разреженные файлы


Криминалистический анализ файловых систем



Новости за месяц

  • Март
    2020
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс