Перевірка цілісності даних після відновлення

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

Файл $MFT, що містить саму таблицю MFT, в системі Windows лише збільшується в розмірах. Кваліфікований зловмисник може спробувати зробити цю таблицю дуже великою і приховати дані в її кінці, але він ризикує втратити дані при створенні нових файлів. Перші 16 записів MFT зарезервовані, деякі з них не використовуються в даний час. Зарезервовані, але невживані структури метаданих традиційно використовувались в інших файлових системах для приховування даних; то ж може статися в NTFS.

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

Кількість прапорів і параметрів в елементів каталогів і записів MFT на­столько велике, що наводити список всіх прапорів, що перевіряються, було б бессмыс­ленно. Одна з труднощів при роботі з NTFS полягає в тому, що ця система надзвичайно гнучка і володіє безліччю параметрів. Без офіційної специфікації невідомо, які комбінації значень слід вважати допустимими, а які — ні.

Лекція 19 Структури даних NTFS

Лекція 20 Файлові системи Ext2 і Ext3: концепція і аналіз

Базова інформація про будову ExtX зберігається в структурі даних суперблоку, що знаходиться на початку файлової системи, Вміст файлів зберігається в блоках, які є групами суміжних секторів. Метадані кожного файлу і каталога зберігаються в структурі даних, названій індексним вузлом (і-вузлом); ця структура володіє фіксованим розміром і знаходиться в індексній таблиці. Для кожної групи блоків існує одна індексна таблиця. Ім'я файлу зберігається в структурі запису каталога, який знаходиться в блоках, виділених батьківському каталогу файлу. Записи каталогів є простими структурами даних, що містять ім'я файлу і покажчик на индексний запис файлу. Відношення між записами каталогів, індексними вузлами і блоками змальовані на рис. 20.1.

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

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

Ми розглянемо модель даних з п'ятьма категоріями в контексті Ext2 і Ext3. У кожному розділі ми спочатку обговоримо основні властивості категорії, а потім перейдемо до подробиць їх реалізації в ExtX. Розглядати ми будемо відносно стабільні підсистеми.

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

До категорії даних файлової системи відноситься загальна інформація про файлову систему.

Загальна інформація

У ExtX для зберігання даних категорії файлової системи використовуються дві структури: суперблок і дескриптор групи. Суперблок знаходиться на початку файлової системи і містить базову інформацію про розмір і конфігурацію. Суперблок є аналогом структур даних завантажувального сектора у файлових системах NTFS і FAT. Як згадувалося раніше, файлова система ділиться на групи блоків, і з кожною групою зв'язується спеціальна структура даних, яка описує її будову — дескриптор групи. Дескриптори груп зберігаються в таблиці дескрипторів груп, яка знаходиться в групі, наступній за суперблоком. У файловій системі створюються резервні копії суперблоку і таблиці дескрипторів груп, використовувані в разі пошкодження основної копії.

Суперблок

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

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

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

Суперблок визначає активні функції файлової системи. Як говорилося вище, функції діляться на три категорії: сумісні, несумісні і сумісні лише для читання. Для простоти детальний опис кожної функції наводитиметься у відповідному розділі. Тут я обмежуся описом лише однієї функції, сумісної лише для читання: так званого «розрідженого суперблоку». При використанні цієї функції резервні копії суперблоку і таблиці дескрипторів груп зберігаються лише в деяких групах блоків. В тестовій файловій системі я виявив, що резервні копії знаходяться в групах 1, 3, 5, 7 і 9, а наступні копії зустрілися лише в групах 25 і 27. При створенні файлової системи ExtX в Linux режим розрідженого суперблоку включений за умовчанням. Ця функція не повинна впливати на хід дослідження — хіба що експерт не повинен передбачати, що кожна група містить зарезервований простір для резервної копії суперблоку.

В Linux мітка тому в суперблоці може використовуватися для ідентифікації файлової системи. Наприклад, стандартний спосіб посилання на файлову систему в Linux заснований на використанні імені пристрою — скажімо, /dev/hda5. Також на файлову систему можна послатися по мітці тому, а системні конфігураційні файли можуть використовувати мітку замість імені пристрою. Наприклад, файл /etc/fstab в Linux містить перелік вмонтовуваних файлових систем; якщо файловій системі привласнена мітка rootfs, то замість посилання на пристрій виду /dev/hda4 в ньому може використовуватися конструкція LABEL=rootfs.

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

