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

Категорія даних файлової системи включає дані, що описують файлову систему в цілому, причому ці дані зазвичай не відповідають конкретному користувацькому файлу. У NTFS ці дані зберігаються у файлах метаданих файлової системи, представлених іменами в кореневому каталозі. За винятком завантажувального коду, ці дані можуть зберігатися у файловій системі в будь-якому місці диска. В цих файлів є одна цікава особливість: з ними, як і із звичайними файлами, можуть асоціюватися позначки дати і часу. Мої експерименти показали, що тимчасові штампи відповідають часу створення файлової системи, що інколи може згодитися при аналізі. В цьому розділі розглянуто всі файли метаданих файлової системи.

18.1.1 Файл $MFT

Одним з найважливіших файлів метаданих файлової системи є файл $MFT. В ньому зберігається головна файлова таблиця MFT (Master File Table), яка містить записи для кожного файлу і каталога в системі. Отже, таблиця MFT необхідна для пошуку інших файлів. Початкова адреса MFT вказується в завантажувальному секторі. Інформація про будову MFT береться із запису 0 самої таблиці.

Початковому запису MFT привласнюється ім'я $MFT, а її атрибут $DATA містить інформацію про кластери, використовувані MFT. Файл $MFT також володіє атрибутом $ВІТМАР, який описує стан виділення записів MFT. Крім того, у нього є стандартні атрибути $FILE_NAME і $STANDARD_INFORMATION.

У Windows файл $MFT починається з мінімального розміру і розширюється у міру створення додаткових файлів і каталогів. Файл $MFT може фрагментуватися, але під його розширення спочатку резервується частина дискового простору.

Кажучи про файли метаданих файлової системи, я використовуватиму тестовий образ файлової системи і програмуistat з пакету TSK (The Sleuth Kit). В лістингу 18.1 наводимо лише дані, такі, що відносяться до категорії файлової системи:

 

Лістинг 18.1 – Категорія файлової системи

# istat -f ntfs ntfsl.dd 0

$STANDARD_ІNFORMATION Attribute Values:

Flags: Hidden, System

Owner IF: 0 Security ID: 256

Created: Thu Jun 26 10:17:57 2003

File Modified: Thu Jun 26 10:17:57 2003

MFT Modified: Thu Jun 26 10:17:57 2003

Accessed: Thu Jun 26 10:17:57 2003

[...]

Attributes:

Type: $STANDARD_ІNFORMATION (16-0) Name: N/A Resident size: 72

Type: $FILE_NAME (48-3) Name: N/A Resident size: 74

Type: $DATA (128-1) Name: $Data Non-Resident size: 8634368

342709 342710 342711 342712 342713 342714 342715 342716

342717 342718 342719 342720 342721 342722 342723 342724

[...]

443956 443957 443958 443959 443960 443961 443962 443963

Type: $BITMAP (176-5) Name: N/A Non-Resident size: 1056

342708 414477 414478 414479

 

Тимчасові штампи $MFT зазвичай збігаються з моментом створення файлової системи і не оновлюються. З лістингу видно, що файл володіє атрибутами $STANDARD_ІNFORMATION і $FILE_NAME, 8-мегабайтним атрибутом $DATA і атрибутом $ВІТМАР.

18.1.2 Файл $MFTMirr

В попередньому розділі говорилося про те, що файл $MFT дуже важливий, оскільки він використовується для пошуку всіх останніх файлів в системі. А це означає, що пошкодження покажчика в завантажувальному секторі або записі $MFT приведе до повної непрацездатності файлової системи. Для вирішення подібних проблем створюється резервна копія найважливіших записів MFT, яка може використовуватися при відновленні. Запис MFT1 відноситься до файлу $MFTMirr, який має нерезидентний атрибут з резервною копією початкових записів MFT.

Атрибут $DATA файлу $MFTMirr виділяє кластери в середині файлової системи і зберігає копії як мінімум перших чотирьох записів MFT: для $MFT, $MFTMirr $LogFile і $Volume. Якщо з визначенням структури MFT виникають проблеми, програма відновлення може на підставі розміру тому вичислити середній кластер файлової системи і прочитати резервні дані. Кожен запис MFT володіє сигнатурою, по якій її можна розпізнати як запис MFT.

По чотирьох резервних записах програма відновлення визначає будову таблиці MFT і її розмір, місцезнаходження $LogFile для відновлення файлової системи, а також отримує інформацію про версію і статус з атрибутів $Volume.

Наведу приклад інформації про файл $MFTMirr з нашого тестового образу:

 

Лістинг 18.2 – Інформація про файл $MFTMirr

# istat -f ntfs ntfsl.dd 1

Attributes:

Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72

Type: $FILE_NAME (48-2) Name: N/A Resident size: 82

Type: $DATA (128-1) Name: $Data Non-Resident size: 4096

514064 514065 014066 514067

 

В даному прикладі образ містить 1208128 кластерів, а атрибут $DATA запису $MFTMirr починається в середньому кластері. Тимчасові штампи не показані, але вони збігаються з тими, що наводилися раніше для $MFT.

18.1.3 Файл $Boot

