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


К категории имен файлов относятся данные, связывающие имя файла с его содержимым. До настоящего момента мы рассматривали способы хранения данных и метаданных в NTFS, но сейчас необходимо разобраться, как же имя связывается с файлом.
Для упорядочения содержимого каталогов в NTFS используются индексы (см. главу 11). Индекс NTFS представляет собой набор структур данных, отсортированных по некоторому ключу. Дерево содержит один или несколько узлов, хранящихся в атрибутах $INDEX_R00T и $INDEX_ALL0CATI0N. Атрибут $INDEX_R00T всегда определяет корневой узел дерева, a $INDEX_ALL0CATI0N — индексные записи, используемые для хранения других узлов. Атрибут $В1ТМАР описывает состояние выделения индексных записей. Каждый узел дерева содержит список индексных элементов.
Индексы каталогов
KaTanorNTFS представлен обычной записью MFT, у которой установлен специальный флаг в заголовке и в атрибутах $STANDARD_IN FORMATION и $FILE_NAME. Индексные элементы в индексе каталога содержат адрес ссылки на файл и атрибут $FILE_NAME. Вспомните, что атрибут $FILE_NAME содержит имя файла, временные штампы, размер и основные флаги. Windows обновляет временные штампы и размеры, чтобы они соответствовали действительности. Если система Windows настроена на обязательное использование имени из пространства имен DOS, индекс содержит несколько атрибутов $FILE__NAME для одного файла. Атрибутам $INDEX_R00T, $IN- D ЕХ_А LL0 С ATI 0 N и $В1ТМАР присваивается одно имя $130. Эти структуры данных представлены в главе 11, а их формальные описания приводятся в главе 13.
На рис. 12.9 показана простая двухуровневая структура каталога, в которой корневой узел находится в атрибуте $INDEX_R00T, а атрибут $INDEX_ALL0CATI0N содержит две индексные записи. Элементы индексной записи 0 содержат имена, «меньшие» hhh.txt, а элементы индексной записи 1 — имена, «большие» hhh.txt Обратите внимание: файл eeeeeeeeeeee.txt не входит в пространство имен DOS, поэтому для него создается дополнительная запись.
При добавлении или удалении файла из каталога дерево реструктурируется так, чтобы данные хранились в отсортированном порядке. Это может привести к перемещению элементов в индексных записях и замене данных в удаленных файлах. У каждого узла дерева имеется поле заголовка, которое идентифицирует последний выделенный элемент. На рис. 12.9 некоторые элементы (ccc.txt в $INDEX_R00T и qqq.txt в индексной записи 1) находятся в свободном пространстве. Файл qqq.txt удален, но файл ccc.txt продолжает существовать, он находится в индексной записи 0. Чтобы понять, почему это происходит, обратитесь к разделу «Индексы» главы 11.