Таблиця дескрипторів груп

В блоці, наступному за суперблоком, зберігається таблиця дескрипторів груп. В таблиці зберігаються структури даних дескрипторів груп для всіх груп блоків у файловій системі. Резервна копія таблиці існує в кожній групі блоків (якщо лише в системі не активізована функція розрідженого суперблоку). Окрім вмісту файлів, групи блоків містять адміністративні дані — резервні копії суперблоку і таблиці дескрипторів груп, таблиці індексних вузлів, бітові карти індексних вузлів і блоків. Дескриптор групи описує місцезнаходження цих даних. Базова будова групи блоків показана на рис. 20.3.

Бітова карта блоків описує стан виділення блоків групи, а її початкова адреса блоку задається в дескрипторі групи. Розмір карти в байтах обчислюється діленням кількості блоків в групі на 8. При створенні файлової системи Linux визначає кількість блоків в групі рівним кількості біт в блоці. Таким чином, для зберігання бітової карти блоків потрібний рівно один блок.

Бітова карта індексних вузлів описує полягання виділення індексних вузлів в групі, а її початкова адреса блоку також задається в дескрипторі групи. Розмір карти в байтах обчислюється діленням кількості індексних вузлів в групі на 9. Як правило, кількість індексних вузлів в групі менше кількості блоків, але користувач може вибрати ці значення при створенні файлової системи. Нарешті, початкова адреса блоку таблиці індексних вузлів міститься в дескрипторі групи, а її розмір обчислюється множенням кількості індексних вузлів в групі на розмір кожного вузла (128 байт).

В дескрипторі групи також міститься кількість вільних блоків та індексних вузлів в групі блоків, а в суперблоці — загальна кількість вільних блоків і індексних вузлів у всіх групах.

Завантажувальний код

Якщо файлова система ExtX містить ядро ОС, в ній може зберігатися завантажувальний код. Всі останні файлові системи, що не є завантажувальними, не містять завантажувального коду. Якщо завантажувальний код існує, він розміщується в 1024 байтах, передуючих суперблоку (тобто в перших двох секторах). Завантажувальний код виконується в результаті передачі управління коду запису MBR (Master Boot Record) в секторі 0 диска. Як правило, завантажувальний код ExtX знає, які блоки були виділені ядру, і завантажує їх в пам'ять.

В багатьох системах Linux завантажувальний код не зберігається у файловій системі з ядром. Замість цього в MBR знаходиться завантажувач (boot loader), якому відомо, в яких блоках знаходиться ядро. В цьому випадку ядро завантажується кодом MBR, а необхідність в додатковому завантажувальному коді файлової системи відпадає.

Приклад образу

Вся робота наведена тут, заснована на тестовому образі файлової системи. Я приведу результат виконання програми fsstat з пакету TSK (The Sleuth Toolkit) для цього образу. Деякі з представлених значень зустрінуться нам в подальшому. Цей же образ використовуватиметься для ручного розбору.

 

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

# fsstat -f linux-ext3 ext3.dd

FILE SYSTEM INFORMATION

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

File System Type: Ext3

Volume Name:

Volume ID: e4636f48c4ec85946e489517a5067a07

 

Last Written at: Wed Aug 4 09:41:13 2008

Last Checked at: Thu Jun 12 10:35:54 2007

 

Last Mounted at: Wed Aug 4 09:41:13 2008

Unmounted properly

Last mounted on:

 

Source OS: Linux

Dynamic Structure

Compat Features: Journa.

InCompat Features: Filetype, Needs Recovery.

Read Only Compat Features: Sparse Super, Has Large Files

 

Journal ID: 00

Journal Inode: 8

 

METADATA INFORMATION

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

Inode Range: 1 – 1921984

Root Directory: 2

Free Inodes: 1917115

 

CONTENT INFORMATION

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

Block Range: 0 – 3841534

Block Size: 4096

Free Blocks: 663631

 

BLOCK GROUP INFORMATION

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

Number of Block Groups: 118

Inodes per group: 16288

Blocks oer group: 32768

 

Group: 0:

Inode Range: 1 – 16288

Block Range: 0 – 32767

Layout:

Super Block: 0 - 0

Group Descriptor Table: 1 - 1

Data bitmap: 2 - 2

Inode bitmap: 3 - 3

Inode Table: 4 - 512

Data Blocks: 513 – 32767

Free Inodes: 16245 (99*)

Free Blocks: 0 (0%)