Файл метаданих файлової системи $Boot знаходиться в записі MFT 7 і містить завантажувальний сектор файлової системи. Це єдиний файл метаданих файлової системи із статичним розташуванням. Атрибут $DATA завжди зберігається в першому секторі файлової системи, тому що він необхідний для завантаження системи. Microsoft зазвичай виділяє для $Boot перші 16 секторів файлової системи, але я виявив, що лише перша половина містить ненульові дані.

Завантажувальний сектор NTFS дуже схожий на завантажувальний сектор FAT, і вони володіють багатьма спільними полями. У них навіть збігається сигнатура 0хаа55, з чого виходить, що при пошуку втрачених завантажувальних секторів FAT може бути знайдений завантажувальний сектор NTFS (і навпаки). Завантажувальний сектор містить основні параметри файлової системи: розмір кластера, кількість секторів у файловій системі, адреси початкового кластера MFT, розмір запису MFT. Крім того, в завантажувальному секторі зберігається серійний номер файлової системи.

Останні сектори, що виділяються для зберігання атрибуту $DATA запису $Boot, містять завантажувальний код.Завантажувальний код необхідний лише в завантажувальних файлових системах, а його основною функцією є пошук файлів, необхідних для завантаження операційної системи.

Резервна копія завантажувального сектора зберігається або в останньому секторі тому або в середині тому. У моїх експериментах з томами Windows NT 4.0, 2000 і ХР резервна копія зберігалася в останньому секторі. Я виявив, що загальна кількість секторів у файловій системі була менша загальної кількості секторів в томі, тому резервна копія завантажувального сектора не завжди асоціюється з конкретним файлом. Наприклад, у використовуваному нами тестовому образі файлової системи том складається з 2056257 секторів, а, за даними завантажувального сектора, файлова система містить 2056256 секторів. Резервна копія завантажувального сектора зберігається в останньому секторі тому, не виділеному для зберігання файлової системи.

Аби показати, як виглядають атрибути файлу $Boot, я приведу результат запуска istat для тестового образу:

 

Лістинг 18.3 – Атрибути файлу $Boot

# istat -f ntfs ntfsl.dd 7

[...]

Attributes:

Type: $STANDARD_INFОRMATI0N (16-0) Name: N/A Resident size: 48

Type: $FILE_NAME (48-2) Name: N/A Resident size: 76

Type: $SECURITY_DESCRIPTOR (80-3) Name: N/A Resident size: 104

Type: $DATA (128-1) Name: $Data Non-Resident size: 8192

0 12 3 4 5 6 7

З нижньої частини лістингу видно, що запис містить чотири атрибути, у тому числі 8-кілобайтний атрибут $DATA, якому виділені кластери з 0 по 7. Часові штампи не показані, але вони збігаються з тими, що наводилися раніше для $MFT і $MFTMirr.

18.1.4 Файл $Volume

Файл метаданих файлової системи $Volume відповідає запису MFT 3. В ньому зберігається мітка тому і інформація версії. Файл володіє двома унікальними атрибутами, якими не повинні володіти останні файли в системі. У атрибуті $VOLUME_NAME міститься ім'я тому в Unicode, а атрибут $VОLUME_INFORMATION визначає версію NTFS і стан оновлення. Окрім цих атрибутів файл зазвичай володіє атрибутом $DATA, але я виявив, що розмір цього атрибуту складає 0 байт.

З кожною новою версією Windows до файлової системи NTFS вносяться невеликі зміни; номер поточної версії можна знайти у файлі $Volume. У Windows NT 4.0 використовувалася версія 1.2, в Windows 2000 — версія 3.0, а в WindowsXP — версія 3.1. Відмінності між версіями незначні, і у всіх версіях використовуються одні і ті ж основні структури даних.

Атрибути файлу $Volume для нашого тестового образу виглядають так:

 

Лістинг 18.4 – Атрибути файлу $Volume

# istat -f ntfs ntfsl.dd 3

Attributes:

Type: $STANDARD_INFОRMATIОN (16-0) Name: N/A Resident size: 48

Type: $FILE_NAME (48-1) Name: N/A Resident size: 80

Type: $0BJECT_ID (64-6) Name: N/A Resident size: 16

Type: $SECURITY_DESCRIPT0R (80-2) Name: N/A Resident size: 104

Type: $V0LUME_NAME (96-4) Name: N/A Resident size: 22

Type: $V0LUME_INF0RMATI0N (112-5) Name: N/A Resident size: 12

Type: $DATA (128-3) Name: $Data Resident size: 0

Інформація, що цікавить нас, міститься в атрибутах $VOLUME_NAME і $VОLUME_NFORMATION, унікальних для цього запису MFT. Звернемо увагу: атрибут $DATA існує, але його розмір дорівнює 0. Тимчасові штампи не показані, але вони збігаються з тими, що наводилися раніше для $MFT і $MFTMirr.

18.1.5 Файл $AttrDel

