Глава 7. Файловая система NTFS

Содержание

Глава 7. Файловая система NTFS
Структуры на диске
$Boot
Индекс
Массивы адресных привязок
Время в NTFS
Главная файловая таблица (MFT)
Структура записи MFT
Заголовок записи MFT
Атрибуты просмотра
$STANDARD_INFORMATION (0x10)
$ATTRIBUTE_LIST (0x20)
$FILENAME (0x30)
$OBJECT_ID (0x40)
$SECURITY_DESCRIPTOR (0x50)
$VOLUME_NAME (0x60)
$VOLUME_INFORMATION (0x70)
$DATA (0x80)
$INDEX_ROOT (0x90)
$INDEX_ALLOCATION (0xA0)
$BITMAP (0xB0)
$REPARSE_POINT (0xC0)
$EA_INFORMATION (0xD0) и $EA (0xE0)
Анализ NTFS
Создание файловых систем NTFS
Поддерживаемые файлы образов NTFS
Анализ NTFS вручную
Обработка $Boot
Восстановление $MFT
Обработка каталогов
Восстановление метаданных файла
Восстановление содержимого файла
Расширенный анализ NTFS
Последующие сведения файловой системы
Удалённые файлы
Фрагментированные файлы
Альтернативные потоки данных
Большие записи MFT
Выводы
Упражнения
Библиография

New Technology File System (NTFS) традиционно одна из наиболее "интересных" файловых систем с точки зрения расследования. Самая основная причина интереса к NTFS обусловлена тем, что она применяется в качестве файловой системы первичного устройства (то есть C:) во всех версиях Windows, начиная с Windows NT. Эта файловая система впервые была предложена в Windows NT 3.1 в 1993 и до наших дней всё ещё файловая система Windows по умолчанию.

Файловая система NTFS была ответвлением HPFS (High-Performance File System), файловой системы, которую Microsoft и IBM разрабатывали в партнёрстве. Следовательно, она разделяет большое число функциональных возможностей HPFS, включая значение идентификатора раздела MBR (0x07, в настоящее время также разделяемого с exFAT). Вплоть до предложения NTFS по умолчанию Windows имело место семейство файловых систем FAT. По мере роста в размерах дисков, семейство FAT предоставляло очевидные ограничения. Адресация кластеров имела лишь четыре байта (в действительности даже менее того). В NTFS адреса кластеров могут составлять до восьми байт, делая возможной адресацию большего числа кластеров, тем самым поддерживая диски большего объёма. Кроме того, NTFS была разработана чтобы гарантировать очень эффективными базовые операции (чтение/ запись файлов), что опять- таки способствует масштабировать файловые системы для систем большего размера.

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

  • Каталоги на основе B- деревьев: Хранилище каталогов в NTFS, как и в большинстве современных файловых систем, основывается на B- деревьях. Эти структуры поддерживают сортировку данных, которая очень быстрая при поиске, однако к тому же допускает эффективные вставки и удаления.

  • Альтернативные потоки данных: Alternate data streams (ADS) это название, предоставляемое в NTFS ветвлениям. Ветвления допускают связывание с названием файла более одного потока данных. Обычно ADS не перечисляются Проводником Windows при просмотре содержимого каталога. Виден лишь первичный поток данных. Инструменты расследования предоставят альтернативный поток данных дополнительно к такому первичному потоку.

    Функциональные возможности ADS изначально создавались для совместимости и ветвлением ресурсов Macintosh. Наиболее частое применение этого служит для выгружаемых файлов. Internet Explorer начал создавать Zone.Identifier ADS для всякого выгружаемого из интернета файла. Это предоставляло значение URL, с которого было выгружено данное содержимое. Что подразумевало, что прочее программное обеспечение уведомлялось о том, что данный файл получен через интернет и, возможно, ему нельзя доверять. С тех пор этому примеру последовали и другие браузеры. С точки зрения расследования, ADS может применяться для сокрытия сведений.

  • Журналирование: NTFS файловая система с ведением журнала. Этот журнал доступен через специальный системный файл ($LogFile). Журналы NTFS записывают изменения метаданных для всоей файловой системы. Применение ведения журналов превратило NTFS в более устойчивую файловую систему по сравнению с предыдущими.

  • Разряжённые файлы: Разряженный файл содержит множество пустых кластеров в своём файле. Большинство файловых систем будут хранить такие нулевые кластеры как часть общего содержимого файлов. NTFS, с другой стороны, в действительности не хранит на диске такие пустые области. Они записываются в структурах метаданных, а пространство может применяться для иных целей.

  • Сжатие: Сжатие в NTFS реализовано на уровне самой файловой системы. Папки (или файлы) могут помечаться как сжатые. Всякий перемещаемый в сжатую папку файл будет автоматически сжиматься. Сжатие достигалось при помощи алгоритма, основанного на алгоритме сжатия LZ77.

  • Шифрование: Определённые версии серверов Windows допускают шифрование файлов. Файлы шифруются при помощи ключа шифрования файлов, применяемого для симметричного шифрования. Такой симметричный ключ шифруется при помощи асимметричного шифрования с применением общедоступного ключа, хранимого в качестве альтернативного потока данных и частного ключа, доступного из подробностей пользователя зарегистрированного пользователя.

  • Списки контроля доступа: NTFS применяет дескрипторы безопасности для определения соответствующего владельца. Всякий дескриптор безопасности содержит два ACL (access control lists). Список разграничительного контроля доступа (DACL, discretionary access control list) определяет действия (чтения, запись и т.п.), которые допускаются/ запрещаются для каждого пользователя/ группы. Системный список контроля доступа (SACL, system access control list) определяет те виды деятельности, которые подлежат регистрации.

Остаток данной главы в первую очередь изучает структуры на диске NTFS (Раздел 7.1), прежде чем продолжить введением в методы базового анализа, применяемыми для файловой системы NTFS (Раздел 7.2). Этот раздел также показывает читателю как инструменты цифрового расследования восстанавливают файлы из файловых систем NTFS. Наконец, читатель будет ознакомлен с некоторыми расширенными понятиями при анализе NTFS (Раздел 7.3) такими как удаление файла, фрагментированные файлы, альтернативные потоки данных и большие записи MFT.

Структуры на диске

Файловая система NTFS состоит из ряда системных файлов, которые сведены воедино в Таблице 7.1. За единственным исключением местоположение этих файлов не определено. Они могут встречаться где угодно в своей файловой системе. Их местоположение задаётся главной файловой таблицей (MFT, Master File Table), которая отслеживает запись всех сведений о местоположении метаданных, содержимого. Единственным исключением выступает файл $Boot, который всегда находится в Секторе 0.

Таблица 7.1. Специальные файлы NTFS
MFT # Название Описание

0

$MFT

Это сама Главная файловая таблица (MFT, Master File Table), которая содержит запись для всех файлов из файловой системы NTFS. Это наиболее важная структура с точки зрения анализа расследования NTFS.

1

$MFTMirr

MFT Mirror зеркалирует самый первый кластер самой MFT.

2

$Logfile

Содержит журнал, который регистрирует изменения метаданных. В отношении предыдущих состояний данной файловой системы сведения могут быть восстановлены из $Logfile

3

$Volume

Содержит сведения тома, такие как его метку, идентификатор и версию.

4

$AttrDef

Содержит информацию об используемых в MFT атрибутах, таких как имена, идентификаторы и размеры.

5

.

Содержит корневой каталог данной файловой системы.

6

$Bitmap

Данная струткура содержит значения состояний выделения (используется или нет) каждого кластера в этой файловой системе.

7

$Boot

Содержит сам загрузочный сектор и код запуска, часто носящий название Записи тома загрузки (VBR, Volume Boot Record). Это единственный файл с гарантированным положением, всегда находящимся в Секторе 0. $Boot применяется для определения местоположения самого первого кластера $MFT.

8

$BadClus

Содержит перечень кластеров, содержащих сбойные секторы.

9

$Secure

Содержит сведения относительно безопасности и контроля доступа для файлов.

10

$Upcase

Содержит версию Верхнего регистра для всех символов unicode

11

$Extend

Каталог, который содержит расширения файловой системы, которые не обладают зарезервированными номерами записей MFT.

$Boot

Файл метаданных $Boot это единственный файл файловой системы NTFS, для которого известно значение местоположения. Этот файл всегда занимает Сектор 0 на своём диске. Файл $Boot служит цели, идентичной для записи запуска тома в FAT/ exFAT, и в самом деле, файл $Boot часто именуют записью запуска тома (VBR, volume boot record) NTFS.

$Boot имеет в размере 512d байт (один сектор). Он содержит код самораскрутки и сведения относительно структуры своего тома. Таблица 7.2 предоставляет общую структуру $Boot. Файл $Boot это самый первый шаг для анализа всей файловой системы NTFS. С точки зрения цифрового расследования, наиболее важной стороной данной структуры является то, что она делает возможной определять местоположение $MFT. Из $MFT можно восстановить все файлы его файловой системы. $MFT к тому же предоставляет прочие жизненно важные для дальнейшего анализа сведения, например, значение размера кластера (комбинацию размера сектора и секторов в кластере), а также величину размера записи $MFT. Остаток самого первого сектора в файловой системе составлен самим кодом самостоятельного запуска.

Таблица 7.2. Структура $Boot NTFS.
Смещение Размер Название Описание

0x00

0x03

Безусловный переход

Инструкция Jump для доступа к коду самостоятельного запуска.

0x03

0x08

OEM название

Название первоначального производителя. Всегда "NTFS"

0x0B

0x01

Размер сектора

Размер сектора в байтах. Обычно это 0x200 (512d) байт.

0x0D

0x01

Секторов/ Кластер

Значение числа секторов в кластере. Это всегда степень двух.

0x0E

0x02

Зарезервировано

Зарезервированные сектора. Должно быть нулём.

0x10

0x03

Зарезервировано

Нули.

0x13

0x02

Не используется

Не используется.

0x15

0x01

Дескриптор носителя

Тип носителя, на котором постоянно пребывает эта файловая система. Для стандартного жёсткого диска обычно это 0XF8.

0x16

0x02

Зарезервировано

Нули.

0x18

0x02

Секторов/ Дорожка

Значение числа секторов на физической дорожке. Это значение относится к старому формату адресации CHS.

0x1A

0x02

# Дорожек

Значение числа дорожек на диске. Это значение относится к старому формату адресации CHS.

0x18

0x02

