Сценарии анализа


Дата создания файловой системы
Имеется файловая система FAT, содержащая незначительный набор файлов и каталогов. Возможно, дело в том, что файловая система мало использовалась, была недавно отформатирована или в ней присутствуют скрытые данные. Чтобы проверить вторую гипотезу, мы анализируем временные штампы записи каталога с атрибутом метки тома, находящейся в корневом каталоге. Программа выводит запись каталога как обычный файл, и мы видим, что форматирование было выполнено за две недели до снятия данных с диска. Это объясняет малое количество имен файлов, однако в системе все равно могут присутствовать скрытые данные, а также данные, оставшиеся от предыдущей файловой системы (их поиск рассматривается в следующем сценарии).
Поиск удаленных каталогов
Требуется восстановить удаленные каталоги в файловой системе FAT. Этот сценарий может встретиться как в обычной ситуации с поиском удаленных файлов, так и в случае, если файловая система FAT была недавно отформатирована и мы хотим восстановить оставшуюся информацию. В этом примере мы извлечем содержимое свободного дискового пространства и проведем поиск сигнатуры записи каталога «.», начинающей содержимое каталога.
Я сделаю это с помощью TSK, но вы можете воспользоваться любой программой, которая позволяет ограничить поиск свободным пространством и искать шестнадцатеричные сигнатуры. В TSK первая задача решается программой dls: dls -f fat fat-10.dd gt; fat-10.dls
Поиск будет проводиться по первым четырем байтам каталога, соответствующим ASCII-кодам «. » (точка с тремя пробелами). В шестнадцатеричном представлении эта сигнатура имеет вид 0х2е202020. Поиск сигнатуры в свободном пространстве осуществляется программой sigfind: sigfind -b 512 2е202020 fat-10.dls
Block size: 512 Offset: 0



Просмотрим содержимое сектора 180 образа fat-10.dls (не исходного образа файловой системы). Оно выглядит так: dd if=fat-10.dls skiр=180 count=l | xxd 0000000:              2е20              2020              2020              2020              2020              2010              0037              5daf              .
0000016:              3с23              3с23              0000              5daf              3с23              4fl9              0000              0000              lt;#lt;#..].lt;#0.
0000032:              2е2е              2020              2020              2020              2020              2010              0037              5daf              .
0000048:              3с23              3с23              0000              5daf              3с23              dcOd              0000              0000              lt;#lt;#..].lt;#..
0000064:              е549              4с45              312е              4441              5420              2020              0000              0000              .ILE1.DAT
0000080:              7521              7521              0000              0000              7521              5619              00d0              0000              u!u!              u!V.
[...]
Каждая запись каталога занимает 32 байта; в этом фрагменте представлены три записи. Первые две относятся к специальным каталогам «.» и «..». Интерпретация первых двух записей показывает, что запись «.» ссылается на кластер 6479 (0xl94f), а запись «..» ссылается на кластер 3548 (OxOddc). Третья запись относится к файлу, который начинается с кластера 6486 (0x1956) и имеет размер 53248 (OxdOOO) байт. После определения начального адреса и размера можно приступать к восстановлению файла.
Действия, выполненные в этом сценарии, показаны на рис. 9.14. Мы извлекли содержимое свободного пространства и провели поиск кластеров, начинающихся с записи каталога «.».


Образ
файловой
системы

Свободные
кластеры

Свободные кластеры с записями каталогов

Рис. 9.14. Процесс поиска удаленных каталогов по структурам записей


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

