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

# istat -f openbsd -z UTC openbsd.dd 3 inode: 3 Allocated Group: 0

uid / gid: 0/0 mode: -rw-r-r-size: 1274880 num of links: 1

Inode Times:

Accessed: Tue Aug 3 14:12:56 2004

File Modified: Tue Aug 3 14:13:14 2004

Inode Modified: Tue Aug 3 14:13:14 2004

Direct Blocks:

288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 [...]

1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 Indirect Blocks:

384 385 386 387 388 389 390 391

Мы видим, что файл занимает 1 247 880 байт и для его хранения требуется более 2 8-килобайтных блоков. В нижней части листинга перечислены все фрагменты, выделенные для хранения файла. Ранее уже говорилось о том, что в индексном узле приводится только адрес блока, но istat приводит адреса всех фрагментов блока. Последняя строка секции Direct Blocks показывает, что используются только пять из восьми фрагментов блока 1576, а фрагменты 1581-1583 могут использоваться другими файлами. Также обратите внимание, что блок 384 используется для косвенной адресации, то есть содержит указатели на другие блоки.

Алгоритмы выделения

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

При выделении содержимое индексного узла стирается, а его М-, А- и С-время (а также время создания в UFS2) задаются равными текущему времени. Счетчик ссылок задается равным 1 для файлов и 2 для каталогов (с учетом записи «.» в каталоге).

При удалении файла системы BSD и Solaris стирают указатели на блоки в индексных узлах, очищают поля размера и режима. Следовательно, размер файла, его тип и местонахождение содержимого восстановить не удастся. Тем не менее содержимое блоков косвенных указателей не стирается, поэтому поиск таких блоков может оказать помощь при восстановлении. Вероятно, для поиска блоков, заполненных 32- или 64-разрядными адресами, потребуется специальная программа. Обратите внимание на различия между процедурой удаления в UFS и той, что мы видели в Linux/ExtX: в Linux поле режима не стиралось, но зато в ExtX терялось содержимое косвенных указателей.

Обновление временных штампов в OpenBSD 3, FreeBSD 5 и Sun Solaris 9 производится по тем же правилам, которые были описаны в разделе ExtX для Fedora Core 2. А именно, при создании файла все временные штампы синхронизируются с текущим временем, а у родительского каталога обновляется М- и С-время. При перемещении у нового файла обновляется С-время, но М- и А-время остается прежним. При копировании файла обновляется А-время исходного файла, а у приемного файла обновляется М-, А- и С-время. При удалении файла обновляется М- и С-время.

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

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

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

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

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

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

Расширенные атрибуты также могут содержать улики и скрытые данные, поэтому их необходимо проанализировать. Для этого следует прочитать блоки, перечисленные в индексном узле, и обработать все записи в них.

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

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

Как было показано для ExtX, команда touch позволяет изменить М- и А-время любого файла. Следовательно, желательно иметь в распоряжении второй источник информации с временными данными для проверки надежности временных штампов. С-время файла обновляется при использовании команды touch. Временные штампы хранятся в формате UTC, поэтому для правильного вывода значений программе анализа должен быть известен часовой пояс, в котором находится компьютер.

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

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

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

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

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

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

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

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

# fis -f openbsd -a openbsd.dd 1921 d/d 1921: d/d 2:

r/r 1932: filel.txt

r/r 1933: file8.txt

r/r 1934: file7.txt

r/- * 1935: file6.txt

[...]

Строка с пометкой «*» соответствует удаленному файлу. В первом столбце указана информация о типе файла, взятая из записи каталога и из индексного узла. Мы видим, что 11Р8 стирает тип файла из индексного узла, потому что у удаленного файла данные о типе в индексном узле отсутствуют.

В иР8 поддерживаются как жесткие, так и мягкие ссылки, позволяющие определять дополнительные имена для файлов и каталогов. Жесткая ссылка представляет собой альтернативное имя для файла или каталога, находящегося в той же файловой системе. При создании жесткой ссылки создается новая запись каталога, которая ссылается на индексный узел исходного файла. Счетчик ссылок в индексном узле увеличивается, что отражает появление нового имени. Мягкие ссылки создаются в виде символических ссылок, которые содержат путь к целевому файлу либо во фрагменте, либо в 60 байтах, обычно используемых для указателей на блоки. В ОТЗ используются 64-разрядные указатели вместо 32-раз-рядных, поэтому пространство для хранения пути увеличивается до 120 байт. Иллюстрации с жесткими и мягкими ссылками были приведены в главе 14.