До загальної категорії даних файлової системи також відноситься файл метаданих файлової системи $AttrDef, представлений записом MFT 4. Атрибут $DATA цього файлу визначає імена і ідентифікатори типів всіх атрибутів. До речі, це один з прикладів «логічного зациклення», що інколи зустрічається в NTFS: щоб дізнатись, який ідентифікатор типу відповідає файлу $DATA, потрібно спочатку якось прочитати атрибут $DATA файлу $AttrDef. На щастя, атрибутам призначені значення за умовчанням, приведені в розділі 1.

Файл $AttrDef дозволяє файловим системам визначати унікальні атрибути файлів, а також перевизначати ідентифікатори стандартних атрибутів. Атрибути файлу $AttrDef у нашому прикладі виглядають так:

 

Лістинг 18.5 – Атрибути файлу $AttrDef

# istat -f ntfs ntfsl.dd 4

Attributes:

Type: $STANDARD_NFORMATION (16-0) Name: N/A Resident size: 48

Type: $FILE_NAME (48-2) Name: N/A Resident size: 82

Type: $SECURITY_DESCRIPTOR (80-3) Name: N/A Resident size: 104

Type: $DATA (128-4) Name: $Ddta Non-Resident size: 2560

342701 342702 342703

Звернемо увагу: розмір атрибуту $DATA перевищує 2 Кбайт. Тимчасові штампи не показані, але вони збігаються з тими, що наводилися раніше для інших файлів метаданих файлової системи.

Тестовий образ

Ми розглянули інформацію про деякі файли нашого тестового образу, а зараз я приведу результат запуску програми fsstat. Ці дані будуть використані в подальшій роботі.

 

Лістинг 18.6 – Результат запуску програми fsstat

# fsstat -f ntfs ntfsl.dd

FILE SYSTEM INFORMATION

- - - - - - - - - - - - - - - - - - - - - - - - -

File System Type: NTFS

Volume Serial Number: 0450228450227C94

OEM Name: NTFS

Volume Name: NTFS Disk 2

Version: Windows XP

 

МЕТА-data INFORMATION

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

First Cluster of MFT. 342709

First Cluster of MFT Mirror: 514064

Size of MFT Entries: 1024 bytes

Size of Index Records: 4096 bytes

Range: 0 – 8431

Root Directory: 5

 

CONTENT-DATA INFORMATION

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Sector Size: 512 Cluster Size: 1024

Total Cluster Range: 0 – 1028127

Total Sector Range: 0 - 2056255

$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

$ОBJECT_ID (64) Size: 0-256 Flags: Resident

$SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident

$VOLUME_NAME (96) Size: 2-256 Flags: Resident

$V0LUME_INF0RMATI0N (112) Size: 12-12 Flags: Resident

$DATA (128) Size: No Limit Flags:

$INDEX_R00T (144) Size: No Limit Flags: Resident

$INDEX_ALLOCATION (160) Size: No Limit Flags: Non-resident

$BITMAP (176) Size: No Limit Flags: Non-resident

$REPARSE_POINT (92) Size: 0-16384 Flags: Non-resident

$EA_INF0RMATI0N (208) Size: 8-8 Flags: Resident

$EA (224) Size: 0-65536 Flags:

$LOGGED_UTILITY_STREAM (256) Size: 0-65536 Flags: Non-resident

 

Методи аналізу

Аналіз даних в категорії файлової системи направлений на визначення конфігурації і будови файлової системи. У NTFS першим кроком повинна стати обробка завантажувального сектора в першому секторі файлової системи, файлу, що є частиною $Boot. Із завантажувального сектора беруться відомості про початкову адресу MFT і розмірі кожного запису MFT. На підставі цих відомостей обрабляється перший запис MFT, пов'язаний з файлом $MFT. З цього запису береться інформація про місцезнаходження інших записів MFT. Якщо які-небудь дані виявилися пошкодженими, але розмір тому відомий, можна знайти середній сектор файлової системи і взяти з нього резервну копію перших записів MFT, що зберігається у файлі $MFTMirr.

Після визначення будови MFT можна переходити до пошуку і обробки файлів метаданих файлової системи $Volume і $AttrDef. З цих файлів береться інформація про версію файлової системи, мітку тому і визначення спеціальних атрибутів.

Фактори аналізу

Категорія даних файлової системи майже не містить призначених для користувача даних. Завантажувальний сектор знаходиться найпростіше і містить лише базову структурну інформацію. Останні дані зберігаються в одному із записів MFT, але знайти їх «вручну», за допомогою одного лише шістнадцяткового редактора, не так вже просто. Завантажувальний сектор містить ряд значень, які не використовуються NTFS, але Microsoft вимагає, аби деякі з них дорівнювали нулю. Я виявив, що Windows XP відмовляється вмонтовувати файлові системи, в яких ці поля містять ненульові значення.

Невеликий об'єм даних можна приховати всередині завантажувального сектора, але більше вільного місця доступно в кінці файлу $Boot після завантажувального коду. Я виявив тут декілька невживаних секторів. Аби виявити резервний простір тому або невживаний простір після файлової системи слід порівняти кількість секторів у файловій системі з розміром тому. Не забуватимемо, що резервна копія завантажувального сектора часто знаходиться в секторі, наступним за кінцем файлової системи, але до кінця тому.