что имя файла используется в качестве адреса метаданных. Напомню, что структура данных записи каталога содержит имя файла по схеме 8.3, то есть имя файла занимает 8 символов, а расширение — 3. В этом разделе основное внимание будет уделено поддержке длинных имен файлов в FAT.
Если длина имени файла превышает восемь символов или в имени присутствуют специальные символы, в каталоге создается запись типа LFN (Long file Name). Файлы с длинными именами также имеют нормальную запись короткого имени SFN (Short File Name). Записи SFN необходимы из-за того, что записи LFN не содержат ни временных штампов, ни размера, ни начального кластера — в них хранится только имя файла. Структура данных LFN подробно рассматривается в главе 10. При освобождении записи LFN в первый байт структуры данных записывается код 0хе5.
Поле атрибутов занимает в структурах данных SFN и LFN одинаковую позицию, но в записях LFN используются специальные значения атрибутов. В остальных байтах записи хранятся 13 символов Unicode в кодировке UTF- 16, каждый символ занимает 2 байта. Если имя файла содержит более 13 символов, создаются дополнительные записи LFN. Все записи LFN в каталоге предшествуют записи SFN и содержат контрольную сумму, которая может использоваться для связывания записей LFN с записью SFN. Записи LFN следуют в обратном порядке, так что первая часть имени файла хранится ближе всего к записи SFN.
На рис. 9.15 представлен список записей каталогов в тестовом образе. В главе 10 мы займемся ручным разбором записей, а пока достаточно сказать, что в каталоге хранится информация о двух файлах, один из которых обладает длинным именем. Записи SFN предшествуют две записи LFN, содержащие символы имени My Long File Name.rtf в обратном порядке. Обратите внимание на совпадение контрольных сумм, вычисленных на основании SFN.

Атр: Файл

Имя: RESUME-1.RTF Кластер: 9

Атр:

LFN

Номер: 2 CSum: Oxdf Имя: Name.rtf

Атр:

LFN

Номер: 1 CSum: Oxdf Имя: My Long File

Атр:

Файл

Имя: MYL0NG~1.RTF Кластер: 26

Атр: Файл

Имя: _ILE6.TXT Кластер: 48

Рис. 9.15. Записи каталога из тестового образа. Каталог содержит информацию о трех файлах; один файл обладает длинным именем, и еще один был удален


Вот какие данные были получены при запуске программы fls для этого каталога тестового образа: fls              -f              fat fat-2.dd
г/г              3:              FAT DISK              (Volume              Label              Entry)
p/r              4:              RESUME-1.RTF
p/p              7:              My Long File              Name.rtf              (MYL0NG~1.RTF)
p/r *              8:              _ile.txt
В третьей строке выводится длинное имя файла, а четвертая строка представляет удаленный файл. Вспомните, что адреса метаданных назначаются в зависимости от позиции записи каталога. Промежуток между адресами RESUME-I.RTFh Му Long File Name.rtf возникает из-за записей LFN в позициях 5 и 6.

