Итак, мы разобрались с тем, как выполняется анализ данных этой категории. Теперь давайте посмотрим, как пользователь может усложнить вашу задачу. Многие программы надежного удаления информации, работающие в категории данных содержимого, заполняют нулями или случайными значениями все неиспользуемые или выделяемые файлу блоки данных.

Надежное удаление получает все более широкое распространение и становится стандартной функцией в некоторых операционных системах. Средства надежного удаления, интегрированные в ОС, наиболее эффективны. Работа сторонних приложений часто зависит от определенных аспектов поведения ОС, что может повлиять на их эффективность. Скажем, много лет назад существовала программа для Ыпих, которая заполняла нули в блоки данных перед их освобождением, однако ОС откладывала запись. Позднее ОС замечала, что блок данных свободен, и вообще не записывала нули на диск. Кроме того, многие программы предполагают, что при записи данных в существующий файл ОС будет использовать те же блоки данных. Однако ОС также может выделить новые блоки данных, и в этом случае содержимое файла останется на диске.

Подтвердить применение программ надежного удаления в этой категории нелегко. Разумеется, если все свободные блоки данных содержат нули или случайные данные, логично предположить, что это работа программы надежного удаления. Если программа записывает случайные данные или копирует содержимое других блоков данных, без доказательств применения программы на прикладном уровне обнаружить ее применение практически невозможно. Конечно, если в системе найдется программа надежного удаления, вы можете определить, использовалась ли она, и проверить время последнего обращения. Если повезет, вам также удастся найти временные копии файла.

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

Категория метаданных объединяет все данные с описаниями других данных. Например, к ней принадлежит время последнего обращения и адреса блоков данных, выделенных файлу. Лишь немногие программы выделяют анализ метаданных как отдельную операцию; чаще он объединяется с анализом категории имени файла. Однако в книге я буду различать их, чтобы показать, откуда поступают данные и почему некоторые удаленные файлы невозможно восстановить.

Многие структуры метаданных хранятся в таблицах фиксированной или динамической длины; каждой записи таблицы назначается адрес. При удалении файла его запись метаданных переводится в свободное состояние, и ОС может стереть часть содержащейся в ней информации.

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

Общая информация

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

Логическая адресация файлов

Ранее я упоминал о логических адресах файловой системы, назначаемых блокам данных. Блок данных, выделенный файлу, также обладает логическим адресом файла, который отсчитывается от начала файла, которому выделен данный блок. Например, если файлу выделены два блока данных, то первому блоку назначается логический адрес файла 0, а второму - логический адрес файла 1. Для формирования уникального логического адреса файла необходимо задействовать имя или адрес метаданных файла. Пример показан на рис. 8.8, дополняющем предыдущий пример. На рисунке изображены два файла с пятью выделенными блоками данных. Обратите внимание: логический адрес файловой системы 1 не выделен файлу, поэтому он не имеет логического адреса файла.

Рис. 8.8. Проверка целостности убеждается в том, что на каждый блок данных ссылается одна и только одна запись метаданных

Резервное пространство

Резервное пространство (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).

Сжатые и разреженные файлы

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

Последний и самый низкий уровень сжатия - сжатие данных на уровне файловой системы. В этом случае приложение, записывающее данные, не знает, что файл будет храниться в сжатом виде. В файловых системах используются два стандартных метода сжатия. Наиболее очевидное решение - применение к блокам данных стандартных алгоритмов сжатия, используемых для файлов. Во втором методе файловая система не выделяет физический блок данных, который должен быть заполнен одними нулями. Файлы, в которых пропускаются блоки данных, заполненные одними нулями, называются разреженными файлами; пример показан на рис. 8.12. Существует несколько способов реализации разреженных файлов. Например, UFS (Unix File System) записывает 0 в поле, в котором обычно хранится адрес блока. Ни одному файлу не может быть выделен блок 0; ОС знает, что ноль означает блок, заполненный одними нулями.

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

Рис. 8.12. Файл хранится в сжатом формате: блоки данных, заполненные одними нулями, не записываются на диск

Шифрование файлов