Помните, что каталоги в 11№Х используются и для хранения имен файлов, и как точки монтирования других файловых систем. В главе 14 описана ситуация, при которой существующий файл становится невидимым в каталоге, потому что там смонтирован другой том. Многие системы семейства В8Б поддерживают режим объединяющего монтирования (хотя он и не активизируется по умолчанию), при котором содержимое каталога, используемого в качестве точки монтирования, остается видимым. ОС объединяет файлы из каталога монтирования и корневого каталога монтируемого тома так, что они выглядят как единое целое.

Алгоритмы выделения

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

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

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

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

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

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

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

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

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

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

Наше знакомство с иРБ завершается примерами создания и удаления файла /сНг 1/Аlel.dat, занимающего 25 ООО байт, в файловой системе 11Р52.

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

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

1. Создание файла начинается с чтения суперблока, который занимает 2 Кбайт и находится в файловой системе со смещением 64 Кбайт. Из суперблока мы узнаем, что размер блока равен 16 Кбайт, а размер фрагмента - 2 Кбайт. Каждая группа цилиндров содержит из 32 776 фрагментов и 8256 индексных узлов. Мы также узнаем, что дескриптор группы хранится со смещением 40 фрагментов, а таблица индексных узлов - со смещением 56 фрагментов в каждой группе цилиндров.

2. Далее необходимо обработать индексный узел 2, чтобы найти каталог dirl в корневом каталоге. Используя информацию о количестве индексных узлов в группе, мы определяем, что индексный узел 2 находится в группе цилиндров 0. Следовательно, таблица индексных узлов с информацией об узле 2 начинается в блоке 56.

3. Из блока 56 читается таблица индексных узлов, в которой обрабатывается третья запись (первая запись соответствует индексному узлу 0). Содержимое индексного узла 2 показывает, что структуры записей каталогов для корневого каталога находятся в блоке 1096.

4. Мы читаем содержимое корневого каталога из блока 1096 и обрабатываем его как список записей каталогов. Последовательно перемещаясь вперед по указанным длинам записей (удаленные файлы нас не интересуют), мы в конечном счете приходим к записи с именем d^rl. В записи указан номер индексного узла 16 549. У корневого каталога обновляется А-время.

5. Местонахождение индексного узла 16 549 определяется делением числа на количество индексных узлов в группе. Так мы определяем, что узел находится в группе цилиндров 2. Группа 2 начинается в блоке 65 552, поэтому ее таблица индексных узлов начинается в блоке 65 608 (если бы использовалась файловая система 11Р81, нам также пришлось бы вычислить базовый адрес для группы).

6. Из блока 65 608 читается таблица индексных узлов, в которой обрабатывается запись 37 - относительным номером индексного узла 16 549. Содержимое индексного узла показывает, что содержимое сИг! находится в блоке 66 816.

7. Мы читаем содержимое с11г1 из блока 66 816 и обрабатываем его как список записей каталогов. Нас интересует неиспользуемое пространство в каталоге. Имя filel.dat состоит из 8 символов, поэтому для хранения записи каталога потребуется 16 байт. Имя нового файла включается между двумя существующими именами, для каталога обновляется М- и С-время. Место, отведенное под новую запись, ранее использовалось удаленным файлом.

8. Для создаваемого файла необходимо выделить индексный узел, причем этот узел должен входить в группу своего родительского каталога, то есть в группу 2. Чтобы найти битовую карту индексных узлов, необходимо сначала найти дескриптор группы, удаленный на 48 фрагментов от начала группы. Выясняется, что дескриптор находится в блоке 65 600; из него мы узнаем, что битовая карта индексных узлов хранится в дескрипторе со смещением 168 байт. Кроме того, дескриптор сообщает, что последней была выделена запись индексного узла 16 650. Проверка состояния индексного узла 16 651 показывает, что узел свободен. Соответствующий бит в битовой карте устанавливается, номер последнего выделенного индексного узла в дескрипторе обновляется, а счетчик свободных индексных узлов в дескрипторе группы и в сводке групп цилиндров уменьшается. Адрес индексного узла заносится в запись каталога filel.dat.