Секторов/ Дорожка

0x1C

0x04

Скрытые секторы

Неопределённое значение.

0x20

0x04

Не используется

Не используется.

0x24

0x04

Не используется

Не используется.

0x28

0x08

# Секторов

Общее число секторов устройства.

0x30

0x08

Местоположение MFT

Номер логического кластера для самого первого кластера в файле $MFT

0x38

0x08

Местоположение MFTMirr

Номер логического кластера для самого первого кластера в файле $MFTMirr

0x40

0x01

Размер записи MFT

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

0x41

0x03

Не используется

Не используется.

0x44

0x01

Секторов/ Индекс

Число секторов в буфере индекса.

0x45

0x03

Не используется

Не используется.

0x48

0x08

Серийный номер

Серийный номер данного тома.

0x50

0x04

Не используется

Не используется.

Индекс

Индексы применяются для хранения групп атрибутов в упорядоченном виде. Одними из наиболее распространённых структур в NTFS являются каталоги. В этом случае в индексе хранится ряд атрибутов $FILENAME (Раздел 7.1.6). Для хранения индексов NTFS пользуется структурой B- дерева. B- дерево это древовидная структура с самостоятельной балансировкой и она часто встречается в современных файловых системах. B- деревья составляются из узлов, которые связываются иерархическим образом. Всякое B- дерево обладает верхним уровнем, головным узлом, который обладает двумя или более потомками (B-дерево с двумя потомками для каждого из узлов носит название двоичного дерева). Внутренние узлы обладают родителем и двумя или более потомками, в то время как узлы листьев имеют одного родителя и ноль потомков.

Структуры индексов (то есть B- деревья) предоставляют большое преимущество в производительности над линейными структурами хранения (такими как записи каталога FAT), ибо они намного быстрее при поиска. B- деревья делают возможными поиск, вставку и удаление за логарифмические порядки времени. Рассмотрим показанное на Рисунке 7.1 (это двоичное дерево, поскольку каждый сил обладает двумя потомками) и выполним поиск значения 7d.

 

Рисунок 7.1


Простая структура B- дерева, отображающая три узла, применяемых при поиске значения 7d.

Головной узел содержит значение 6d. Что меньше требуемого значения. Это означает, что, если оно присутствует в данном дереве, искомое значение 7d должно пребывать в потомке справа от головного узла. Рассмотрение этого узла отображает его значение 8d, что больше искомого. В результате это приводит к поиску в левом потомке. Этот узел и содержит требуемое значение. Сопоставим это с линейной структурой, такой как:


		[6, 3, 8, 1, 4, 7, 10]

Для определения местоположения значения 7d это потребует шесть проверок в противоположность трём проверкам по B- дереву.

В противоположность показанному на Рисунке 7.1 дереве, в общем случае B- деревья могут содержать более одного единственного значения для каждого из узлов. Рисунок 7.2 предоставляет более точную интерпретацию B- дерева, применяемого для хранения имён файлов, в котором каждый узел обладает возможность хранения максимально до трёх значений.

 

Рисунок 7.2


Простая структура B- дерева с именами файлов в качестве значений. Подобное можно наблюдать во множестве файловых систем.

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

Индексы хранятся в атрибутах $INDEX_ROOT и $INDEX_ALLOCATION (см. Раздел 7.1.6). В случае небольших индексов они будут применять постоянно присутствующий в памяти атрибут $INDEX_ROOT, в то время как большие индексы используют $INDEX_ALLOCATION, подкачиваемый атрибут. Каждый индекс состоит из заголовка и атрибута (например, для каталогов, $FILENAME). Обработка этих атрибутов (и всех индексов) отображается в этой главе позднее (Раздел 7.2.3).

Массивы адресных привязок

Для увеличения надёжности NTFS применяет понятие массивов адресных привязок (fixup arrays, также носящих название массивов последовательностей обновлений, Update Sequence Array). Последние два байта в каждом секторе структуры метаданных (например, записи MFT) заменяются подписью. При доступе к этой структуре данная подпись может быть проверена для гарантии того, что все секторы составляют одну и ту же структуры метаданных. Рисунок 7.3 отображает некую структуру метаданных NTFS до и после применения значений адресных привязок.

На Рисунке 7.3, перед применением необходимых значений адресных привязок, мы видим, что заключительные два байта самого первого сектора равны 0x1234, а последние два байта второго сектора равны 0xCDEF. Позиции массива адресных привязок обнулены. Для применения необходимых значений адресных привязок должно произойти следующее:

  1. Значение подписи увеличивается (оно превращается в 0x0001)

  2. Самые последние два байта нашего первого сектора сохраняются в первой позиции массива адресных привязок

  3. В самые последние два байта первого сектора записывается подпись (0x0001)

  4. Для каждого из секторов в данной структуре повторяются шаги 2 и 3.

 

Рисунок 7.3


Первоначальная структура метаданных NTFS (вверху) и та же самая структура метаданных после применения значений адресной привязки (внизу).

Для интерпретации этих массивов адресных привязок необходимо сначала обработать сам массив адресных привязок. Отметим, что в данном случае запись MFT используется в качестве примера. Значение смещения массива определяется двумя байтами в 0x04 из заголовка $MFT, а длина массива адресной привязки задаётся в следующих двух байтах. Собственно Массив адресной привязки начинается с номера последовательности обновления (на Рисунке 7.3 это подпись, signature), а за ним следуют собственно реальные значения адресной привязки. Листинг 7.1 отображает выдержку из Записи MFT (обращаем внимание, что часть содержимого была удалена для целей более ясного представления).

 

Листинг 7.1. Запись MFT, демонстрирующая применение её массива адресных привязок.


010400: 4649 4c45 3000 000300 0000 0000 0000 0000 FILE0...........
010410: 0200 0100 3800 0100 b801 0000 0004 0000 ....8...........
010420: 0000 0000 0000 0000 0400 0000 4100 0000 ............A...
010430: 1d00 0000 0000 0000 1000 0000 4800 0000 ............H...
...[snip]...
0105f0: 0000 0000 0000 0000 0000 0000 0000 1d00 ................
010600: 0000 0000 0000 0000 0000 0000 0000 0000 ................
...[snip]...
0107f0: 0000 0000 0000 0000 0000 0000 0000 1d00 ................
0030020: 8100 0000 0000 0000 0000 0000 0000 0000 ................
0030030: 0000 0000 0200 0000 0008 0000 0000 0000 ................

В Листинге 7.1 мы наблюдаем, что наш Массив адресных привязок расположен по смещению 0x30 и содержит 0x03 элементов. Каждый элемент обладает размером в два байта. Сам по себе массив адресных привязок выделен. Первый элемент в этом массиве это подпись (0x1D00), в то время как остальные элементы это первоначальные значения, которые были заменены этой подписью. В самом конце каждого из секторов Записи MFT последние два байта были заменены значением этой подписи. Эти значения подписи указывают на то, что данные секторы из запроса связаны!

Поддерживающие NTFS инструменты расследования будут содержать возможность обработки подобных значений, замещая в процессе анализа встречающиеся подписи первоначальными значениями. Такой подход применим во многих файлах метаданных NTFS, а раз так, он важен для понимания. {Прим. пер.: его появление объясняется недостаточными вычислительными мощностями при появлении NTFS, см, например, Файловая система NTFS извне и изнутри Криса Касперски.}

Время в NTFS

Большая часть величин времени в NTFS хранится в виде 64-битных значений со знаком, исчисляя число 100 нс (10-7) промежутков начиная с 1 января 1601. Все эти величины времени сохраняются во временной зоне UTC+0. При встрече таких величин имеется ряд преобразователей, которыми можно воспользоваться для обработки таких значений. Листинг 7.2 отображает средство воспринимаемого человеком времени для конкретного Времени файла Windows: 0x1D7FED75319AEB1 (132854914796334769d).

 

Листинг 7.2. Применение date для преобразования времени файла Windows (0x1D7FED75319AEB1) в воспринимаемый человеком формат.


$ date -ud @$(( (0x1D7FED75319AEB1 / 10000000) - 11644473600))
Sat 01 Jan 2022 06:17:59 UTC

Время эпохи Unix исчисляет число секунд начиная с 1 января 1970. Для преобразования величин времени файлов в воспринимаемый человеком формат можно применять команду date. Команда date работает с временными метками Unix, а потому время файла Windows надлежит преобразовать во время Unix. Это процесс из двух шагов. Прежде всего величину времени Windows необходимо преобразовать из интервалов в 100нс в секунды. Это требует деления на 10 000 000d. Результат этого вычисления это число секунд, исчисляемых с 1601. Второй шаг заключается в удалении числа секунд между 1601 и 1970, иными словами, сдвиг эпох. Это влечёт собой вычитание величины 11 644 473 600d из нашего первого результата. Такой процесс (включая команду date) отображён в листинге 7.2.

Главная файловая таблица (MFT)

Главная файловая таблица (Master File Table, $MFT) это одна из самых важных структур в NTFS. $MFT содержит сведения относительно всех файлов и каталогов в своей файловой системе. Именно эта структура обрабатывается инструментами расследования когда они желают перечислить файлы файловой системы, восстановить метаданные, а также восстановить содержимое файла. Но $MFT содержит не только сведения относительно созданных пользователем файлов, она также всегда хранит записи для всех системных файлов NTFS (включая и саму $MFT!)

$MFT составляется из ряда записей MFT, по крайней мере по одной на файл. Собственно структура каждой записи отображена на Рисунке 7.4. Каждая запись начинается с заголовка записи, за которым следует некоторое число атрибутов. Атрибуты составляются компонентами заголовка и данных. Данные для некого атрибута могут быть резидентными (храниться в самой Записи MFT) или не резидентными (храниться где-то ещё в своей файловой системе). В случае нерезидентных данных их атрибут будет содержать указатель на местоположение оговариваемых нерезидентных данных. Обычно всякая запись MFT состоит из 1024d байт; тем не менее, в этом следует убедиться из $Boot.