Содержимое файла может храниться в зашифрованном виде для защиты от постороннего доступа. Шифрование может выполняться приложением, создавшим файл, внешним приложением, которое читает незашифрованный файл и создает зашифрованный файл1, или операционной системой при создании файла. Перед тем как записывать файл на диск, ОС шифрует его и сохраняет текст шифра в блоках данных. Информация, не относящаяся к содержимому файла (например, имя файла и время последнего обращения), обычно не шифруется. Приложение, записывающее данные, не знает, что данные хранятся в зашифрованном виде. Другой способ шифрования содержимого файлов заключается в шифровании целого тома2. В этом случае шифруются все данные файловой системы, не только содержимое файлов. Как правило, том с операционной системой не шифруется.

Шифрование данных создает проблемы при анализе, поскольку многие файлы оказываются недоступными, если эксперту неизвестен ключ шифрования или пароль. Еще хуже, если неизвестен способ шифрования. Существуют программы для подбора ключей и паролей простым перебором («атака методом грубой силы»), но если алгоритм неизвестен, они тоже оказываются неэффективными. Если зашифрованы только отдельные файлы и каталоги, иногда удается найти копии незашифрованных данных во временных файлах или свободных блоках [Casey, 2002; Wolfe, 2004].

Методы анализа

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

Поиск метаданных

Во многих случаях анализ метаданных выполняется потому, что мы нашли имя файла, ссылающееся на конкретную структуру метаданных, и хотим получить дополнительную информацию о файле. Таким образом, нужно найти запись метаданных и обработать ее. Например, при просмотре содержимого каталога мы обнаружили файл badstuff.txt и теперь хотим узнать его содержимое и дату создания. Многие программы автоматически выполняют такого рода поиск при составлении списков имен файлов в каталогах и позволяют отсортировать результаты по значениям метаданных.

Конкретная процедура поиска зависит от файловой системы, так как метаданные могут храниться в разных местах. В TSK для вывода структур метаданных используется программа istat. На рис. 8.13 изображена файловая система со структурами метаданных, обнаруженными в блоке 371. Программа читает блок данных и выводит содержимое двух записей метаданных. Одна запись представляет удаленный файл, а другая - существующий каталог.

Рис. 8.13. Процесс просмотра содержимого записи метаданных

Просмотр логических файлов

После обнаружения метаданных можно просмотреть содержимое файла; для этого следует прочитать блоки данных, выделенные файлу. Обычно это делается при поиске улик в содержимом файла. Допустим, мы определили адрес блока данных файла badstuff.txt и теперь хотим ознакомиться с его содержимым.

Этот процесс работает как в категории метаданных, так и в категории данных содержимого. На рис. 8.14 перечислены блоки данных, связанные с записями метаданных 1 и 2. Многие графические программы объединяют эту процедуру с перечислением имен файлов. Если выбрать файл, программа переходит к поиску блоков данных, указанных в метаданных файла.

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

В пакете ТБК для просмотра содержимого блоков данных, выделенных структуре метаданных, используется программа ка! При запуске с ключом -б выводится информация о резервном пространстве, а с ключом -г программа пытается восстанавливать удаленные файлы.

Рис. 8.14. Объединение информации из метаданных и блоков данных позволяет просмотреть содержимое файла

Поиск в логических файлах

Предыдущие методы подразумевают, что вам известен конкретный файл и вы хотите просмотреть его содержимое. Нередко возникает обратная задача - найти файл на основании его содержимого (например, найти все файлы, содержащие слово «ЬгепБЮБ»). В таких ситуациях применяется поиск в логических файлах. Он основан на тех же принципах, что и просмотр логических файлов, но вместо просмотра содержимого в файле ищется конкретное значение.

Своим названием этот метод сильно напоминает поиск в логической файловой системе. Действительно, эти методы очень похожи, только в данном случае поиск в блоках данных производится в порядке их использования файлами, а не в порядке их следования в томе. На рис. 8.15 изображены две записи метаданных и выделенные им блоки данных. В данном случае поиск осуществляется в блоках 2, 3, 4 и 6 как в едином наборе. Преимущество такого вида поиска перед поиском в логической файловой системе состоит в том, что он находит данные, фрагментированные по блокам данных или секторам. Допустим, мы ищем слово «ЬгепБЮБ», которое начинается в блоке данных 4 и заканчивается в блоке 6. При поиске в логической файловой системе оно найдено не будет, потому что оно не содержится в смежных блоках данных. Разновидностью этого вида поиска является поиск файла с известным хеш-кодом МБ5 или БНА-!.