Записи LFN содержат символы Unicode, что позволяет использовать в них международные символы (тогда как кодировка ASCII ограничивается английскими символами). До появления записей LFN международному сообществу пользователей приходилось использовать кодовые страницы для включения символов национальных алфавитов в имена файлов. В ASCII из 256 возможных символов задействовано только 128. Кодовые страницы используют дополнительные 128 позиций и ассоциируют их с дополнительными символами. Помимо обычных ASCII-символов запись SFN может содержать символы из кодовой страницы. Список кодовых страниц приводится в документации Microsoft [Microsoft, 2004а].
Алгоритмы выделения
Имена файлов хранятся в тех же структурах данных, что и метаданные, поэтому для категории имен файлов используются те же алгоритмы выделения, что и в категории метаданных. Единственное различие заключается в том, что записи LFN должны следовать перед записью SFN, поэтому ОС ищет промежуток, достаточный для сохранения всех записей.
Таким образом, при использовании стратегии поиска первой доступной записи ОС будет пропускать все записи, к которым не примыкают другие свободные записи.
Процедура удаления уже рассматривалась в разделе «Категория метаданных» — а именно, первый байт записи заменяется кодом 0хе5. В записи SFN это приводит к замене первого символа имени, а в записи каталога SFN стирается ее порядковый номер. Обычно при восстановлении удаленных файлов первый символ короткого имени приходится вводить вручную, но, если у файла также имеется длинное имя, можно воспользоваться его первым символом. При удалении каталога содержащиеся в нем записи могут изменяться, а могут остаться в прежнем состоянии.
Методы анализа
Анализ в категории данных имен файлов выполняется с целью поиска конкретного имени файла. Чтобы сделать это в FAT, необходимо сначала найти корневой каталог, причем процедура поиска зависит от версии FAT. В FAT12/16 корневой каталог начинается в секторе, следующем за областью FAT, а его размер задается в загрузочном секторе. В FAT32 адрес начального кластера корневого каталога хранится в загрузочном секторе, а его строение определяется по структуре FAT.
Обработка содержимого каталога осуществляется перебором всех 32-байтовых структур записей каталогов. Если у структуры установлен атрибут записи LFN, мы сохраняем ее содержимое и переходим к следующей записи. Процесс повторяется вплоть до обнаружения записи, не являющейся записью LFN, контрольная сумма которой совпадает с записями LFN. Состояние выделения записи проверяется по первому байту.
Вероятно, после обнаружения файла или каталога, представляющего интерес, вы захотите найти его соответствующие метаданные. Благодаря FAT это очень легко, потому что все метаданные файла хранятся в записи каталога. Это означает, что синхронизация метаданных, ассоциированных с именем файла, не нарушится после удаления файла. Метаданные, ассоциированные с именем уда
ленного файла, останутся корректными вплоть до стирания (как метаданных, так и имени).
Факторы анализа
Поскольку имя файла и метаданные хранятся в одной структуре данных, для всех найденных записей удаленных файлов всегда будет известно имя. При использовании LFN восстанавливается все длинное имя, хотя часть его может быть потеряна при замене первого байта кодом 0хе5.
Как показали мои эксперименты с системой Windows ХР, программа ScanDisk для файловых систем FAT не слишком придирчива. Мне удалось создать записи LFN, не соответствующие ни одной записи SFN, и программа не посчитала это ошибкой. Это позволило сохранить небольшой объем скрытых данных, не отображаемых при выводе содержимого каталога. В зависимости от того, как проводится поиск по ключевым словам или устроена программа анализа, данные, скрытые в записях LFN, также могут остаться необнаруженными.
Как упоминалось в разделе «Категория метаданных», злоумышленник также может скрыть данные в конце каталога. Некоторые ОС прерывают обработку каталога после обнаружения записи, заполненной одними нулями, хотя после нулевой записи могут следовать скрытые данные. Впрочем, другая реализация FAT может пропустить нулевую запись и продолжить обработку до конца каталога.
Если для поиска имени файла используется механизм поиска по ключевым словам, убедитесь в том, что вы указываете Unicode-версию длинных имен файлов. Записи SFN хранятся в ASCII, но в записях LFN используется Unicode. Также следует помнить что имя может оказаться разбитым на части в нескольких записях LFN (см. сценарий в следующем разделе).
Сценарии анализа
Чтобы продемонстрировать некоторые методы анализа, я приведу в этом разделе два сценария. Один посвящен поиску файла по имени, а другой — определению относительного порядка записей каталогов.
Поиск файла по имени
Предположим, потребовалось найти в файловой системе все ссылки на файл с именем TheStuff.dat. Нас интересуют как существующие, так и удаленные экземпляры файла. Как это сделать, если в программе анализа поддерживается поиск по именам файлов?
Если провести поиск по ключевому слову в файловой системе, вероятно, нам удастся найти ссылки на искомый файл в содержимом файлов. Тем не менее сам файл останется ненайденным, потому что его имя хранится в записи LFN, а запись SFN содержит измененную версию имени. Возможны два варианта: либо провести поиск строки «THESTUFI-1DAT» в ASCII, либо изменить критерий поиска для длинного имени.
Чтобы найти длинную версию имени, необходимо разбить имя на фрагменты. Каждая запись длинного имени содержит 13 символов и делится на фрагменты из пяти, шести и двух символов. Таким образом, в Unicode наша запись длинного

имени будет разбита на фрагменты «TheSt», «uff.da» и «t». Графическое представление записей каталогов для этого файла показано на рис. 9.16.


TheSt
uff.da
t

THESTU-1
DAT