Корневой каталог
В любой файловой системе для поиска файла по полному пути необходимо знать местонахождение корневого каталога. Корневой каталог NTFS всегда находится в записи MFT 5; ему присваивается имя «.». Запись обладает стандартными атрибутами $INDEX_R00T, $INDEX_ALLOCATION и $В1ТМАР. В этом каталоге находятся все файлы метаданных файловой системы (хотя они и скрыты от большинства пользователей).
Ссылки на файлы и каталоги
В NTFS файлу может быть присвоено более одного имени; это происходит при создании жесткой ссылки (hard link). Жесткая ссылка не отличается от исходного имени файла, и для нее в индексе родительского каталога создается запись, которая указывает на ту же запись MFT, что и исходное имя. Счетчик ссылок в заголовке записи MFT увеличивается на 1 при создании жесткой ссылки, причем запись не освобождается до тех пор, пока ее счетчик ссылок не уменьшится до 0. Другими словами, если исходное имя файла удаляется, но жесткая ссылка продолжает существовать, файл удален не будет. Запись MFT содержат по одному атрибуту $FILE_NAME для каждого из имен своих жестких ссылок. Жесткие ссылки создаются только в пределах того же тома.
В NTFS 3.0+ появился новый механизм точек подключения (reparse points), которые могут использоваться для создания ссылок на файлы, каталоги и тома. Точка подключения представляет собой специальный файл или каталог, содержащий информацию о том объекте, на который он ссылается. Точки подключения могут связываться с файлами и каталогами, находящимися на том же томе, другом томе или на удаленном сервере. Точки подключения также могут использоваться для монтирования тома в каталог вместо буквы диска (например, Е:\). Символическая ссылка представляет собой точку подключения, связывающую два
файла; переход (junction) — точку подключения, связывающую два каталога; наконец, точка монтирования связывает каталог с томом. Механизм Windows Remote Storage Server использует точки подключения для описания местонахождения файла или каталога на сервере.
Точки подключения представляют собой специальные файлы, а в их атрибутах $STAN DA R D_I N FO RM ATIO N и $FILE_NAME устанавливаются соответствующие флаги. Кроме того, они содержат атрибут $REPARSE_POINT с информацией о местонахождении целевого файла или каталога. Структура данных атрибута $REPARSE_POINT обсуждается в главе 13.
В NTFS информация о точках подключения хранится в индексе из файла метаданных файловой системы \$Extend\$Reparse. Индекс сортируется по файловым ссылкам, но не содержит сведений о местонахождении целевых файлов.
Кроме файла $Reparse, NTFS хранит информацию о точках монтирования в атрибуте $DATA корневого каталога (запись MFT 5). Атрибут $DATA с именем $MountMgrRemoteDatabase содержит список целевых томов, на которые ссылаются точки подключения. Этот атрибут $DATA создается только в том случае, если в файловой системе существует точка монтирования.
Идентификаторы объектов
В NTFS версий 3.0+ существует дополнительный метод адресации файлов и каталогов (кроме стандартной адресации по именам каталогов/файлов или адресов записей MFT). Приложение или ОС может присвоить файлу уникальный 128- разрядный идентификатор объекта, который в дальнейшем используется для ссылок на объект даже в случае его переименования или перемещения на другой том. Продукты Microsoft используют идентификаторы объектов при внедрении файлов. Идентификатор может использоваться для ссылки на внедренный файл даже после его перемещения.
У файла или каталога, которому присваивается идентификатор объекта, создается атрибут $0BJECT_ID. Он содержит идентификатор объекта, а также может содержать дополнительную информацию об исходном домене и томе, на котором он был создан. Если потребуется найти файл по идентификатору объекта, обратитесь к индексу \$Extend\$0bjId. Индекс содержит записи для всех присвоенных идентификаторов объектов в файловой системе.
Этот метод адресации может повлиять на работу эксперта, так как может возникнуть необходимость в поиске файла по идентификатору объекта. На момент написания книги мне не известна ни одна программа, которая позволяла бы проводить поиск файлов по идентификатору объекта.
Алгоритмы выделения
Индексы NTFS строятся на базе В-деревьев; это означает, что при выделении структур данных не используются стратегии поиска первого или следующего доступного объекта. Тем не менее возможны разные варианты реализации В-деревьев в контексте добавления или удаления элементов. Основной принцип заключается в том, чтобы определить, где в дереве должен находиться файл, и попытаться добавить его. Если узел содержит слишком много записей, он разбивается надвое
с созданием нового уровня. Процесс повторяется до тех пор, пока дерево не перейдет в допустимое состояние. При удалении файла его данные удаляются из дерева, и происходит перемещение остальных элементов данного узла.
Если узел содержит слишком мало элементов, он пытается позаимствовать элементы из других узлов для сохранения сбалансированности дерева.
Небольшие каталоги состоят из одного узла, находящегося в атрибуте $IN- DEX_R00T. Если записи не помещаются в этом атрибуте, ОС перемещает их в индексную запись в атрибуте $INDEX_ALLOCATION. На этой стадии В-дерево по-прежнему содержит только один узел, a $INDEX_R00T не содержит элементов, кроме пустого элемента, ссылающегося на дочерний узел. После заполнения индексной записи выделяется вторая запись, и атрибут $1N DEX_R0ОТ используется в качестве корневого узла, дочерними узлами которого являются две индексные записи. После заполнения этих индексных записей выделяется третья, в результате чего корневой узел будет содержать три дочерних узла.
В протестированных мной системах временные штампы и размеры в атрибуте $FILE_NAME обновлялись с той же частотой, что и значения в атрибуте $STAN- DARD_INFORMATION в записи MFT файла. За дополнительной информацией обращайтесь к подразделу «Алгоритмы выделения» раздела «Категория метаданных».
Методы анализа
Анализ данных в категории имен файлов проводится с целью идентификации файлов и каталогов по именам. Процесс включает поиск каталогов, обработку их содержимого и поиск метаданных, ассоциированных с файлом.
Как было показано в этом разделе и в предыдущей главе, анализ имен файлов и индексов в NTFS является довольно сложным процессом. Он начинается с поиска корневого каталога, представленного записью MFT 5. В процессе обработки каталога мы просматриваем содержимое атрибутов $INDEX_R00T и $INDEX_ALLOCATION и обрабатываем индексные элементы. В этих атрибутах хранятся списки, называемые индексными записями и соответствующие узлам дерева. Каждая индексная запись содержит один или несколько индексных элементов. Индексные записи также могут содержать свободные индексные элементы; в заголовке записи указывается, где находится последний выделенный элемент. Состояние выделения индексных записей определяется по атрибуту $В1ТМАР каталога. Существующие файлы могут ассоциироваться не только с выделенными, но и со свободными индексными элементами, потому что каталоги хранятся в виде В-деревьев, требующих повторной сортировки при добавлении и удалении файлов.
Имя файла также может соответствовать точке подключения — ссылке или точке монтирования. Целевой объект точки подключения определяется в атрибуте $REPARSE_POINT записи MFT. Компания Microsoft определила некоторые типы точек подключения, но возможны и другие типы, специфические для конкретных приложений.
Факторы анализа
Имена файлов в свободных записях NTFS могут создавать путаницу. При добавлении и удалении файлов в каталогах дерево сортируется заново, элементы
перемещаются в другие узлы и в другие позиции внутри узла. Это приводит к тому, что информация удаленных файлов оказывается в незанятом пространстве узла дерева, а данные удаленных файлов стираются. Свободное пространство некоторых индексов может содержать несколько копий данных одного файла. Чтобы определить, был ли файл действительно удален, необходимо провести среди оставшихся индексных элементов поиск копии имени файла в выделенном пространстве.
При обнаружении имени удаленного файла NTFS предоставляет ряд преимуществ по сравнению с другими файловыми системами. Порядковый номер в ссылке показывает, происходило ли повторное выделение записи MFT после удаления файла. Если запись выделялась заново, скорее всего, ее данные относятся к другому файлу. В других файловых системах нам пришлось бы гадать, сохранилась синхронизация или нет. Другое преимущество заключается в том, что в индексе существует атрибут $FILE_NAME с полным набором временных штампов и флагов. Следовательно, даже если запись MFT была выделена заново, а данные файла были стерты, базовая информация все же остается.
При поиске удаленных файлов в каталоге программа должна проверить два возможных места. Первое — свободные области каждого узла в дереве индекса каталога, а второе — свободные записи MFT. Если имя файла было стерто из индекса, но запись MFT еще существует, мы можем определить, что файл находился в каталоге, обратившись к адресу MFT родительского каталога в атрибуте $FILE_NAME. Убедитесь в том, что ваша программа анализа проводит обе проверки при поиске удаленных файлов в каталогах.
Сценарий анализа
Ваша лаборатория собирается обновить свой инструментарий анализа файловых систем, и вам поручено протестировать новые программы. В процессе расследования вы решаете протестировать программу Digital Investigator 4000 (DI4K), а для подтверждения результатов воспользоваться программой FSAnalyzer 1000 (FSA1K), которая применялась до настоящего времени. На анализируемом компьютере с файловой системой NTFS найден каталог с многочисленными уликами. Сравнение содержимого каталога в двух программах выявляет ряд различий: Удаленный файл aaa.txt не показывается в выходных данных DI4K, но присутствует в выводе FSA1K. Две программы выводят разные временные штампы файла mmm.txt. В DI4K они относятся к более раннему моменту, чем в FSA1K. Удаленный файл www.txt показывается в выходных данных DI4K, но отсутствует в выводе FSA1K.
Для существующих файлов результаты совпадают. Чтобы разобраться в причинах происходящего, мы запускаем шестнадцатеричный редактор и начинаем разбирать индекс каталога. После ручной обработки атрибутов $INDEX_R00T и $INDEX_ALL0CATI0N выясняется, что индекс имеет структуру, показанную на рис. 12.10 (А).
Из содержимого каталога видно, отчего возникла первая проблема. Программа FSA1K вывела файл aaa.txt как удаленный, несмотря на то, что он про