Тимчасові штампи, що асоціюються з файлами метаданих файлової системи, зазвичай відповідають часу створення файлової системи. Ця обставина може згодитися під час дослідження, якщо нам буде потрібно визначити час форматування диска. Скажімо, по даті форматування можна визначити тривалість використання файлової системи.

Файл $MFT може мати довільний розмір, причому в Windows цей розмір ніколи не зменшується. Кінець файлу може використовуватися для зберігання прихованих даних, проте цей спосіб вельми ризикований, тому що дані можуть бути стерті в ході стандартних операцій. Наприклад, користувач може створити множину файлів, внаслідок чого MFT виросте до великого розміру. Якщо після цього файли будуть видалені, в MFT залишаться невикористовувані записи, в яких можуть розміщуватися приховані дані.

Також може бути корисно проаналізувати атрибути кожного файлу метаданих файлової системи. Можливо, серед них знайдуться додаткові атрибути, додані для зберігання прихованих даних

Сценарій аналізу

В процесі досліджування був виявлений жорсткий диск, з якого були зняті дані. На жаль, диск містив велику кількість пошкоджених секторів, включаючи перший сектор (в якому знаходиться таблиця розділів) і сектор 63 (де зазвичай починається перший розділ). Отже, ми повинні з'ясувати, чи починається розділ з сектора 63, а також визначити його тип і розмір. Диск був взятий з системи Windows XP, і ми передбачаємо, що на ньому використовувалася файлова система NTFS. Образ диска знятий в низькорівневому форматі, а пошкоджені сектори заповнювалися нулями.

Пошук починається з сигнатури завантажувального сектора, тобто значення 0хаа55 в двох останніх байтах секторів. Ми розраховуємо виявити або перший сектор файлової системи NTFS, або сектор, наступний за кінцем файлової системи, в якому зберігається резервна копія. Для проведення пошуку вибрана утиліта sigfind, хоча замість неї можна скористатися будь-якою програмою з можливістю пошуку по шістнадцятковому значенню.

# sigfind -о 510 -1 АА55 disk5.dd

Block size: 512 Offset: 510

Block: 210809 (-)

Block: 210810 (+1)

Block: 210811 (+1)

Block: 210812 (+1)

Block: 210813 (+1)

Block: 210814 (+1)

Block: 210815 (+1)

Block: 210816 (+1)

Block: 318170 (+107354)

Block: 339533 (+21363)

Block: 718513 (+378980)

[...]

В результаті пошуку виявляється серія дуже близьких співпадінь, починаючи із сектора 210809. Картина виглядає не так, як можна було б чекати при виявленні завантажувального сектора на початку файлової системи — далі повинні слідувати завантажувальний код, а не нові копії. Така структура також не характерна і для таблиць розділів, що володіють тією ж сигнатурою.

Проаналізуємо одну з копій і поглянемо, чи є співпадіння помилковим:

# dd if=disk5.dd skip=210809 count=l | xxd

0000000: eb3c 904d 5357 494e 342e 3100 0208 0100.<.MSWIN4.1.....

0000016: 0200 0203 51f8 0800 1100 0400 0100 0000....Q...........

0000032: 0000 0000 8000 2900 0000 004e 4f20 4e41......)....NO NA

0000048: 4d45 2020 2020 4641 5431 3220 2020 33c9 ME FAT12 3.

[...]

Вміст сектора не характерний для файлової системи NTFS; швидше, він нагадує завантажувальний сектор FAT12. Перевіримо співпадіння в наступному секторі:

# dd if=disk5.dd skip=210810 count=l | xxd

0000000: eb58 904d 5357 494e 342e 3100 0202 0800.X.MSWIN4.1.....

0000016: 0100 0400 00f8 0000 1100 0400 0100 0000................

0000032: 0000 0200 e0lf 0000 0000 0000 0000 0000................

0000048: 0100 0600 0000 0000 0000 0000 0000 0000................

0000064: 8000 2900 0000 004e 4f20 4e41 4d45 2020..)....NO NAME

0000080: 2020 4641 5433 3220 2020 33c9 8edl bcf4 FAT32 3.....

[...]

Перед нами базовий шаблон завантажувального сектора файлової системи FAT32. Співпадіння в секторі 210 811 відповідає базовому шаблону структури даних FAT FSINFO, що не містить значень. Схоже, ці збіги не мають відношення до нашого пошуку завантажувального сектора NTFS; у думках беремо їх на замітку і рухаємося далі.

Аби зменшити число помилкових співпадінь, проведемо пошук рядка «NTFS», починаючи з байта 3 сектора; цей рядок є частиною поля OEM. Порівняння результатів пошуку з попередніми співпадіннями допоможе звузити коло пошуку для нашої системи. Слід пам'ятати, що рядок «NTFS» не належить до обово’язкових значень завантажувального сектора NTFS, тому її може і не бути. У шістнадцітковому представленні рядок «NTFS» має вигляд 0х4е544653; деякі програми дозволяють шукати сектори, які містять обидві сигнатури.

# sigfind -0 3 4е544653 disk5.dd