Total Directories: 11

 

Group: 1:

Inode Range: 16289 – 32576

Block Range: 32768 – 65535

[...]

 

У вихідних даних fsstat відображуються загальні параметри файлової системи з суперблоку: загальна кількість індексних вузлів і блоків, розміри блоків і так далі Також наводиться опис структури кожної групи блоків. Для групи 0 воно приведене повністю — в лістингу вказані діапазони блоків і індексних вузлів. Також показані прапори функцій і тимчасові штампи.

 

 

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

Аналіз даних категорії файлової системи має на увазі обробку ключових структур даних для визначення будови файлової системи, а це завдання напряму веде до складніших і корисніших методів аналізу. В ExtX аналіз починається з пошуку суперблоку; зробити це неважко, тому що суперблок завжди зберігається із зсувом 1024 байти від початку файлової системи. Коли суперблок буде виявлений, можна переходити до його обробки. Структура суперблоку грає ключову роль в будь-яких розслідуваннях, тому що в ній зберігаються відомості про розміри і місцезнаходження найважливіших структур даних. На випадок пошкодження суперблоку в системі повинні існувати його резервні копії. Прапори функцій вказують, чи володіє файлова система унікальними можливостями, не підтримуваними програмою аналізу або ОС. Розмір файлової системи обчислюється за розміром блоку і кількістю блоків у файловій системі. У блоці, наступному за суперблоком, знаходиться таблиця дескрипторів груп. Вона містить записи для всіх груп і використовується для ідентифікації структур даних, що визначають стан виділення блоків і індексних вузлів. Резервні копії таблиці також знаходяться в кожній групі,що містить суперблок. Використовуючи суперблок і дескриптори груп, можна знайти всі структури даних, використовувані файлами і каталогами.

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

Як і в всіх останніх файлових системах, в ExtX ця категорія містить важливу інформацію, що описує будову файлової системи. Проте в ній відносно мало призначених для користувача даних, що містять інформацію виникнення деяких подій. Суперблок містить великий об'єм невикористовуваного простору, який може використовуватися для зберігання прихованих даних. Суперблок ExtX набагато простіший за суперблок UFS; це обставина спрощує виявлення значень, використовуваних для приховання даних. 1024 байти перед початком суперблоку зарезервовано для зберігання завантажувального коду; якщо вони не використовуються, в них можуть зберігатися приховані дані. Також варто порівняти розмір файлової системи з розміром тому — за результатами порівняння можна взнати, чи немає невживаних секторів після файлової системи.

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

Якщо суперблок пошкоджений або його не вдається знайти, проведемо пошук резервних копій. Один із способів заснований на пошуку сигнатури 0xef53 в байтах 56-57. Також можна спробувати визначити кордони груп блоків на підставі припущеного розміру блоку і того факту, що розмір групи блоків часто залежить від кількості бітів в одному блоці. Отже, якщо помножити розмір блоку на 9 і додати 1, ми отримаємо адресу сектора з резервною копією. Наприклад, якщо у файловій системі використовуються 1024-байтові блоки, а кожна група складається з 8192 блоків, то резервна копія суперблоку повинна знаходитися в блоці 8192 (за відсутності зарезервованих блоків). Резервні копії структури даних можуть використовуватися для виявлення змін, що вносяться вручну до основної копії.

 

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

Представлена для дослідження система не містить таблиці розділів.

Диск імовірно використовувався в системі Linux, тому ми шукатимемо файлову систему ExtX. Взагалі кажучи, на комп'ютері також могла використовуватися система Reiser або інша файлова система, тому пошук не повинен обмежуватися лише ExtX. Також слід пам'ятати, що багато систем Linux часто використовують декілька файлових систем і розділів на одному диску. На практиці перша файлова система незрідка виявляється відносно невеликою, тому що вона використовується лише для зберігання завантажувальні коди і ядра.

Суперблок ExtX володіє сигнатурою 0xef53, що зберігається в байтах 56-57. Ми проведемо пошук цього значення, аби знайти початок файлової системи. Можна чекати, що в процесі пошуку буде знайдено багато помилкових збігів, оскільки сигнатура має малу довжину. Для перевірки істинності збігу можна перевірити інші величини, які мають бути присутніми в суперблоці (наприклад, можна переконатися в тому, що розмір блоку є розумною величиною). Також можна скористатися тим фактом, що в кожній групі блоків повинна зберігатися резервна копія, так що при виявленні справжнього суперблоку ExtX має бути виявлена серія збігів, розділених рівними інтервалами. Крім того, розмір групи блоків зазвичай визначається на підставі розміру блоку, так що у випадку використання стандартної процедури створення відстань між суперблоками має дорівнювати 8192, 16384 або 32768. Також слід враховувати, що в системі може діяти функція розрідженого суперблоку; в цьому випадку резервна копія не включатиметься в кожну групу блоків.