Упорядочение записей каталогов
В процессе экспертизы системы был обнаружен каталог с множеством незаконных графических изображений; требуется определить, как они попали в систему[7]. Например, были ли они загружены по отдельности, или скопированы с компакт- диска? Записи в этом каталоге следуют в алфавитном порядке, что немного странно, потому что Windows обычно не сортирует записи каталогов. Каталог не содержит свободных записей.
Относительно каталога выдвигается ряд гипотез, в том числе: он был скопирован или перемещен, а новые записи создавались в алфавитном порядке; каталог был создан в результате распаковки zip-файла, а программа распаковки создала записи в алфавитном порядке; пользователь загружал файлы в алфавитном порядке, потому что так был отсортирован список на удаленном сервере.
Чтобы проверить первую гипотезу, мы сравним время создания и последней модификации файлов. У файлов, созданных в результате копирования, время создания относится к более позднему моменту, чем время последней модификации. В нашем случае у всех файлов время создания совпадает с временем последней модификации, поэтому вариант с копированием выглядит маловероятным (при условии, что временным штампам можно доверять).
Чтобы проверить гипотезу с перемещением каталога, мы создаем систему, аналогичную исследуемой, и проводим ряд экспериментов. Мы создаем каталог с теми же именами файлов, как в проверяемом каталоге, причем файлы создаются не по алфавиту. Чтобы проверить гипотезу с перемещением, мы включаем в диспетчере файлов режим сортировки, а затем начинаем перемещать файлы посредством перетаскивания. Записи в полученном каталоге следуют почти в алфавитном порядке, но не совсем. Сортировка получается более строгой, чем в исходном каталоге, и все же не совсем. Эксперимент повторяется с другими параметрами сортировки, но добиться желаемого эффекта так и не удалось. Зато выясняется, что если бы все файлы перемещались по отдельности в порядке сортировки, то содержимое нового каталога было бы отсортированным.

Во втором сценарии мы проверяем, не были ли файлы созданы в результате распаковки zip-файла. Для проведения эксперимента создается zip-файл, содержащий анализируемые файлы, после чего его содержимое распаковывается в новый каталог. Выясняется, что файлы извлекаются из zip-архива в порядке их включения в архив. Следовательно, если файлы добавлялись в архив в алфавитном порядке, то и извлекаться они будут в том же порядке. Мы также замечаем, что у полученных файлов время создания и модификации совпадает с исходным временем последней модификации файла. Итак, у нас нет никаких улик, которые противоречили бы такому сценарию.
Последний сценарий — загрузка файлов в отсортированном порядке. Эксперимент показывает, что этот вариант возможен, но маловероятен из-за временных штампов. Время создания и модификации разных файлов иногда различается на дни и даже месяцы. Предположить, что пользователь загружал эти файлы в отсортированном порядке в течение нескольких месяцев? Такая ситуация была бы возможна, если бы файлы публиковались периодически, а их имена формировались в зависимости от даты.
После проверки всех трех сценариев можно сделать вывод, что два последних наиболее вероятны. Остается исследовать оба сценария более подробно для обнаружения доказательств (например, zip-файлов или следов продолжительной загрузки файлов). Вероятно, можно придумать и другие сценарии, которые могли привести к данной ситуации, и проверка не исчерпывает всех возможных вариантов. Наконец, результаты зависят от версий ОС и ZIP.
<< | >>
Источник: Кэрриэ Б.. Криминалистический анализ файловых систем. 2007

Еще по теме Сценарии анализа:

  1. Сценарий анализа
  2. Деловая игра.Анализ сценариев политического развития России
  3. 5.6. Метод сценариев
  4. Вопрос 66 ЧТО ТАКОЕ СЦЕНАРИЙ СТРАТЕГИЧЕСКОГО УПРАВЛЕНИЯ?
  5. 2.2.4. Использование метода «сценариев будущего» в стратегическом управлении
  6. 1.5. УПРОСТИТЕ СЦЕНАРИИ РЕШЕНИЯ ЗАДАЧ
  7. 5.3. Возможные сценарии разрешения КОНФЛИКТА
  8. ВОПРОСЫ ДЛЯ ОБСУЖДЕНИЯ НА СЕМИНАРЕ «ВЗАИМОДЕЙСТВИЕ КУЛЬТУРЫ И СЦЕНАРИЕВ ДЕЯТЕЛЬНОСТИ ЛИЧНОСТИ»
  9. Учебная игра. Сценарии развития стратификационной системы российского общества
  10. Глава 5 КУЛЬТУРНЫЕ СЦЕНАРИИ ДЕЯТЕЛЬНОСТИ
  11. Система и дисистема. Сценарии и перспективы
  12. ПРИМЕРНЫЕ СЦЕНАРИИ РОДИТЕЛЬСКИХ СОБРАНИЙ
  13. Постмодерн и сценарии развития российского общества
  14. NASA составило возможный сценарий катастрофы "шаттла" Columbia
  15. ПРИЛОЖЕНИЕ 10 Сценарий фокус-групп по проблемам жилищного контракта