Не забывайте, что логические адреса файлов присваиваются только выделенным блокам данных. Это означает, что для поиска того же значения в свободных блоках данных следует провести поиск в логическом томе. Например, поиск в логических файлах на рис. 8.15 не затронет блоки 0 и 1, поэтому необходимо провести второй поиск, который включал бы блоки 0, 1, 7, 9, 10, 11 и т. д.

Рис. 8.15. -При поиске в логическом файле просматриваются блоки данных, выделенные записи метаданных

Обязательно выясните, включает ли ваша программа анализа резервное пространство файла при поиске в логическом файле; одни программы это делают, другие - нет. Для этой цели можно воспользоваться поиском по ключевым словам в тестовых образах на сайте DFTT.

Анализ свободных метаданных

Если поиск проводится в содержимом удаленных файлов, не ограничивайтесь именами удаленных файлов из содержимого каталога. Примеры будут приведены в разделе «Категория данных имен файлов», а пока достаточно сказать, что имя удаленного файла может быть использовано заново прежде, чем его структура метаданных. Следовательно, ваши улики могут находиться в свободной записи метаданных, однако вы не увидите их, потому что эта запись не связана с именем. Многие программы анализа выводят список свободных записей метаданных для проведения поиска или просмотра. Для получения списка свободных структур данных в TSK используется программа Us.

Поиск и сортировка по атрибутам метаданных

На практике поиск файлов также нередко осуществляется по одному из их полей метаданных. Допустим, имеется система обнаружения вторжений (IDS, Intrusion Detection System) и вы хотите найти все файлы, созданные в течение ближайших двух минут с момента полученного предупреждения. А может быть, вы анализируете действия некоторого пользователя и хотите найти все файлы, в которые ему разрешена запись. В общем случае на некоторой стадии расследования может возникнуть необходимость в поиске значений метаданных. Некоторые примеры будут рассмотрены в этом разделе.

Время обращения к файлу легко изменить в любой системе, но оно часто содержит полезную информацию. Предположим, мы проверяем гипотезу, что злоумышленник получил доступ к компьютеру в 20:13 и установил в системе вредоносный код; для этого можно провести поиск всех файлов, созданных между 20:13 и 8:23. Если за этот промежуток времени не будет найдено ни одного подозрительного файла или мы найдем посторонний файл, созданный в другое время, это означает, что неверно задано время создания файла или неверна наша гипотеза (а возможно, и то и другое).

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

Некоторые программы составляют временные диаграммы файловых операций. Как правило, количество точек данных на диаграмме для каждого файла совпадает с количеством временных штампов. Например, если в метаданных хранится время последнего обращения, последней записи и последней модификации, на диаграмме создаются три точки данных. В пакете TSK для построения временных диаграмм файловых операций используется программа mactime. Пример выходных данных mactime для каталога C:\Windows:

Wed Aug 11 2004 19:31:58 34528 .а. /system32/ntio804.sys

34392 .a. /system32/ntio412.sys

[...]

Wed Aug 11 2004 19:33:27 2048 mac /bootstat.dat

1024 mac /system32/config/default.LOG 1024 mac /system32/config/software.L0G

Wed Aug 11 2004 19:33:28 262144 ma. /system32/config/SECURITY

262144 ma. /system32/config/default

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

Прежде чем пытаться увязывать временные штампы и записи журналов с разных компьютеров, необходимо понять, как файловая система хранит временные штампы. Некоторые временные штампы хранятся в формате UTC; это означает, что для определения фактического времени необходимо знать смещение часового пояса, в котором находится компьютер. Например, если я обращаюсь к файлу в 14:00 в Бостоне, штат Массачусетс, ОС зафиксирует, что обращение произошло в 19:00 в формате UTC, потому что Бостон смещен на пять часов назад по отношению к времени UTC. Когда эксперт будет анализировать файл, он должен преобразовать 19:00 к местному времени. В других файловых системах время хранится с учетом местного часового пояса, и в данном примере в них будет храниться значение 14:00. У некоторых программ также возникают проблемы с летним временем.