Для виявлення сигнатур можна скористатися будь-якою програмою з можливістю пошуку шістнадцяткових значень. Така програма, як grep, в даному випадку не підійде, тому що вона підтримує лише пошук по ASCII-кодам. В нашому випадку використовуватиметься програма sigfind з пакету TSK.

Шістнадцяткова сигнатура зберігається на диску в прямому порядку байт, тому необхідно або вибрати відповідну конфігурацію програми, або змінити порядок байт сигнатури при введенні (тобто використовувати послідовність 0x53ef). Результат роботи sigfind виглядає так:

# sigfind -о 56 -1 ef53 disk-8.dd

Block size: 512 Offset: 56

Block: 298661 (-)

Block: 315677 (+17016)

Block: 353313 (+37636)

Block: 377550 (+24237)

Програма sigfind виводить сектор, в якому виявлена сигнатура, і відстань від попереднього збігу. Поки відстані не дорівнюють мірам 2, а сопівпадіння не видалені на однакові відстані, тому ми їх проігноруємо (ймовірно, програма автоматизованого пошуку таблиці розділів провела б аналіз їх вмісту). Проте пізніше у вихідних даних виявляються цікаві дані:

[...]

Block: 2056322 (+274327)

Block: 2072706 (+16384)

Block: 2105474 (+32768)

Block: 2148242 (+32768)

Block: 2171010 (+32768)

Block: 2203778 (+32768)

Звернемо увагу: останні чотири збіги знаходяться на однакових відстанях, а попередній збіг віддалений від попереднього на 16 384 сектори. Всі ці відстані досить характерні для груп блоків. Таким чином, початкова гіпотеза полягає в тому, що перший суперблок знаходиться в секторі 2 056 322, а резервні копії знаходяться в секторах 2 072 706, 2 105 474 і так далі. Ймовірно, група блоків складається з 16 384 секторів, а в системі діє режим розрідженого суперблоку, тому резервні копії суперблоку присутні не у всіх групах.

Аби перевірити цю гіпотезу, ми читаємо 1024 байти, починаючи з сектора 2 056 322, відображуємо їх на структуру даних суперблоку і аналізуємо її різні поля. Аналіз показує, що розмір блоку дорівнює 1024 байтам, а в системі активна функція розрідженого суперблоку. Файлова система складається з 104 422 блоків, по 8192 блоки в групі. Отже, резервна копія суперблоку має бути видалена на 16 384 сектори (тому що один блок складається з двох секторів) — доки все збігається.

Остання перевірка повинна визначити, чи є суперблок в секторі 2 056 322 першим у файловій системі, або це одна з резервних копій. Одне з полів суперблоку ідентифікує групу блоків, до якої він належить; у нашому випадку воно дорівнює 0. В суперблоку в секторі 2 072 706 це поле дорівнює 1. Отже, ми можемо передбачити, що файлова система починається в секторі 2 056 320 (за 2 сектори до суперблоку) і слідує до сектора 2 265 164.

Виникає спокуса просто порівняти різні суперблоки і знайти серед них однакові, аби згрупувати їх як резервні копії. На жаль, такий спосіб не спрацює, тому що резервні копії не оновлюються з тією ж частотою, що і основна копія. Основна копія містить тимчасові штампи і прапори оновлення; ці дані не оновлюються в резервних копіях. Більш того, одне з полів показує, до якої групи блоків відноситься суперблок, тому жодні дві резервні копії не будуть ідентичні.

Поки все було просто і логічно, оскільки ми знайшли відносно рідко оновлюваний розділ /boot. Із наступною групою збігів справа йде складніше. Звернемо увагу: наступний збіг віддалений на 2 сектори від того місця, в якому, за нашими підрахунками, повинна закінчуватися попередня файлова система:

Block: 2265167 (+61389)

Block: 2265733 (+566)

Block: 2265985 (+252)

Block: 2266183 (+198)

Block: 2266357 (+174)

Block: 2266457 (+100)