должает существовать. Вероятно, свободная запись появилась после удаления другого файла и перемещения элемента aaa.txt по узлу. Более новая программа DI4K нашла существующую запись aaa.txt и не стала выводить свободную запись.
Вторая проблема относится к временным штампам файла mmm.txt. Мы видим, что индексный элемент находится в корневом узле индекса, а его метаданные хранятся в записи MFT 31, показанной на рис. 12.10 (В). Мы обрабатываем атрибут $STANDARD_INFORMATION записи MFT 31 и находим временные штампы, выведенные программой FSA1K. Просмотр временных штампов в атрибуте $FILE_NAME индексного элемента обнаруживает временные штампы, выведенные в DI4K. Чтобы узнать, какая информация была более точной, мы сравниваем порядковые номера индексного элемента и записи MFT. Выясняется, что у индексного элемента порядковый номер равен 3, а у записи MFT — 4. Следовательно, запись MFT была выделена заново после удаления файла mmm.txt, программа DI4K это заметила и вывела данные из атрибута $FILE_NAME индексного элемента.
Третья проблема относилась к новому файлу www.txt; тем не менее в индексе такого файла нет. Вспомните, что говорилось ранее о «зависании» удаленных файлов NTFS, происходящем из-за перезаписи удаленных имен в индексах. Мы ищем запись MFT для имени www.txt; для этого в логической файловой системе проводится поиск строки «www.txt» в Unicode. В результате поиска обнаруживается запись MFT 30, в которой указана запись родительского каталога 36 — запись того самого каталога, который мы анализируем. Можно сделать вывод, что новая программа DI4K не только выводит информацию о свободных элементах в индексе, но и ищет зависшие файлы.
В отчете вы документируете все найденные различия. Ни одна программа не выдает ложных данных, но вывод D14K был гораздо более точным.
<< | >>
Источник: Кэрриэ Б.. Криминалистический анализ файловых систем. 2007

Еще по теме Категория имен файлов:

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