Цього разу кількість співпадінь виявляється набагато меншою. Порівнюючи результати, ми виявляємо, що сектори 1 0755 545, 1 075 561 і 2 056 319 присутні в обох результатах. Вміст сектора 1 075 545 виглядає начебто відповідним, але загальна кількість секторів в ньому дорівнює 0. Те ж відбувається в секторі 1075561; отже, ці дані не потрібні. Швидше за все, вони не належать реальній файловій системі.

Сектор 2 056 319 містить більше ненульових значень, ніж попередні два співпадіння. Поле розміру кластера в ньому дорівнює 1024 байт; кількість секторів — 2056256, а початковий кластер MFT — 342709. Якщо це дійсно завантажувальний сектор, можливі два сценарії. По-перше, це може бути копія, розташовна в першому секторі файлової системи; по-друге, це може бути копія в секторі, який є наступним за кінцем файлової системи. Ми помічаємо, що вказана кількість секторів файлової системи на 64 сектори менше адреси, в якій ми знайшли завантажувальний сектор. Отже, це може бути резервний завантажувальний сектор файлової системи, що починається в секторі 63.

Для перевірки цієї теорії звернемося до MFT. У завантажувальному секторі вказано, що MFT починається з кластера 342 709, що відповідає сектору 685 418 файлової системи і сектору 685 481 диска. Кожен запис MFT починається із сигнатурного рядка «FILE», і ми знаходимо сигнатуру у визначеному місці:

# dd if=disk5.dd skip=685481 count=l | xxd

0000000: 4649 4c45 3000 0300 4ba7 6401 0000 0000 FILE0...K.d.....

[...]

Аби переконатися в тому, що ми дійсно знайшли перший запис MFT, ми повертаємося на два сектори назад (оскільки розмір кожного запису MFT дорівнює 1024 байт) і бачимо, що сектор не починається з сигнатури «FILE»:

# dd if=disk5.dd skip=685479 count=l | xxd

0000000: ffff 00ff ffff ffff ffff ffff ffff ffff................

[...]

Тепер можна з упевненістю сказати, що на диску могла існувати файлова система NTFS, яка починалася в секторі 63 і мала розмір 2056256 секторів. Ми створюємо копію дискового образу і копіюємо резервну копію завантажувального сектора в сектор 63. Аби імпортувати файлову систему у звичайну програму аналізу, можна або витягувати 2056256 секторів з дискового образу, або створити в секторі 0 образу просту таблицю розділів, що містить розділ в секторах 63-2056318.

Категорія даних вмісту

Кластери

Файл NTFS є сукупністю атрибутів. Атрибути діляться на резидентні і нерезидентні: вміст резидентних атрибутів зберігається безпосередньо в записі MFT, тоді як для зберігання вмісту нерезидентних атрибутів виділяються окремі кластери. Кластером називається група суміжних секторів, кількість яких рівне степені 2 (тобто 1, 2, 4, 8, 16).

Кожному кластеру призначається адреса, починаючи з 0. Нумерація починається з першого кластера файлової системи, що створює значно менше плутанини у порівнянні із схемою нумерації FAT. Аби перетворити адресу кластера на адресу сектора, досить помножити його на кількість секторів в кластері:

СЕКТОР = КЛАСТЕР * секторів_в_кластері

NTFS не пред'являє жорстких вимог до будови файлової системи. Будь-який кластер може бути виділений для зберігання будь-якого файлу або атрибуту (за винятком файлу $Boot, який завжди починається з першого сектора). Компанія Microsoft використовує ряд загальних схем пристрою файлової системи. Якщо розмір тому не кратний розміру кластера, деякі сектори в кінці диска не належатимуть жодному кластеру. Загальний розмір цієї зони менше розміру кластера.

18.2.2 Файл $Bitmap

Стан виділення кластера визначається за допомогою файлу метаданих файлової системи, що зберігається в записі MFT 6. Атрибут $DATA цього файлу містить один біт для кожного кластера файлової системи; наприклад, біт 0 представляє кластер 0, а біт 1 представляє кластер 1. Якщо біт дорівнює 1, значить, кластер виділений; якщо біт дорівнює 0, кластер вільний.

Інформація про файл $Bitmap у файловій системі нашого тестового образу виглядає так:

# istat -f ntfs ntfsl.dd 6

[...]

Attributes:

Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72

Type: $FILE_NAME (48-2) Name: N/A Resident size: 80

Type: $DATA (128-1) Name: $Data Non-Resident size: 128520

514113 514114 514115 514116 514117 514118 514119 514120

514121 514122 514123 514124 514125 514126 514127 514128

[...]

Ми бачимо, що файл $Bitmap володіє стандартними атрибутами файлів, а його тимчасові штампи збігаються з тими, що наводилися раніше для інших файлів метаданих файлової системи.

18.2.3 Файл $BadClus

