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


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

Общие сведения
В UFS1 и UFS2 используются те же структуры данных имен файлов, что и в ExtX, поэтому в этом разделе я лишь в общих чертах обрисую ключевые концепции, описанные в одноименном разделе главы 14. В структуре данных записи каталога хранится имя файла, адрес индексного узла и значение типа. Длина структуры определяется длиной имени, максимальная длина которой равна 255 символам. Имя хранится в кодировке ASCII и завершается нуль-символом, хотя имена ExtX не завершаются нулями.

Структуры записей каталогов находятся в блоках, выделенных каталогам. Каталог отличается от обычного файла лишь тем, что в поле режима для них указывается тип каталога. Первые две записи любого каталога всегда соответствуют записям «.» и «..». В каждой записи каталога хранится длина, по которой определяется начало следующей записи, а длина последней записи ссылается на конец блока. При удалении файла длина предыдущей записи увеличивается таким образом, чтобы она ссылалась на запись после скрываемой. За подробностями обращайтесь к главе 14. Корневой каталог всегда находится в индексном узле 2. В главе 17 приведено подробное описание структуры данных каталога и пример из образа файловой системы. Далее приводится результат выполнения программы fls для тестового образа файловой системы, описанного в следующей главе.

# fl

s -f openbsd

1 -a openbsd.dd 1921

d/d

1921:


d/d

2:


г/г

1932:

filei.txt

г/г

1933:

file8.txt

г/г

1934:

file7.txt

г/-

* 1935:

file6.txt

[...

]



Строка с пометкой «*» соответствует удаленному файлу. В первом столбце указана информация о типе файла, взятая из записи каталога и из индексного узла. Мы видим, что UFS стирает тип файла из индексного узла, потому что у удаленного файла данные о типе в индексном узле отсутствуют.
В UFS поддерживаются как жесткие, так и мягкие ссылки, позволяющие определять дополнительные имена для файлов и каталогов. Жесткая ссылка представляет собой альтернативное имя для файла или каталога, находящегося в той же файловой системе. При создании жесткой ссылки создается новая запись каталога, которая ссылается на индексный узел исходного файла. Счетчик ссылок в индексном узле увеличивается, что отражает появление нового имени. Мягкие ссылки создаются в виде символических ссылок, которые содержат путь к целевому файлу либо во фрагменте, либо в 60 байтах, обычно используемых для указателей на блоки. В UFS используются 64-разрядные указатели вместо 32-раз- рядных, поэтому пространство для хранения пути увеличивается до 120 байт. Иллюстрации с жесткими и мягкими ссылками были приведены в главе 14.
Помните, что каталоги в UNIX используются и для хранения имен файлов, и как точки монтирования других файловых систем. В главе 14 описана ситуация, при которой существующий файл становится невидимым в каталоге, потому что там смонтирован другой том. Многие системы семейства BSD поддерживают режим объединяющего монтирования (хотя он и не активизируется по умолчанию), при котором содержимое каталога, используемого в качестве точки монтирования, остается видимым. ОС объединяет файлы из каталога монтирования и корневого каталога монтируемого тома так, что они выглядят как единое целое.

Алгоритмы выделения
В BSD и Solaris для каталогов применяется стратегия выделения первой доступной записи. ОС перебирает записи каталогов и сравнивает указанную длину записи с фактической, то есть реально необходимой для хранения имени файла соот
ветствующей длины. Если указанная длина больше и информация о новом файле помещается в неиспользуемом «хвосте», запись каталогов создается в этом месте. При выделении записи каталогов заполняются нулями. Структуры записей каталогов не пересекают границы блоков.
При удалении файла указанная длина предыдущей записи увеличивается так, чтобы она ссылалась на начало следующей записи за удаленным файлом. В отличие от Solaris, системы BSD не стирают тип файла или поля индексного узла. Это означает, что в BSD можно получить информацию о временных штампах для удаленного файла, но прямые указатели на блоки, скорее всего, окажутся стертыми. Другие операционные системы могут использовать другие методы со стиранием имени.
Методы анализа
Анализ данных в категории имен файлов направлен на получение списка файлов и подкаталогов в заданном файле, с поиском закономерностей и конкретных имен. Для этой цели обычно требуется сначала найти корневой каталог. Он всегда находится в индексном узле 2, и это обстоятельство позволяет использовать при поиске его содержимого приемы, описанные ранее в разделе «Категория метаданных». После того как содержимое каталога будет найдено, оно обрабатывается как список записей каталогов.
При обработке содержимого каталога следующая запись находится по указателю, хранящемуся в текущей записи. Поиск удаленных записей основан на проверке пространства от конца имени файла в выделенной записи и до начала следующей записи. Если в этом пространстве удается обнаружить данные в формате записи каталога, вероятно, они остались от удаленных файлов. После обнаружения удаленного файла или каталога, представляющего интерес, можно получить о нем дополнительную информацию — для этого следует определить адрес соответствующего индексного узла и обработать его. Многие программы решают эту задачу автоматически и выводят временные штампы вместе с информацией об имени. В главе 14 приведена иллюстрация и описан сценарий с определением последовательности удаления файлов.
При удалении каталогов связь между индексным узлом и блоками обычно разрывается. Если потребуется найти содержимое удаленного каталога, попробуйте найти записи «.» и «..». Записи каталогов не могут пересекать границы блоков, поэтому каждый блок должен начинаться с новой записи.
Факторы анализа
Архитектура записей каталогов и ее реализация в большинстве систем позволяет легко находить имена удаленных файлов, а тот факт, что поле индексного узла не стирается в системах BSD, позволяет также найти метаданные файлов. Solaris стирает содержимое этого поля, поэтому найти дополнительные данные не удастся. Впрочем, даже если вы обнаружите удаленную запись каталога с сохранившимся значением индексного узла, будет непросто определить, не соответствует ли содержимое индексного узла прежнему файлу, или индексный узел был выделен заново, и его содержимое теперь соответствует другому файлу. Можно прове
сти простейшую проверку и определить, свободен ли индексный узел в настоящий момент. Если он используется, значит, индексный узел был выделен заново, или же файл был перемещен в пределах файловой системы, и вы анализируете его исходный индексный узел. Многие ОС стирают поле режима в индексных узлах UFS, что не позволяет сравнить тип файла с типом, указанным в записи каталога.
Структуры записей каталогов могут содержать скрытые данные — пространство между последней записью каталога и концом блока не используется системой. Однако эта методика сокрытия данных весьма рискованна, потому что ОС может стереть данные при создании нового имени файла.
<< | >>
Источник: Кэрриэ Б.. Криминалистический анализ файловых систем. 2007

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

  1. Категория данных имен файлов
  2. Категория имен файлов
  3. Категория имен файлов
  4. Категория данных файловой системы
  5. Категория данных файловой системы
  6. Категория данных файловой системы
  7. Записи каталогов для длинных имен файлов
  8. Категория файловой системы
  9. Категории данных
  10. Методы анализа и категории данных
  11. Категория прикладных данных
  12. Категория данных содержимого
  13. Категория прикладных данных
  14. Категория прикладных данных
  15. Категория данных