На підставі положення сектора 2 265 167 по відношенню до кінця попереднього розділу можна було б передбачити, що він починає нову файлову систему. З іншого боку, із-за різних відстаней між подальшими співпадіннями несхоже, аби вони були резервними копіями; програма находить більше 200 збігів, багато хто з яких розділений всього 20 секторами. Мабуть, їх теж можна проігнорувати. Пропустимо пару сотень збігів:

Block: 2278273 (+2800)

Block: 2281551 (+3278)

Block: 2282617 (+1066)

Block: 2314319 (+31702)

Block: 2347087 (+32768)

Block: 2379855 (+32768)

Block: 2412623 (+32768)

Тепер ми бачимо рівномірні інтервали, характерні для резервних копій. Перегляд сектора 2 314 319 показує, що це файлова система Ext3 з 1024-байтовим розміром блоку і 8192 блоками в групі. Також ми бачимо, що копія належить до групи блоків 3. А це означає, що група блоків почалася 49 152 секторів назад, тобто в секторі 2 265 167 відразу ж за кінцем попередньої файловой системи.

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

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

Категорія вмісту

До цієї категорії відноситься безпосередній вміст файлів і каталогів. Цей розділ присвячений категорії даних вмісту в ExtX і способах їх аналізу.

Основна інформація

В ExtX одиницею даних є блок — група суміжних секторів. Блоки ExtX можна розглядати як аналоги кластерів в FAT і NTFS. В цьому розділі розглянемо розміри блоків і способи їх адресації, а також способи перевірки стану виділення.

Блоки

Розмір блоку ExtX складає 1024, 2048 або 4096 байт; його значення вказане в суперблоці. В системі UFS, на базі якої розроблялася ExtX, блоки розбиваються на фрагменти. Код ExtX для Linux не підтримує цього ділення, хоча в суперблоці присутнє поле, в якому може зберігатися розмір фрагмента. Оскільки фрагменти не підтримуються основними системами, механізми роботи з ними залишаються невідомими; нами передбачено, що розмір фрагмента збігається з розміром блоку.

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

група - (блок - ПЕРШИЙ_БЛОК_ДАНИХ) / БЛОКІВ_В_ГРУПІ

Наприклад, якщо зарезервована область відсутня, а група складається з 32 768 блоків, блок 60 000 повинен входити до групи 1.

Стан виділення

Стан виділення блоку визначається по бітовій карті блоків, місцезнаходження якого задається дескриптором групи. Для зберігання бітової карти виділяється повний блок, кожен біт якого представляє деякий блок групи. Аби визначити, який біт представляє заданий блок, необхідно спочатку визначити адресу блоку відносно початки групи. Отримана адреса може розглядатися як логічна адреса блоку в групі. Формула обчислення першого блоку в групі виглядає так:

перший_блок - група * БЛОКІВ_В_ГРУПІ + ПЕРШИЙ_БЛОК_ДАНИХ

Потім адреса першого блоку в групі віднімається з адреси блоку. Наприклад, базова адреса групи 1 в нашому випадку рівний 32 768, тому блоку 60 000 відповідатиме зсув 27 232. Відповідний біт знаходиться в байті 3 404 бітової карти. Приклад бітової карти EXTX наводиться нижче.

Механізм створення файлових систем в Linux вибирає розмір групи блоків так, щоб бітова карта блоків поміщалася в одному блоці. Звідси, у всіх файлових системах з 4 096-байтовими блоками за умовчанням група складається з 32 768 блоків. Користувач може перевизначити ці значення при створенні файлової системи, а в інших застосуваннях можуть використовуватися інші алгоритми.

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

Програма dstat з пакету TSK відображує стан виділення блоку і номер групи блоків, до якої він належить. Приклад виведення dstat для тестового образу:

# dstat -f linux-ext3 ext3.dd 14380

Block: 14380

Allocated

Group: 0

Ми бачимо, що блок 14 380 входить до групи блоків 0 і що він виділений.

 

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

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

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

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

При записі даних на диск Linux заповнює невживані байти нулями, тому за останнім блоком файлу не повинно залишатися жодних попередніх даних.

 

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

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

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