9. На следующем этапе мы находим в таблице индексных узлов узел 139 (относительный адрес узла 16 651) и инициализируем его параметры. Временные штампы инициализируются текущим временем, а счетчик ссылок задается равным 1. Также заполняются поля 11ГО, вГО и режима.

10. Размер файла равен 25 000 байт, для хранения его содержимого требуется выделить один блок и пять фрагментов. Прежде всего из дескриптора группы определяется смещение битовой карты фрагментов, которая хранится со смещением 1200. В дескрипторе группы указан номер последнего выделенного блока 67 896. Мы проверяем блок 67 904 по битовой карте свободных фрагментов и определяем, что он свободен. Бит этого блока в карте обнуляется, а счетчик свободных блоков уменьшается. Также обновляется поле указателя на последний выделенный блок. Пять свободных фрагментов находятся по битовой карте (или одному из служебных списков); в нашем примере это фрагменты 74 242-74 246. Биты фрагментов обнуляются, обновляются соответствующие служебные данные. Адрес блока и начальный фрагмент включаются в индексный узел.

11. Содержимое файла filel.dat записывается в выделенный блок и фрагменты.

Рис. 16.8. Итоговое состояние системы после добавления файла dirlZfilel.dat

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

Перейдем к процедуре удаления файла /сИг1/*р1 Lel.dat с использованием методов, характерных для В8Б. Как упоминалось в предыдущем разделе, порядок освобождения структур данных зависит от ОС, и описанная далее процедура может отличаться от той, что используется в вашей конкретной системе.

1. Удаление файла начинается с чтения из суперблока структуры данных объемом 2 Кбайт, которая находится в файловой системе со смещением 64 Кбайт. Из суперблока мы узнаем, что размер блока равен 16 Кбайт, а размер фрагмента - 2 Кбайт. Каждая группа цилиндров состоит из 32 776 фрагментов и 8256 индексных узлов. Мы также узнаем, что дескриптор группы хранится со смещением 40 фрагментов, а таблица индексных узлов - со смещением 56 фрагментов в каждой группе цилиндров.

2. Далее необходимо обработать индексный узел 2, чтобы найти каталог dirl в корневом каталоге. Используя информацию о количестве индексных узлов в группе, мы определяем, что индексный узел 2 находится в группе цилиндров 0. Следовательно, таблица индексных узлов с информацией об узле 2 начинается в блоке 56.

3. Из блока 56 читается таблица индексных узлов, в которой обрабатывается третья запись (первая запись соответствует индексному узлу 0). Содержимое индексного узла 2 показывает, что структуры записей каталогов для корневого каталога находятся в блоке 1096.

4. Мы читаем содержимое корневого каталога из блока 1096 и обрабатываем его как список записей каталогов. Последовательно перемещаясь вперед по указанным длинам записей (удаленные файлы нас не интересуют), мы в конечном счете приходим к записи с именем dir 1. В записи указан номер индексного узла 16 549. У корневого каталога обновляется А-время.

5. Местонахождение индексного узла 16 549 определяется делением числа на количество индексных узлов в группе. Так мы определяем, что узел находится в группе цилиндров 2. Группа 2 начинается в блоке 65 552, поэтому ее таблица индексных узлов начинается в блоке 65 608.

6. Из блока 65 608 читается таблица индексных узлов, в которой обрабатывается запись 37 - относительным номером индексного узла 16 549, Содержимое индексного узла показывает, что содержимое dirl находится в блоке 66 816.

7. Мы читаем содержимое dirl из блока 66 816 и обрабатываем его как список записей каталогов. Нас интересует запись файла filel.dat. Мы находим эту запись и узнаем, что ей выделен индексный узел 16 651. Чтобы освободить запись каталога, ее длина прибавляется к длине предыдущей записи каталога, относящейся к файлу 12.jpg. В системе Solaris также пришлось бы стереть содержимое указателя на индексный узел. Для каталога dirl обновляется М-, А- и С-время.

8. В результате удаления имени файла счетчик ссылок в индексном узле 16 651 таблицы индексных узлов группы 2 уменьшается на 1. Значение счетчика становится равным 0; это означает, что индексный узел необходимо освободить. Для этого соответствующий разряд битовой карты индексных узлов обнуляется, а в дескрипторе группы и сводке групп цилиндров обновляются счетчики свободных индексных узлов. В индексном узле стирается поле режима.

9. Также необходимо освободить один блок и пять фрагментов, выделенных для хранения содержимого файла. Для каждого блока или фрагмента устанавливается соответствующий разряд битовой карты блоков/фрагментов и стирается указатель на блок в индексном узле. Размер файла уменьшается при каждом освобождении блока, и в конечном счете он становится равным 0. М-и С-время индексного узла обновляется в соответствии с внесенными изменениями. В дескрипторе группы и сводке групп цилиндров обновляются счетчики свободных блоков и фрагментов.

Итоговое состояние системы показано на рис. 16.9. Жирные линии и значения представляют изменения файловой системы в результате удаления.

Рис. 16.9. Итоговое состояние системы после удаления файла dirl7filel.dat

Разное

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

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

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

Во многих системах ВББ пространство выделяется 64- или 128-килобайтны-ми участками из смежных блоков. Такая стратегия выделения может быть полезной, потому что смежные блоки обычно содержат больше данных, чем случайная выборка со стратегией поиска первого доступного блока. С другой стороны, этот вариант уступает стратегии оптимального подбора, при которой весь файл может быть размещен в смежных блоках. Более того, поскольку некоторые системы ограничивают количество блоков, выделяемых файлу в одной группе, большие файлы могут оказаться фрагментированными даже в том случае, если файл сохраняется в смежных блоках. БокпБ меняет группу цилиндров после выделения первых 12 блоков, поэтому с извлечением таких файлов могут возникнуть очень большие проблемы. Содержимое косвенных указателей не стирается в ВБО и 5о1апз; возможно, это поможет вам получить дополнительную информацию о восстанавливаемых данных.

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

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

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

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

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

Итоги

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

Основные трудности при анализе файловой системы UFS в стандартных ОС связаны с восстановлением удаленных файлов. Система стирает указатели на блоки, a Solaris даже уничтожает связь между именем и индексным узлом. Следовательно, для восстановления придется применить методы прикладного уровня, но процесс извлечения данных затрудняется стратегиями выделения блоков, которые пытаются предотвратить выделение группы цилиндров под хранение одного файла. Хотя структуры данных и методы удаления в файловой системе UFS заметно отличаются от FAT и NTFS, основные методы анализа остаются теми же.

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

• FreeBSD Source Code. 2004. http://fxr.watson.org/fxr/source/.

• Garfinkel, Simson, Gene Spafford, and Alan Schwartz. Practical Unix and Internet Security. 3rd ed. Sebastopol: O’Reilly, 2003.

• Mauro, Jim, and Richard McDougall. Solaris Internals: Core Kernel Architecture. Upper Saddle River: Sun Microsystems Press, 2001.

• McKusick, Marshall K. «Enhancements to the Fast File System to Support Multi-Terabyte Storage Systems». Proceedings of USENIX BSDCON ’03 Conference, September 2003.

• McKusick, Marshall, Keith Bostic, Michael Karels, and John Quarterman. The Design and Implementation of the 4.4 BSD Operating System. Boston: Addison-Wesley, 1996.

• McKusick, Marshall K., William N. Joy, Samuel J. Leffler, and Robert S. Fabry. «А Fast File System for Unix». ACM Transactions on Computer Systems 2(3): 181 - 197, August 1984.

• McKusick, Marshall, and Geroge Neville-Neil. The Design and Implementation of the FreeBSD Operating System. Boston: Addison-Wesley, 2004.

• OpenBSD Source Code. 2004. http://fxr.watson.org/fxr/source/?v=OPENBSD.

• Smith, Keith A. and Margo Seltzer.«A Comparison of FFS Disk Allocation Algorithms». Proceedings of 1996 Usenix Annual Technical Conference, 1996.

Расширенные атрибуты | Криминалистический анализ файловых систем | Структуры данных ufs1 и ufs2


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



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

  • Апрель
    2020
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31