Еще одна стандартная задача - поиск файлов, в которые некоторому пользователю разрешена запись. Результат поиска покажет, какие файлы могли быть созданы подозреваемым (предполагается, что ОС соблюдает разрешения доступа, а подозреваемый не имеет прав администратора). Также возможно проведение поиска по идентификатору владельца. Обычно такие операции используются при расследовании действий конкретного пользователя.

Если ранее мы провели поиск в логической файловой системе и обнаружили интересные данные в одном из блоков, можно попытаться найти адрес этого блока в метаданных. Возможно, поиск покажет, какому файлу был выделен блок данных, после чего можно будет найти другие блоки данных, принадлежащие тому же файлу. Пример показан на рис. 8.16; улики были обнаружены в блоке данных 34. Поиск в метаданных показывает, что блок был выделен структуре 107 наряду с блоками данных 33 и 36. Если ОС не стирает адреса при удалении файлов, этот процесс также поможет найти освободившуюся запись метаданных. Программа іїїпсі из пакета ТБК выполнит эту работу за вас.

Рис. 8.16. Поиск в структурах метаданных позволит узнать, какой из них был выделен заданный блок данных

Порядок выделения записей метаданных

Если потребуется узнать относительный порядок выделения двух записей, воз-можно, это удастся сделать с применением стратегии выделения, используемой вашей ОС. Это сложная задача, которая к тому же сильно зависит от ОС. Записи метаданных обычно выделяются по стратегии поиска первой доступной или следующей доступной записи. Полное описание этой методики анализа выходит за рамки книги, поскольку она зависит от прикладного уровня.

Проверка целостности данных

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

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

Также следует проверить, что записям специальных типов файлов не выделяются блоки данных. Например, в некоторых файловых системах создаются специальные файлы, называемые сокетами и используемые при обмена данных между процессами. Таким файлам блоки данных не выделяются.

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

Методы надежного удаления

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

Категория имен файлов

К категории имен файлов относятся данные, благодаря которым пользователь может ссылаться на файл по имени (вместо адреса его метаданных). В минимальном варианте эта категория данных включает только имя файла и адрес его метаданных. В некоторых файловых системах к ней также причисляется информация о типе файла или временные штампы, но такая классификация не является стандартной.

Один из важных этапов анализа имен файлов - определение местонахождение корневого каталога, необходимого для поиска файла по полному имени. Например, в Windows каталог С:\ является корневым каталогом диска С:. В каждой файловой системе используется свой способ определения местонахождения корневого каталога.

Общие сведения

В этом разделе мы рассмотрим общие концепции категории имен файлов. Эта категория относительно проста; нас интересует только метод восстановления файлов по именам.

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

Как было показано при описании категории метаданных, удаленные файлы можно восстановить по метаданным. При восстановлении, основанном на именах файлов, имя удаленного файла и соответствующий ему адрес метаданных используются для восстановления содержимого файла по метаданным. Иначе говоря, вся «черная работа» выполняется на уровне метаданных, а на уровне имен файлов мы ограничиваемся идентификацией записей метаданных, используемых для восстановления.

На рис. 8.17 показаны два имени файлов и три записи метаданных. Фaйлfavo-rites.txt удален, а его имя ссылается на свободную запись метаданных. Мы можем попытаться восстановить его содержимое, используя методы восстановления по метаданным. Обратите внимание: содержимое, связанное с записью метаданных 2, тоже можно восстановить, но его имя уже утрачено. В этом разделе рассматриваются некоторые проблемы, связанные с восстановлением файлов по именам.

Рис. 8.17. Поиск в структурах метаданных позволит узнать, какой из них был выделен заданный блок данных

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