С точки зрения расследования, обратите внимание на то, что в самом конце Записи MFT зачастую имеется не используемое пространство (зазор). Это предоставляет некий потенциал для частичного восстановления старых записей MFT. Атрибуты в NTFS включают в свой состав (обратите внимание, что идентификатор типа атрибута представлен в квадратных скобках):

  • $STANDARD_INFORMATION (0x10): Этот атрибут содержит связанные с файлом метаданные. Они включают в себя времена MACB, владельца, сведения безопасности и т.п.. Они жизненно важны для криминалистического восстановления метаданных.

  • $ATTRIBUTE_LIST (0x20): Применяются в том случае, когда файлу требуется несколько Записей MFT. Когда он имеется, он указывает на прочие местоположения в которых можно обнаружить остающиеся атрибуты.

  • $FILE_NAME (0x30): Содержит значение имени файла для файла/ каталога запроса. Обратите внимание, что в случае жёстких ссылок или длинных имён файлов, может иметься множество атрибутов $FILE_NAME. В данном атрибуте также присутствует временная метка.

  • $OBJECT_ID (0x40): Это уникальный идентификатор файла, который всегда отслеживает файл, даже когда имя изменено (или даже когда он перемещается между системами). Он присутствует в поздних версиях NTFS.

  • $SECURITY_DESCRIPTOR (0x50): Свойства безопасности/ списки контроля доступа данного файла.

  • $VOLUME_NAME (0x60): Содержит имя тома файловой системы и обычно находится только в записи 3 MFT ($VOLUME).

  • $VOLUME_INFORMATION (0x70): В данной структуре находятся сведения о версии файловой системы. Этот атрибут также пребывает только в записи 3 MFT ($VOLUME).

  • $DATA (0x80): Это ещё один жизненно важный для цифровой криминалистики атрибут, сообщающий нам как найти собственно содержимое файла! Как мы уже указывали ранее, он может быть как резидентным (для очень маленьких файлов) и в этом случае содержимое файла хранится в самой записи MFT, либо не резидентным, и в такой ситуации $DATA снабдит нас значением местоположения своего содержимого. По целому ряду причин, файлы в NTFS способны обладать множеством атрибутов $DATA. Одна из них состоит в возможности Альтернативных потоков данных (Alternate Data Streams, ADS), обособленной части независимых от реального содержимого файла данных.

  • $INDEX_ROOT (0x90): Именно он является узлом B- дерева, используемым в B- дереве. Он применяется для хранения файлов в каталогах.

  • $INDEX_ALLOCATION (0xA0): В ситуации, при которой для хранения сведений в структуре $INDEX_ROOT недостаточно места, для выделения дополнительных кластеров данной структуре применяется $INDEX_ALLOCATION.

  • $BITMAP (0xB0): Структура битовой маски, которая информирует о состоянии выделения кластера.

  • $REPARSE_POINT (0xC0): Это программные ссылки, указатели на иные файлы в данной MFT.

  • $EA_INFORMATION (0xD0): Применяется для реализации расширенных атрибутов OS2 с целью обратной совместимости (OS2 была созданной Microsoft и IBM в соавторстве операционной системой до 1992 и единолично IBM до 2001). {Прим. пер.: Полноценной заменой версиям OS/2 4.5 может рассматриваться Blue Lion от Arca Noae с названием ArcaOS, заключившей в ноябре 2015г соглашение с IBM на выпуск и продажу нового дистрибутива.}

  • $EA (0xE0): С целью обратной совместимости применяется для реализации расширенных атрибутов OS2.

  • $LOGGED_UTILITY_STREAM (0x100): Содержит ключи и сведения относительно атрибутов шифрования в текущих версиях NTFS.

 

Рисунок 7.4


Структура записи MFT.

Приведённые выше атрибуты будут более подробно рассмотрены позднее в данном разделе.

Структура записи MFT

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

Заголовок записи MFT

Структура заголовка записи MFT это структура из 42d байт в самом начале каждой записи MFT. Структура этого заголовка записи отображена в Таблице 7.3.

Таблица 7.3. Структура заголовка записи MFT.
Смещение Размер Название Описание

0x00

0x04

Подпись

Значение подписи данной записи MFT (FILE).

0x04

0x02

Смещение массива адресных привязок

Значение смещения массива адресных привязок.

0x06

0x02

Размер массива адресных привязок

Число записей в массиве адресных привязок.

0x08

0x08

LSN

Номер последовательности $LOGFILE.

0x10

0x02

Значение последовательности

Количество применений данной записи MFT.

0x12

0x02

Счётчик ссылок

Число ссылок на этот файл.

0x16

0x02

Флаги

Флаги записи: 0x01 - запись используется; 0x02 Каталог.

0x18

0x04

Размер записи (используемый)

Реальный размер этой записи MFT в байтах.

0x1C

0x04

Размер записи (выделенный)

Выделенный размер этой записи MFT в байтах. Обычно такой же как в структуре $Boot для размера записи MFT.

0x20

0x08

Ссылка файла

Ссылка файла на базовую запись.

0x28

0x02

Идентификатор следующего атрибута

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

Каждый атрибут начинается с заголовка из 16 байт. Затем следуют сведения о том, где можно найти данные этого атрибута. Существует две возможности: данные либо резидентные, либо нерезидентные. Резидентные данные располагаются в самой реальной записи MFT, в то время как нерезидентные данные пребывают в ином местоположении данной файловой системы. Таблица 7.4. Предоставляет структуру заголовка атрибута.

Таблица 7.4. Структура заголовка атрибута.
Смещение Размер Название Описание

0x00

0x04

Тип атрибута

Значение идентификатора типа атрибута (для полного перечня атрибутов - с идентификаторами - обратитесь к Разделу 7.1.5).

0x04

0x04

Размер атрибута

Размер атрибута в байтах.

0x08

0x01

Флаг не резидента

Это флаг 0x01 когда атрибут нерезидентный и 0x00 для резидентных атрибутов.

0x09

0x01

Длина имени

Длина имени атрибута в байтах.

0x0A

0x02

Смещение имени

Смещение имени атрибута в байтах.

0x0C

0x02

Флаги

Относящиеся к данному атрибуту флаги. Некоторые из флагов это 0x0001 (сжатый); 0x4000 (зашифрован) and 0x8000 (разрежённый).

0x0E

0x02

Идентификатор атрибута

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

За заголовком атрибута следует вторичный заголовок. Его структура зависит от того является ли данный атрибут резидентным, или нерезидентным.Структура заголовка резидентного атрибута отображена в Таблице 7.5, а заголовок нерезидентного атрибута представлен в Таблице 7.6.

Таблица 7.5. Структура заголовка резидентного атрибута.
Смещение Размер Название Описание

0x00

0x10

Общий заголовок

Это общий заголовок (см. Таблицу 7.4).

0x10

0x04

Размер содержимого

Значение размера содержимого атрибута в байтах.

0x14

0x02

Смещение содержимого

Значение смещения на начало атрибута в байтах. Данное смещение исчисляется относительно начала самого атрибута.

Таблица 7.6. Структура заголовка нерезидентного атрибута.
Смещение Размер Название Описание

0x00

0x10

Общий заголовок

Это общий заголовок (см. Таблицу 7.4).

0x10

0x08

Начальный VCN

Значение начального номера виртуального кластера (VCN, virtual cluster number) данного списка последовательности (иными словами, местоположение содержимого того файла, которое представляет этот рассматриваемый список).

0x18

0x08

Конечный VCN

Значение конечного VCN.

0x20

0x02

Смещение списка последовательности

Значение местоположения этого списка обхода относительно начала самого атрибута.

0x22

0x02

Модуль сжатия

Применяемый алгоритм сжатия.

0x24

0x04

Не используется

Не используется.

0x28

0x08

Выделенный размер

Величина выделенного размера содержимого данного атрибута.

Заголовки резидентных атрибутов позволяют непосредственно размещать данные резидентного атрибута для их определения предоставляя смещение байт начала данных и размер данных в байтах. Нерезидентные атрибуты слегка сложнее в отношении определения положения реальных данных. Ключевым компонентом местоположения в нерезидентном атрибуте выступает список последовательности (runlist). Структура заголовка нерезидентного атрибута предоставляет значение смещения на этот список последовательности относительно начала данного атрибута (см. Таблицу 7.6). Список последовательности сам по себе это структура переменной длины (завершающаяся null). Как следует из самого названия, список последовательности составлен из одного или более прогонов. Каждый прогон предоставляет значение начального кластера и число кластеров, в которых могут располагаться данные.

Списки последовательности сами по себе состоят из трёх частей. Первая часть (один единственный байт) описывает всю структуру своего списка последовательности. Вторая часть снабжает значением числа кластеров в данном прогоне, а третья часть даёт значение начального кластера этого списка последовательности. Завершающие две части структуры списка последовательности имеют переменную длину. Значение самого первого байта информирует анализ о длине каждой из частей. Рассмотрим список последовательности 0x21112001, как это отображено на Рисунке 7.5.

 

Рисунок 7.5


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

Самый первый байт описывает свою структуру. Старший полубайт этого байта содержит количество применяемых в начальном кластере байт, тогда как младший полубайт содержит количество байт, используемых для хранения количества смежных кластеров в последовательности. Далее следует значение числа непрерывных кластеров в последовательности. Величина длины этого значения определяется младшим полубайтом в самом первом байте. А именно, на Рисунке 7.5 это 0x11 (17d). Наконец, найден начальный кластер. Длина этого значения определяется старшим полубайтом самого первого байта. На рисунке 7.5 значением начального кластера является 0x120 (288d).

Атрибуты просмотра

Обычно при операции над записью MFT необходимо обрабатывать все имеющиеся атрибуты. Вот тот метод, коим это осуществляется:

  1. Обработать заголовок записи MFT (Таблица 7.3) и определить местоположение смещение для первого атрибута.

  2. Обработать общий заголовок атрибута для 1 атрибута и найти длину этого атрибута. Выделите это содержимое (именно это и есть атрибут 1).

  3. Повторите шаг 2 ( при помощи длины атрибута для перемещения к началу следующего атрибута). Этот процесс показан в Листинге 7.3 для образца записи MFT.

 

Листинг 7.3. Некая запись MFT, отображающая значение смещения для первого атрибута (0x38), а также значения типов атрибутов и длин помимо маркера конца записи.