NTFS відстежує пошкоджені кластери, виділяючи їх атрибуту $DATA файлу метаданих файлової системи $BadCLus(запис MFT 8). Атрибут $DATA, якому привласнене ім'я $BAD, зберігається в розрідженому форматі; коли система виявляє пошкоджений кластер, він додається в цей атрибут. Як було сказано вище, розріджений файл економить місце за рахунок відмови від виділення кластерів, якщо вони заповнені нулями. Вказаний розмір атрибуту $Bad відповідає загальному розміру файлової системи, але спочатку йому не виділяється жоден кластер. Виявляючи пошкоджені кластери,Windows додає їх в атрибут $Bad, але багато жорстких дисків виявляють пошкоджені сектори ще до того, як це зробить файлова система.

Інформація про файл $BadCLus у файловій системі нашого тестового образу виглядає так:

# istat -f ntfs ntfsl.dd 8

[...]

Attributes:

Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72

Type: $FILE_NAME (48-3) Name: N/A Resident size: 82

Type: $DATA (128-2) Name: $Data Resident size: 0

Type: $DATA (128-1) Name: $Bad Resident size: 1052803072

Звернемо увагу: файл містить два атрибути $DATA, причому атрибут за умовчанням ($Data) є резидентним і має нульовий розмір. Атрибут $DATA з ім'ям $Bad є нерезидентним і має розмір 1052803072 байти, проте адреси кластерів не показані, тому що файлова система не містить пошкоджених кластерів. Розмір атрибуту збігається з розміром файлової системи, показаним у вихідних даних fsstat.

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

У цьому розділі описано мої спостереження відносно стратегії, яка використовується Windows XP при виділенні нових кластерів NTFS. Як і в інших файлових системах, стратегія виділення залежить від конкретної ОС, і в різних реалізаціях NTFS можуть використовуватися різні стратегії. Я відмітив, що Windows ХР використовує алгоритм оптимального підбору. Це означає, що дані розміщаються так, щоб найефективніше використовувати доступний простір, навіть якщо це не перший або не наступний доступний блок. Відповідно, при невеликому об'ємі записувані дані поміщаються в кластери, що входять до невеликої групи вільних кластерів, — замість великої групи, в якій можуть зберігатися великі файли. Наприклад, в сценарії, показаному на рис. 2.1, для файлу потрібно виділити 10 кластерів. У системі існує три групи вільних кластерів. Перша група знаходиться в кластерах 100-199, друга, — в кластерах 280-319, а третя — в кластерах 370-549. Алгоритм оптимального підбору виділяє під новий файл кластери 280-289, тому що це найменша із можливих груп кластерів, в яких поміститься новий файл.

Структура файлової системи

Файлова система NTFS не володіє жорстко заданою структурою, але при форматуванні файлової системи Windows дотримує ряд загальних правил. В більшості версій NTFS структура розрізняється, але існує цілий ряд спільних концепцій.

До їх числа відноситься концепція зони MFT. Windows створює таблицю MFT мінімального розміру і розширює її лише при необхідності додавання нових записів. Таким чином, виділення простору за MFT для зберігання файлів створює ризик фрагментації таблиці. Аби цього не сталося, Microsoft резервує частину файлової системи для MFT. Зоною MFT (MFT Zone) називається колекція суміжних кластерів, які не використовуються для зберігання вмісту файлів або каталогів до тих пір, поки не буде заповнений весь диск. За умовчанням Microsoft виділяє під MFT 12,5% файлової системи. Після заповнення всієї файлової системи використовується зона MFT.

Всі версії NTFS і Windows виділяють перші кластери файлу $Boot Windows NT і 2000 розміщують файли метаданих файлової системи відразу ж після файлу $Boot і в середині файлової системи. Наприклад, якщо у файловій системі використовуються 1-кілобайтні кластери, то перші 8 кластерів будуть виділено файлу $Boot, а кластери файлу $MFT можуть починатися з кластера 16 або 32. Наступні 12,5% файлової системи потрапляють в зону MFT. Середній кластер файлової системи виділяється файлу $MFTMirr, за ним слідують наступні файли метаданих файлової системи — такі, як $LogFile, $Root, SBitmap і $Upcase. Між Windows NT і 2000 виявилася одна відмінність: NT поміщає файл $AttrDef в останню частину файлової системи, а в Windows 2000 він розміщується перед файлом $MFT.

Експерименти показали, що Windows XP переміщає частину даних до точки, що відзначає третину файлової системи. Так, кластери файлів $LogFile, $AttrDef, $MFT і $Secure виділяються від третини простору файлової системи. Останні файли метаданих файлової системи розміщуються від половини файлової системи. Лише файл $Boot знаходиться в декількох початкових кластерах. Всі кластери між файлами метаданих файлової системи можуть виділятися призначеним для користувача файлам і каталогам. На рис. 18.2 показано місцезнаходження різних файлів метаданих файлової системи, що відформатувана в Windows 2000 або ХР.

Методи аналізу

Аналіз даних в категорії вмісту зазвичай пов'язаний з пошуком конкретного кластера, визначенням його стану виділення і обробкою вмістимого тим або іншим способом. Знайти конкретний кластер нескладно, тому що перший кластер знаходиться на початку файлової системи, а розмір кластера задається в першому секторі.

Аби перевірити стан виділення кластера, слід знайти файл $Bitmap і обробити його атрибут $DATA. Кожен біт цього атрибуту відповідає кластеру у файловій системі.