Якщо потрібно буде витягувати вміст всіх вільних блоків у файловій системі, необхідно послідовно перебрати всі записи в таблиці дескрипторів груп. Для кожного запису завантажується бітова карта блоку, і в ній відбувається пошук нульових бітів. Далі залишається лише витягувати вміст кожного блоку, біт якого дорівнює 0. В ExtX суперблоки, дескриптори груп, таблиці індексних вузлів і бітові карти відносяться до виділених даних, хоча вони і не зв'язуються з конкретними файлами. Якщо на початку файлової системи присутні зарезервовані сектори, визначити стан виділення дещо складніше, тому що інформація про такі сектори не включається в бітову карту. Ймовірно, результат залежатиме від конкретної програми.

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

В тому, що стосується відновлення видаленого вмісту, може пригодитися знання алгоритмів виділення у файлових системах ExtX. Якщо ОС виділяє блоки в тій же групі, в якій знаходиться індексний вузол, пошук зазвичай можна обмежити групою (замість пошуку по всій файловій системі). Наприклад, якщо ми шукаємо файл, що містить деяке ключове слово, і ми знаємо, до якої групи відносився цей файл, провести пошук доказів в рамках групи. Такий спосіб працює набагато швидше, ніж пошуки по всій файловій системі. Втім, такий спосіб пошуку не є універсальним, тому що копії файлу можуть існувати в інших групах, а ОС виділяє блоки не лише з тієї групи, до якої належить індексний вузол. Для визначення місцезнаходження групи можна скористатися програмою fsstat з пакету TSK, як це було зроблено раніше; втім, ту ж інформацію можна отримати і за допомогою інших програм.

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

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

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

Спочатку ми читаємо суперблок, що знаходиться в секторі 2 файлової системи. Розмір блоку зберігається в байтах 24-27; він дорівнює 2. Розмір блоку зберігається у вигляді числа двійкових розрядів, на які необхідно зрушити число 1024 (0x0400); у нашій файловій системі зрушення проводиться на дві позиції вліво. Однократне зрушення дає число 2048 (0x0800), а повторне — число 4096 (0x1000). Якщо ми не зрозуміли, що відбувається, досить пригадати, що число 0x4 має двійкове представлення 0100, а число 0x8 — двійкове представлення 1000. При зрушенні 0x4000 на 1 розряд вліво число 0x4 переходить в 0x8.

Потім необхідно визначити останній блок файлової системи. Значення зберігається в байтах 4-7 і не вимагає додаткових обчислень. Файлова система складається з 512 064 блоків; це означає, що пошук повинен проводитися вперед на 512 063 блоки, а кожен блок займає 4 096 байт, або 8 секторів. Таким чином, в шістнадцятковому редакторові слід проглянути сектори з 4 096 504 по 4 096 511.

В розглянутому сценарії був відтворений процес пошуку заданого блоку. Багато програм аналізу роблять це автоматично, проте пошук блоку — досить стандартне завдання, тому корисно знати, як вона вирішується.

 

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

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

Спочатку ми читаємо суперблок, що знаходиться в секторі 2 файлової системи. Розмір блоку зберігається в байтах 24-27; він дорівнює 2. Розмір блоку зберігається у вигляді числа двійкових розрядів, на які необхідно зрушити число 1024 (0x0400); у нашій файловій системі зрушення проводиться на дві позиції вліво. Однократне зрушення дає число 2048 (0x0800), а повторне — число 4096 (0x1000). Якщо ми не зрозуміли, що відбувається, досить пригадати, що число 0x4 має двійкове представлення 0100, а число 0x8 — двійкове представлення 1000. При зрушенні 0x4000 на 1 розряд вліво число 0x4 переходить в 0x8.

Потім необхідно визначити останній блок файлової системи. Значення зберігається в байтах 4-7 і не вимагає додаткових обчислень. Файлова система складається з 512 064 блоків; це означає, що пошук повинен проводитися вперед на 512 063 блоки, а кожен блок займає 4 096 байт, або 8 секторів. Таким чином, в шістнадцятковому редакторові слід проглянути сектори з 4 096 504 по 4 096 511.

В розглянутому сценарії був відтворений процес пошуку заданого блоку. Багато програм аналізу роблять це автоматично, проте пошук блоку — досить стандартне завдання, тому корисно знати, як вона вирішується.

 

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

До категорії метаданих відносяться дані, що описують файли або каталоги. В цьому розділі наведемо, де зберігаються ці дані і як проводиться їх аналіз.

Загальна інформація

В ExtX основні метадані файлів зберігаються в структурах даних індексних вузлів. Додаткові метадані можуть зберігатися в розширених атрибутах. Обидва різновиди структур даних буде описано нижче.

Індексні вузли