010800: 4649 4c45 3000 0300 0000 0000 0000 0000 FILE0...........
010810: 0100 0100 3800 0100 a801 0000 0004 0000 ....8...........
010820: 0000 0000 0000 0000 0400 0000 4200 0000 ............B...
010830: 8b00 0000 0000 0000 1000 0000 4800 0000 ............H...
010840: 0000 0000 0000 0000 3000 0000 1800 0000 ........0.......
010850: 8ee3 3a81 bc0b da01 8e90 3b81 bc0b da01 ..:.......;.....
010860: 8e90 3b81 bc0b da01 8ee3 3a81 bc0b da01 ..;.......:.....
010870: 2000 0000 0000 0000 0000 0000 0000 0000 ...............
010880: 3000 0000 7000 0000 0000 0000 0000 0300 0...p...........
010890: 5400 0000 1800 0100 4100 0000 0000 0100 T.......A.......
0108a0: 8ee3 3a81 bc0b da01 8ee3 3a81 bc0b da01 ..:.......:.....
0108b0: 8ee3 3a81 bc0b da01 8ee3 3a81 bc0b da01 ..:.......:.....
0108c0: 0040 0400 0000 0000 0000 0000 0000 0000 .@..............
0108d0: 2000 0000 0000 0000 0900 6800 6900 6c00 .........h.i.l.
0108e0: 6c00 7300 2e00 6a00 7000 6700 1800 0000 l.s...j.p.g.....
0108f0: 5000 0000 6800 0000 0000 0000 0000 0100 P...h...........
010900: 5000 0000 1800 0000 0100 0480 1400 0000 P...............
010910: 2400 0000 0000 0000 3400 0000 0102 0000 $.......4.......
010920: 0000 0005 2000 0000 2002 0000 0102 0000 .... ... .......
010930: 0000 0005 2000 0000 2002 0000 0200 1c00 .... ... .......
010940: 0100 0000 0003 1400 ff01 1f00 0101 0000 ................
010950: 0000 0001 0000 0000 8000 0000 4800 0000 ............H...
010960: 0100 4000 0000 0200 0000 0000 0000 0000 ..@.............
010970: 4300 0000 0000 0000 4000 0000 0000 0000 C.......@.......
010980: 0040 0400 0000 0000 3d31 0400 0000 0000 .@......=1......
010990: 3d31 0400 0000 0000 2144 0042 0000 0000 =1......!D.B....
0109a0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................

В Листинге 7.3 значение смещения первого атрибута задаётся как 0x38 байт. По этому смещению начинается заголовок атрибута для самого первого атрибута. Первые четыре байта этого заголовка определяет тип этого атрибута. В данном случае это 0x10 (что определяет атрибут $STANDARD_INFORMATION - см. Раздел 7.1.5). Следующие четыре байта содержат значение длины этого атрибута (0x48 байт). Переместившись далее на 0x48 байт обнаружим начало следующего атрибута. Данный процесс продолжается как это было описано. Результаты этого отображены в Таблице 7.7.

Таблица 7.7. Значения атрибутов и их длины из записи MFT Листинга 7.3.
Тип атрибута Название атрибута Длина

0x10

$STANDARD_INFORMATION

0x48

0x30

$FILENAME

0x70

0x50

$SECURITY_DESCRIPTOR

0x68

0x80

$DATA

0x48

$STANDARD_INFORMATION (0x10)

Большинство метаданных NTFS хранится в атрибуте $STANDARD_INFORMATION. Их структура отображена в Таблице 7.8. Этот атрибут всегда резидентный. Раз так, его общий заголовок (Таблицу 7.4) за которым следует структура данного резидентного заголовка (Таблицу 7.5).

Таблица 7.8. Структура атрибута $STANDARD_INFORMATION.
Смещение Размер Название Описание

0x00

0x08

Время создания

Значение времени в которое был создан данный файл.

0x08

0x08

Время изменения

Значение времени в которое содержимое файла было изменено.

0x10

0x08

Время изменения MFT

Значение времени в которое произошло последнее изменение метаданных файла.

0x18

0x08

Время доступа

Значение времени в которое был осуществлён последний доступ к этому файлу.

0x20

0x04

Флаги

Здесь представлены сведения относительно файла, на который ссылается данная запись MFT. Значения флагов приведены в Таблице 7.9.

0x24

0x04

Макс. # версий

Значение максимального номера версий.

0x28

0x04

Номер версии

Номер текущей версии.

0x2C

0x04

Идентификатор класса

Значение идентификатора класса.

0x30

0x04

Идентификатор владельца

Значение идентификатора владельца (не всегда присутствует).

0x34

0x04

Идентификатор безопасности

Значение идентификатора безопасности, соответствующего $SECURE (не SID Windows).

0x38

0x08

Изменённая квота

Изменение квоты.

0x40

0x08

USN

Обновление последовательного номера (Update Sequence Number, USN) (присутствует не всегда).

Таблица 7.9. Значения флагов для атрибута $STANDARD_INFORMATION.
Значение Описание Значение Описание

0x0001

Read-Only

0x0200

Sparse File

0x0002

Hidden

0x0400

Reparse Point

0x0004

System

0x0800

Compressed

0x0020

Archive

0x1000

Offline

0x0040

Device

0x2000

Content not indexed

0x0080

Normal

0x4000

Encrypted

0x0100

Temporary

 

 

$STANDARD_INFORMATION содержит значения временных меток файла. NTFS записывает временные метки MACB изменения, доступа, изменения и порождения (создания). Эти значения являются 64 битными временными метками Windows, которые можно преобразовывать как это было показано в Разделе 7.1.4.

$ATTRIBUTE_LIST (0x20)

В ситуации, при которой атрибуты для записи MFT не будут помещаться в одну запись MFT, имеется атрибут $ATTRIBUTE_LIST, который предоставит местоположение прочих атрибутов. $ATTRIBUTE_LIST может быть резидентным или нерезидентным. Содержимое $ATTRIBUTE_LIST это перечень структур по 32d байт, за каждой из которых следует показанная в Таблице 5.10 структура. Раздел 7.1.5 предоставляет образец записи MFT с использованием $ATTRIBUTE_LIST.

Таблица 7.10. Структура $ATTRIBUTE_LIST.
Смещение Размер Название Описание

0x00

0x04

Тип атрибута

Идентификатор типа атрибута для конкретного атрибута.

0x04

0x02

Длина элемента

Размер этой структуры в байтах.

0x06

0x01

Длина имени

Размер имени в байтах.

0x07

0x01

Смещение имени

Значение смещения для имени атрибута.

0x08

0x08

Начальный VCN

Применяется если этот атрибут требует множества элементов MFT для описания своего содержимого.

0x10

0x08

Макс. # версий

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

0x18

0x01

Идентификатор атрибута

Идентификатор атрибута.

$FILENAME (0x30)

Как это и подразумевает их название, атрибуты $FILENAME хранят имена файлов для конкретных записей MFT. И файлы и каталоги обладают по крайней мере одним атрибутом $FILENAME. Помимо самого названия файла эти атрибуты также содержат времена MACB. Аналогично $STANDARD_INFORMATION эти временные метки являются объектами времени файла Windows (интервалы в 100 нс, исчисляемые с 1 января 1601 года). Структура $FILENAME представлена в Таблице 7.11.

Таблица 7.11. Структура атрибута $FILENAME.
Смещение Размер Название Описание

0x00

0x08

Родительская MFT

Ссылка на MFT файла родительского каталога.

0x08

0x08

Время создания

Время, в которое была создана эта MFT.

0x10

0x08

Время модификации

Время, в которое это содержимое было изменено.

0x18

0x08

Время изменения

Время, в которое это была изменена эта запись MFT.

0x20

0x08

Время доступа

Время последнего доступа к данному содержимому.

0x28

0x08

Размер выделения

Размер пространства, в байтах, выделенное на диске для хранения этого файла.

0x30

0x08

Реальный размер

Реальный размер файла в байтах.

0x38

0x04

Флаги

Флаги (те же самые что и для $STANDARD_INFORMATION - см. Таблицу 7.9).

0x3C

0x04

Reparse value

Значение повторной обработки.

0x40

0x01

Длина имени

Число символов UTF-16 в названии (n × 2 предоставляет число байт для этого имени).

0x41

0x01

Пространство имени

Тип пространства имён. Допустимые значения:

0x00: POSIX - чувствительный к регистру unicode;

0x01: Win32 - не чувствительный к регистру unicode;

0x02: DOS - не чувствительный к регистру, без специальных символов, необходим формат 8.3; и

0x03: Win32/ DOS - исходное имя соответствует стандарту DOS и не нет необходимости в двух именах.

0x42

n × 2

Имя

Реальное имя (кодированное в UTF-16).

Интересный момент относительно атрибута $FILENAME состоит в том, что данный атрибут применяется для хранения размера файла. Для полного восстановления содержимого файла этот атрибут необходимо использовать наряду с атрибутом $DATA. $DATA предоставляет местоположение данных файла, в то время как $FILENAME обеспечивает значение реального размера файла. Кроме того, в отличии от прочих файловых систем NTFS содержит второй набор временных меток в отношении каждого файла в этом атрибуте $FILENAME. Эти временные метки относятся к самому имени файла и обычно обновляются при создании, перемещении, переименовании и т.п., а не тогда когда изменяется содержимое или осуществляется доступ к нему.

$OBJECT_ID (0x40)

Атрибут $OBJECT_ID (OID) применяется службой отслеживания распределённых ссылок в Windows, которая используется для определения местоположения файла даже после его перемещения или переименования. $OBJECT_ID содержит универсальный уникальный идентификатор (Universally Unique IDentifier, UUID) для каждого созданного в этой системе файла.Они проиндексированны в специальном системном файле $Extend\$ObjID, что делает возможным определение местоположения файла даже после переименования/ перемещения.

Атрибут $OBJECT_ID всегда резидентный с максимумом в размере 64d байт. Структура $OBJECT_ID отображена в Таблице 7.12. Многие современные реализации определяют в этой структуре лишь самое первое поле. Иными словами, теперь общепринято перечислять атрибуты $OBJECT_ID только состоящим из 16d байт OBJECT ID и больше ничем.

Таблица 7.12. Структура атрибута $OBJECT_ID. Обратите внимание, что в последних версиях Windows зачастую используются только самые первые 16d байт.
Смещение Размер Название Описание

0x00

0x10

OID UUID

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

0x10

0x10

Birth VID

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

0x20

0x10

Birth OID

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

0x30

0x10

Domain ID

Значение UUID для того домена, в котором был создан этот элемент. Обычно он не применяется.

Атрибут $OBJECT_ID создаётся в Windows как часть Службы отслеживания распределённых ссылок (Distributed Link Tracking Service). А раз так, его обычно нельзя обнаружить при созданных/ открытых файлах в прочих операционных системах. Данный атрибут образуется только при создании или открытии файла при помощи Windows. Большинство операций (перемещение или переименование) предохраняют это значение OID, однако копирование этого файла изменит его. Это обусловлено тем, что создание нового элемента из такой копии не может обладать тем же самым OID, что и его первоначальный элемент.

