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

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

Журнал изменений хранится в файле \$Extend\$UsrJrnl. Обычно этому файлу не выделяется одна из зарезервированных записей MFT, и он обладает двумя атрибутами $DATA. Первый атрибут с именем $Мах содержит базовую информацию о журнале. Второй атрибут с именем $J содержит сам журнал в виде списка записей переменного размера. Каждая запись содержит имя файла, время изменения и тип изменения. Длина записи зависит от длины имени файла. Каждая запись обладает 64-разрядным порядковым номером обновления, или USN (Update Sequence Number). Номера USN используются для индексирования записей в журнале и хранятся в атрибуте $STANDARD_INFORMATION модифицированного файла. USN соответствует смещению внутри журнала в байтах, что позволяет легко найти запись по USN (потому что все записи имеют разные размеры). Запись не содержит информации о том, какие данные изменились; указывается только тип изменений.

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

Факторы анализа

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

Общая картина

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

Создание файла

В этом примере создается файл \dirl\filel.dat; предполагается, что каталог dirl уже существует в корневом каталоге. Размер файла составляет 4000 байт, а размер кластера равен 2048 байт.

1. Создание файла начинается с чтения первого сектора файловой системы и обработки загрузочного сектора для определения размера кластера, начального адреса MFT и размера записи MFT.

2. Мы читаем из MFT первую запись (файл $MFT) и обрабатываем ее для определения структуры остальных записей MFT. Информация хранится в атрибуте $DATA.

3. Для нового файла выделяется запись MFT. Чтобы найти неиспользуемую запись, мы обрабатываем атрибут $В1ТМАР файла $MFT. Первая свободная запись (304) выделяется новому файлу, а соответствующий бит карты устанавливается в 1.

4. Происходит инициализация записи MFT 304, для чего мы находим запись в MFT и стираем ее содержимое. В записи создаются атрибуты $STAN-DARD_INFORMATION и $FILE_NAME, а временные штампы инициализируются текущим временем. В заголовке записи MFT устанавливается флаг использования.

5. Далее для файла необходимо выделить два кластера; при этом используется атрибут $DATA файла $Bitmap, находящийся в записи MFT 6. Два смежных кластера, 692 и 693, находятся с использованием алгоритма оптимального подбора. Соответствующие биты карты для кластеров устанавливаются равными 1. В кластеры записывается содержимое файла, и атрибут $DATA обновляется адресами кластеров. В записи MFT обновляются временные штампы.

6. На следующем шаге создается информация об имени файла. Информация dirl ищется в корневом каталоге, находящемся в записи MFT 5. Мы читаем атрибуты $INDEX_R00T и $INDEX_ALL0CATI0N и перемещаемся по отсортированному дереву. После обнаружения индексного элемента dirl из него берется адрес записи MFT 200. Обновляется время последнего обращения к каталогу.

7. Обработка атрибута $INDEX_R00T записи MFT 200 дает местонахождение файла filel.dat. Для файла создается новый индексный элемент, и все дерево сортируется заново. Это может привести к перемещению индексных элементов внутри узла. У нового индексного элемента в поле базового адреса указана запись MFT 304, а временные штампы и флаги заданы соответствующим образом. Для каталога обновляется время последней модификации и обращения.

8. Каждый из перечисленных этапов может сопровождаться созданием записей в журнале файловой системы $LogFile и журнале изменений \$Extend\$UsrJrnl. Если в системе поддерживаются квоты, новый размер файла включается в квоту пользователя в файле \$Extend\$Quota.

Связи между компонентами и итоговое состояние системы показаны на рис. 12.13.

Рис. 12.13. Состояние системы после создания файла \dirl\filel.dat

Пример удаления файла

Теперь посмотрим, что происходит при удалении файла \dirl\filel.dat.

1. Удаление файла начинается с чтения первого сектора файловой системы и обработки загрузочного сектора для определения размера кластера, начального адреса MFT и размера записи MFT.

2. Мы читаем из MFT первую запись (файл $MFT) и обрабатываем ее для определения структуры остальных записей MFT. Информация хранится в атрибуте $ DATA.

3. Далее необходимо найти каталог dirl, поэтому мы обрабатываем запись MFT корневого каталога (5) и перемещаемся по индексу в атрибутах $INDEX_R00T и $INDEX_ALLOCATION. Из обнаруженного элемента dirl берется адрес записи MFT 200. Обновляется время последнего обращения к каталогу.

4. Мы обрабатываем атрибут $INDEX_R00T записи MFT 200 и ищем в нем элемент filel.dat. Выясняется, что адрес MFT файла соответствует записи 304.

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

6. Запись MFT 304 освобождается сбросом флага использования. Также обрабатывается атрибут $DATA файла $Bitmap, и в нем обнуляется бит данной записи.

7. Обрабатываются нерезидентные атрибуты записи MFT 304; соответствующие кластеры переводятся в свободное состояние в битовой карте файла \$Bitmap. В нашем примере освобождаются кластеры 692 и 693.

8. Каждый из перечисленных этапов может сопровождаться созданием записей в журнале файловой системы $LogFile и журнале изменений \$Extend\$UsrJrnl. Если в системе поддерживаются квоты, новый размер файла вычитается из квоты пользователя в файле \$Extend\$Quota.

Итоговое состояние показано на рис. 12.14. Обратите внимание: при удалении файла в NTFS Windows не стирает указатели. Таким образом, связь между записью MFT и кластером сохраняется, а связь между именем файла и записью MFT тоже продолжала бы существовать, если бы запись не была потеряна в результате пересортировки.