Допустим, имеется файл, в структуре имени файла которого присутствует имя fiLel.dat; структура ссылается на запись метаданных 100 (рис. 8.18 (А)). Файл был удален, а обе структуры (имени файла и метаданных) были освобождены, однако указатель в структуре имени файла не был стерт. Новый файл fiLe2.dat создается в новой структуре данных, и ему заново выделяется запись метаданных 100 (рис. 8.18 (В)). Позднее файл file2.dat также был стерт, а его структуры имени файла и метаданных освободились (рис. 8.18 (С)). Если проанализировать систему в этом состоянии, мы найдем в ней две структуры имени файла, ссылающиеся на одну запись метаданных. Неизвестно, какому файлу принадлежит содержимое, адрес которого хранится в записи метаданных 100- filel.dat или file2.dat.

Рис. 8.18. Последовательность состояний при создании и удалении файлов: в состоянии (В) две структуры имен файлов ссылаются на одну структуру метаданных. Невозможно определить, к какой из них относится содержимое файла

Чтобы ситуация стала еще более запутанной, продолжим этот пример. Файл file3.dat создается в новой записи метаданных 200 и блоке данных 1000 из предыдущего примера (рис. 8.19 (А)). Файл file3.dat удаляется, и структура имени файла передается файлу file4.dat (который нас не интересует). Затем создается файл file5.dat с записью метаданных 100 и блоком данных 1000 (рис. 8.19 (С)). Файл file5.dat тоже удаляется. Наконец, создается файл file6.dat, которому повторно выделяется та же структура имени файла, что и file5.dat, но этот файл использует новую запись метаданных 300 и новый блок данных 2000 (рис. 8.19(С)).

Рис. 8.19. Последовательность состояний при создании и удалении файлов: в состоянии (С) нарушается синхронизация некоторых указателей

Предположим, что система анализируется в этом состоянии. Мы сталкиваемся со следующими проблемами:

• На блок данных 1000 ссылаются две записи метаданных, и мы не знаем, какая из них была последней; также неизвестно, существовали ли другие записи метаданных, ссылавшиеся на нее с момента повторного выделения.

• На запись метаданных 100 ссылаются две структуры имен файлов, и мы не знаем, какая из них была последней; также неизвестно, существовали ли другие записи, ссылавшиеся на нее с момента повторного выделения. В нашем примере последним был файл file5.dat, но он более не существует.

• На запись метаданных 200 не ссылается ни одна структура имени файла, поэтому мы не можем определить имя хотя бы одного файла, которому она была выделена.

Эти проблемы могут повлиять на работу эксперта в нескольких отношениях. Представьте программу анализа, которая читает список файлов в каталоге и выводит рядом с каждым именем соответствующие временные штампы. Информация о времени и содержимом filel.dat и file2.dat будет неверной, потому что она в действительности относится к файлу file5.dat, имя которого более не существует. Значения, связанные с записью метаданных 200, не будут присутствовать в списках файлов, потому что с этой записью не связана структура имени. Именно из-за таких ситуаций я разделил категории имен файлов и метаданных; было бы неправильно считать, что между ними существует более тесная связь.

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

Методы анализа

В этом разделе рассматриваются методы анализа, применимые к данным из категории имен файлов.

Получение списка имен файлов

Категория данных имен файлов предназначена для того, чтобы ассоциировать файлы с именами. Как нетрудно предположить, одним из самых распространенных методов анализа является получение списка файлов и каталогов. Обычно это делается при поиске улик на основании имени, пути или расширения файла. Когда файл будет опознан, адрес его метаданных используется для получения дополнительной информации. У этого метода есть несколько разновидностей: например, файлы можно отсортировать по расширениям, что позволяет сгруппировать однотипные файлы.

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

Получение списка начинается с обнаружения корневого каталога файловой системы. Обычно для этого используется процесс, который был описан ранее для просмотра логических файлов в разделе «Категория метаданных». Строение корневого каталога хранится в записи метаданных, поэтому мы должны найти запись и блоки данных, выделенные для этого каталога.

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