Значения OID вырабатываются следуя определённому шаблону. Рассмотрим показанный в Листинге 7.4 OID. Он составлен тремя компонентами. Первые восемь байт представляют значение времени, когда был создан данный элемент. Следующие два байта это некий счётчик, в то время как последние шесть байт выступают значением MAC адреса того компьютера, в котором был порождён данный элемент. Это можно применять как ссылку на файл в неком конкретном компьютере; тем не менее, данные сведения могут обманывать. Когда отсутствует MAC адрес, вместо этого применяется случайное число.

 

Листинг 7.4. Обнаруживаемый в атрибуте $OBJECT_ID некой записи MFT OID.


00e5a8: 47f8 44e4 3478 ec11 88c9 0800 2771 5e21

Значение применяемого в $OBJECT_ID времени не то же самое, что используется в остальной NTFS. В данном случае время это значение из 60d бит, которые исчисляют число 100d нс интервалов с 1 января 1582 года. Для преобразования значения 64d с прямым порядком байт из Листинга 7.4, первый шаг состоит в преобразовании к обратному порядку следования байт и отбрасыванию самого значимого полубайта (то есть верхних 4d бит). Согласно листингу 7.4 это будет иметь результатом 0x1EC7834E444F847. Следующий шаг состоит в вычитании числа 100d нс интервалов между 1582 и 1601 годами (началом традиционной NTFS). Это значение равно 0x146BF33E42C000, что в результате приводит к 0x1D80C4196023847. Это значение можно преобразовать при помощи показанного ранее метода. Его преобразование в воспринимаемый человеком формат даёт нам вторник, 18 января 2022 8:01:23 AM.

$SECURITY_DESCRIPTOR (0x50)

Атрибуты $SECURITY_DESCRIPTOR обычно встречаются только в файлах $SECURE вместо записей MFT. Этот атрибут может быть резидентным или нерезидентным. Структурно данные атрибуты состоят из заголовка в 0x14 байт, за которым следуют два ACL: один, SACL (Системный список контроля доступа), для целей аудита, а другой, DACL (Список разграничительного контроля доступа) для разрешений. Каждый ACL состоит из одной или более пар Элемента управления доступом (Access Control Entries, ACE) и SIDэ Данный этого атрибута завершаются двумя Идентификаторами безопасности (security identifiers, SID), представляющими значения владельца и группы. Структура заголовка атрибута $SECURITY_DESCRIPTOR показана в Таблице 7.13.

Таблица 7.13. Структура заголовка атрибута $SECURITY_DESCRIPTOR.
Смещение Размер Название Описание

0x00

0x01

Revision

Номер версии.

0x01

0x01

Padding

Байт заполнения (0x00).

0x02

0x02

Control Flags

Управляющие флаги.

0x04

0x04

User SID Offset

Смещение в байтах до User SID.

0x08

0x04

Group SID Offset

Смещение в байтах до Group SID.

0x0C

0x04

SACL Offset

Смещение в байтах до SACL.

0x10

0x04

DACL Offset

Смещение в байтах до DACL.

Все представленные в Таблице 7.13 смещения задаются относительно начала данных этого атрибута. Этот заголовок составлен из сведений о местоположениях Дескрипторов безопасности Пользователя и Группы (User и Group SID), а также значений смещений до Системного и Разграничительного ACL (SACL и DACL).

Значение SID уникально идентифицирует пользователя (или группу) в данной операционной системе Windows и могут применяться NTFS для отображения владельца файла. SID это структура переменной длины, которая показана в Таблице 7.14. Всякая SID представлена, как минимум, двумя компонентами (идентификаторами версии и полномочий), а также любым числом необязательных идентификаторов подчинённой авторизации. SID Windows записываются по определённому шаблону, к примеру, S-1-5-32-544 (это значение SID группы локальных администраторов Windows). Буква S просто обозначает следующее значение как некий SID. Далее следует уровень редакции (1), за которым следует идентификатор полномочий (5 - SECURITY_NT_AUTHORITY, некоторые распространённые ключи и значения полномочий можно найти в https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids), а также два значения подчинённой авторизации (32 и 544).

Таблица 7.14. Структура Идентификатора безопасности (SID).
Смещение Размер Название Описание

0x00

0x01

Version

Номер версии это самый первый компонент SID (и, как правило, это 1). Для целей представления данных перед номером версии добавляется S-.

0x01

0x01

Sub-Auth Count (n)

Число присутствующих в данном SID подчинённых полномочий.

0x02

0x06

Authority ID

Идентификатор полномочий, то есть, X это S-1-X..

0x08

0x04× 4

SubAuthority[]

Каждый элемент из четырёх байт в данном массиве добавляется в конец этого SID в том порядке, в котором они находятся в этих полях.

Рассмотрим показанный в Листинге 7.5 SID. Чередующиеся поля подчёркнуты.

 

Листинг 7.5. Пример SID.


0000000: 0102 0000 0000 0005 2000 0000 0800 2771 5e212002 0000 ................

Получаемый в результате SID представляется как S-1-5-32-544. А именно, это версия 1d, состоящая из двух подчинённых полномочий. Основной идентификатор полномочий равен 5d, в то время как подчинённые полномочия это 32d и 544d. В случае нескольких подчинённых полномочий в SID, последней частью является относительный идентификатор (который должен быть уникальным в рассматриваемом домене), в то время как прочие подчинённые полномочия представляют этот домен. Каждый домен обязан обладать уникальным значением подчинённых полномочий.

Следующим компонентом $SECURITY_DESCRIPTOR является Список управления доступом (ACL). Структура ACL отображена в Таблице 7.15. Могут присутствовать два типа ACL, а именно: SACL и DACL. Значение DACL определяет пользователей/ группы и те действия, которые им дозволено осуществлять с данным элементом. С другой стороны, SACL определяет те предпринимаемые действия, которые обязаны регистрироваться в журнале событий Windows.

Таблица 7.15. Структура Списка управления доступом (ACL).
Смещение Размер Название Описание

0x00

0x01

ACL Revision

Связанный с этим ACL номер версии.

0x01

0x01

Padding

Заполнение.

0x02

0x02

ACL Size

Размер применяемого ACL в байтах.

0x04

0x02

ACE Count

Число применяемых в этом ACL ACE.

0x06

0x02

Padding

Заполнение.

Всякий ACL составлен из перечня Элементов управления доступом (Access Control Entries, ACE). Каждый ACE определяет те права доступа, которые должны быть разрешены/ запрещены (либо регистрироваться в случае когда ACE это SACL) для конкретного пользователя/ группы. Обратите внимание, что когда нет никакого DACL, система предоставит все права всем пользователям, но если имеется DACL, который не содержит никаких ACE, система запретит все права всем пользователям. Структура ACE показана в Таблице 7.16.

Таблица 7.16. Структура Элемента управления доступом (ACE).
Смещение Размер Название Описание

0x00

0x01

Тип

Описывает предоставленные данным ACE полномочия. Допустимые значения содержат: 0x00 – Access Allowed - Доступ разрешён; 0x01 – Access Denied - Доступ запрещён; и 0x02 – System Audit - Аудит системы.

0x01

0x01

Флаги

Флаги ACE.

0x02

0x02

Размер ACE

Размер применяемого ACE в байтах.

0x04

0x04

Маска доступа

Маска доступа определяет допустимые типы доступа.

0x08

Переменный

SID

Значение SID, к которому относится данный ACE.

Маска доступа в ACE применяется для определения в точности допустимых прав доступа. Такая маска доступа это структура битовых полей, как это отображено на Рисунке 7.6. Значения конкретных для этого объекта прав доступа и стандартных прав доступа приведены, соответственно, в Таблицах 7.17 и 7.18.

 

Рисунок 7.6


Структура побитовых полей Маски доступа.

Таблица 7.17. Конкретные биты маски доступа к объекту.
Бит Значение

0

FILE_READ_DATA/FILE_LIST_DIRECTORY

1

FILE_WRITE_DATA/FILE_ADD_FILE

2

FILE_APPEND_DATA/FILE_ADD_SUBDIRECTORY/FILE_CREATE_PIPE_INSTANCE

3

FILE_READ_EA/FILE_READ_PROPERTIES

4

FILE_WRITE_EA/FILE_WRITE_PROPERTIES

5

FILE_EXECUTE (Файл)/FILE_TRAVERSE (Каталог)

6

FILE_DELETE_CHILD

7

FILE_READ_ATTRIBUTES

8

FILE_WRITE_ATTRIBUTES

Таблица 7.18. Стандартные биты маски доступа к объекту.
Бит Значение

16

DELETE

17

READ_CONTROL

18

WRITE_DAC

19

WRITE_OWNER

20

SYNCHRONIZE

Побитовое поле маски доступа в сочетании с типом доступа и значением SID отражают какие действия разрешены/ запрещены для выполнения определённым пользователям.

$VOLUME_NAME (0x60)