Рис. 12.14. Состояние системы после удаления файла \dirl\filel.dat. Серым цветом помечены освобождающиеся блоки

Разное

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

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

Восстановить удаленный файл в NTFS проще, чем в большинстве файловых систем. При удалении файла его имя исключается из индекса родительского каталога, освобождается его запись MFT и занимаемые им кластеры. Компонент Microsoft не стирает содержимое указателей, хотя исключать такую возможность в будущих версиях Windows нельзя.

У NTFS есть один большой недостаток: при исключении имени файла из индекса родительского каталога индекс сортируется заново, и информация об имени может быть потеряна. В этом случае имя удаленного файла пропадает из исходного каталога. Тем не менее недостаток отчасти компенсируется тем, что все записи MFT хранятся в одной таблице, что упрощает поиск всех свободных записей. Кроме того, каждая запись содержит атрибут $FILE_NAME с базовым адресом родительского каталога. А это означает, что при нахождении свободной записи обычно удается определить ее полный путь, если только записи ее родительских каталогов не были повторно выделены новым файлам или каталогам.

Другое обстоятельство, которое необходимо учитывать при восстановлении удаленных файлов в NTFS - поиск дополнительных атрибутов $DATA. Для тестирования программ восстановления файлов в NTFS можно воспользоваться тестовыми образами с сайта DFTT [Carrier 2004]. Образ содержит удаленные файлы с несколькими атрибутами $DATA, на которые не ссылается ни один индексный элемент.

Чтобы восстановить все удаленные файлы в NTFS, необходимо провести в MFT поиск свободных записей. После обнаружения свободной записи имя определяется по атрибуту $FILE_NAME и адресу родительского каталога. Указатели на кластеры продолжают существовать, и если данные еще не были перезаписаны, их удастся восстановить. Восстановление возможно даже при сильной фрагментации файла. Если значение атрибута было резидентным, данные не будут перезаписаны вплоть до повторного выделения записи MFT. Если для хранения атрибутов файла требуется более одной записи MFT, для полного восстановления могут потребоваться другие записи. В Windows для записей MFT используется алгоритм выделения первой доступной записи, поэтому записи MFT с малыми номерами выделяются чаще, чем записи с большими номерами.

При восстановлении файлов или просмотре удаленного содержимого могут пригодиться данные журнала файловой системы или журнала изменений. Журнал изменений не всегда активен, но в нем можно найти информацию о времени удаления и последнего редактирования файла.

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

Проверки целостности применяются в расследованиях для идентификации поврежденных образов или выявления фактов постороннего вмешательства. В этом разделе рассматриваются некоторые проверки, выполняемые с образами файловой системы NTFS. Первая проверка относится к загрузочному сектору. Загрузочный сектор NTFS содержит мало данных, но компания Microsoft требует, чтобы некоторые неиспользуемые значения были обязательно равны нулю. Я обнаружил, что после загрузочного кода в файле $Boot часто следует большое количество неиспользуемых кластеров. Как и в других файловых системах, кластеры, помеченные как поврежденные в файле $BadClus, необходимо перепроверять, потому что многие жесткие диски заменяют поврежденные кластеры еще до того, как они будут распознаны файловой системой.

Файл $MFT, содержащий саму таблицу MFT, в системе Windows только увеличивается в размерах. Квалифицированный злоумышленник может попытаться сделать эту таблицу очень большой и скрыть данные в ее конце, но он рискует потерять данные при создании новых файлов. Первые 16 записей MFT зарезервированы, некоторые из них не используются в настоящее время. Зарезервированные, но неиспользуемые структуры метаданных традиционно использовались в других файловых системах для сокрытия данных; то же может произойти в NTFS.

Каждый выделенный кластер должен входить в серию кластеров. Каждый выделенный кластер NTFS является частью файла или каталога, и проверка целостности должна подтвердить этот факт. У каждой выделенной записи MFT должны быть установлены флаг использования и соответствующий бит атрибута $В1ТМАР. Кроме того, у каждой выделенной записи MFT для каждого имени файла должен существовать элемент в индексе каталога. Даже файлы метаданных файловой системы должны быть представлены именами в своих родительских каталогах.

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

Итоги

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

На момент написания книги система NTFS занимала доминирующее положение в семействе Windows. Домашние пользователи устанавливают ХР и форматируют свои диски в NTFS вместо FAT. Некоторые аспекты NTFS упрощают работу эксперта: прежде всего это простота восстановления удаленных файлов и возможность реконструкции событий на базе журналов (если они включены).

С другой стороны, из-за общей сложности системы эксперту труднее объяснить, где именно были найдены улики.

Библиография

• Carrier, Brian. «NTFS Keyword Search Test #1». Digital Forensic Tool Testing, October 2003. http://dftt.sourceforge.net

• Carrier, Brian. «NTFS Undelete (and leap year) Test #1». Digital Forensic Tool Testing, February 2003. http://dftt.sourceforge.net

• Microsoft. «Recovering NTFS Boot Sector on NTFS Partitions». Knowledge Base Article 153973,2003. http://support.microsoft.com/default.aspx?scid=kb;EN-US;ql53973

• Microsoft MSDN Library. «FILETIME». 2004. http://msdn.microsoft.com/Library/ en-us/sysinfo/base/filetime_str.asp.

Также см. раздел «Библиография» главы 11.

Журналы файловых систем | Криминалистический анализ файловых систем | Структуры данных ntfs


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



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

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