Эта методика поддерживается большинством программ анализа, причем многие программы объединяют информацию из категории имен файлов с информацией из категории метаданных - например, чтобы в одном представлении с именами файлов выводились пометки даты и времени. На рис. 8.20 показан пример анализа: при обработке блока данных 401 были обнаружены два имени. Нас интересует файл favorites.txt; мы видим, что его метаданные находятся в записи 3. В нашей файловой системе соответствующая структура метаданных находится в блоке данных 200. Мы обрабатываем информацию из соответствующего блока данных, получая размер и адреса содержимого этого файла.

Рис. 8.20. Чтобы получить список имен файлов, мы обрабатываем содержимое каталога и извлекаем имена (а иногда и связанные с ним метаданные)

Данный метод анализа поддерживается многими программами. В пакете TSK для вывода имен существующих и удаленных файлов используется программа fis.

Поиск имен файлов

Список имен файлов удобен в том случае, если вы знаете имя искомого файла, но это не всегда так. Если полное имя файла неизвестно, можно провести поиск по известной части. Например, мы можем знать расширение файла или его имя, но без каталога. В результате поиска выводится список файлов, удовлетворяющих критерию поиска. Скажем, если в ситуации на рис. 8.20 провести поиск по расширению .txt, программа просмотрит каждую запись и выведет как badstuff.txt, так и favorites.txt. Учтите, что поиск по расширению не всегда возвращает файлы заданного типа, поскольку расширение может быть изменено для скрытия файла. Для поиска всех файлов заданного типа необходимо использовать методы прикладного уровня, анализирующие строение файла.

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

Другая разновидность поиска в этой категории -- поиск имени файла, которому была выделена заданная запись метаданных. Это может быть необходимо, если вы обнаружили улики в блоке данных, а затем нашли структуру метаданных, которой он был выделен. После обнаружения структуры метаданных среди имен файлов ищется полное имя файла, которому был выделен блок с уликами. Задача решается программой №пс! пакета ТБК.

Порядок выделения структур данных

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

Проверка целостности данных

При проверке целостности данных имен файлов эксперт убеждается в том, что все выделенные структуры имен ссылаются на выделенные структуры метаданных. В некоторых файловых системах одному файлу может быть присвоено несколько имен; как правило, эта функциональность реализуется созданием нескольких структур имен файлов с одинаковыми адресами метаданных.

Методы надежного удаления

Программы надежного удаления в этой категории стирают имя и адрес метаданных в структуре. Один из методов удаления может стирать поля структуры имени файла; в этом случае анализ покажет, что запись существует, но ее данные стали недействительными. Например, имя файла setuplog.txt будет заменено именем аЬсс^дИ.123. В некоторых ОС это решение усложняется тем, что ОС помещает новое имя в конец списка, используя стратегию поиска следующей доступной структуры.

Другая методика надежного удаления имен файлов заключается в реорганизации списка имен, при которой имя удаленного файла заменяется именем одного из существующих файлов. Этот метод гораздо сложнее первого; с другой стороны, он гораздо эффективнее в отношении сокрытия данных. Эксперт может даже не заподозрить, что с каталогом что-то не в порядке.

Категория прикладных данных

В некоторых файловых системах хранятся данные, традиционно относящиеся к прикладной категории. Эти данные не являются необходимыми для файловой системы и обычно хранятся в виде специальных данных файловой системы, а не обычных файлов, потому что такой способ более эффективен. В этом разделе рассматривается механизм журналов - один из самых распространенных механизмов прикладной категории.

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

Журналы файловой системы

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

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

Многие современные файловые системы поддерживают журналы, потому что они экономят время при загрузке больших систем. Журнальные данные относятся к категории прикладных данных, потому что файловая система может функционировать и без них. Эти данные существуют лишь для того, чтобы ускорять проверку целостности данных.

Журналы файловой системы могут пригодиться при расследованиях, хотя до настоящего времени они еще не использовались в полной мере. В журналах содержится информация о недавно происходивших событиях файловой системы, а эта информация может помочь при реконструкции недавнего инцидента. Большинство программ анализа не обрабатывает содержимое журналов файловой системы. В пакет TSK входят программы jls и jcat, выводящие содержимое некоторых журналов.

Проверка целостности данных | Криминалистический анализ файловых систем | Методы поиска на прикладном уровне


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



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

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