$VOLUME_NAME обнаруживается только в записи MFT для файла $VOLUME ( запись MFT: 3d. Этот атрибут содержит значение метки тома, которая была назначена данному устройству во время создания. Листинг 7.6 показывает атрибут $VOLUME_NAME. Выделены значения заголовка атрибута, резидентный заголовок и данные.

 

Листинг 7.6. Образец атрибута $VOLUME_NAME.


000d68: 6000 0000 2800 0000 0000 1800 0000 0400 ‘...(...........
000d78: 0e00 0000 1800 0000 4e00 5400 4600 5300 ........N.T.F.S.
000d88: 2d00 4600 5300 0000 -.F.S...
0000000: 0102 0000 0000 0005 2000 0000 0800 2771 5e212002 0000 ................

Структура данных этого атрибута очень простая, это просто кодированная UTF-16 метка тома. Значения смещения этих данных и размера данных находятся в резидентном заголовке атрибута ($VOLUME_NAME всегда резидентный). В Листинге 7.6 значение смещения данных равно 0x18, а данные имеют размер 0x0E. Значение метки тома это "NTFS-FS".

$VOLUME_INFORMATION (0x70)

Аналогично $VOLUME_NAME, $VOLUME_INFORMATION это другой атрибут, который находится лишь в файле $VOLUME (запись MFT, 3). Листинг 7.7 показывает содержимое представителя атрибута $VOLUME_INFORMATION.

 

Листинг 7.7. Содержимое образца атрибута $VOLUME_INFORMATION в записи MFT $Volume.


000d90: 7000 0000 2800 0000 0000 1800 0000 0500 p...(...........
000da0: 0c00 0000 1800 0000 0000 0000 0000 0000 ................
000db0: 0301 0000 0000 0000 ........

И опять- таки, этот атрибут всегда резидентный и по размеру состоит из 0x28 байт. Значение резидентного заголовка выдаёт аналитику сведения, что данные начинаются по x18 и в длину имеют 0x0C байт. Данные интерпретируются при помощи Таблицы 7.19.

Таблица 7.19. Структура атрибута $VOLUME_INFORMATION. Значения взяты из Листинге 7.7.
Смещение Размер Название Описание Значение

0x00

0x08

не используется

Не применяется - обычно нули

0x00

0x08

0x01

Главная версия FS

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

0x03

0x09

0x01

Дополнительная версия FS

Вспомогательный номер версии файловой системы

0x01

0x0A

0x02

Флаги

Флаги тома (см. Таблицу 7.20)

0x00

Таблица 7.20. Значения флагов для атрибута $VOLUME_INFORMATION в NTFS.
Флаг Описание

0x0001

Изменён (Dirty)

0x0002

Изменить размер $Logfile

0x0004

Обновить Volume в следующий раз

0x0008

Смонтирован в NT

0x0010

Удаление журнала изменений

0x0020

Идентификаторы объекта восстановления

0x8000

Изменён chkdsk

Сочетание основной/ вспомогательной версий $VOLUME_INFORMATION применяется для предоставления значения возраста файловой системы. Значение 1.2 обычно создаётся под Windows NT, 3.0 была создана под Windows 2000, в то время как 3.1 это нечто созданное со времени WindowsXP. Большинство встречающихся версий файловых систем NTFS обладают версией 3.1.

$DATA (0x80)

Атрибут $DATA применяется для обнаружения местоположения содержимого файла. Атрибуты $DATA могут быть как резидентными, так и не резидентными. Они не обладают никакой реальной структурой и целиком зависят собственно от содержимого файла. Этот атрибут в основном используется для определения местоположения содержимого. В случае когда первичный атрибут $DATA резидентный (к примеру, для чрезвычайно маленьких файлов), содержимое такого файла находится непосредственно в самой записи MFT, а следовательно, не занимает на диске никаких кластеров. Местоположение не резидентного $DATA определяется через находящиеся в заголовке не резидентного атрибута данные.

Одна запись MFT может содержать множество атрибутов $DATA. Обычно на них ссылаются как на альтернативные потоки данных и, как правило, они именуются атрибутами (например, упомянутым ранее ADS Zone.Identifier). В Разделе 7.3.4 представлена обработка такого ADS.

$INDEX_ROOT (0x90)

Для хранения записей каталога применяются структуры индекса NTFS и они организованы B- деревьями. Существует два вида атрибутов индекса, $INDEX_ROOT и $INDEX_ALLOCATION. В случае небольших структур индекса (к примеру, каталога лишь с небольшим числом файлов) все имеющиеся элементы перечисляются в резидентной структуре $INDEX_ROOT. В ситуации, когда объём данных слишком велик для резидентной структуры, вместо этого применяется не резидентная структура $INDEX_ALLOCATION.

Листинг 7.8 отображает пример атрибута $INDEX_ROOT. Такой атрибут $INDEX_ROOT всегда является атрибутом с названием , причём это название постоянно $I30. Данные такого атрибута составляются 16d байтами заголовка $INDEX_ROOT, за которым следуют заголовок узла, а далее последовательность записей каталога. Такие записи каталога, помимо всего прочего, содержат атрибут $FILENAME, предоставляющий сведения о каждом из файлов этого каталога.

 

Листинг 7.8. Атрибут $INDEX_ROOT из записи MFT с номером 65d в NTFS_V1.E01.


014550: 9000 0000 2001 0000 0004 1800 0000 0200 .... ...........
014560: 0001 0000 2000 0000 2400 4900 3300 3000 .... ...$.I.3.0.
014570: 3000 0000 0100 0000 0010 0000 0100 00003000 0000 0100 0000 0010 0000 0100 0000 0...............
014580: 1000 0000 f000 0000 f000 0000 0000 0000 ................
014590: 4400 0000 0000 0100 6800 5600 0000 0000 D.......h.V.....
0145a0: 4100 0000 0000 0100 5af1 3490 bc0b da01 A.......Z.4.....
0145b0: 9d03 3590 bc0b da01 9d03 3590 bc0b da01 ..5.......5.....
0145c0: 5af1 3490 bc0b da01 4800 0000 0000 0000 Z.4.....H.......
0145d0: 4200 0000 0000 0000 2000 0000 0000 0000 B....... .......
0145e0: 0a00 6400 6500 6c00 6500 7400 6500 2e00 ..d.e.l.e.t.e...
0145f0: 7400 7800 7400 0000 4200 0000 0000 4b00 t.x.t...B.....K.
014600: 6800 5400 0000 0000 4100 0000 0000 0100 h.T.....A.......
014610: 8ee3 3a81 bc0b da01 8e90 3b81 bc0b da01 ..:.......;.....
014620: 8e90 3b81 bc0b da01 8ee3 3a81 bc0b da01 ..;.......:.....
014630: 0040 0400 0000 0000 3d31 0400 0000 0000 .@......=1......
014640: 2000 0000 0000 0000 0900 6800 6900 6c00 .........h.i.l.
014650: 6c00 7300 2e00 6a00 7000 6700 0000 0000 l.s...j.p.g.....
014660: 0000 0000 0000 0000 1000 0000 0200 0000 ................

Таблица 7.21 представляет структуру заголовка $INDEX_ROOT.Все включённые в эту таблицу значения взяты из Листинга 7.8. Одним из наиважнейших пунктов сведений, предоставляемых в данном заголовке, выступает значение типа атрибута в самом индексе. В таблице 7.21 значение типа атрибута равно 0x30, что является атрибутом $FILENAME. Как и ожидалось, атрибут $FILENAME содержит значение имён файла согласно перечисляемого содержимого каталога.

Таблица 7.21. Структура заголовка $INDEX_ROOT со значениями из Листинге 7.8.
Смещение Размер Название Описание Значение

0x00

0x04

Тип

Значение типа атрибута в индексе

0x30 (48d)

0x04

0x04

Правило сортировки

Надлежащие к применению правило сортировки

0x01 (1d)

0x08

0x04

Размер записи

Размер каждой записи индекса в байтах

0x1000 (4096d)

0x0C

0x01

Размер записи

Размер каждой записи индекса в кластерах

0x0001 (1d)

0x0D

0x03

не используется

 

0x30 (48d)

Заголовок $INDEX_ROOT следует непосредственно за заголовком узла. Эта структура позволяет определять местоположение записей индекса. Структура заголовка узла представлена в Таблице 7.22. Отображаемые в Таблице 7.22 значения взяты из Листинга 7.8.

Таблица 7.22. Структура заголовка узла $INDEX_ROOT со значениями из Листинге 7.8.
Смещение Размер Название Описание Значение

0x00

0x04

Смещение списка индексов

Смещение в байтах до начала Списка записей индекса (относительно начала самого заголовка узла)

0x10 (16d)

0x04

0x04

Смещение конца индексов

Смещение в байтах до окончания Списка записей индекса (относительно начала самого заголовка узла)

0xF0 (240d)

0x08

0x04

Смещение буфера индексов

Смещение в байтах до конца выделенного буфера Списка записей индекса (относительно начала самого заголовка узла)

0xF0 (240d)

0x0C

0x04

Флаги

 

0x00 (0d)

0x0D

0x03

не используется

 

0x30 (48d)

Заголовок узла делает возможным определение местоположения самой первой записи в индексе (0x10). Значение смещения в байтах предоставляется относительно начала самого заголовка узла. Значение типа из заголовка $INDEX_ROOT определяет присутствующий тип записи. В нашем случае это атрибуты $FILENAME . Беглый взгляд на Листинг 7.8 показывает, что имеются два файла, delete.txt и hills.jpg.

$INDEX_ALLOCATION (0xA0)

Когда число записей в неком индексе достаточно велико для резидентной структуры $INDEX_ROOT, вместо неё применяется не резидентная структура $INDEX_ALLOCATION. В ситуации, когда помимо атрибута $INDEX_ALLOCATION всё ещё имеется атрибут $INDEX_ROOT, состояние выделения записей индекса организует атрибут $BITMAP.

Всякий атрибут $INDEX_ALLOCATION содержит записи индекса с фиксированной длиной, причём каждая из них содержит единственный узел дерева. Величина размера каждой записи индекса определяется в соответствующей структуре $INDEX_ROOT.

Каждая запись составлена из заголовка записи индекса, за которым следует заголовок узла и далее перечень записей. Заголовок узла в точности соответствует той же структуре, сто и атрибут $INDEX_ROOT (Таблица 7.22). Структура заголовка записи индекса задаётся в Таблице 7.23.

Таблица 7.23. Структура заголовка записи индекса.
Смещение Размер Название Описание

0x00

0x04

Подпись

Подпись заголовка записи индекса (INDX).

0x04

0x02

Смещение адресных привязок

Значение смещения до массива адресных привязок

0x06

0x02

Размер адресных привязок

Число записей в массиве адресных привязок

0x08

0x02

LSN

Номер Log File Sequence (последовательность системного журнала)

0x10

0x10

VCN

Номер виртуального кластера данной записи в этом потоке индексов

$BITMAP (0xB0)

Маска побитного отображения (или состояние выделения) описывает значение состояния выделения некого элемента в вычислительной системе. Для NTFS эти сведения содержит атрибут $BITMAP (обращаем ваше внимание также на то, что также имеется файл $Bitmap, который содержит значения состояний выделения кластеров для данной файловой системы - запись MFT 6 - важно не путать их). Атрибут $BITMAP всегда находится в самой записи MFT для $MFT. Листинг 7.9 отображает некую выжимку из побитного отображения выделения.

 

Листинг 7.9. Часть примера структуры побитового отображения представляющей запись состояния выделения MFT.


002000: ffff 0007 0000 0000 0706 0000 0000 0000 ................

В структуре побитового отображения всякий элемент представлен единственным битом. Значение 1 бита означает выделение данного элемента, в то время как 0 подразумевает что он не выделен. Самый первый байт представляет элементы 0 - 7 (нулевой бит представлен самым младшим битом, в то время как элемент 7 представлен старшим битом). Второй байт представляет элементы 8 - 15 и так далее.

Рассмотрим байт со смещением 0x03 из Листинга 7.9. Он обладает значением 0x07, что, в двоичном представлении является 0b00000111. Поскольку это четвёртый байт из побитного представления, он соответствует состоянию выделения элементов 24d) - 31d). Три младших бита отмечены как выделенные, что означает, что элементы 24d), 25d) и 26d) выделены, в то время как остальные представленные этим байтом элементы не выделены (они все имеют значение 0).