До стандартних прийомів аналізу належить витягування всього вільного простору файлової системи. У NTFS це завдання вирішується аналізом файлу $Bitmap і витягуванням вмісту всіх кластерів з нульовими бітами. Адміністративні дані файлової системи NTFS зберігаються у файлі, тому вони не розглядатимуться як вільні дані в цьому процесі.

 

Фактори аналізу

Не існує жодних особливих обставин, які необхідно було б враховувати при аналізі категорії вмісту NTFS (на відміну від інших файлових систем). Адресація кластерів починається з першого кластера, тому необхідна лише одна схема адресації. Microsoft зазвичай виділяє під файлову систему лише реально використовуваний простір, тому в кінці файлової системи не повинно бути секторів, що не володіють адресою кластера. З іншого боку, це означає, що після файлової системи і перед кінцем тому можуть зберігатися приховані дані.

При проведенні пошуку немає відмінностей між пошуком по логічному тому і пошуком по логічній файловій системі, тому що кожен сектор, який використовується файловою системою, виділяється кластеру. Оскільки всі дані категорії файлової системи асоціюються з файлами, в будь-якому конкретному випадку має бути зрозуміло, виділений кластер чи ні. Для порівняння пригадаємо, що в системі FAT багато програм розходяться відносно того, чи потрібно розглядати область FAT і зарезервовану область як виділений простір чи ні.

Як і у всіх сучасних системах, завжди перевіряйте всі кластери, помічені як пошкоджені на рівні файлової системи. Як правило, диски замінюють пошкоджені сектори ще до того, як про їх існування стане відомо файловій системі.

 

Сценарій аналізу

В даному випадку ми знайдемо у файловій системі кластер 9900009. Першим кроком повинно стати визначення розміру кластера. Ми читаємо перший сектор файлової системи і визначаємо, що кожен сектор займає 512 байт, а кожен кластер складається з 8 секторів (4096 байт).

Кластер 0 в NTFS починається з сектора 0. Отже, адреса сектора шуканого кластера обчислюється простим множенням адреси кластера на кількість секторів в кластері. Множення дає результат 792000072. Аби отримати зміщення в байтах, достатньо помножити адресу сектора на 512; добуток дорівнює 40550436864.

 

Категорія метаданих

До категорії метаданих відносяться дані, що описують файли або каталоги. Всі метадані зберігаються в атрибутах, тому в цьому розділі ми детально розглянемо атрибути файлів. Нагадаю, що типовий файл володіє атрибутами $STANDARD_INFОRMATIОN, $FILE_NAME і $DATA. На рис. 18.3 показаний типовий файл із стандартними атрибутами.

18.3.1 Атрибут $STANDARD_INFORMATION

Атрибут $STANDARD_INFORMATION існує у всіх файлів і каталогів; в ньому зберігаються основні метадані. Саме тут знаходяться основні (хоча і не єдині) тимчасові штампи, а також інформація про власника, безпеку і квоти. Вміст цього атрибуту не є строго необхідним для зберігання файлів, але багато функцій прикладного рівня, Microsoft, що надаються, залежать від нього.

За умовчанням ідентифікатор типа цього атрибуту дорівнює 16. Атрибут має статичний розмір, який дорівнює 72 байтам в Windows 2000 і ХР, і 48 байтам в Windows NT. Microsoft сортує атрибути в записах MFT, і цей виявляється завжди на першому місці, тому що він володіє найменшим ідентифікатором типа.

Атрибут містить чотири тимчасові штампи. У NTFS для представлення часу і дат використовуються 64-розрядні значення, що представляють кількість сотень наносекунд, які пройшли з 1 січня 1601 року у форматі UTC. Ця особливість, мабуть, буде особливо корисною при аналізі комп'ютерів, які використовувались в XVII столітті. Що стосується значень цього числа, то 1 січня 1970 року у форматі UTC відповідає 116444736000000000 сотень наносекунд. Зрозуміло, я не стану описувати методику перетворення цього часу у формат, зрозумілий для людини, тому що більшість калькуляторів не справляються з такими числами — втім, для вирішення цього завдання можна скористатися шістнадцятковим редактором або іншою программою. Атрибут містить чотири тимчасові штампи:

 час створення — час, в який була створена файлова система;

 час останньої модифікації — час останньої зміни атрибутів $DATA і $INDEX;

 час модифікації MFT — час останньої модифікації метаданих файлу. Врахуйте, що це значення не відображується в Windows при перегляді властивостей файлу;

 час останнього звернення — час останнього звернення до вмісту файлу.

Атрибут також містить прапор загальних властивостей файлу (доступ лише для читання, системний або архівний). З властивостей також видно, чи є файл стиснутим, розрідженим або зашифрованим. Властивості не вказують, чи відповідає запис файлу або каталогу, але цю інформацію можна отримати за допомогою прапорів в заголовках записів MFT.