$REPARSE_POINT (0xC0)

Точка повторного анализа предоставляет возможность расширения файловой системы NTFS. Точки повторного анализа состоят из тега и данных. Значение тега указывает на приложение/ фильтр, которые надлежит применять к его данным. Различные теги точки повторного анализа могут определяться приложением/ производителем, однако имеются некоторые стандартно применяемые теги. Они содержат символические ссылки, точки соединения каталогов, точки монтирования томов и так далее. Таблица 7.24 предоставляет структуру для атрибута $REPARSE_POINT.

Таблица 7.24. Структура атрибута $REPARSE_POINT.
Смещение Размер Название Описание

0x00

0x04

Тип вторичного анализа

Значение типа используемой точки повторного анализа.

0x04

0x02

Длина (n)

Значение длины данных атрибута $REPARSE_POINT (n).

0x06

0x02

Заполнение

Заполнение (нули).

0x08

(n)

Данные

Собственно данные для этой $REPARSE_POINT. Их структура зависит от встреченного типа $REPARSE_POINT.

Значение типа повторного анализа подразделяется на три составные части. Последние 16d бит представляют тип точки повторного анализа, представленной значением атрибута $REPARSE_POINT. Следующие 13d бит зарезервированы для последующего применения, в то время как три первых бита обладают особым значением. Будучи установленным, бит 29d информирует аналитика что данная $REPARSE_POINT это псевдоним иного системного объекта. Когда установлен бит 30d, это сигнализирует аналитику, что доступ к первому байту данных будет медленным (например, когда данные находятся на внешнем ленточном накопителе). Такой бит носит название бита большой задержки. Наконец, самый старший бит именуется битом Microsoft. Он устанавливается для заявленных Microsoft тегов. Для определяемых пользователем тегов его значением должен быть 0.

Рассмотрим тип повторного анализа со значением 0xA0000003. Его младшие 16d бит представляют значение 3d, что означает значение типа записи (в данном случае точку соединения/ монтирования). Три самых старших бита это 0b101, что означает, что данный тег Microsoft и он синоним некого иного типа объекта файловой системы.

Сами данные зависят от типа атрибута $REPARSE_POINT. В ситуации точки монтирования/ соединения (тип: 0xA0000003) структура этих данных отображена в Таблице 7.25.

Таблица 7.25. Структура атрибута $REPARSE_POINT с типом 0xA0000003.
Смещение Размер Название Описание

0x00

0x02

Смещение целевого имени

Смещение в байтах до начала целевого имени относительно конца данной структуры (0x08 в данных/ 0x10 в структуре атрибута $REPARSE_POINT).

0x02

0x02

Длина целевого имени (n)

Значение длины целевого имени в байтах.

0x04

0x02

Смещение выводимого на печать имени

Смещение в байтах до начала выводимого на печать имени относительно конца данной структуры (0x08 в данных/ 0x10 в структуре атрибута $REPARSE_POINT).

0x08

(n)

Длина выводимого на печать имени (p)

Значение длины выводимого на печать имени в байтах.

$EA_INFORMATION (0xD0) и $EA (0xE0)

Атрибуты $EA_INFORMATION совместно с $EA используются для реализации Extended Attributes из HPFS OS/2. Эти атрибуты встречаются редко; следовательно, данный раздел в целом лишь задаёт Таблицами 7.26 и 7.27 структуру этих атрибутов. Оба атрибута могут быть как резидентными, так и не резидентными.

Хотя это и не обычное их применение, одним из наиболее частых вариантов выявления расширенных атрибутов выступает их применение в качестве сокрытия вредоносного программного обеспечения. В тех редких ситуациях, когда они имеют место в ходе расследования, они могут представлять интерес!

Таблица 7.26. Структура атрибута $EA_INFORMATION.
Смещение Размер Название Описание

0x00

0x02

Упакованный размер

Размер упакованного расширенного атрибута.

0x02

0x02

Число EA

Значение числа расширенных атрибутов, которые обладают установленным флагом NEED_EA.

0x04

0x02

Распакованный размер

Размер распакованного расширенного атрибута.

Таблица 7.27. Структура атрибута $EA.
Смещение Размер Название Описание

0x00

0x04

Смещение следующего EA

Смещение для следующего EA.

0x04

0x01

Флаги

Флаги – 0x80: NEED_EA.

0x05

0x01

Длина названия (n)

Длина названия расширенного атрибута.

0x06

0x02

Длина значения (v)

Длина значения расширенного атрибута.

0x08

(n)

Название

Название расширенного атрибута.

0x08 + (n)

(v)

Значение

Значение расширенного атрибута.

Анализ NTFS

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

Создание файловых систем NTFS

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

Листинг 7.10 показывает применяемую для создания NTFS в Linux команду. В данном примере определяется лишь метка тома.

 

Листинг 7.10. Создание файловой системы NTFS из терминала Linux.


$ sudo mkfs.ntfs -L "NTFS FS" /dev/sdb1
Cluster size has been automatically set to 4096 bytes.
Initializing device with zeroes: 100% - Done.
Creating NTFS volume structures.
mkntfs completed successfully. Have a nice day.
$

Поддерживаемые файлы образов NTFS

Для целей демонстрации на протяжении этой главы используется ряд образов диска NTFS. Данные образы доступны на вебсайте этой книги. Таблица 7.28 суммирует все доступные образы.

Таблица 7.28. Структура атрибута $EA.
Образ файла Описание

NTFS_V1.E01

Базовая файловая система, содержащая четыре файла и один каталог. Один из этих файлов содержит альтернативный поток данных.

NTFS_V2.E01

NTFS_V1.E01 со множеством ссылок на один из файлов и двумя удалёнными файлами

NTFS_V3.E01

Этот образ содержит фрагментированные файлы.

Анализ NTFS вручную

Для успешного анализа файловой системы NTFS имеется ряд шагов, которых надлежит придерживаться. Эти шаги подробно описываются в данной разделе. Вот они:

  1. Обработать $Boot: Для определения местоположения структур файловой системы (в особенности $MFT) и для получения сведений обо всей файловой системы как целого необходимо обработать структуру $Boot.

  2. Восстановить $MFT: Главная таблица файлов (master file table, $MFT) выступает одним из важнейших применяемых для анализа NTFS файлов. Он содержит сведения относительно всех отдельных файлов в всвоей файловой системе. Когда мы говорим что всё в NTFS это файлы, мы подразумеваем что данная структура содержит информацию обо всех структурах данной файловой системы помимо созданных пользователем файлов и каталогов.

  3. Обработать каталоги: При обработке каталогов можно создавать перечень файлов. Это позволяет создавать список всего содержимого в данной файловой системе.

  4. Восстановить метаданные: Файл метаданных хранится в $MFT. Следующий шаг состоит в восстановлении метаданных для каждого содержащегося в нашей файловой системе файла.

  5. Восстановить содержимое: Заключительным шагом анализа NTFS является восстановление содержимого файла.

Обработка $Boot

Как и для всех задач анализа при расследовании файловой системы, анализ NTFS начинается с восстановления сведений о данной файловой системе в целом. Они включают в себя размеры элементов (секторов/ кластеров) базового хранилища, а также жизненно важных для файловой системы структур, таких как $MFT (и к тому же $MFTMirr в случае разрушений в первичном $MFT). Для автоматического обеспечения этими сведениями Sleuthkit предоставляет команду fsstat. Листинг 7.11 показывает вывод fsstat при её исполнении в дисковом образе NTFS_V1.E01.

 

Листинг 7.11. Частичный ввод fsstat для NTFS_V1.E01. Подчёркнутые сведения могут быть восстановлены непосредственно из $Boot.


FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: 2BEFA0611D6F5839
OEM Name: NTFS
Volume Name: NTFS-FS
Version: Windows XP

METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 4
First Cluster of MFT Mirror: 16383
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 69
Root Directory: 5

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 32766
Total Sector Range: 0 - 262142

$AttrDef Attribute Values:
$STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident
$ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident
$FILE_NAME (48) Size: 68-578 Flags: Resident,Index
...[snip]...

На самом деле вывод из fsstat вырабатывается путём обработки двух структур файловой системы. Первые три раздела (Сведения файловой системы, Сведения о метаданных, Сведения о содержимом) вырабатываются из файла $Boot в NTFS, который изучается в данном разделе. Остальной раздел, Значения атрибута $AttrDef, производятся из файла $AttrDef. Этот файл содержит информацию обо всех возможных атрибутах в своей файловой системе NTFS. Листинг 7.12 показывает содержимое $Boot из NTFS_V1.E01, в то время как таблица 7.29 отображает некоторые обработанные из $Boot значения.

 

Листинг 7.12. Обрезок $Boot из NTFS_V1.E01.


000000: eb52 904e 5446 5320 2020 2000 0208 0000 .R.NTFS .....
000010: 0000 0000 00f8 0000 3f00 ff00 0008 0000 ........?.......
000020: 0000 0000 8000 8000 ffff 0300 0000 0000 ................
000030: 0400 0000 0000 0000 ff3f 0000 0000 0000 .........?......
000040: f600 0000 0100 0000 3958 6f1d 61a0 ef2b ........9Xo.a..+
Таблица 7.29. Обработанные значения из структуры $Boot в NTFS_V1.E01.
Смещение Размер Название Описание

0x03

0x08

Имя OEM

NTFS

0x0B

0x02

Размер сектора

0x200 (512d)

0x0D

0x01

Секторов в кластере

0x08 (512 × 8 = 4096d)

0x28

0x08

Число секторов

0x3FFFF (262 143d)

0x30

0x08

Местоположение MFT

0x04 (4d)

0x38

0x08

Местоположение MFTMirr

0x3FFF (16 383d)

0x40

0x01

Размер записи MFT

0xF6 (−10d)

(−10d → 210 = 1024d)

0x48

0x08

Серийный номер

0x2BEFA0611D6F5839

Сопоставление вывода fsstat (Листинг 7.11) с содержимым Таблицы 7.29 показывает, что из $Boot можно восстановить множество сведений. Например, в этой структуре имеется имя OEM, наряду с размерами сектора и кластера. Величины диапазонов секторов и кластеров могут быть вычислены из доступных здесь сведений. Общее число секторов равно 262 143d; поскольку для всех структур в NTFS нумерация начинается с 0d, это подразумевает диапазон секторов начиная с 0d по 262 142d, что и показывает fsstat.

Здесь нет соответствующего вывода для общего числа кластеров; тем не менее, предоставляется значение числа секторов в кластере (8d). Общее число кластеров можно вычислить, воспользовавшись:

numClusters = int (sectorsPerCluster / numSectors )

В данном случае это приводит к 32 767d. И снова, поскольку вся нумерация стартует с 0d, в результате это даёт нам диапазон кластеров с 0d по 32 766d. Также обратите внимание, что в данном примере в самом конце устройства также присутствуют семь секторов, не относящихся ни к какому кластеру!

$Boot также снабжает сведениями относительно Главной таблицы файлов (MFT). Значение первого кластера структуры $MFT находится в самой структуре $Boot. В таблице 7.29 это значение равно 4d; зная размер кластера в данном образе, мы можем установить, что самый первый кластер $MFT можно отыскать по смещению в байтах 4 × 4096 = 16 384d. Однако это предоставляет нам только самый первый кластер искомого файла $MFT. Для восстановления всего содержимого $MFT следует обработать самую первую запись из этого кластера. Это сделает возможным восстановление всего файла $MFT целиком (Во всех файловых системах NTFS самая первая запись MFT - 0d - это запись для самого $MFT!) $MFT настолько жизненно необходим для файловой системы NTFS, что поддерживается зеркало самого первого кластера $MFT. Его местоположение также находится в $Boot. Согласно Таблицы 7.29, его можно найти в кластере 16 383d.

Окончательным элементом необходимых для обработки сведений является размер записи MFT. Хотя обычно это 1024d байт, он может изменяться в процессе создания файловой системы. Значение, которое для этого располагается в $Boot равно 0xF6. Это два представленных обратным видом числа (см. Раздел 3.2.7), которые имеют значение -10d. Поскольку это отрицательное значение, размер записи MFT равен 2, возведённым в степень абсолютной величины этого значения. Иными словами, размер записи MFT равен 210 = 1024d байт.

Восстановление $MFT

Наш следующий шаг после обработки $Boot заключается в восстановлении Главной таблицы файлов (MFT, master file table). Помимо значения размера каждой записи MFT, самый первый кластер получается из $Boot. Самая первая запись MFT это $MFT сам по себе (В случае ошибки в файле $MFT, вторя запись это $MFTMirr). Из Таблицы 7.29 известно, что размер записи MFT равен 1024d. Листинг 7.13 отображает запись MFT для $MFT из NTFS_V1.E01 (обращаем внимание на то, что часть нулевых байт из самого конца записи были удалены). Данная запись начинается с Заголовка записи MFT, за которым следуют эти выделенные альтернативные атрибуты.

 

Листинг 7.13. Запись MFT для $MFT в NTFS_V1.E01.


004000: 4649 4c45 3000 0300 0000 0000 0000 0000 FILE0...........
004010: 0100 0100 3800 0100 9801 0000 0004 0000 ....8...........
004020: 0000 0000 0000 0000 0400 0000 0000 0000 ................
004030: 0700 0000 0000 0000 1000 0000 6000 0000 ............‘...
004040: 0000 1800 0000 0000 4800 0000 1800 0000 ........H.......
004050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
004060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
004070: 0600 0000 0000 0000 0000 0000 0000 0000 ................
004080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
004090: 0000 0000 0000 0000 3000 0000 6800 0000 ........0...h...
0040a0: 0000 1800 0000 0200 4a00 0000 1800 0100 ........J.......
0040b0: 0500 0000 0000 0500 0069 b830 bc0b da01 .........i.0....
0040c0: 0069 b830 bc0b da01 0069 b830 bc0b da01 .i.0.....i.0....
0040d0: 0069 b830 bc0b da01 0070 0000 0000 0000 .i.0.....p......
0040e0: 006c 0000 0000 0000 0600 0000 0000 0000 .l..............
0040f0: 0403 2400 4d00 4600 5400 0000 0000 0000 ..$.M.F.T.......
004100: 8000 0000 4800 0000 0100 4000 0000 0100 ....H.....@.....
004110: 0000 0000 0000 0000 1200 0000 0000 0000 ................
004120: 4000 0000 0000 0000 0030 0100 0000 0000 @........0......
004130: 0014 0100 0000 0000 0014 0100 0000 0000 ................
004140: 1113 0400 0000 0000 b000 0000 4800 0000 ............H...
004150: 0100 4000 0000 0300 0000 0000 0000 0000 ..@.............
004160: 0000 0000 0000 0000 4000 0000 0000 0000 ........@.......
004170: 0010 0000 0000 0000 1000 0000 0000 0000 ................
004180: 1000 0000 0000 0000 1101 0200 0000 0000 ................
004190: ffff ffff 0000 0000 0000 0000 0000 0000 ................

Таблица 7.30 суммирует значения атрибутов, присутствующих в записи MFT для $MFT. Как и ожидалось, присутствует атрибут $STANDARD_INFORMATION, который предоставляет метаданные относительно самого файла $MFT. Он следует за атрибутом $FILENAME. Ознакомление с ASCII значениями $атрибута $FILENAME из Листинга 7.13 показывает, сто значением его имени, как и ожидалось, выступает $MFT. Заключительными двумя атрибутами являются $DATA и $BITMAP. Значение атрибута $DATA предоставит местоположение содержимого данного файла, а значение атрибута $BITMAP сообщает какие записи MFT используются/ свободны.

Таблица 7.30. Выявленные в записи MFT для $MFT атрибуты из NTFS_V1.E01.
ID типа Название Размер Резидент

0x10

$FILENAME

0x68 (104d)

Да

0x30

$STANDARD_INFORMATION

0x60 (96d)

Да

0x80

$DATA

0x48 (72d)

Нет

0xB0

$BITMAP

0x48 (72d)

Нет

Для восстановления всего содержимого самого файла MFT надлежит проанализировать значение атрибута $DATA. Из Таблицы 7.30 видно, что этот атрибут не резидентный. Значение этого атрибута самого по себе представлено в Листинге 7.14. Значение атрибута начинается с общего заголовка атрибута, за которым следует не резидентный заголовок (выделенный). Обработанные заголовки отражены в Таблице 7.31.

 

Листинг 7.14. Атрибут $DATA для записи 0 MFT (файл $MFT) в NTFS_V1.E01. Выделены заголовки самого атрибута и не резидента.


004100: 8000 0000 4800 0000 0100 4000 0000 0100 ....H.....@.....
004110: 0000 0000 0000 0000 1200 0000 0000 0000 ................
004120: 4000 0000 0000 0000 0030 0100 0000 0000 @........0......
004130: 0014 0100 0000 0000 0014 0100 0000 0000 ................
004140: 1113 0400 0000 0000 ........

Из Таблицы 7.31 получены следующие сведения:

  • Этот атрибут $DATA представлен в первых 19d кластерах содержимого файла (начальный VCN это кластер 0d, а последний VCN это 18d).

  • Итого наш кластер размещён в 19d (выделенное пространство равно 0x13000, в то время как размер кластера равен 0x1000). В сочетании с этими сведениями предыдущего пункта означает, что для этого файла требуется лишь один атрибут $DATA.

  • Потенциально в конце данного файла имеется пустое пространство. Под файл выделено 0x13000, однако его реальный размер равен 0x11400. Это подразумевает потенциально 0x1C00 пустых байт в самом конце файла.

  • Значение списка последовательности находится по смещению 0x40 от начала этого атрибута. Значение списка последовательности равно 0x111304.

Таблица 7.31. Частично обработанная структура заголовка не резидентного атрибута в файле $MFT атрибута $DATA.
Смещение Размер Название Описание

0x00

0x10

Общий заголовок

Тип: 0x80 ($DATA)

Размер: 0x48 (72d)

Резидентный: Нет

Длина имени: 0x00 (0d)

Смещение имени: 0x40 (64d)

Флаги: 0x00 (0d)

ID атрибута: 0x01 (1d)

0x10

0x08

Начальный кластер

0x00 (0d)

0x18

0x08

Последний кластер

0x12 (18d)

0x20

0x02

Смещение списка последовательности

0x40 (64d)

0x28

0x08

Размер выделенного пространства

0x13000 (77 824d)

0x30

0x08

Реальный размер

11400 (70 656d)

0x38

0x08

Инициализированный размер

11400 (70 656d)

Для восстановления содержимого далее следует интерпретировать содержимое списка последовательности. Возвращаясь к Рисунку 7.5, видим, что в данной ситуации число байт, используемых для начального кластеров и значения числа непрерывных кластеров равно 1d. Это подразумевает, что наш список последовательности представлен 0x13 непрерывными кластерами, начинающимися с кластера 0x04. Листинг 7.15 отображает команду dd, которой можно воспользоваться для выделения данного файла. Также показан sleuthkitс обоими результатами для сравнения их значений MD5.

 

Листинг 7.15. Применение dd для восстановления содержимого $MFT из NTFS_V1.E01


$ dd if=mnt/ewf1 of=mft.dd.raw bs=1 skip=$((4*4096))
count=$((0x11400))
70656+0 records in
70656+0 records out
70656 bytes (71 kB, 69 KiB) copied, 1.83432 s, 38.5 kB/s
$
$ md5sum mft.*
dc382d0e7992af4dfad9d35f708eace9 mft.dd.raw
dc382d0e7992af4dfad9d35f708eace9 mft.tsk.raw

Раз $MFT был восстановлен, теперь у нас для анализа имеются все сведения относительно исследуемой файловой системы. Этот процесс продолжается перечислением всех имеющихся в данной файловой системе файлов/ каталогов.

Обработка каталогов

Восстановление метаданных файла

Восстановление содержимого файла

Расширенный анализ NTFS

Последующие сведения файловой системы

Удалённые файлы

Фрагментированные файлы

Альтернативные потоки данных

Большие записи MFT

Выводы

Упражнения

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