У NTFS версій 3.0+ (Windows 2000 і ХР) цей атрибут містить чотири додаткових значення, що використовуються функціональністю системи безпеки і прикладного рівня. Одне з нових значень визначає особу (identity) власника, яка відповідає власникові файлу і використовується для індексування даних квот. Інше значення атрибуту вказує, скільки байт було додано в квоту користувача із-за цього файлу. Ідентифікатор безпеки використовується для індексування файлу $Secure і визначення правил контролю доступу, що діють відносно файлу (файл $Secure буде розглянутий пізніше). Якщо в системі використовується протоколювання змін, цей атрибут містить порядковий номер оновлення USN (Update Sequence Number) для останнього запису, створеного для цього файлу. Журнали змін розглядаються в розділі 2.5; поки досить сказати, що журнал є файлом з інформацією про зміни у файловій системі, який дозволяє швидко знайти файли, що змінилися за певний проміжок часу, замість того, щоб перебирати всі файли окремо.

Коротше кажучи, цей атрибут містить немало цікавих метаданих, але ніякі з них не є необхідними для файлової системи. В ній зберігаються основні тимчасові штампи і деякі ідентифікатори, але ОС сама вирішує, коли оновлювати вміст тимчасових штампів і чи використовувати ідентифікатори. Звернемо увагу: цей атрибут існує для всіх файлів і каталогів, але в небазових записах MFT він може бути відсутнім.

18.3.2 Атрибут $FILE_NAME

Запис MFT кожного файлу і каталога містить як мінімум один атрибут $FILE_NAME. Крім того, кожен файл і каталог представлений як мінімум одним екземпляром атрибуту $FILE_NAME у індексі батьківського каталога, хоча ці два екземпляри не обов'язково містять однакові дані. Атрибут $FILE_NAME батьківського каталогу буде описаний пізніше, а в цьому розділі мова піде про атрибут в записі MFT. Цей атрибут має ідентифікатор типу 48 і змінну довжину, яка залежить від імені файлу. Базова довжина складає 66 байт + ім'я.

Атрибут $FILE_NAME містить ім'я файлу в кодуванні Unicode UTF-16. Ім'я повинно належати одному із стандартних форматів, таких як формат DOS 8.3, формат Win32 або POSIX. У Windows імена файлів зазвичай задаються у просторі імен DOS 8.3, тому в деяких файлів є атрибути $FILE_NAME як для реального імені, так і для DOS-версії, але цю поведінку можна заборонити. Кожен простір імен встановлює власні обмеження відносно того, які символи вважаються допустимими.

Атрибут $FILE_NAME містить посилання на батьківський каталог; це одне з найкорисніших значень атрибуту в записі MFT. Це посилання спрощує визначення повної дороги для довільного запису MFT.

Крім того, атрибут містить чотири тимчасові штампи, які раніше згадувались. Як правило, Windows не оновлює цей набір тимчасових штампів, як і у випадку з атрибутом $STANDARD__INFORMATION, і дані зазвичай відносяться до моменту створення, переміщення або перейменування файлу.

Атрибут $FILE_NAME містить поля для фактичного і виділеного розміру файлу, але експерименти показали, що для призначених для користувача файлів і каталогів в Windows ці значення дорівнюють 0. Нарешті, атрибут містить поле прапорів, які є ознаками каталогів, доступу лише для читання, системних, стиснутих, зашифрованих файлів, і так далі. Поле включає ті ж прапори, які використовувались в $STANDARD_INFОRMATIОN.

Отже, багато значень цього атрибуту дублюють вміст $STANDARD_INF0RMATIОN. Втім, є і нові дані — ім'я файлу і адреса батьківського каталогу, які можуть використовуватися для визначення повної дороги.

18.3.3 Атрибут $DATA

Атрибут $DATA призначений для зберігання довільних даних — він не має фіксованого формату або заздалегідь визначених значень. Його ідентифікатор типу атрибуту рівний 128, причому атрибут може мати довільний розмір, у тому числі і 0 байт. Для кожного файлу за умовчанням створюється один атрибут $DATA, якому ім'я не привласнюється. Деякі програми, у тому числі які входять в пакет TSK (The Sleuth Kit), привласнюють йому умовне ім'я $Data. Запис MFT може містити додаткові атрибути $DATA, але цим атрибутам повинні бути привласнені імена.

В додаткових атрибутів $DATA знаходяться різні використання. Скажемо, у Windows користувач може клацнути на файлі правою кнопкою миші і ввести «зведення» із загальною інформацією про файл; ці відомості зберігаються в атрибуті $DATA. Деякі антивірусні програми і програми резервного копіювання створюють атрибут $DATA для оброблених файлів. Навіть каталоги можуть мати атрибут $DATA разом зі своїми індексними атрибутами. Нарешті, в додаткових атрибутах $DATA можуть зберігатися приховані дані. Додаткові атрибути $DATA не включаються при виведенні вмісту каталога; для роботи з ними необхідні спеціальні програми. Багато аналітичних програм виводять вміст додаткових атрибутів $DATA, які також називаються альтернативними потоками даних, або ADS (Alternate Data Streams).

З точки зору користувача, створити ADS зовсім нескладно; для цього достатньо командного рядка. Аби зберегти дані в ADS, слід поставити після імені ф