.

Кэрриэ Б. 2007 – Криминалистический анализ файловых систем (книга)

Язык: русский
Формат: реферат
Тип документа: Word Doc
17 34951
Скачать документ

Кэрриэ Б. 2007 – Криминалистический анализ файловых систем

Содержание

Предисловие…………………………………………………….
………………………19

От
издательства……………………………………………………
………………………..20

Введение……………………………………………………….
…………………………21

Структура
книги………………………………………………………….
………………….22

Ресурсы………………………………………………………..
………………………………23

Благодарности…………………………………………………..
……………………..24

Часть I.
Основы…………………………………………………………
………..25

Глава 1- Основы цифровых
расследований………………………………………..26

Цифровые расследования и
улики…………………………………………………….26

Процесс анализа места цифрового
преступления…………………………….27

Фаза сохранения
системы………………………………………………………..
….28

Фаза поиска
улик…………………………………………………………..
…………..29

Фаза реконструкции
событий……………………………………………………….2
9

Общие
рекомендации……………………………………………………
…………….30

Анализ
данных…………………………………………………………
…………………….31

Типы
анализа………………………………………………………..
…………………..31

Необходимые и вспомогательные
данные……………………………………….34

Инструментарий
эксперта……………………………………………………….
……….35

EnCase (Guidance
Software)………………………………………………………
…..35

Forensic Toolkit (Access
Data)…………………………………………………………3
6

ProDiscover (Technology
Pathways)…………………………………………………36

SMART (ASR Data)
………………………………………………………………
………36

The Sleuth
Kit/Autopsy…………………………………………..???????????
???

Итоги………………………………………………………….
………………………………..37

Библиография……………………………………………………
………………………….37

Глава 2. Основные принципы работы
компьютеров…………………………….38

Организация
данных…………………………………………………………
…………….38

Двоичная, десятичная и шесгнадцатеричная
запись………………………..38

Размеры
данных…………………………………………………………
………………41

Строковые данные и кодировка
символов………………………………………42

PAGE 8 _Содержание

Структуры
данных…………………………………………………………
……………44

Флаги………………………………………………………….
……………………………45

Процесс
загрузки……………………………………………………….
…………………..46

Процессор и машинный
код………………………………………………………….46

Местонахождение загрузочного
кода…………………………………………….47

Технологии жестких
дисков…………………………………………………………
…..48

Геометрия и внутреннее устройство жесткого
диска…………………………48

Интерфейс
ATA/IDE………………………………………………………..
…………..50

Типы адресации
секторов……………………………………………………….
……52

BIOS и прямой
доступ…………………………………………………………
………57

Диски
SCSI…………………………………………………………..
……………………58

Итоги………………………………………………………….
………………………………..62

Библиография
………………………………………………………………
……………….62

Глава 3- Снятие данных с жесткого
диска………………………………………….63

Введение……………………………………………………….
……………………………..63

Общая процедура снятия
данных………………………………………………….63

Уровни снятия
данных…………………………………………………………
………64

Тесты программ снятия
данных…………………………………………………….64

Чтение исходных
данных…………………………………………………………
………65

Прямой доступ или
BIOS?………………………………………………………….
…65

Режимы снятия
данных…………………………………………………………
…….66

Обработка
ошибок…………………………………………………………
…………..67

Область
НРА……………………………………………………………
…………………67

DCO……………………………………………………………
……………………………68

Аппаратная блокировка
записи…………………………………………………….68

Программная блокировка
записи…………………………………………………..70

Запись снятых
данных…………………………………………………………
………….71

Выбор
приемника………………………………………………………
……………….71

Формат файла
образа…………………………………………………………
………72

Сжатие файла
образа…………………………………………………………
……….73

Сетевое снятие
данных…………………………………………………………
…….73

Хеширование и целостность
данных………………………………………………74

Практический пример с использованием
dd………………………………………..75

Источник……………………………………………………….
………………………….75

НРА……………………………………………………………
…………………………….76

Приемник……………………………………………………….
…………………………77

Обработка
ошибок…………………………………………………………
…………..78

Криптографическое
хеширование…………………………………………………79

Итоги………………………………………………………….
………………………………..80

Библиография……………………………………………………
………………………….80

Содержание_ PAGE 9

Часть П. Анализ
томов………………………………………………………..81

Глава 4. Анализ
томов………………………………………………………….
………..82

Введение……………………………………………………….
……………………………..82

Общие
положения………………………………………………………
………………….83

Концепция
тома…………………………………………………………..
…………….83

Общая теория
разделов……………………………………………………….
……..83

Использование томов в
UNIX………………………………………………………..84

Общая теория объединения
томов………………………………………………..85

Адресация
секторов……………………………………………………….
…………..86

Основы
анализа………………………………………………………..
……………………87

Методы
анализа………………………………………………………..
……………….87

Проверка
целостности…………………………………………………….
…………..88

Получение содержимого
разделов…………………………………………………89

Восстановление удаленных
разделов…………………………………………….90

Итоги………………………………………………………….
………………………………..92

Глава 5- Разделы на персональных
компьютерах………………………………..93

Разделы в
DOS……………………………………………………………
………………….93

Общий
обзор………………………………………………………….
……………………..94

Основные концепции
MBR……………………………………………………………
…..94

Концепция расширенного
раздела…………………………………………………….95

Структуры
данных…………………………………………………………
……………….99

Факторы
анализа………………………………………………………..
……………108

Итоги………………………………………………………….
………………………….109

Разделы
Apple………………………………………………………….
…………………..109

Общий
обзор………………………………………………………….
………………..109

Структуры
данных…………………………………………………………
………….110

Факторы
анализа………………………………………………………..
……………113

Итоги………………………………………………………….
………………………….ИЗ

Съемные
носители……………………………………………………….
……………….114

Библиография……………………………………………………
………………………..115

Глава 6. Разделы в серверных
системах………………………………………….117

Разделы
BSD……………………………………………………………
…………………..117

Общий
обзор………………………………………………………….
………………..117

Структуры
данных…………………………………………………………
……………..121

Факторы
анализа………………………………………………………..
……………127

Итоги………………………………………………………….
………………………….128

Сегменты Sun
Solaris………………………………………………………..
……………129

Общий
обзор………………………………………………………….
………………..129

Структуры данных
Sparc………………………………………………………….
…130

PAGE 10 _Содержание

Структуры данных
i386…………………………………………………………..
…. 134

Факторы
анализа………………………………………………………..
……………137

Итоги………………………………………………………….
…………………………. 137

Разделы
GPT……………………………………………………………
…………………..138

Общий
обзор………………………………………………………….
………………..138

Структуры
данных…………………………………………………………
………….139

Факторы
анализа………………………………………………………..
……………141

Итоги………………………………………………………….
………………………………142

Библиография
………………………………………………………………
……………..142

Глава 7. Многодисковые
тома………………………………………………………..
143

RAID…………………………………………………………..
………………………………143

Уровни RAID
………………………………………………………………
……………143

Аппаратная реализация
RAID……………………………………………………..146

Программная реализация
RAID……………………………………………………147

Общие замечания по поводу
анализа…………………………………………..150

Итоги………………………………………………………….
………………………….150

Объединение
дисков…………………………………………………………
…………..150

Общий
обзор………………………………………………………….
………………..151

Linux
MD…………………………………………………………….
………………….. 152

Linux
LVM……………………………………………………………
………………….. 154

Microsoft Windows
LDM……………………………………………………………
…156

Библиография……………………………………………………
……………………. 162

Часть III. Анализ файловых
систем……………………………………163

Глава 8. Анализ файловых
систем…………………………………………………. 164

Что такое файловая
система?……………………………………………………….
..164

Категории
данных…………………………………………………………
………….165

Необходимые и вспомогательные
данные……………………………………..166

Методы анализа и категории
данных……………………………………………167

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

Методы
анализа………………………………………………………..
……………..168

Категория данных
содержимого…………………………………………………….
..169

Общие
сведения……………………………………………………….
………………169

Методы
анализа………………………………………………………..
……………..172

Методы надежного
удаления………………………………………………………1
75

Категория
метаданных……………………………………………………..
……………176

Общая
информация……………………………………………………..
……………176

Методы
анализа………………………………………………………..
……………..182

Категория имен
файлов…………………………………………………………
………187

Общие
сведения……………………………………………………….
………………187

Содержание_ PAGE 11

Методы
анализа………………………………………………………..
……………..190

Методы надежного
удаления………………………………………………………1
92

Категория прикладных
данных………………………………………………………..1
92

Журналы файловой
системы………………………………………………………19
3

Методы поиска на прикладном
уровне……………………………………………..193

Восстановление файлов на прикладном
уровне……………………………..194

Сортировка файлов по
типу……………………………………………………….195

Конкретные файловые
системы………………………………………………………19
5

Итоги………………………………………………………….
………………………………196

Библиография……………………………………………………
………………………..197

Глава 9- FAT: основные концепции и
анализ……………………………………. 198

Введение……………………………………………………….
……………………………198

Категория файловой
системы………………………………………………………..
.199

Методы
анализа………………………………………………………..
……………..203

Факторы
анализа………………………………………………………..
……………204

Сценарий
анализа………………………………………………………..
…………..204

Категория
содержимого…………………………………………………….
…………..207

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

Методы
анализа………………………………………………………..
……………..209

Факторы
анализа………………………………………………………..
……………209

Сценарий
анализа………………………………………………………..
…………..211

Категория
метаданных……………………………………………………..
……………211

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

Методы
анализа………………………………………………………..
……………..219

Факторы
анализа………………………………………………………..
……………219

Сценарии
анализа………………………………………………………..
…………..221

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

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

Методы
анализа………………………………………………………..
……………..224

Факторы
анализа………………………………………………………..
……………225

Сценарии
анализа………………………………………………………..
…………..225

Общая
картина………………………………………………………..
…………………..227

Создание
файлов…………………………………………………………
…………..227

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

Прочее…………………………………………………………
…………………………….229

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

Определение типа файловой
системы………………………………………….231

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

Итоги………………………………………………………….
………………………………233

Библиография……………………………………………………
………………………..233

PAGE 12 _Содержание

Глава 10. Структуры данных
FAT……………………………………………………235

Загрузочный
сектор…………………………………………………………
……………235

Структура
FSINFO…………………………………………………………
………………239

FAT……………………………………………………………
……………………………….240

Записи
каталогов………………………………………………………
………………….241

Записи каталогов для длинных имен
файлов…………………………………….245

Итоги………………………………………………………….
………………………………249

Библиография
………………………………………………………………
……………..249

Глава 11. NTFS: основные
концепции……………………………………………..250

Введение……………………………………………………….
……………………………250

Все данные —
файлы………………………………………………………….
…………251

Концепции
MFT……………………………………………………………
……………….251

Содержимое записи
MFT……………………………………………………………
252

Адреса записей
MFT……………………………………………………………
…….253

Файлы метаданных файловой
системы…………………………………………254

Атрибуты записей
MFT……………………………………………………………
……..255

Заголовки
атрибутов………………………………………………………
…………255

Содержимое
атрибутов………………………………………………………
……..256

Стандартные типы
атрибутов……………………………………………………..2
57

Другие концепции
атрибутов…………………………*…………………………..
….259

Базовые записи
MFT……………………………………………………………
…….259

Сжатые
атрибуты……………………………………………………….
…………….260

Шифрование
атрибутов………………………………………………………
……..262

Индексы
,……………………………………………………………..
……………………..265

B-деревья………………………………………………………
………………………..265

Атрибуты индексов
NTFS…………………………………………………………..
.268

Программы
анализа………………………………………………………..
…………….270

Итоги………………………………………………………….
………………………………271

Библиография
………………………………………………………………
……………..271

Глава 12. NTFS:
анализ…………………………………………………………
……..273

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

Файл
$MFT…………………………………………………………..
………………….273

Файл
$MFTMirr……………………………………………………….
………………..274

Файл
$Boot………………………………………………………….
…………………..275

Файл
$Volume………………………………………………………..
…………………276

Файл
$AttrDef……………………………………………………….
………………….277

Тестовый
образ………………………………………………………….
…………….277

Методы
анализа………………………………………………………..
……………..278

Факторы
анализа………………………………………………………..
……………278

Сценарий
анализа………………………………………………………..
…………..279

Содержание _ PAGE 1 3

Категория данных
содержимого…………………………………………………….
..281

Кластеры……………………………………………………….
………………………..281

Файл
$В№тар…………………………………………………………
………………..282

Файл
$Вас1С1и5………………………………………………………
………………….282

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

Структура файловой
системы……………………………………………………..283

Методы
анализа………………………………………………………..
……………..284

Факторы
анализа………………………………………………………..
……………285

Сценарий
анализа………………………………………………………..
…………..285

Категория
метаданных……………………………………………………..
……………285

Атрибут
$5ТАМОАкО^РОкМАТЮМ……………………………………………..2
86

Атрибут
$РИЕЛАМЕ……………………………………………………….
………..287

Атрибут
$ОАТА………………………………………………………….
……………..288

Атрибут
$АигавиТЕ_иВТ…………………………………………………..
……..289

Атрибут
фЭБСиКЛУ^ЕЗСЮРТад……………………………………………….
.291

Файл
$Бесиге………………………………………………………..
…………………291

Тестовый
образ………………………………………………………….
…………….292

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

Методы
анализа………………………………………………………..
……………..294

Факторы
анализа………………………………………………………..
……………296

Сценарий
анализа………………………………………………………..
…………..298

Категория имен
файлов…………………………………………………………
………300

Индексы
каталогов………………………………………………………
……………300

Корневой
каталог………………………………………………………..
……………301

Ссылки на файлы и
каталоги………………………………………………………3
01

Идентификаторы
объектов……………………………………………………….
..302

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

Методы
анализа………………………………………………………..
……………..303

Факторы
анализа………………………………………………………..
……………303

Сценарий
анализа………………………………………………………..
…………..304

Категория прикладных
данных………………………………………………………..3
06

Дисковые
квоты………………………………………………………….
……………306

Журналы файловых
систем………………………………………………………..3
06

Журнал
изменений………………………………………………………
……………309

Общая
картина………………………………………………………..
…………………..310

Создание
файла………………………………………………………….
……………311

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

Разное…………………………………………………………
……………………………..314

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

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

PAGE 14 _Содержание

Итоги………………………………………………………….
………………………………315

Библиография
………………………………………………………………
……………..316

Глава 13- Структуры данных
ГЛТБ………………………………………………….317

Базовые
концепции………………………………………………………
………………317

Маркеры………………………………………………………..
……………………….317

Записи МП” (файловые
записи)…………………………………………………..318

Заголовок
атрибута……………………………………………………….
………….320

Стандартные атрибуты
файлов……………………………………………………….32
4

Атрибут
$5ТАМОАРЮ_1ЫРОкМАТ10М……………………………………………
..324

Атрибут
$РИЕ_ЫАМЕ………………………………………………………
…………326

Атрибут
$ОАТА………………………………………………………….
……………..328

Атрибут
$АТтавиТЕ_иВТ…………………………………………………..
……..328

Атрибут
$ОИЕСГ_ГО………………………………………………………
…………330

Атрибут
$1*ЕРА115Е_Р01МТ………………………………………………..
………..330

Атрибуты и структуры данных
индексов……………………………………………331

Атрибут
$П\ГОЕХ_1ЮОТ……………………………………………………
…………331

Атрибут
$1ШЕХ_АШХАТЮЫ…………………………………………………..
…332

Атрибут
$ВГГМАР………………………………………………………..
…………….334

Структура данных заголовка индексного
узла……………………………….334

Структура данных обобщенного индексного
элемента…………………….335

Структура данных индексного элемента
каталога…………………………..336

Файлы метаданных файловой
системы……………………………………………..339

Файл
$МП-…………………………………………………………..
………………….339

Файл
$Boot………………………………………………………….
…………………..339

Файл
$АйгОеГ………………………………………………………..
…………………341

Файл
$В№тар…………………………………………………………
………………..342

Файл
$\/о1ите……………………………………………………….
………………….343

Файл
$ОЬ]М………………………………………………………….
…………………344

Файл
$(}1кЛа………………………………………………………..
………………….345

Файл
$иэдН1е………………………………………………………..
…………………347

Файл
$из^гп1………………………………………………………..
…………………348

Итоги………………………………………………………….
………………………………351

Библиография
………………………………………………………………
……………..351

Глава 14. Ext2 и ExtЗ: концепции и
анализ………………………………………352

Введение……………………………………………………….
……………………………352

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

Общие
сведения……………………………………………………….
………………354

Методы
анализа………………………………………………………..
……………..358

Факторы
анализа………………………………………………………..
……………358

Сценарий
анализа………………………………………………………..
…………..359

Содержание_ PAGE 15

Категория
содержимого…………………………………………………….
…………..362

Общие
сведения……………………………………………………….
………………362

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

Методы
анализа………………………………………………………..
……………..364

Факторы
анализа………………………………………………………..
……………364

Сценарий
анализа………………………………………………………..
…………..365

Категория
метаданных……………………………………………………..
……………365

Общие
сведения……………………………………………………….
………………366

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

Выделение индексных
узлов………………………………………………………371

Методы
анализа………………………………………………………..
……………..373

Факторы
анализа………………………………………………………..
……………374

Сценарий
анализа………………………………………………………..
…………..375

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

Общие
сведения……………………………………………………….
………………376

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

Методы
анализа………………………………………………………..
……………..381

Факторы
анализа………………………………………………………..
……………382

Сценарии
анализа………………………………………………………..
…………..383

Категория прикладных
данных………………………………………………………..
387

Журналы файловой
системы………………………………………………………38
7

Сценарий
анализа………………………………………………………..
…………..389

Общая
картина………………………………………………………..
…………………..390

Пример создания
файла………………………………………………………….
…391

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

Разное…………………………………………………………
……………………………..395

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

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

Итоги………………………………………………………….
………………………………397

Библиография……………………………………………………
…..-…………………..397

Глава 15- Структуры данных Ех12 и
Ех13………………………………………….399

Суперблок………………………………………………………
…………………………..399

Таблица дескрипторов
групп………………………………………………………….
403

Битовая карта
блоков…………………………………………………………
…………404

Индексные
узлы…………………………………………………………..
……………….405

Расширенные
атрибуты……………………………………………………….
…………409

Запись
каталога……………………………………………………….
…………………..412

Символическая
ссылка…………………………………………………………
………..414

Хеш-деревья…………………………………………………….
………………………….415

Структуры данных
журнала………………………………………………………..
…..416

PAGE 16 __Содержание

Итоги………………………………………………………….
………………………………421

Библиография
………………………………………………………………
……………..421

Глава 16. ІІРБІ и 1^2: концепции и
анализ…………………………………….422

Введение……………………………………………………….
……………………………422

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

Общие
сведения……………………………………………………….
………………423

Методы
анализа………………………………………………………..
……………..429

Факторы
анализа………………………………………………………..
……………430

Категория
содержимого…………………………………………………….
…………..430

Общие
сведения……………………………………………………….
………………430

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

Методы
анализа………………………………………………………..
……………..433

Факторы
анализа………………………………………………………..
……………433

Категория
метаданных……………………………………………………..
……………434

Общие
сведения……………………………………………………….
………………434

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

Методы
анализа………………………………………………………..
……………..437

Факторы
анализа………………………………………………………..
……………437

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

Общие
сведения……………………………………………………….
………………438

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

Методы
анализа………………………………………………………..
……………..440

Факторы
анализа………………………………………………………..
……………440

Общая
картина………………………………………………………..
…………………..441

Создание
файла………………………………………………………….
……………441

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

Разное…………………………………………………………
……………………………..445

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

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

Итоги………………………………………………………….
………………………………447

Библиография
………………………………………………………………
……………..447

Глава 17. Структуры данных ІІРБІ и
1^2……………………………………….448

Суперблок
І^БІ…………………………………………………………..
……………….448

Суперблок
1^2……………………………………………………………
………………453

Сводка групп
цилиндров………………………………………………………
………..456

Дескриптор группы ІІРБІ
………………………………………………………………
.457

Дескриптор группы
1!РБ2………………………………………………………….
……459

Битовые карты блоков и
фрагментов……………………………………………….460

Содержание PAGE 17

Индексные узлы
UFS1…………………………………………………………..
……….461

Индексные узлы
UFS2…………………………………………………………..
……….464

Расширенные атрибуты
UFS2………………………………………………………….4
65

Записи
каталогов………………………………………………………
…………………. 466

Итоги………………………………………………………….
………………………………468

Библиография
………………………………………………………………
……………..468

Приложение. The Sleuth Kit и
Autopsy…………………………………………….469

The Sleuth
Kit……………………………………………………………
………………….469

Программы для работы с
диском……………………………………………………..470

Программы для работы с
томами…………………………………………………470

Программы файловой
системы……………………………………………………470

Программы
поиска…………………………………………………………
…………473

Autopsy………………………………………………………..
……………………………..474

Режимы анализа
………………………………………………………………
………474

Библиография……………………………………………………
………………………..475

Алфавитный
указатель………………………………………………………
……476

Посвящаю эту книгу моим дедушкам и бабушкам — Генри, Габриэль, Альберту
и Рите

Предисловие

Компьютерный криминологический анализ — относительно новое явление, и за
последние годы оно называлось многими терминами: «цифровая экспертиза»,
«анализ носителей информации» и т.д. Только в последнее время стало
очевидно, что цифровые устройства также могут служить ценным источником
улик в широком спектре расследований. Хотя профессиональные криминалисты
среди первых проявили интерес к цифровым уликам, разведка, службы
информационной безопасности и специалисты по гражданскому праву с
энтузиазмом приняли этот новый источник информации.

В 2003 г. Американское общество директоров криминологических лабораторий
— Совет по аккредитации лабораторий (ASCLD-LAB) признал поиск цифровых
улик полноценной отраслью криминологической экспертизы. Наряду с этим
признанием наблюдался рост интереса к обучению и повышению квалификации
в этой области. Для содействия разработке учебных программ была
сформирована рабочая группа Computer Forensic Educator’s Working Group
(сейчас известная под названием Digital Forensics Working Group). В
настоящее время свыше 30 колледжей и университетов ведут разработку
научных программ в области цифровой экспертизы, и каждый месяц их ряды
пополняются.

Я имел удовольствие работать со многими органами правопорядка, учебными
учреждениями, колледжами и университетами в области разработки программ
цифровой экспертизы. Один из первых вопросов, который мне обычно
задавали, — не могу ли я порекомендовать хороший учебник для их курсов.
На эту тему было написано немало книг. Одни ориентировались на отдельные
аспекты расследования — такие, как методы реагирования или
криминологическая экспертиза. Другие представляли собой учебники по
использованию конкретных программных пакетов. Было трудно найти книгу,
которая закладывала бы надежную техническую и системную основу в области
цифровой экспертизы… Так было до настоящего времени.

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

20

Предисловие

Когда мне предложили написать это предисловие, я с радостью принял
предложение! Мы с Брайаном Кэрриером знакомы уже много лет. На меня
всегда производило впечатление замечательное сочетание его выдающейся
технической квалификации и умения понятно объяснять не только то, что
знает он, но и, что еще важнее, то, что необходимо знать читателю.
Работа Брайана над Autopsy и The Sleuth Kit (TSK) доказала его
компетентность — его имя известно любому специалисту в области
компьютерной экспертизы. Мне выпала честь работать с Брай-ном в его
текущей должности в Университете Пердью (Purdue), где он помогает
сделать академическому сообществу то, что однажды сделал для
коммерческого сектора: установить высокие стандарты.

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

Марк М. Поллитт (Mark М. Pollitt).

Президент Digital Evidence Professional Services, Inc.

Бывший директор программы ФБР Regional Computer Forensic Laboratory
Program.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу электронной
почты: HYPERLINK “mailto:[email protected][email protected] (издательство
«Питер», компьютерная редакция). Мы будем рады узнать ваше мнение!

На веб-сайте издательства — HYPERLINK “http://www.piter.com”
http://www.piter.com — вы найдете подробную информацию о наших книгах.

Введение

Одной из главных проблем, с которыми я сталкивался за годы разработки
TSK (The Sleuth Kit), был поиск хорошей документации по файловым
системам и томам (таблицы разделов, RAID и т. д.). Кроме того, мне было
трудно объяснить пользователям, почему некоторые файлы не удается
восстановить или что делать при повреждении файловой системы, — я не мог
порекомендовать им хорошую книгу. Легко найти ресурсы, описывающие
файловые системы на высоком уровне, но за подробностями обычно
необходимо обращаться к исходному коду. В этой книге я постараюсь
заполнить этот пробел, описать способы хранения данных на диске, а также
объяснить, где и как следует искать цифровые улики.

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

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

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

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

PAGE 22

Введение

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

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

Структура книги

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

Часть 1, «Основы», начинается с главы 1, «Основы цифровых
расследований»; в ней я излагаю свой подход к цифровым расследованиям.
Будут представлены различные фазы расследования и рекомендации, чтобы вы
знали, где используются методики, описанные в книге. Впрочем, книга не
требует, чтобы вы использовали этот же подход в своей работе. Главы 2 и
3 содержат теорию и примеры снятия данных с жесткого диска для их
последующего анализа в частях 2 и 3.

Часть 2, «Анализ томов», посвящена анализу структур данных,
обеспечивающих разбиение и объединение дискового пространства в томах. В
главе 4, «Анализ томов», приводится общий обзор методов анализа томов, а
в главе 5, «Разделы на персональном компьютере», рассматриваются
распространенные схемы разделов DOS и Apple. Глава 6, «Разделы в
серверных системах», посвящена разделам в системах BSD, Sun Solaris и
Itanium. В главе 7, «Многодисковые тома», говорится о RAID и объединении
томов.

Часть 3, «Анализ файловых систем», посвящена анализу тех структур данных
томов, которые непосредственно связаны с сохранением и загрузкой данных.
В главе 8, «Анализ файловых систем», представлена общая теория анализа
файловых систем и определяется терминология для остальных глав части 3.
Каждой файловой системе посвящаются как минимум две главы: в первой
излагаются общие

Ресурсы

23

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

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

В главах 9, «FAT: основные концепции и анализ», и 10, «Структуры данных
FAT», подробно описывается файловая система FAT. Глава 11, «NTFS:
основные концепции», глава 12, «NTFS: анализ», и глава 13, «Структуры
данных NTFS», посвящены NTFS. Затем в главах 14, «Ext2 и Ext3: концепции
и анализ» и в главе 15, «Структуры данных Ext2 и Ext3», мы перейдем к
файловым системам Linux Ext2 и Ext3. Наконец, глава 16, «UFS1 и UFS2:
концепции и анализ», и глава 17, «Структуры данных UFS1 и UFS2»,
посвящены системам UFS1 и UFS2, встречающимся в FreeBSD, NetBSD, OpenBSD
и Sun Solaris.

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

Итак, вы знаете, о чем говорится в книге, теперь я скажу, чего в ней
нет. Книга останавливается на уровне файловой системы и не доходит до
прикладного уровня. Следовательно, мы не будем заниматься анализом
различных файловых форматов. Кроме того, здесь не рассматриваются файлы,
создаваемые конкретной файловой системой или приложением. Если вас
интересуют подробные инструкции по анализу компьютера с Windows 98,
который использовался для загрузки подозрительных файлов, скорее всего,
книга вас разочарует. Если вы ищете руководство по обследованию
взломанных серверов Linux, вы найдете здесь ряд полезных приемов, но
книга написана о другом. Все эти темы относятся к области анализа
прикладного уровня, и для их полноценного изложения потребуется
отдельная книга. Но если вас интересует нечто большее, чем пошаговые
инструкции, — вероятно, эта книга написана для вас.

Ресурсы

На протяжении всей книги пакет TSK (The Sleuth Kit) используется для
обработки тестовых образов дисков, чтобы материал включал как
низкоуровневые, так и отформатированные данные. Однако это вовсе не
означает, что книга является руководством по использованию TSK. Пакет
TSK и Autopsy (графический интерфейс к TSK) описаны в приложении к
книге. Дополнительную документацию можно загрузить по адресу: HYPERLINK
“http://www.sleuthkit.org” http://www.sleuthkit.org .

URL-адреса и ссылки на другие программы приводятся по мере надобности.
Дополнительные ресурсы, ссылки и исправления размещаются на сайте книги:
HYPERLINK “http://www.digital-evidence.org/fsfa/”
http://www.digital-evidence.org/fsfa/ .

Благодарности

Мне хотелось бы поблагодарить многих людей, помогавших мне в области
цифровой экспертизы. Прежде всего я должен упомянуть тех, кто оказывал
мне общее содействие в течение многих лет: это Эоган Кейси (Eoghan
Casey), Дэйв Дитрих (Dave Dittrich), Дэн Фармер (Dan Farmer), Дэн Гир
(Dan Geer), Дэн Калил (Dan КаШ), Уоррен Круз (Warren Kruse), Гэри Палмер
(Gary Palmer), Юджин Спаффорд (Eugene Spafford), Ланс Спицнер (Lance
Spitzner) и Витце Венема (Wietse Venema). Я благодарен им за
руководство, наставления и предоставленные возможности.

Также мне хотелось бы поблагодарить Кори Альтейд (Cory Altheide), Эогана
Кейси (Eoghan Casey), Кнута Экстейна (Knuth Eckstein) и Джима Лайла (Jim
Lyle) за рецензирование книги. Хочу особо отметить Кнута, который
просмотрел все шестнадцатеричные дампы всех тестовых дисковых образов и
проверил все преобразования из шестнадцатеричной системы в десятичную (и
обнаружил несколько опечаток), и Эогана, вовремя напоминавшего, когда
требовались более реалистичные примеры. Кристофер Браун (Christopher
Brown), Симеон Гарфинкель (Simson Garfinkel), Кристофер Гренье
(Christopher Grenier), Барри Гранди (Barry Grundy), Горд Хама (Gord
Наша), Джессе Корнблум (Jesse Kornblum), Трой Лар-сон (Troy Larson),
Марк Менц (Mark Menz), Ричард Рассон (Richard Russon) и Крис Санфт
(Chris Sanft) — все они просмотрели текст и внесли улучшения в тех
областях, в которых они особенно хорошо разбирались.

Книга появилась на свет благодаря многочисленным работникам Addison
Wesley и Pearson. Джессика Голдстейн (Jessica Goldstein) направляла мою
работу и подбадривала меня; Кристи Хакерд (Christy Hackerd) следила за
тем, чтобы редактирование и верстка шли гладко, а Чанда Лири-Куту
(Chanda Leary-Coutu) использовала свой опыт маркетинга. Спасибо Элизе
Уолтер (Elise Walter) за правку, Кристал Андри (Christal Andry) за
корректуру, Эрику Шредеру (Eric Schroeder) за составление алфавитного
указателя, Джейку МакФарленду (Jake McFarland) за компьютерную верстку и
Чути Празерсит (Chuti Prasersith) за дизайн обложки.

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

ЧАСТЬ I

Основы

Глава 1. Основы цифровых расследований…………………….26

Глава 2. Основные принципы работы компьютеров………….38

Глава 3. Снятие данных с жесткого диска………………………63

Основы цифровых расследований

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

Цифровые расследования и улики

Существует огромное количество определений цифровой экспертизы и
расследований. В этом разделе я приведу те определения, которые
использую лично я, вместе с обоснованиями. Объектом цифрового
расследования является некоторое цифровое устройство, задействованное в
инциденте или преступлении. Цифровое устройство могло использоваться при
совершении физического преступления, а могло и стать источником события,
нарушившего правила или закон. Приведу пример первого случая:
подозреваемый собирает в Интернете информацию для подготовки физического
преступления. Среди примеров второго случая можно выделить получение
несанкционированного доступа к компьютеру, загрузку незаконного
материала по сети или отправку электронной почты с угрозами. После того
как факт нарушения будет выявлен, начинается расследование. Оно должно
ответить на такие вопросы: почему произошло нарушение, кто или что
послужил причиной и т. д.

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

Цифровые расследования и улики

PAGE 27

Возьмем сервер, подвергшийся внешнему вторжению. Расследование
начинается с определения ответа на вопрос: когда это произошло и кто это
сделал. В процессе расследования обнаруживаются данные, которые были
созданы событиями, связанными с инцидентом. Эксперт восстанавливает на
сервере удаленные записи журнала, находит программы, задействованные в
атаке, и многочисленные уязвимости, существующие на сервере. По этим и
другим данными строится гипотеза относительно того, какая уязвимость
была использована нападающим, и что он делал потом. Позднее эксперт
анализирует конфигурацию брандмауэра (firewall) и журнала. По
результатам анализа он определяет, что некоторые сценарии,
сформулированные в гипотезах, невозможны, потому что сетевой трафик
соответствующего типа не существовал, а в журнале не нашлось
обязательных записей. Таким образом обнаруживаются улики, опровергающие
одну или несколько гипотез.

В этой книге я использую термин «улика» в следственном контексте. Улики
имеют как юридическое, так и следственное применение. Приведенное ранее
определение относилось к следственному применению улик; далеко не всегда
найденные улики могут быть предъявлены в суде. Поскольку требования к
юридической допустимости улик зависят от страны или штата, а я не
обладаю юридической подготовкой, я сосредоточу внимание на общей
концепции улик, а вы можете внести поправки с учетом местного
законодательства. В действительности никаких юридических требований,
относящихся именно к файловым системам, не существует, поэтому
необходимую информацию можно почерпнуть из общей литературы по цифровому
расследованию.

Процесс анализа места цифрового преступления

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

Подход, который я использую в цифровых расследованиях, основан на
процессе анализа места физического преступления [Carrier and Spafford,
2003]. В данном случае мы имеем место цифрового преступления, к которому
относится цифровое окружение, создаваемое программами и оборудованием.
Процесс состоит из трех основных фаз: консервации системы, поиска улик и
реконструкции событий. Эти фазы не обязаны следовать одна за другой, а
общая схема процесса показана на рис. 1.1.

Фаза сохранения системы

Фаза поиска улик

Фаза реконструкции событий

W

W

Рис. 1.1. Три основные фазы анализа места цифрового преступления

Этот процесс применяется при проведении расследования как в живых, так и
в мертвых системах. Живой анализ происходит при поиске улик с
использованием операционной системы или других ресурсов анализируемого
компьютера. Мертвый анализ происходит тогда, когда вы запускаете
доверенное приложение в до

PAGE 28

Глава 1. Основы цифровых расследований

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

Фаза сохранения системы

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

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

Методы сохранения

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

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

При сохранении важных данных в процессе живого или мертвого анализа
следует вычислить криптографический хеш-код; позднее он поможет
доказать, что данные не изменялись. Криптографический хеш-код (MD5,
SHA-1 или SHA-256) представляет собой очень большое число, вычисляемое
по математической формуле для набора входных данных. Изменение хотя бы
одного бита во входных данных приводит к заметному изменению выходного
числа; более подробную информацию можно найти в книге «Applied
Cryptography», 2nd Edition [Schneier, 1995]. Для хеширования разработаны
специальные алгоритмы, при которых получение одинакового результата для
двух разных входных данных крайне маловероятно. Следовательно, если
хеш-код важных данных остался прежним, это говорит о том, что данные не
подвергались модификации.

Цифровые расследования и улики

PAGE 29

Фаза поиска улик

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

Теория процесса поиска проста. Сначала следует определить общие
характеристики искомого объекта, а затем провести поиск этого объекта в
наборе данных. Например, если потребуется найти все файлы с расширением
JPG, следует просмотреть все имена файлов и выделить среди них те,
которые заканчиваются символами «JPG». Два ключевых шага — это
определение того, что нужно найти, и тех мест, где должен проводиться
поиск.

Часть 2, «Анализ томов», и часть 3, «Анализ файловых систем», посвящены
поиску улик в томах и файловых системах. В сущности, главы анализа
файловых систем организованы таким образом, чтобы читатель мог
сосредоточиться на конкретной категории данных, содержащей улики. В
конце главы приводится сводка популярных аналитических программ; все они
позволяют просматривать, искать и сортировать данные в подозрительных
системах с целью поиска улик.

Методы поиска

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

Иногда поиск известных файлов проводится сравнением хеш-кодов
содержимого файлов, вычисленных по алгоритму MD5 или SHA-1, с базой
данных хеш-кодов — такой, KaKNational Software Reference Library (NSRL—
HYPERLINK “http://www.nsrLnist.gov” http://www.nsrLnist.gov ). Базы
данных хеш-кодов часто применяются при поиске заведомо хороших или
заведомо вредоносных файлов. Другой распространенный метод поиска
основан на сигнатурах, присутствующих в содержимом. По сигнатурам часто
удается найти все файлы заданного типа даже в том случае, если они были
переименованы.

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

Фаза реконструкции событий

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

PAGE 30

Глава 1. Основы цифровых расследований

политику или закон, но факт их обнаружения не дает никакой информации о
событиях. Выясняется, что один из файлов появился в результате
определенного события — загрузки по сети; также следует попытаться
определить, какое приложение загрузило его. Был ли это веб-браузер или
какая-то вредоносная программа? Известен ряд случаев использования
вредоносных программ для защиты при обнаружении незаконных материалов
или других цифровых улик [George, 2004; Brenner, Carrier, and Henninger,
2004]. Иногда после фазы реконструкции цифровых событий удается связать
эти цифровые события с физическими.

Для реконструкции событий эксперт должен хорошо знать приложения и ОС,
установленные на компьютере, чтобы строить гипотезы на основании их
возможностей. Например, цифровые события в Windows 95 отличаются от
событий Windows ХР, а разные версии браузера Mozilla порождают разные
события. Такой тип анализа выходит за рамки книги, но некоторые общие
рекомендации можно найти в [Casey, 2004].

Общие рекомендации

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

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

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

• Вычислите хеш-коды MD5 или SHA важных данных. Позднее они помогут
доказать, что данные не изменились.

• Воспользуйтесь устройством блокировки записи во время любых действий,
способных привести к записи в анализируемые данные.

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

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

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

Анализ данных

PAGE 31

привести к запуску сценариев и загрузке файлов с удаленного сервера. Оба
варианта потенциально опасны, и от них необходимо защититься. Изоляция
от подозрительных данных реализуется их просмотром в приложениях с
ограниченной функциональностью или виртуальных средах, легко
воссоздаваемых в случае уничтожения — таких, как VMWare ( HYPERLINK
“http://www.vmware.com” http://www.vmware.com ).

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

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

Третье правило — проверка данных по другим независимым источникам. Тем
самым снижается риск использования ложных данных. Например, как будет
показано позднее, в большинстве систем временные штампы файлов легко
изменить. Таким образом, если в вашем расследовании время играет важную
роль, постарайтесь найти записи в журналах, сетевой трафик или другие
события, которые подтверждали бы время выполнения операций с файлами.

Последнее правило — документирование всех действий. Это поможет вам
определить, какой поиск еще не проводился и какие результаты были
получены ранее. При проведении живого анализа или применении методов,
которые могут привести к модификации данных, очень важно документировать
все происходящее; позднее вы сможете описать, какие изменения были
внесены в систему из-за ваших действий.

Анализ данных

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

Типы анализа

При анализе цифровых данных эксперт ищет объекты, спроектированные
человеком. Кроме того, при проектировании систем хранения данных
большинства цифровых устройств разработчики стремились добиться гибкости
и масштабируемости, вследствие чего такие системы имеют многоуровневую
структуру. Я воспользуюсь этой многоуровневой структурой для определения
различных типов анализа [Carrier, 2003а].

PAGE 32

Глава 1. Основы цифровых расследований

Если начать с нижних уровней архитектуры, мы обнаруживаем на них две
независимые области анализа. Первая базируется на устройствах хранения
информации, а вторая — на устройствах обмена данными. В этой книге
основное внимание уделяется анализу устройств хранения информации, а еще
точнее — устройств долгосрочного хранения информации (таких, как жесткие
диски). Анализ коммуникационных систем (таких, как сети IP) в книге не
рассматривается, но вы можете найти необходимую информацию в других
источниках [Bejtlich, 2005; Casey, 2004; Mandia et al., 2003].

Различные области анализа представлены на рис. 1.2. На нижнем уровне
выполняется анализ физических носителей информации: жестких дисков, карт
памяти и дисков CD-ROM. Анализ в этой области может быть сопряжен с
чтением низкоуровневых данных с магнитной поверхности и другими
методами, для которых необходима чистая комната. В книге я буду
предполагать, что в вашем распоряжении имеется надежный метод чтения
данных с физического носителя, а на устройство хранения информации уже
записан поток из нулей и единиц.

Анализ прикладного уровня/ОС

Анализ областей подкачки

Анализ файловой системы

Анализ физических носителей информации

Сетевой анализ

Рис. 1.2. Иерархия уровней анализа, основанная на архитектуре цифровых
данных. Блоки, выделенные жирными линиями, рассматриваются в книге

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

Как правило, устройства долгосрочного хранения информации организуются в
виде томов. Том представляет собой совокупность ячеек носителя
информации, доступных для чтения и записи со стороны приложений. Анализ
томов будет подробно рассматриваться в части 2 книги, а сейчас я упомяну
о двух важнейших концепциях этого уровня. Первая — это разделы (один том
разбивается на несколько томов меньшего объема), а вторая — сборка
(объединение нескольких томов в один большой том, на котором в
дальнейшем могут создаваться разделы). Примерами данных этой категории
служат таблицы разделов DOS, разделы Apple и массивы RAID. Некоторые
носители (скажем, дискеты) не содержат данных на этом уровне, а весь
диск представляет собой один том. Анализ данных на уровне томов
позволяет определить, где находится файловая система и другие данные и
где может храниться скрытая информация.

Анализ данных

PAGE 33

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

Рис. 1.3. Процесс анализа данных: от физического уровня к прикладному

Чтобы понять, что находится внутри файла, необходимо перейти на
прикладной уровень. Структура каждого файла определяется приложением или
ОС, создавшей файл. Например, с точки зрения файловой системы файл
реестра Windows ничем не отличается от обычной HTML-страницы — и то и
другое является файлом. Тем не менее эти файлы имеют совершенно разную
структуру, а для их анализа должны применяться разные инструменты.
Анализ прикладного уровня играет очень важную роль: именно на этом
уровне на основании анализа конфигурационных файлов мы определяем, какие
программы выполнялись в системе, не содержит ли скрытых данных
графический файл, и т. д. В книге прикладной анализ не рассматривается —
чтобы представить его на том же уровне, что и анализ томов и файловых
систем, потребуется несколько отдельных книг. За дополнительной
информацией обращайтесь к общей литературе по цифровым расследованиям.

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

PAGE 34

Глава 1. Основы цифровых расследований

Необходимые и вспомогательные данные

Все данные в описанной схеме в той или иной степени структурированы, но
не вся структура необходима для выполнения основных функций уровня.
Например, целью уровня файловой системы является организация пустых
томов для хранения данных и их последующей выборки. Файловая система
связывает имя файла с содержимым. Следовательно, данные об имени файла и
его местонахождении на диске являются обязательными. Так, на рис. 1.4
изображен файл с именем mirade.txt и содержимым, хранящимся по адресу
345. Если имя файла или адрес содержимого окажутся неверными или будут
отсутствовать, прочитать содержимое файла не удастся. Например, если в
поле адреса будет храниться значение 344, то при попытке чтения будет
получено постороннее содержимое.

Имя: Кластер: Размер: Последнее обращение:

miracle.txt 345 40 27 октября 2004 г.

Кластер 344 Кластер 345

Today, the Red Sox won the World Series

Рис. 1.4. Чтобы система могла найти и прочитать этот файл, его имя,
размер и местонахождение содержимого должны быть точно заданы. С другой
стороны, точное значение времени последнего обращения не обязательно

На рис. 1.4 также показано, что для файла хранится время последнего
обращения. Однако этот атрибут не является необходимым для выполнения
основной функции файловой системы: даже если он будет изменен, пропадет
или будет задан неверно, это никак не повлияет на процесс чтения и
записи содержимого.

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

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

Today, the Yankees won the World Series

Инструментарий эксперта

35

Инструментарий эксперта

Существует множество программ, используемых аналитиками при анализе
цифровых систем. Функции большинства программ такого рода в основном
сосредоточены в фазах сохранения и поиска. В примерах, приводимых в
книге, будет использоваться пакет TSK (The Sleuth Kit). Я разрабатываю
этот пакет и опишу его позднее в этом разделе. TSK распространяется
бесплатно; это означает, что любой читатель может воспроизвести
приведенные примеры без каких-либо дополнительных затрат.

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

Если вас интересует более обширный список программ, обратитесь на сайт
Кристин Сидсма (Christine Siedsma) Electronic Evidence Information (
HYPERLINK “http://” http:// HYPERLINK “http://www.e-evidence.info”
www.e-evidence.info ) или на сайт Якко Тунниссена (Jacco Tunnissen)
Computer Forensics, Cybercrime and Steganography ( HYPERLINK
“http://www.forensics.nl” http://www.forensics.nl ). Я также веду список
программ анализа с открытыми исходными кодами — как коммерческих, так и
некоммерческих ( HYPERLINK “http://www.opensourceforensics.org”
http://www.opensourceforensics.org ). В книге приводятся теоретические
обоснования того, как программы используются при анализе файловой
системы, но мне кажется, что программы с открытым кодом также пригодятся
в расследовании: эксперт или доверенная сторона может прочитать исходный
код и проверить, как в программе реализована теория. Это позволит
экспертам дать более обоснованные показания относительно цифровых улик
[Carrier, 2003Ь].

EnCase (Guidance Software)

Несмотря на отсутствие официальных цифр, считается, что EnCase (
HYPERLINK “http://www.en-” http://www.en- HYPERLINK “http://case.com”
case.com ) является самой распространенной программой компьютерных
расследований. EnCase работает на платформе Windows и позволяет снимать
и анализировать данные с применением локальной или сетевой версии.
EnCase анализирует различные форматы файловых систем, включая FAT, NTFS,
HFS, UFS, Ext2/3, Reiser, JFS, CD-ROM и DVD. Кроме того, EnCase
поддерживает динамические диски Microsoft Windows и AIX LVM.

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

PAGE 36

Глава 1. Основы цифровых расследований

Forensic Toolkit (Access Data)

Пакет FTK (Torensic Toolkit) работает на платформе Windows. К его
функциям относятся снятие данных и анализ дисков, файловых систем и
прикладных данных ( HYPERLINK “http://www.accessdata.com”
http://www.accessdata.com ). FTK поддерживает файловые системы FAT, NTFS
и Ext2/3, но пакет более всего известен своими возможностями поиска и
поддержкой анализа прикладного уровня. FTK строит отсортированный индекс
слов в файловой системе, существенно ускоряющий поиск. Кроме того, FTK
содержит множество программ просмотра различных файловых форматов и
поддерживает разные форматы электронной почты.

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

ProDiscover (Technology Pathways)

ProDiscover ( HYPERLINK “http://www.techpathways.com”
http://www.techpathways.com ) работает на платформе Windows. Эта
программа снятия данных и анализа существует как в локальной, так и в
сетевой версиях. ProDiscover умеет анализировать файловые системы FAT,
NTFS, Ext2/ 3 и UFS, а также динамические диски Windows. В области
поиска реализованы основные функции составления списков файлов и
каталогов, восстановления удаленных файлов, поиска по ключевым словам и
идентификации файлов по базам данных хеш-кодов. Возможен вариант
приобретения лицензии ProDiscover с исходными кодами, чтобы аналитик мог
проверить принципы работы программы.

SMART (ASR Data)

SMART ( HYPERLINK “http://www.asrdata.com” http://www.asrdata.com ) —
программа снятия и анализа данных на платформе Linux. Ее разработчиком
является Энди Розен (Andy Rosen), создатель исходной версии Expert
Witness (теперь эта программа называется EnCase). SMART работает со
многими файловыми системами, поддерживаемыми в Linux, и умеет
анализировать FAT, NTFS, Ext2/3, UFS, HFS+, JFS, Reiser, CD-ROM и другие
системы. При поиске улик SMART дает возможность фильтровать файлы и
каталоги в образе диска, восстанавливать удаленные файлы, проводить
поиск по ключевым словам, просматривать все графические файлы и
идентифицировать файлы по базам данных хеш-кодов.

The Sleuth Kit/Autopsy

TSK (The Sleuth Kit) — набор программ анализа для UNIX, работающих в
режиме командной строки, a Autopsy — графический интерфейс для TSK (
HYPERLINK “http://www.sl.euth-” http://www.sl.euth- HYPERLINK
“http://kit.org” kit.org ). Инструментарий файловой системы TSK
создавался на базе пакета ТСТ (The Coroner’s Tookit), авторами которого
были Дэн Фармер (Dan Farmer) и Вит-це Венема (Wietse Venema). TSK и
Autopsy анализируют файловые системы FAT, NTFS, Ext2/3 и UFS, выводят
списки файлов и каталогов, восстанавливают

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

PAGE 37

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

Итоги

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

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

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

• Bej tlich, Richard. The Tao of Network Security Monitoring: Beyond
Intrusion Detection. Boston: Addison Wesley, 2005.

• Brenner, Susan, Brian Carrier, and Kef Henninger. «The Trojan Defense
in Cybercrime Cases». Santa Clara Computer and High Technology Law
Journal, 21(1), 2004.

• Carrier, Brian. «Defining Digital Forensic Examination and Analysis
Tools Using Abstraction layers*. International Journal ofDigital
Evidence, Winter 2003a. http:/ HYPERLINK “file:///www.ijde.org”
/www.ijde.org .

• Carrier, Brian. «Ореп Source Digital Forensic Tools: The Legal
Arguments Fall 2003b. HYPERLINK “http://www.digital-evidence.org”
http://www.digital-evidence.org .

• Carrier, Brian, and Eugene H. Spafford. «Getting Physical with the
Digital Investigation Process». International Journal of Digital
Evidence, Fall 2003. HYPERLINK “http://” http:// HYPERLINK
“http://www.ijde.org” www.ijde.org .

• Casey, Eoghan. Digital Evidence and Computer Crime. 2nd ed. London:
Academic Press, 2004.

• Clifford, Ralph, ed. Cybercrime: The Investigation, Prosecution, and
Defense of a Computer-Related Crime. Durham: Carolina Academic Press,
2001.

• George, Esther. «UK Computer Misuse Act – The Trojan Virus Defense».
Journal of Digital Investigation, 1(2), 2004.

• The Honeynet Project. Know Your Enemy. 2nd ed. Boston: Addison-Wesley,
2004.

• Houghton Mifflin Company. The American Heritage Dictionary. 4th
ed.Boston: Houghton Mifflin, 2000.

• Mandia, Kevin, Chris Prosise, and Matt Pepe. Incident Response and
Computer Forensics. 2nd ed.
Emeryvil?›??????????????????????????????????????????????????????

Основные принципы работы компьютеров

Данная глава посвящена низкоуровневым основам работы компьютеров. О том,
как организуется хранение данных, достаточно подробно рассказано в
следующих главах, а здесь приводится вводный курс для читателей, не
обладающих опытом программирования и познаниями в архитектуре
операционных систем. Глава начинается с обсуждения данных и способов их
хранения на диске. В частности, будут рассмотрены двоичное и
шестнадцатеричное представление, а также прямой и обратный порядок
байтов. Затем мы перейдем к процессу начальной загрузки системы и
системному коду, необходимому для запуска компьютера. В конце главы речь
пойдет о жестких дисках, их геометрии, командах АТА, защищенных областях
и технологии SCSI.

Организация данных

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

Двоичная, десятичная и шестнадцатеричная запись

Начнем с систем счисления. Люди привыкли работать с десятичными числами,
но компьютеры работают с двоичными данными, состоящими из нулей и
единиц. Каждая двоичная цифра (ноль или единица) называется битом;
группа из 8 битов называется байтом. Двоичные числа аналогичны
десятичным, если не считать того, что в десятичных числах используются
10 разных цифр (от 0 до 9), а в двоичных — только две.

Прежде чем подробно заниматься двоичными числами, необходимо понять, что
такое десятичное число. Десятичное число представляет собой серию
символов (цифр), при этом каждая цифра обладает некоторым значением. Для
крайней правой цифры это значение равно 1, для цифры слева от нее — 10 и
т. д. Каждая цифра обладает весовым значением, в 10 раз превышающим
значение предыдущего разряда: для второй цифры справа это значение равно
10, для третьей — 100, для четвертой — 1000 и т. д. Для примера возьмем
десятичное число 35 812. Чтобы

Организация данных

PAGE 39

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

Десятичное число: 35 812

10 000 1000 100 10 1

3 5 8 1 2

(3 х 10 000) + (5 х 1000) + (8 х 100) + (1 х 10) + (2 х 1) = 35 812 Рис.
2.1. Значение каждой цифры в десятичном числе

Крайняя правая цифра называется младшей, а крайняя левая — старшей. Так,
для числа 35 812 цифра 3 является старшей, а цифра 2 — младшей.

Теперь перейдем к двоичным числам. В каждом разряде двоичного числа
находится только одна из двух цифр (0 и 1); при этом каждый разряд
обладает десятичным значением, вдвое превышающим значение предыдущего
разряда. Таким образом, крайний правый разряд соответствует десятичному
значению 1, второй разряд справа — десятичному значению 2, третий — 4 и
четвертый — 8 и т. д. Чтобы вычислить десятичное представление двоичного
числа, следует просуммировать весовые значения столбцов, умноженные на
находящиеся в них цифры. На рис. 2.2 показано, как двоичное число 1001
0011 переводится в десятичную систему. Из результата видно, что его
десятичное значение равно 147.

В табл. 2.1 приведены десятичные значения первых 16 двоичных чисел. В
ней также указаны их шестнадцатеричные эквиваленты, о которых речь
пойдет далее.

Двоичное число: 1001 0011

128 64 32 16 8 4 2 1

1 0 0 1 0 0 1 1

(1 х 128)+ (0x64)+ (0x32)+ (1 х 16)+ (0x8)+ (0x8)+ (0x4)+ (1 х 2) + (1 х
1) = 147 Рис. 2.2. Преобразование двоичного числа в десятичное значение

Таблица 2.1. Преобразования между двоичной, десятичной и
шесгнадцатеричной системами

Двоичная запись Десятичная запись Шестнадцатеричная запись

0000 00 0

0001 01 1

0010 02 2

ООП 03 3

0100 04 4

0101 05 5

продолжение &

PAGE 40

Глава 2. Основные принципы работы компьютеров

Таблица 2.1 {продолжение)

Двоичная запись Десятичная запись Шестнадцатеричная запись

ОНО 06 6

0111 07 7

1000 08 8

1001 09 9

1010 10 А

1011 11 В

1100 12 С

1101 13 D

1110 14 Е

1111 15 F

При записи шестнадцатеричных чисел используются 16 цифр (от 0 до 9, за
которыми следуют буквы от А до Б). В табл. 2.1 показано соответствие
между шестнадцатеричными цифрами и десятичными числами.
Шестнадцатеричная запись удобна прежде всего тем, что она легко
преобразуется в двоичную (и наоборот), и часто применяется при работе с
низкоуровневыми данными. Я буду снабжать шестнадцатеричные числа
префиксом Ох, чтобы отличить их от десятичных.

Необходимость в преобразовании шестнадцатеричных чисел в десятичную
запись возникает довольно редко, но я все же покажу, как это делается.
Десятичные весовые коэффициенты разрядов шестнадцатеричного числа
увеличиваются в 16 раз. Таким образом, десятичное значение первого
(крайнего правого) разряда равно 1, второго — 16, третьего — 256 и т. д.
Чтобы выполнить преобразование, мы просто умножаем весовые коэффициенты
разрядов на соответствующие цифры и суммируем результаты. На рис. 2.3
показан результат преобразования шестнадцатеричного числа 0х8ВЕ4 в
десятичную систему.

Шестнадцатеричное число: 0х8ВЕ4

Эквиваленты ОхВ = 11 0хЕ = 14

4 096 256 16 1

8 11 14 4

(8×4 096) + (11 х 256) + (14 х 16) + (4 х 1) = 35 812 Рис. 2.3.
Преобразование шестнадцатеричного числа в десятичную систему

Остается рассмотреть преобразования между шестнадцатеричной и двоичной
записью. Такие преобразования выполняются гораздо проще и сводятся к
простой подстановке. Чтобы получить двоичное представление имеющегося
шестнадцатеричного числа, достаточно обратиться к табл. 2.1 и заменить
каждую шестнад-цатеричную цифру эквивалентной последовательностью из 4
битов. И наоборот, при преобразовании двоичного числа в
шестнадцатеричное следует разделить число на группы по 4 бита и заменить
каждую «четверку» эквивалентной шестнадцатеричной цифрой. Вот и все!
Преобразование двоичного числа в шестнадцатеричное и наоборот показано
на рис. 2.4.

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

Организация данных

PAGE 41

чество допустимых цифр в степень, равную числу разрядов, и вычесть 1
(чтобы учесть нулевое значение). Например, для двоичных чисел мы
возводим 2 в степень, равную количеству битов, и вычитаем 1.
Следовательно, наибольшее десятичное число, которое может быть
представлено 32-разрядной двоичной последовательностью:

232 – 1 = 4 294 967 295 К счастью, в большинстве системных редакторов
имеется встроенный калькулятор с возможностью преобразования между
двоичной, десятичной и шестнадца-теричной записью, поэтому запоминать
все эти методы вам не придется. В книге дисковые данные приводятся в
шестнадцатеричной записи; важнейшие значения будут приводиться как в
шестнадцатеричной, так и в десятичной записи.

1001 0011 в шестнадцатеричную запись

Шестнадцатеричная 0x9

1001 0011

0x9 0x3

0x93 в двоичную запись

0x9 0x3

ч/

1001 0011

0x3 Шестнадцатеричная

Рис. 2.4. Преобразование между двоичной и шестнадцатеричной записью
осуществляется

простой заменой по табл. 2.1

Размеры данных

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

В общем случае байт представляет собой наименьшую область памяти,
выделяемую для хранения данных. Байт позволяет представить до 256
возможных значений, поэтому для хранения больших чисел байты приходится
группировать. Как правило, на практике используются группы размером 2, 4
и 8 байт. Конкретный способ хранения многобайтовых данных зависит от
компьютера. На одних компьютерах применяется обратный порядок байтов
(big-endian), при котором в первом байте на носителе хранится старший
(наиболее значимый) байт хранимого числа, а на других — прямой порядок
байтов (little-endian), при котором в первом байте хранится младший
(наименее значимый) байт. Напомню, что старшим называется байт с
наибольшим весовым коэффициентом (крайний левый байт), а младшим — байт
с наименьшим весовым коэффициентом (крайний правый байт).

На рис. 2.5 изображено 4-байтовое значение с прямым и обратным порядком
байтов. Для его хранения выделяется 4-байтовый блок, начинающийся с
байта 80 и заканчивающийся байтом 83. При анализе содержимого диска и
файловой системы необходимо учитывать порядок байтов исходной системы, в
противном случае вычисленное значение окажется неверным.

PAGE 42

Глава 2. Основные принципы работы компьютеров

В системах на базе IА32 (например, Intel Pentium) и их 64-разрядных
аналогах используется прямой порядок байтов, поэтому, если мы хотим,
чтобы старший байт оказался в крайней левой позиции, байты необходимо
«переставить». На Sun SPARC и Motorola PowerPC (например, на компьютерах
Apple) применяется обратный порядок байтов.

Фактическое значение: 0x12345678

79 80 81 82 83 84

Обратный порядок 00 12 34 56 78 00

79 80 81 82 83 84

Прямой порядок 00 78 56 34 12 00

Рис. 2.5. 4-байтовое значение с прямым и обратным порядком байтов

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

В предыдущем разделе рассказывалось о том, как на компьютерах хранятся
числовые данные, но мы также должны подумать о хранении строковых
данных, то есть отдельных символов и целых предложений. На практике для
хранения символьных данных чаще всего применяется кодировка ASCII или
Unicode. Кодировка ASCII проще, поэтому начнем с нее. В ASCII каждый
символ английского языка обозначается числовым кодом. Например, букве А
соответствует код 0x41, а символу & — код 0x26. Наибольшее определенное
значение равно 0х7Е; таким образом, любой символ базового набора
представляется одним байтом. Многие коды соответствуют управляющим
символам и не имеют печатного представления — например, звуковой сигнал
0x07. В табл. 2.2 приведены соответствия между шестнадцатеричными
числами и символами ASCII. Более подробная таблица ASCII-кодов
приводится по адресу: HYPERLINK “http://www.asciitable.com/”
http://www.asciitable.com/ .

Таблица 2.2. Шестнадцатеричные коды символов в ASCII

00-NULL 1—DLE 20-SPC 30-0 40-@ 50-Р 60-‘ 70—р

01-SOH 11-DCI 21-! 31-1 41-А 51-Q 61-а 71-q

02-STX 12-DC2 22-” 32-2 42-В 52-R 62-Ь 72-r

03-ЕТХ 13-DC3 23-# 33-3 43-С 53-S 63-с 73-s

04-ЕОТ 14-DC4 24-$ 34-4 44-D 54-Т 64-d 74-t

05-ENQ 15-NAK 25-% 35-5 45-Е 55-U 65-е 75-u

06-АСК 16-SYN 26-& 36-6 46-F 56-V 66-f 76-v

07-BEL 17-ЕТВ 27-‘ 37-7 47-G 57-W 67-g 77-w

08-BS 18-CAN 28-( 38-8 48-Н 58-Х 68-h 78-x

09-ТАВ 19-ЕМ 29-) 39-9 49-1 59-Y 69-і 79-y

0A-LF 1A-SUB 2А-* ЗА-: 4A-J 5A-Z 6A-j 7A-z

Организация данных

PAGE 43

ов-вт 1B-ESC 2В-+ ЗВ-; 4В-К 5В-[ бВ-к 7В-{

0C-FF 1C-FS 2С-, ЗС- 4E-N 5Е-А 6Е-п 7Е-~

0F-SI 1F-US 2F-/ 3F-? 4F-0 5F-_ 6F-0 7F-

Чтобы сохранить предложение или слово в кодировке ASCII, необходимо
выделить под него область памяти, размер которой в байтах соответствует
количеству символов в слове. В каждом байте хранится код одного символа.
Порядок байтов в этом случае роли не играет, потому что каждый символ
представлен отдельным 1-байтовым кодом. Таким образом, первый символ
слова или предложения всегда находится на первом месте.
Последовательность байтов в слове или предложении называется строкой
(string). Строки часто завершаются нуль-символом (NULL), соответствующим
коду 0x00. На рис. 2.6 показан пример строки, хранящейся в кодировке
ASCII. Строка состоит из 10 символов и завершается нуль-символом,
поэтому для ее хранения выделяется 11 байт, начиная с байта 64.

Строка: 1 Main St.

64 65 66 67 68 69 70 71 72 73 74

31 20 4D 61 69 бе 20 53 74 2е 00

1

М а i п

S t

Рис. 2.6. ASCII-строка, хранящаяся в памяти, начиная с адреса 64

Кодировка ASCII проста и удобна, если ваши потребности ограничиваются
английским алфавитом. Однако для пользователей из других стран мира ее
явно недостаточно, поскольку ASCII не позволяет представлять символы
национальных алфавитов. Для решения этой проблемы была создана кодировка
Unicode, в которой числовой код символа занимает более 1 байта (за
подробностями обращайтесь на сайт HYPERLINK “http://www.unicode.org”
www.unicode.org ). Версия 4.0 стандарта Unicode поддерживает более 96
000 символов, при этом для представления одного символа необходимы 4
байта (вместо 1 байта в ASCII).

Существует три варианта хранения символов Unicode. В первом варианте —
UTF-32 — каждый символ представляется 4 байтами, но при этом большая
часть памяти будет расходоваться неэффективно. Во втором варианте,
UTF-16, часто используемые символы хранятся в 2-байтовых кодах, а более
редкие — в 4-байтовых, поэтому в среднем текст занимает меньший объем,
чем в UTF-32. Третий вариант называется UTF-8, и один символ в нем
представляется 1, 2 или 4 байтами. При этом наиболее часто используемые
символы кодируются всего 1 байтом.

Переменная длина кода в UTF-8 и UTF-16 несколько усложняет обработку
данных. На практике чаще используется UTF-8, поскольку в этой кодировке
меньше места расходуется напрасно, a ASCII является ее подмножеством.
Если строка UTF-8 состоит только из ASCII-символов, каждый символ в ней
кодируется 1 байтом, а по своему содержимому такая строка совпадает с
эквивалентной ASCII-строкой.

PAGE 44

Глава 2. Основные принципы работы компьютеров

Структуры данных

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

Способ размещения данных в памяти определяется структурами данных.
Структура данных напоминает шаблон или карту. Она делится на поля, при
этом каждое поле обладает определенным размером и именем (хотя эта
служебная информация не хранится вместе с данными). Например, структура
данных может определить, что первое поле называется number и имеет длину
в 2 байта. В программе это поле будет использоваться для хранения номера
дома в адресе. Сразу же за полем number следует поле street, длина
которого равна 30 байтам. Соответствующая структура данных показана в
табл. 2.3.

Таблица 2.3. Простая структура данных для хранения номера дома и
названия улицы

Диапазон байтов Описание

0-1 Номер дома (2 байта)

2-31 Название улицы в кодировке ASCII (30 байт)

Когда данные требуется записать на носитель информации, область памяти
для каждого компонента записи определяется по соответствующей структуре
данных. Например, если требуется сохранить адрес 1 Main St., сначала
адрес разбивается на составляющие: номер дома и название улицы. Число 1
записывается в байты 0-1 выделенного блока, а строка «Main St.» — в
байты 2-9 в виде ASCII-кодов каждого символа. Остальные байты можно
обнулить, так как в данном примере они не используются. 32 байта,
выделенные для хранения данных, могут располагаться в любом месте
устройства. Смещения задаются относительно начала выделенного блока. Не
забывайте, что очередность байтов в номере дома зависит от порядка
байтов на компьютере.

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

00000000: 0100 4d61 696е 2053 742е 0000 0000 0000 ..Main St…….

00000016: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

00000032: 1900 536f 7574 6820 5374 2е00 0000 0000 ..South St……

00000048: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

Результат получен от утилиты UNIX xxd, напоминающей графический
шестнад-цатеричный редактор. В левом столбце приводится смещение в
байтах, в средних 8 столбцах — 16 байт данных в шестнадцатеричной форме,
а в последнем столбце — их представление в кодировке ASCII. Символами
«.» обозначается отсутствие

Организация данных

PAGE 45

печатных ASCII-символов в данной позиции. Вспомните, что каждый
16-разрядный символ представляет 5 бита, поэтому на один байт требуется
2 шестнадцате-ричных символа.

Просматривая раскладку структуры данных, мы видим, что каждый адрес
занимает 32 байта, поэтому первый адрес хранится в байтах 0-31. Байты
0-1 предназначены для хранения 2-байтового номера дома, а байты 2-31 —
для названия улицы. В байтах 0-1 отображается значение 0x0100. Данные
взяты из системы Intel, использующей прямой порядок байтов, поэтому 0x01
и 0x00 необходимо поменять местами — получаем 0x0001. Преобразование к
десятичному виду дает число 1.

Второе поле структуры данных занимает байты 2-31. Содержащаяся в нем
ASCII-строка не зависит от порядка байтов в системе, поэтому
переставлять данные не придется. Мы можем либо преобразовать каждый байт
в ASCII-эквивалент, либо схитрить и сразу заглянуть в нужные столбцы,
чтобы найти в них название «Main St.». Именно это значение было записано
ранее. Из приведенного вывода следует, что другая структура данных
начинается с байта 32 и продолжается до байта 63. Попробуйте
самостоятельно обработать ее для практики (она соответствует адресу «25
South St.»).

Разумеется, в структурах данных файловых систем хранится совершенно иная
информация, но базовые принципы остаются прежними. Например, в первом
секторе файловой системы обычно хранится большая структура данных с
десятками полей; читая ее, мы знаем, что размер файловой системы
хранится в байтах 32-35. Во многих файловых системах задействовано
несколько больших структур данных, используемых в разных местах.

Флаги

Прежде чем переходить к реальным структурам данных, я хотел бы обсудить
еще один тип данных — флаги. Некоторые данные всего лишь показывают,
выполняется или не выполняется некоторое условие: скажем, является ли
раздел загрузочным или нет. Значения таких данных представляются одной
двоичной цифрой (1 или 0). Конечно, для этой информации можно выделить
целый байт, в котором сохраняется значение 0 или 1. Однако такой способ
крайне неэффективен: из 8 выделенных битов реально используется всего
один. Более эффективный способ основан на упаковке нескольких двоичных
условий в одно значение, каждый бит которого соответствует некоторому
признаку или условию. Такие биты часто называются флагами (flags). Чтобы
получить значение флага, необходимо преобразовать число в двоичную форму
и проанализировать нужный бит. Если бит равен 1, значит, флаг
установлен.

Давайте рассмотрим практический пример и преобразуем структуру данных с
почтовым адресом в нечто более сложное. Исходная структура содержала два
поля данных: для номера дома и названия улицы. В новой версии в нее
добавляется необязательное 16-байтовое название города, следующее за
названием улицы. Так как имя города не является обязательным, необходимо
добавить флаг, указывающий на его наличие или отсутствие. Флаг хранится
в байте 31; если запись содержит название города, бит 0 устанавливается
(то есть 0000 0001). Если название города присутствует, структура данных
содержит 48 байт вместо 32. Новая структура данных приведена в табл.
2.4.

PAGE 46

Глава 2. Основные принципы работы компьютеров

Таблица 2.4. Структура данных со значением флага

Диапазон байтов Описание

0-1 Номер дома (2 байта)

2-30 Название улицы в кодировке ASCII (29 байт)

31-31 Флаги

32-47 Название города в кодировке ASCII (16 байт) — если флаг установлен

Пример данных, записанных на диск с использованием этой структуры:

00000000: 0100 4d61 696е 2053 742е 0000 0000 0000 ..Main St…….

00000016: 0000 0000 0000 0000 0000 0000 0000 0061 ……………а

00000032: 426f 7374 6f6e 0000 0000 0000 0000 0000 Boston……….

00000032: 1900 536f 7574 6820 5374 2e00 0000 0000 ..South St……

00000064: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

Первая строка выглядит точно так же, как в предыдущем примере. Флагу в
байте 31 присвоено значение 0x61. Размер флага составляет всего 1 байт,
поэтому беспокоиться о порядке байтов не нужно. Значение необходимо
преобразовать в двоичную систему; по табл. 2.1 значения 0x6 и 0x1
заменяются двоичным значением ОНО 0001. Младший бит, то есть флаг
города, установлен. В остальных битах содержатся значения других флагов
— скажем, признак юридического адреса. На основании значения флага
известно, что в байтах 32-47 хранится название города («Boston»).
Следующая структура данных начинается с байта 48, а ее поле флагов
хранится в байте 79. Значение равно 0x60, флаг города не установлен.
Следовательно, третья структура данных начинается с байта 80.

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

Процесс загрузки

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

Процессор и машинный код

Главную роль на современном компьютере играет центральный процессор
(CPU, Central Processing Unit); на некоторых компьютерах процессоров
устанавливается два и более процессора. В качестве примеров процессоров
можно назвать Intel Pentium и Itanium, AMD Athlon, Motorola PowerPC и
Sun UltraSPARC. Сам no себе процессор не приносит особой пользы, потому
что он умеет только выполнять полученные команды. В этом отношении он
напоминает калькулятор. Как

Процесс загрузки

PAGE 47

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

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

Я кратко опишу структуру машинного кода, чтобы вы знали, с чем имеете
дело, обнаружив его на диске. Каждая команда машинного кода состоит из
нескольких байтов. Первая пара байтов определяет тип команды, называемый
кодом операции (opcode). Например, значение 3 может обозначать операцию
сложения. За кодом операции следуют аргументы команды — скажем,
аргументы команды сложения определяют два суммируемых числа.

Для данной книги более подробного описания не потребуется, но я приведу
простейший пример. Одна из машинных команд заносит числа в регистры
процессора. Регистрами называются ячейки, в которых процессор хранит
обрабатываемые данные. Ассемблерная команда M0V АН,00 заносит значение 0
в регистр АН. Эквивалентная команда машинного кода в шестнадцатеричном
виде имеет 0хВ400, где В4 — код операции M0V АН, а 00 —
шестнадцатеричное число, помещаемое в регистр. Некоторые утилиты
автоматически транслируют машинный код на ассемблер, но во многих
случаях неочевидно, имеете ли вы дело с машинным кодом или какими-то
произвольными данными.

Местонахождение загрузочного кода

Итак, центральный процессор является «сердцем» компьютера, и для работы
ему необходимо передавать команды. Следовательно, для запуска компьютера
некое устройство должно поставлять процессору команды, называемые
загрузочным кодом. В большинстве систем этот процесс состоит из двух
этапов: на первом этапе происходит инициализация оборудования, а на
втором запускается операционная система или иное программное
обеспечение. Мы кратко познакомимся с загрузочным кодом, потому что во
всех томах и файловых системах имеется специальная область для хранения
загрузочного кода, причем она зачастую не используется.

При включении питания компьютер способен только прочитать команды из
специальной области памяти, как правило — из постоянной (ПЗУ). Код ПЗУ
заставляет систему провести проверку и настройку оборудования. После
завершения настройки процессор переходит к поиску устройства, которое
может содержать дополнительный загрузочный код. Если такое устройство
найдено, то управление передается его загрузочному коду, а последний
пытается найти и загрузить операционную систему. Процесс загрузки после
обнаружения загрузочного диска зависит от конкретной платформы, и более
подробно рассматривается в следующих главах.

А пока для примера мы в общих чертах рассмотрим процесс загрузки системы
Microsoft Windows. При включении питания процессор читает команды из
BIOS (Basic Input/Output System) и ищет жесткие диски, дисководы CD-ROM
и другие устройства, поддержка которых настроена в BIOS. После
идентификации

PAGE 48

Глава 2. Основные принципы работы компьютеров

оборудования BIOS анализирует флоппи-диски, жесткие диски и дисководы
CD-ROM в некотором заданном порядке и обращается к первому сектору за
загрузочным кодом. Код первого сектора загрузочного диска заставляет
процессор обработать таблицу разделов и найти загрузочный раздел, в
котором находится операционная система Windows. В первом секторе раздела
размещается дополнительный загрузочный код, обеспечивающий поиск и
загрузку операционной системы. На рис. 2.7 изображено взаимодействие
различных компонентов в процессе загрузки.

Команды BIOS

2) Диск/ Сектор 0/ Команды

Процессор

3) Раздел/ Сектор 0/ Команды

/

ДискО

Операционная система Windows

Рис. 2.7. Взаимодействие компонентов загрузочного кода в системах IA32

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

Технологии жестких дисков

В этом разделе рассматриваются основные концепции жестких дисков и
различные темы, представляющие интерес с аналитической точки зрения:
методы доступа, блокировка записи и возможные места хранения скрытых
данных. В первом подразделе содержится краткий обзор принципов работы
диска, а два следующих подраздела посвящены дискам ATA/IDE и SCSI
соответственно.

Геометрия и внутреннее устройство жесткого диска

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

Технологии жестких дисков

PAGE 49

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

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

Рис. 2.8. Внутреннее устройство диска АТА: справа находятся пластины, а
слева — рычаг с магнитной головкой, осуществляющей чтение и запись

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

Пустые пластины размечаются операцией низкоуровневого форматирования,
создающей структуры данных дорожек и секторов. Каждая дорожка (track)
представляет собой замкнутое «кольцо», проходящее по поверхности
пластины. Адреса, присваиваемые дорожкам жесткого диска, увеличиваются
по направлению от края к центру. Например, если на каждой пластине
размещается по 10 ООО дорожек, то внешней дорожке каждой пластины
присваивается адрес 0, а внутренней дорожке (возле центра круга) — адрес
9 999. Так как все пластины имеют одинаковое строение, а находящимся на
них дорожкам присваиваются одинаковые адреса, совокупность всех дорожек
с заданным адресом на всех пластинах называется цилиндром. Так, цилиндр
0 состоит из дорожек 0 от нижней до верхней пластины жесткого диска.
Головкам чтения/записи также присваиваются адреса, что позволяет
однозначно определить, на какой пластине и с какой стороны должна быть
выполнена операция чтения или записи.

Дорожки делятся на секторы — наименьшие самостоятельно адресуемые блоки
жесткого диска, размер которых обычно составляет 512 байт. Каждому
сектору дорожки присваивается адрес, начиная с 1. Таким образом, к
конкретному сектору

PAGE 50

Глава 2. Основные принципы работы компьютеров

можно обратиться по адресу цилиндра (С), определяющему дорожку, адресу
головки (Н), определяющему пластину и ее поверхность, и адресу сектора
(Б). Схема обращения продемонстрирована на рис. 2.9.

Рис. 2.9. Геометрия отдельной пластины с адресами дорожек (цилиндров) и
секторов; цифры не имеют даже отдаленного отношения к реальности

Как будет показано в разделе «Типы адресации секторов», схема CHS уже не
является основной схемой адресации. Вместо нее используется адресация
LBA (Logical Block Address), при которой всем секторам присваиваются
последовательные адреса. Адрес LBA никак не связан с физическим
расположением сектора.

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

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

Интерфейс ATA/IDE

Интерфейс ATA (AT Attachment) является самым распространенным
интерфейсом жестких дисков. Диски, использующие этот интерфейс, часто
называются дисками IDE, но сокращение IDE означает «Integrated Disk
Electronics» и обозначает жесткий диск со встроенной логической схемой
(чего не было в старых

Технологии жестких дисков

PAGE 51

дисках). Интерфейс, используемый дисками «IDE», называется АТА. В этом
разделе приводятся некоторые важные детали спецификации АТА, чтобы
позднее мы могли обсудить такие технологии, как аппаратная блокировка
записи и защищенные области.

Спецификации АТА разрабатывались техническим комитетом Т13 ( HYPERLINK
“http://” http:// HYPERLINK “http://www.tl3.org” www.tl3.org ),
входящим в Международный комитет стандартов информационных технологий
(INCITS). Окончательные версии спецификаций распространяются за плату,
но предварительные версии можно загрузить бесплатно с сайта INCITS. Для
знакомства с жесткими дисками достаточно и предварительных версий.

Диски АТА обслуживаются контроллером, который в современных системах
встраивается в материнскую плату. Контроллер передает команды одному или
двум дискам АТА по плоскому кабелю. Максимальная длина кабеля составляет
45,7 см. Разъем кабеля имеет 40 контактов, но на новых дисках
задействованы 40 дополнительных проводов, не связанных ни с какими
контактами. Интерфейс показан на рис. 2.10. Дополнительные провода
предотвращают взаимные помехи между проводами. На портативных
компьютерах часто устанавливаются более компактные диски с 44-контактным
интерфейсом, включающим контакты для питания. Как показано на рис. 2.11,
для стыковки двух интерфейсов применяются специальные адаптеры. Также
существует 44-контактный интерфейс высокой плотности, применяемый на
некоторых портативных устройствах (таких, как Apple iPod).

Рис. 2.10. Диск АТА с 40-контактным разъемом, перемычками и разъемом
питания

Рис. 2.11. 44-контактный АТА-диск для портативного компьютера
подключается 40-контактным плоским кабелем через адаптер (я благодарен
за фото Эохану Кейси (Eoghan Casey))

Интерфейсная линия связи между контроллером и диском называется каналом.
Каждый канал может обслуживать два диска, называемых «ведущим» (master)
и «ведомым» (slave), хотя ни один из дисков не управляет работой
другого. Диски

PAGE 52

Глава 2. Основные принципы работы компьютеров

АТА настраиваются на выполнение роли ведущего или ведомого при помощи
физической перемычки на диске. Некоторые диски также поддерживают режим
Cable Select, в котором роль ведущего или ведомого назначается в
зависимости от того, к какому разъему плоского кабеля подключен диск. На
большинстве бытовых компьютеров используются два канала и поддержка до
четырех дисков АТА.

Типы адресации секторов

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

Существует два разных метода физической адресации. На старых жестких
дисках используются геометрические параметры и уже упоминавшаяся схема
CHS. Упрощенный пример организации адресов цилиндров и головок показан
на рис. 2.9.

Схема адресации CHS проста и удобна, но ее возможности оказались слишком
ограниченными, поэтому в наши дни она встречается редко. В исходной
спецификации АТА задействован 16-разрядный номер цилиндра, 4-разрядный
номер головки и 8-разрядный номер сектора, однако в старых версиях BIOS
использовался 10-разрядный номер цилиндра, 8-разрядный номер головки и
6-разрядный номер сектора. Следовательно, для взаимодействия с жестким
диском через BIOS должен использоваться минимальный размер каждого
параметра, вследствие чего максимальный объем диска ограничивается 504
Мбайт.

Чтобы обойти это ограничение, были разработаны новые версии BIOS,
транслировавшие «свои» диапазоны адресов в диапазоны адресов,
соответствующие спецификации АТА. Например, если приложение запрашивало
данные из цилиндра 8, головки 4 и сектора 32, система BIOS транслировала
его и запрашивала с диска цилиндр 26, головку 2, сектор 32. Для успешной
работы трансляции система BIOS сообщала параметры геометрии диска,
отличающиеся от фактических. Процесс трансляции не работает для дисков
объемом более 8,1 Гбайт.

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

Ограничение в 8,1 Гбайт, присущее трансляции, необходимо было
преодолеть, поэтому от схемы адресации CHS пришлось отказаться.
Стандартной стала схема адресации LBA (Logical Block Addresses), в
которой каждый сектор обозначается одним числом, начиная с 0. Схема LBA
поддерживается с момента выхода первой официальной спецификации АТА. В
схеме LBA приложение не обязано ничего знать о геометрии диска;
достаточно одного числа. Поддержка адресации CHS была исключена из
спецификации АТА в версии АТА-6.

Технологии жестких дисков

PAGE 53

К сожалению, некоторые файловые системы и другие структуры данных
продолжают работать со старыми адресами CHS, поэтому в книге нам
неоднократно потребуется преобразовывать CHS в LBA. Адрес LBA 0
соответствует адресу CHS 0,0,1, а адрес LBA 1 соответствует адресу CHS
0,0,2. Когда все секторы дорожки будут исчерпаны, используется первый
сектор следующей головки того же цилиндра, соответствующий адресу CHS
0,1,1. Представьте, что внешнее кольцо нижней пластины постепенно
заполняется, после чего происходит переход к следующей пластине, пока не
будет достигнута верхняя пластина. После этого используется второе
кольцо нижней пластины. Формула преобразования выглядит так:

LBA = (((ЦИЛИНДР * головок_на_цилиндр) + ГОЛОВКА) * секторов_на_дорожку)
+ СЕКТОР – 1 где значения ЦИЛИНДР, ГОЛОВКА И СЕКТОР заменяются
соответствующими компонентами CHS. Для примера возьмем диск с 16
головками на цилиндр и 63 секторами на дорожку. Адрес CHS 2,3,4
преобразуется в LBA следующим образом:

2208 – (((2 * 16) + 3) * 63) + 4 – 1

Стандарты интерфейсов

В области жестких дисков встречаются многочисленные названия
интерфейсов, способные запутать потребителя. Некоторые термины означают
одно и то же; просто комитет стандартизации выбрал один термин, а
компания, выпустившая жесткий диск, — другой. Описания неофициальных
терминов вроде «Enhanced IDE» или «Ultra ATA» приводятся на странице PC
Guide «Unofficial IDE/ATA Standards and Marketing Programs» ( HYPERLINK
“http://www.pcguide.com/ref/hdd/if/” http://www.pcguide.com/ref/hdd/if/
ide/unstd.htm). Как правило, каждый новый стандарт обеспечивает более
быстрый метод чтения или записи данных либо снимает ограничения
предыдущего стандарта.

Учтите, что спецификации АТА относятся только к жестким диска. Съемные
носители информации (такие, как CD-ROM и ZlP-диски) должны использовать
особую спецификацию ATAPI (AT Attachment Packet Interface). Устройства
AT API обычно подключаются к тем же кабелям и контроллерам, но для их
работы необходимы специальные драйверы.

Краткий перечень спецификаций, представляющих интерес для нашей темы:

• АТА-1: опубликована в 1994 году. Спецификация включает поддержку CHS и
28-разрядных адресов LBA [Т13 1994].

• АТА-3: спецификация опубликована в 1997 году, в нее были включены
средства контроля надежности pi безопасности. В частности, в АТА-3 была
представлена технология SMART (Self-Monitoring Analysis and Reporting
Technology), которая пытается повысить надежность работы диска
посредством отслеживания нескольких его частей. В этой спецификации
также появились пароли [Т13 1997].

• ATA/ATAPI-4: спецификация для съемных носителей AT API была
интегрирована в спецификацию АТА в версии АТА-4, опубликованной в 1998
году. В ней появился 80-проводный кабель для снижения помех. В АТА-4
также добавилась поддержка НРА, о которой речь пойдет далее [Т13 1998].

PAGE 54

Глава 2. Основные принципы работы компьютеров

• ATA/ATAPI-6: в обновленной спецификации, опубликованной в 2002 году,
добавилась 48-разрядная адресация LBA, исчезла поддержка адресации CHS и
добавилась поддержка DCO [Т13 2002].

• ATA/ATAPI-7: на момент написания книги спецификация оставалась в
предварительной версии. В нее вошла поддержка Serial ATA (см. далее).

Команды диска

В этом разделе приводится обзор взаимодействия контроллера с жестким
диском, который поможет вам лучше понять аппаратную блокировку записи и
защищенные области. Материал не относится к устройствам ATAPI (скажем,
дисководам CD-ROM).

Контроллер передает команды жесткому диску по плоскому кабелю. Команда
может быть принята обоими дисками, подключенными к кабелю, но одна из
частей команды указывает, для какого диска она предназначена: ведущего
или ведомого. Взаимодействие контроллера с жестким диском основано на
записи данных в регистры (небольшие ячейки памяти). После того как все
необходимые данные будут загружены в регистры, контроллер осуществит
запись в регистр команд, и жесткий диск выполнит команду (как при щелчке
на кнопке Submit после заполнения HTML-формы). Теоретически диск ничего
не должен делать до момента записи в регистр команд.

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

Пароли жестких дисков

В спецификации АТА-3 появились новые средства защиты данных, в том числе
возможность назначения пароля в BIOS или прикладных программах. Если
парольная защита реализована, жесткому диску назначаются два пароля:
пользовательский и главный. Главный пароль нужен для того, чтобы
администратор мог получить доступ к компьютеру в случае утраты
пользовательского пароля. При использовании паролей диск может работать
в двух режимах: повышенной и максимальной безопасности. В режиме
повышенной безопасности блокировка с диска снимается как
пользовательским, так и главным паролем. В режиме максимальной
безопасности пользовательский пароль может снять блокировку с диска, но
снятие блокировки главным паролем становится возможным только после
стирания всего содержимого диска. После нескольких неудачных попыток
ввода пароля диск «зависает», и систему приходится перезагружать.

Перед выполнением многих команд АТА должна быть выполнена команда SECU
RITY_U N LOCK с правильным паролем. После ввода правильного пароля диск
работает обычным образом вплоть до отключения питания.

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

Технологии жестких дисков

PAGE 55

ли диск, и позволяют снять блокировку с вводом пароля. Для примера
назову две такие программы, atapwd и hdunlock \ Пароль задается в BIOS
или в специальном приложении. Некоторые компании, специализирующиеся на
восстановлении данных, умеют обходить пароль для открытия диска.

Область НРА

Защищенной областью НРА (Host Protected Area) называется специальная
область диска, предназначенная для сохранения данных и невидимая для
постороннего наблюдателя. Размер этой области задается командами АТА.
Для большинства дисков по умолчанию он равен 0.

Поддержка НРА появилась в АТА-4. Она предназначалась для того, чтобы
производитель компьютера мог сохранить данные, которые не терялись бы
при форматировании жесткого диска пользователем и стирании его
содержимого. НРА находится в конце диска, а обращение к ее содержимому
возможно лишь в результате изменения конфигурации жесткого диска.

Рассмотрим процесс резервирования НРА более подробно, на уровне команд
АТА. Некоторые из используемых команд существуют в двух версиях в
зависимости от размера диска, но я буду приводить только одну версию.
Первые две команды возвращают максимальный номер адресуемого сектора;
если возвращаемые значения различаются, значит, на диске существует
область НРА. Команда READ_N ATIVE_ MAX_ADDRESS возвращает максимальный
физический адрес, а команда IDENTIFY_DEVICE возвращает количество
секторов, доступных для пользователя. Следовательно, при наличии НРА
READ_NATIVE_MAX_ADDRESS вернет фактический конец диска, тогда как
IDENTIFY_DEVICE вернет конец пользовательской области (и начало НРА).
Обратите внимание: как будет показано в следующем разделе, команда
READ_NATIVE_MAX_ADDRESS не всегда возвращает последний физический адрес
диска.

При создании НРА команда SET_MAX_ADDRESS задает максимальный адрес,
доступный для пользователя. Если потребуется отказаться от использования
НРА, команда SET_MAX_ADDRESS выполняется заново с фактическим
максимальным размером диска, возвращаемым командой
READ_NATIVE_MAX_ADDRESS.

Например, если объем диска составляет 20 Гбайт, READ_NATIVE_MAX_ADDRESS
возвращает количество секторов для 20 Гбайт (скажем, 41 943 040). Чтобы
создать защищенную область НРА объемом 1 Гбайт, следует выполнить
команду SET_MAX_ADDRESS с адресом 39 845 888. Любые попытки чтения или
записи в последние 2 097 152 сектора (1 Гбайт) приводят к ошибке, а
команда IDENTIFY_DEVICE возвращает максимальный адрес 39 845 888 (рис.
2.12). Чтобы снять защиту с НРА, следует снова выполнить команду
SET_MAX_ADDRESS с полным количеством секторов.

Среди параметров команды SET_MAX_ADDRESS присутствует «бит
устойчивости». Если он установлен, то НРА продолжает существовать после
сброса жесткого диска или отключения питания. В спецификации АТА также
присутствуют команды блокировки, которые запрещают модификацию
максимального адреса до следующего сброса. Это позволяет BIOS прочитать
или записать данные в защищенную область при включении питания, задать
размер защищенной области так,

1 Эти программы чаще всего встречаются на веб-сайтах, посвященных
модификации игровых приставок — например, http•// HYPERLINK
“http://www.xbox-scene.com/tools/tools.php?page=ha%d0%b3dd%d0%b3ive”
www.xbox-scene.com/tools/tools.php?page=haгddгive .

PAGE 56

Глава 2. Основные принципы работы компьютеров

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

О 19 20

ев ев ев

Секторы, адресуемые пользователем

НРА

IDENTIFY.DEVICE READ_NATIVE_MAX_ADDRESS Рис. 2.12. Диск объемом 20 Гбайт
с 1-гигабайтной защищенной областью НРА

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

DCO

Помимо НРА для скрытия данных также может применяться механизм DCO
(Device Configuration Overlay), поддержка которого была добавлена в
АТА-6. DCO ограничивает доступ к некоторым функциям жесткого диска. В
каждой спецификации АТА указываются дополнительные возможности,
реализация которых жестким диском не является обязательной. Для
определения набора возможностей, фактически поддерживаемых жестким
диском, используется команда IDENTIFY_DEVICE. Под воздействием DCO
команда IDENTIFY_DEVICE сообщает о том, что некоторые поддерживаемые
возможности якобы не поддерживаются, и выдает размер диска меньше
фактического.

Рассмотрим некоторые команды DCO. Команда DEVICE_CONFIGURATION_IDENTIFY
возвращает информацию о возможностях диска и его размере. Следовательно,
для обнаружения вмешательства DCO следует сравнить вывод команд
DEVICЕ_С0N FI-GURATION.IDENTIFY и IDENTIFY.DEVICE. Напомню, что команда
READ_NATIVE_MAX_AD-DRESS возвращает полный размер диска (вместе с НРА).
Сравнив результат READ_NATIVE_MAX_ADDRESS с результатом
DEVICE_CONFIGURATION_IDENTIFY, можно обнаружить присутствие секторов,
скрытых DCO.

Допустим, имеется 20-гигабайтный жесткий диск, в котором механизм DCO
установил максимальный адрес 19 Гбайт. Команды READ_NATIVE_MAX_ADDRESS и
IDENTIFY_DEVICE указывают, что размер диска равен только 19 Гбайт. Если
на диске также создается НРА размером 1 Гбайт, команда IDENTIFY_DEVICE
покажет, что размер диска составляет всего 18 Гбайт (рис. 2.13).

Для создания или изменения скрытой области DCO применяется команда
DEVICE_CONFIGURATION_SET, а для ее удаления – команда
DEVICE_C0NFIGURATI0N_RE-SET. В отличие от НРА, не существует возможности
внести изменения только на время текущего сеанса. Все изменения DCO
являются устойчивыми, сохраняются при сбросе и отключении питания.

Технологии жестких дисков

PAGE 57

о

GB 18 GB 19 GB 20 GB

Секторы, адресуемые пользователем

НРА

DCO

А

А

IDENTIFYJDEVICE

READ_NATIVE_MAX_ADDRESS

DEVICE.CONFIGURATIONJDENTIFY

Рис. 2.13. РСО создает скрытые секторы в конце диска (помимо секторов,
скрытых НРА)

Serial ATA

У устройств АТА имеются свои недостатки. Их кабели слишком велики,
недостаточно гибки, а разъемы часто оказываются совсем не там, где они
нужны. Кроме того, перемычки «ведущий/ведомый» усложняют конфигурацию
жестких дисков. Кабели и скорость передачи данных стали некоторыми
причинами для разработки интерфейса Serial АТА, включенного в
спецификацию АТА-7.

Интерфейс называется «последовательным» (Serial), потому что в любой
момент времени между контроллером и диском передается только один бит
информации — в отличие от 16 битов исходного интерфейса «параллельного
АТА». Разъемы Serial АТА примерно в четыре раза меньше разъемов
параллельного АТА и содержат только семь контактов. Каждое устройство
Serial АТА подключается к контроллеру напрямую, подключение «гирляндой»
не поддерживается.

Интерфейс Serial АТА проектировался таким образом, чтобы после установки
нового контроллера компьютер не отличал новое устройство Serial АТА от
исходных (параллельных) устройств АТА. Более того, регистры контроллера
Serial АТА создают у компьютера «иллюзию», будто он взаимодействует с
параллельным диском АТА. С точки зрения компьютера каждый диск,
подключенный к контроллеру Serial АТА, работает как ведущий (master)
диск на отдельном канале.

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

Прямой доступ к контроллеру

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

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

BIOS и прямой доступ

PAGE 58

Глава 2. Основные принципы работы компьютеров

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

Доступ к контроллеру через BIOS

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

Как говорилось ранее в разделе «Местонахождение загрузочного кода», BIOS
используется при запуске компьютера. В процессе загрузки BIOS решает
много задач, но сейчас нас интересуют две из них. Первая — это сбор
подробной информации об установленных дисках, а вторая — заполнение
таблицы прерываний, используемой для обслуживания запросов операционной
системы и прикладных программ.

Чтобы воспользоваться сервисом жестких дисков BIOS, программа должна
загрузить необходимые данные (например, адрес и размер сектора) в
регистры процессора и выполнить команду программного прерывания 0xl3h
(INT 13h). Получив команду программного прерывания, процессор обращается
к таблице прерываний и находит в ней адрес кода обработки запроса на
прерывание. Как правило, для прерывания 0x13 в таблице хранится адрес
кода BIOS, который использует имеющуюся информацию о жестких дисках для
взаимодействия с контроллером. В сущности, BIOS выполняет функции
посредника между программным обеспечением и жестким диском.

Вообще говоря, прерывание INT 13h представляет целую категорию дисковых
функций. В эту категорию входят функции записи на диск, чтения с диска,
форматирования дорожек и получения информации о диске. Исходные функции
INT 13h использовали для чтения/записи адреса CHS и позволяли программам
работать с дисками объемом 8,1 Гбайт и менее. Для снятия этого
ограничения в код BIOS были добавлены новые функции, называемые
«расширенными обработчиками INT 13h».

Расширенные обработчики INT 13h требовали нового кода BIOS и
использовали 64-разрядные адреса LBA. В целях совместимости старые
функции CHS были сохранены, и для использования новых функций LBA INT
13h пришлось вносить изменения в программное обеспечение.

Диски SCSI

В этом разделе приводится обзор технологии SCSI (Small Computer Systems
Interface), различных типов устройств и отличий от AT А. Жесткие диски
SCSI не получили столь широкого распространения, как жесткие диски АТА
для «бытовых» PC, но именно они применяются на большинстве серверов.

Как и в случае с АТА, существует целый ряд спецификаций SCSI,
опубликованных техническим комитетом Т10 при INCITS ( HYPERLINK
“http://www.tlO.org” http://www.tlO.org ). Три основные спецификации
SCSI — SCSI-1, SCSI-2 и SCSI-3 — включают несколько спецификаций более
низкого уровня, но их подробное описание выходит за рамки книги.

Технологии жестких дисков

PAGE 59

SCSI И АТА

Между SCSI и АТА существует множество различий как на высоком, так и на
низком уровне. К наиболее очевидным различиям верхнего уровня относятся
многочисленные типы разъемов. В АТА поддерживаются разъемы только с 40 и
44 контактами, но в SCSI набор форм и типов разъемов гораздо более
разнообразен. Кабели SCSI могут иметь гораздо большую длину, чем кабели
АТА, и к одному кабелю может подключаться более двух устройств. Каждому
устройству, подключенному к кабелю SCSI, присваивается уникальный
числовой идентификатор, который задается при помощи перемычек на диске
или специальной программы. На многих дисках SCSI также присутствует
перемычка, которая разрешает доступ к диску только для чтения; по своим
функциям она напоминает блокировщик записи АТА — внешнее устройство,
блокирующее команды записи (см. главу 3).

Первое низкоуровневое различие между АТА и SCSI состоит в том, что в
технологии SCSI нет контроллера. Интерфейс АТА проектировался в расчете
на единый контроллер, управляющий работой одного или двух жестких
дисков. Интерфейс SCSI проектировался как шина для взаимодействия
различных устройств, круг которых не ограничивается жесткими дисками. В
конфигурации SCSI плата, подключаемая к компьютеру, не является
контроллером, поскольку все устройства на кабеле SCSI равноправны и
могут обращаться с запросами друг к другу.

По аналогии с АТА, стандартный интерфейс SCSI работает в параллельном
режиме, а пересылка данных осуществляется 8- или 16-разрядными пакетами.
Как и в АТА, существует последовательная версия спецификации.

Типы SCSI

Различия в версиях SCSI сводятся к количеству одновременно пересылаемых
битов, скорости передачи (частоте сигналов в кабеле) и типам
используемых сигналов. Более старые разновидности существовали в двух
версиях, нормальной и расширенной; в нормальной версии одновременно
передавалось 8 битов, а в расширенной — 16 битов. Например, устройства
Ultra SCSI использовали 8-разрядную пересылку, а устройства Wide Ultra
SCSI — 16-разрядную. Во всех новых системах используется 16-разрядная
пересылка, и различать нормальную и расширенную версию уже не нужно.

Второе различие между версиями SCSI определяет скорость передачи сигнала
по кабелю. В табл. 2.5 приведены названия типов SCSI, частоты и скорость
передачи данных для 8-разрядной нормальной и 16-разрядной расширенной
шины.

Таблица 2.5. Скорость передачи данных для различных типов SCSI Тип
Частота, 8-разрядная 16-разрядная (расширенная)

МГц передача, Мбайт/с передача, Мбайт/с

SCSI (нормальная) 5 5 10

Fast SCSI 10 10 20

Ultra SCSI 20 20 40

Ultra2 SCSI 40 40 80

Ultra3 SCSI 80 — 160

Ultral60 SCSI 80 — 160

Ultra320 SCSI 160 — 320

PAGE 60

Глава 2. Основные принципы работы компьютеров

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

Второй способ передачи данных называется дифференциальным, и для
пересылки каждого бита в нем задействуются два провода. При пересылке 0
на обоих проводах напряжение отсутствует. При пересылке 1 на один провод
подается положительное напряжение, а на другой — отрицательное. Принимая
сигналы с кабеля, устройство определяет разность между напряжениями на
двух проводах. Дифференциальный сигнал высокого напряжения (HVD, High
Voltage Differential) существовал в SCSI, начиная с первой версии, тогда
как дифференциальный сигнал низкого напряжения (LVD) появился только в
Ultra2 SCSI и является основным типом сигнала для новых дисков. В табл.
2.6 показано, в каких типах SCSI используются те или иные разновидности
сигналов.

Таблица 2.6. Разновидности сигналов в разных типах SCSI

Тип сигнала Типы SCSI

SE SCSI, Fast SCSI, Ultra SCSI

HVD SCSI, Fast SCSI, Ultra SCSI, Ultra2 SCSI

LVD Ultra2 SCSI, Ultra3 SCSI, Ultral60 SCSI, Ultra320 SCSI

Ни в коем случае не путайте типы сигналов! Подключение устройств SE к
устройствам HVD и некоторым устройствам LVD приведет к их повреждению.
Некоторые диски LVD являются SE-совместимыми pi могут использоваться в
среде SE без повреждения, но только на тех скоростях, на которых
работают устройства SE. На устройствах SCSI присутствует условное
обозначение используемого типа сигнала (рис. 2.14).

А) В) С) D)

Рис. 2.14. Условные обозначения типа сигнала на устройствах SCSI: (А) —
устройства SE, (В) — устройства LVD, (С) — SE- и LVD-совместимые
устройства, (D) — устройства HVD

Типы разъемов

Существует много разновидностей разъемов SCSI, но на практике часто
встречаются лишь некоторые из них. Как правило, диски с 8-разрядной
шиной используют 50-контактные разъемы, а диски с 16-разрядной шиной —
68-контактные. В настоящее время наибольшее распространение получили
68-контактные адаптеры высокой плотности, существующие в двух
модификациях: нормальные и очень

Технологии жестких дисков

PAGE 61

высокой плотности. Нормальные разъемы получили наибольшее
распространение (рис. 2.15). 68-контактный адаптер используется для
сигналов LVD и SE, но физические кабели для разных типов сигналов
различаются. Внимательно проверьте пометку на кабеле, чтобы избежать
возможных проблем.

Рис. 2.15. Диск SCSI с 68-разрядным разъемом

Одну из разновидностей 68-контактных разъемов высокой плотности
представляют разъемы SCA (Single Connector Attachment). Они
предназначены для объединения проводов питания с проводами данных в
одном разъеме, что упрощает замену дисков на сервере. Разъем состоит из
80 контактов, среди которых присутствуют контакты для подачи питания и
настройки конфигурации диска. На рис. 2.16 показано, как выглядит такой
разъем.

Рис. 2.16. Диск SCSI с разъемом SCA

Существует множество адаптеров для разных разъемов SCSI; предполагается,
что устройства SCSI обладают обратной совместимостью. Тем не менее
работают не все адаптеры и конфигурации устройств (а даже если они
работают, то на скорости самого медленного из устройств). Помните, что
устройства HVD не должны комбинироваться с устройствами LVD и SE без
соответствующих адаптеров, а сочетания устройств LVD и SE возможны
только в том случае, если устройства LVD способны работать в режиме SE.

Ограничения размера

Ограничения размеров, действующие для дисков АТА, не распространяются на
диски SCSI, потому что в спецификации SCSI всегда использовались 32- и
64-разрядные адреса LBA. Тем не менее максимальный размер диска,
поддерживаемый BIOS (при использовании INT 13h) или файловой системой,
может быть меньше того, что поддерживается спецификацией SCSI. Данное
обстоятельство может стать ограничивающим фактором.

При работе с диском через BIOS контроллер SCSI преобразует адреса CHS в
адреса LBA. Разные контроллеры используют разные способы отображения, но
во многих случаях способ выбирается на основании геометрии, описываемой
в таблице разделов. Может оказаться, что в рабочей системе аналитика
установлен контроллер с другой схемой отображения адресов, поэтому
обращение к диску должно осуществляться методом прямого доступа, а не
через BIOS.

PAGE 62

Глава 2. Основные принципы работы компьютеров

Итоги

В этой главе рассматривались основные принципы организации и хранения
данных. Материал играет важную роль в книге, потому что мы будем
рассматривать структуры данных и методы хранения информации в разных
файловых системах. Дополнительная информация о структурах данных
приводится в книгах, посвященных языку С. Кроме того, в этой главе
представлены основные технологии жестких дисков; этот материал тоже
важен, потому что именно жесткие диски чаще всего становятся объектом
анализа и экспертизы. Дополнительные сведения о технологии жестких
дисков можно найти на сайте PC Guide ( HYPERLINK “http://” http://
HYPERLINK “http://www.pcguide.com/ref/hdd/index.htm”
www.pcguide.com/ref/hdd/index.htm ) и в официальных спецификациях АТА и
SCSI.

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

• Sammes, Tony, and Brian Jenkinson. Forensic Computing: A
Practitioner’s Guide. New York: Springer-Verlag, 2000.

• T13. «Information Technology — AT Attachment Interface for Disk
Drives», X3T10, 791D Revision 4c, 1994. HYPERLINK
“http://www.tl3.org/project/d0791r4c-ATA-l.pdf”
http://www.tl3.org/project/d0791r4c-ATA-l.pdf .

• T13. «Information Technology — AT Attachment with Packet Interface – 6
(АТА/ ATAPI-6». 1410D Revision 3b, February 26, 2002. HYPERLINK
“http://www.tl3.org/docs2002/” http://www.tl3.org/docs2002/
dl410r3b.pdf.

• T13. «Information Technology — AT Attachment with Packet Interface
Extension (ATA/ATAPI-4». 1153D Revision 18, August 19,1998. HYPERLINK
“http://www.tl3.org/project/” http://www.tl3.org/project/
dll53rl8-ATA-ATAPI-4.pdf.

• T13. «Information Technology — AT Attachment-3 Interface (ATA-3)»,
X3T13, 2008D Revision 7b, January 27, 1997. HYPERLINK
“http://www.tl3.org/project/d2008r7b-ATA-”
http://www.tl3.org/project/d2008r7b-ATA- 3.pdf.

Снятие данных с жесткого диска

Основная часть материала так или иначе связана со снятием данных,
находящихся на носителе информации — а именно, на жестком диске. Анализ
также может проводиться в «живых» системах, но чаще данные копируются
для проведения стороннего анализа. Как правило, снятие данных происходит
в фазе сохранения системы и является одной из важнейших составляющих
цифровой экспертизы. Ведь если данные не будут скопированы в другую
систему, они могут быть случайно утрачены, и тогда они перестанут быть
уликами. Более того, если копирование произведено некорректно, данные
тоже утрачивают свою юридическую силу. В этой главе приводится теория
снятия данных, а также рассматривается конкретный пример с применением
утилиты Linux dd.

Введение

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

Общая процедура снятия данных

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

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

PAGE 64

Глава 3. Снятие данных с жесткого диска

Уровни снятия данных

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

Чтобы показать, почему снятие данных обычно производится на уровне
диска, рассмотрим пару примеров. Допустим, диск был клонирован на уровне
тома, с созданием копии каждого сектора в каждом разделе. Такая копия
позволит восстановить удаленные файлы в каждом разделе, но анализ
секторов, не принадлежащих ни одному из разделов, будет невозможен. Как
будет показано в главе 5, на диске с разделами DOS не используются
секторы с 1 по 62, и в них могут находиться скрытые данные. При
проведении снятия на уровне тома эти скрытые данные будут потеряны.

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

В некоторых системах наше правило относительно снятия данных на
минимальном уровне, на котором мы рассчитываем найти улики, означает,
что достаточно скопировать только файлы. Допустим, вы расследуете
попытку взлома сети с действующей системой обнаружения вторжений (IDS,
Intrusion Detection System), у которой имеется журнал с информацией об
атаке. Если вы считаете, что данные IDS не подвергались посторонним
изменениям, то все улики существуют на файловом уровне; можно просто
скопировать необходимые журналы и предпринять необходимые шаги по их
сохранению. Если есть подозрение, что данные IDS были изменены, то
информацию следует копировать на дисковом уровне для проведения анализа
всех данных.

Тесты программ снятия данных

Клонирование является критической составляющей процесса расследования, и
Национальный институт стандартов и технологий (NIST, National Institute
of Standards and Technology) провел сравнительное тестирование
распространенных программ клонирования. В рамках проекта CFTT (Computer
Forensic Tool

Чтение исходных данных

PAGE 65

Testing) в NIST был разработан набор требований и тестов для утилит
создания образов дисков. Результаты и спецификации приведены на
веб-сайте ( HYPERLINK “http://” http:// HYPERLINK
“http://www.cftt.nist.gov/disk_imaging.htm”
www.cftt.nist.gov/disk_imaging.htm ).

Чтение исходных данных

В соответствии с общей теорией клонирования, описанной в предыдущем
разделе, процесс состоит из двух основных частей. Сначала данные
необходимо прочитать из источника, а затем записать их в приемник.
Поскольку в книге основное внимание уделяется анализу томов и данных
файловых систем, мы рассмотрим процесс клонирования на уровне диска
(поскольку именно на этом уровне хранится большинство структур данных
томов). В этом разделе будут рассмотрены вопросы, связанные с чтением
диска, а в следующем речь пойдет о записи. Предполагается, что в
качестве источника используется типичная система IA32 (например,
x86/i386). Мы рассмотрим различные способы обращения к данным, обработку
ошибок и снижение риска записи данных на исследуемый диск.

Прямой доступ или BIOS?

Как показано в главе 2, существует два способа обращения к данным на
диске. В первом способе операционная система или программа клонирования
обращается к жесткому диску напрямую; для этого программа должна
обладать полной информацией о конфигурации оборудования. Во втором
способе операционная система или программа клонирования обращается к
жесткому диску через прослойку BIOS (Basic Input/Output System), которой
известны все подробности конфигурации. На первый взгляд особых различий
не видно, и работать через BIOS вроде бы удобнее, потому что BIOS берет
на себя все аппаратные тонкости. К сожалению, когда речь идет о
расследовании, дело обстоит несколько сложнее.

При обращении через BIOS возникает опасность того, что BIOS вернет
неверную информацию о диске. Если BIOS считает, что размер диска
составляет 8 Гбайт, тогда как фактический размер равен 12 Гбайт, функции
INT 13h предоставят доступ только к первым 8 Гбайт дискового
пространства. Следовательно, при клонировании диска последние 4 Гбайт не
будут скопированы. Суть происходящего продемонстрирована на рис. 3.1,
где два приложения пытаются определить размер диска разными способами.

Арр #1

How Big Is Disk О

8GB

В

4-?

I

0

DiskO

s

How Big are you?

App #2

4

12GB

Рис. 3.1. Два приложения пытаются определить размер диска. Из-за
неверной конфигурации BIOS сообщает, что размер 12-гигабайтного диска
составляет всего 8 Гбайт

Возможны различные варианты этого сценария. Первый — когда BIOS
настраивается на конкретную геометрию жесткого диска, отличную от
фактической.

PAGE 66

Глава 3. Снятие данных с жесткого диска

В другом варианте программа клонирования использует устаревший метод
получения размера диска. Приложение может запросить у BIOS размер диска
двумя способами. Во-первых, оно может воспользоваться исходной функцией
INT 13h, которая подвержена ограничению в 8 Гбайт и возвращает
результат, используя геометрию диска в формате CHS. Во-вторых,
приложение может воспользоваться расширенной функцией INT 13h,
возвращающей результат в формате LBA. Так, группа CFTT в NIST
использовала 2-гигабайтный жесткий диск и компьютер, на котором исходная
и расширенная функции INT 13h возвращали разные размеры. Результат
расширенной функции был правильным, тогда как исходная функция выдавала
заниженный результат [U.S. Department of Justice, 2003].

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

Режимы снятия данных

Помимо способа доступа к диску аналитик также выбирает режим
клонирования данных. Мертвое снятие данных происходит тогда, когда
данные из анализируемой системы копируются без содействия установленной
на ней операционной системы. Исторически термин «мертвое» относится не к
состоянию компьютера в целом, а только к состоянию операционной системы,
поэтому при мертвом клонировании возможно использование оборудования
исходного компьютера — при условии, что загрузка производится с
надежного компакт-диска или дискеты. Живое снятие данных означает, что
операционная система на анализируемом компьютере продолжает работать и
используется для копирования данных.

Живое снятие данных сопряжено с определенным риском: злоумышленник мог
изменить операционную систему или другое программное обеспечение таким
образом, чтобы во время клонирования поставлялись неверные данные.
Проведу аналогию с реальным миром: представьте, что полиция прибывает на
место преступления, на котором находятся несколько людей; нельзя
исключать, что кто-то из них причастен к преступлению. Полицейские
начинают искать некую улику и предлагают одному из незнакомцев сходить в
одну из комнат и помочь им в поисках. Незнакомец возвращается к
полицейскому и говорит, что он ничего не нашел; но можно ли ему
доверять? Вполне возможно, что незнакомец является преступником, а улика
находилась в комнате, но он успел уничтожить ее.

Нападающие часто устанавливают в атакуемых системах так называемые
рут-киты (rootkits), передающие пользователю ложную информацию [Skoudis
& Zeltser, 2004]. Руткиты скрывают некоторые файлы в каталогах или
работающие процессы. Чаще всего нападающий скрывает файлы, установленные
им после взлома системы. Также он может модифицировать операционную
систему так, чтобы в процессе она автоматически подменяла данные в
некоторых секторах диска.

Чтение исходных данных

PAGE 67

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

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

Обработка ошибок

В процессе чтения данных с диска программа клонирования должна
обрабатывать возникающие ошибки. Причины могут быть различными: как
отказ всего диска, так и сбои в ограниченном количестве секторов. При
повреждении части секторов клонирование возможно — но при условии, что
программа обработает все ошибки.

Общепринятый способ обработки поврежденных секторов заключается в
сохранении адреса и записи нулей на место данных, которые не удалось
прочитать. Запись нулей сохраняет правильное местонахождение остальных
данных. Если бы поврежденные секторы просто игнорировались, то
полученная копия оказалась бы слишком маленькой, а многие аналитические
программы не смогли бы с ней работать. На рис. 3.2 показана
последовательность клонируемых секторов. Три сектора содержат ошибки, и
прочитать их не удалось, поэтому в копию на их место записываются нули.

342622 000000 000000 826193 153068 000000 648633 774628

Рис. 3.2. Оригинал содержит три ошибки, замененные нулями

Область НРА

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

Программа обнаруживает присутствие НРА, сравнивая результаты выполнения
двух команд АТА. Команда READ_NATIVE_MAX_ADDRESS возвращает общее
количество секторов на диске, а команда IDENTIFY_DEVICE — количество
секторов, доступных для пользователя. Если область НРА существует, эти
два числа будут различаться.

Если у вас нет программы, которая выполняла бы необходимые команды АТА,
вероятно, вам придется сравнить количество секторов, скопированных в
процессе снятия данных, с количеством секторов, указанным на наклейке на
диске. Многие современные программы снятия данных обнаруживают
присутствие НРА. Также

PAGE 68

Глава 3. Снятие данных с жесткого диска

существуют специализированные утилиты, такие как BXDR ( HYPERLINK
“http://www.sanderson-” http://www.sanderson- HYPERLINK
“http://forensics.co.uk/BXDR.htm” forensics.co.uk/BXDR.htm ) Пола
Сэндерсона(Раи1 Sanderson), diskstat из пакета The Sleuth Kit, DRIVEID
компании MyKey Technology ( HYPERLINK “http://www.rnykeytechnology.com”
http://www.rnykeytechnology.com ) и hpa Дэна Мареса (Dan Mares) (
HYPERLINK “http://www.dmares.eom/maresware/gk.htm%23HPA”
http://www.dmares.eom/maresware/gk.htm#HPA ).

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

Процесс удаления НРА сопряжен с изменением конфигурации диска.
Существует крайне малая вероятность того, что в контроллере диска или
программе снятия данных неверно реализован механизм изменения НРА, и
попытка снятия защиты приведет к потере данных. Следовательно, перед
удалением НРА стоит создать полный образ диска. Если в процессе удаления
будут нанесены какие-либо повреждения, у пользователя останутся исходные
данные для анализа. Пример диска с НРА будет рассмотрен далее в этой
главе. Факт снятия НРА обязательно должен быть отражен в ваших заметках.

DCO

При снятии данных с современных дисков АТА также следует проверить
наличие области DCO (Device Configuration Overlay), из-за которой размер
диска кажется меньше фактического. Область DCO в целом похожа на НРА,
причем обе области могут существовать на диске одновременно (тема DCO
также обсуждалась в главе 2).

Присутствие DCO обнаруживается сравнением результатов двух команд АТА.
Команда READ_NATIVE_MAX_ADDRESS возвращает максимальный сектор диска,
доступный для обычных команд АТА, а команда DEVICEJIONFIGURATION
JDENTIFY -физическое количество секторов. Если результаты двух команд
различаются, значит, на диске существует защищенная область DCO и ее
необходимо удалить для снятия всей информации.

Чтобы удалить область DCO, необходимо изменить конфигурацию диска
командой D EVI С Е_С0 N FIG U RATIO N_S ET или D EVICE_C0 N FIG U RATIO
N_RESET. Оба изменения имеют постоянный характер и не пропадают при
сбросе, как это возможно при создании областей НРА. В настоящее время
лишь немногие программы способны обнаруживать и удалять DCO. Например,
программа Image MASSter Solo 2 от ICS ( HYPERLINK
“http://www.icforensic.com” http://www.icforensic.com ) копирует
секторы, скрытые в DCO. Как и в случае с НРА, самое безопасное решение
заключается в полном копировании диска с областью DCO, ее удалении и
создании второй копии. Не забудьте документировать факт удаления DCO.
Кроме того, проверьте, не запрещено ли удаление DCO аппаратным
блокировщиком записи.

Аппаратная блокировка записи

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

Чтение исходных данных

PAGE 69

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

Аппаратный блокировщик записи представляет собой устройство,
подключенное между компьютером и носителем информации. Такое устройство
отслеживает передаваемые команды и не позволяет компьютеру записывать
данные на устройство хранения информации. Блокировщики поддерживают
разные интерфейсы пересылки данных, в том числе ATA, SCSI, FireWire
(IEEE 1394), USB или Serial ATA. Они особенно важны в операционных
системах, способных смонтировать исходный диск (например, Microsoft
Windows).

При обсуждении команд АТА в главе 2 говорилось о том, что диск выполняет
какие-либо действия лишь после записи в его регистр команд. Таким
образом, теоретически простейший аппаратный блокировщик записи АТА
просто не дает контроллеру записать в регистр команд никакие значения,
которые могли бы привести к записи информации или ее стиранию с диска.
Тем не менее такое устройство может разрешить контроллеру запись данных
в другие регистры. Можно сказать, что блокировщик записи разрешает
зарядить ружье, но не дает возможности спустить курок. На рис. 3.3
показано, что команды чтения передаются диску, а команды записи — нет.

Команда чтения

Чтение сектора 5

Данные сектора 5

Чтение сектора 5

Данные сектора 5

Диск О

Команда записи

Запись сектора 5

Диск О

Рис. 3.3. Запрос на чтение сектора 5 передается через блокировщик
записи, но команда записи в тот же сектор блокируется на пути к диску

Устройство No Write компании MyKeyTechnologies обладает более сложной
конструкцией и выполняет функции посредника с поддержкой состояния между
контроллером и жестким диском [MyKeyTechnology, 2003]. Данные и команды
передаются жесткому диску только для заведомо безопасных команд.
Аргументы команд не записываются в регистры, если устройство NoWrite не
знает, к какой команде они относятся. Пересылка данных несколько
замедляется, но зато снижается опасность записи потенциально опасных
команд. Если продолжить предыдущую аналогию, такой процесс проверяет
каждый патрон и разрешает заряжать ружье только холостыми.

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

PAGE 70

Глава 3. Снятие данных с жесткого диска

НРА и DCO диску необходимо передать соответствующие команды. Так как
выполнение этих команд приводит к изменению устройства, они должны быть
остановлены аппаратным блокировщиком записи. Устройство No Write делает
исключение для команды SET_MAX и разрешает выполнять ее при сброшенном
бите устойчивости, чтобы изменения не носили постоянного характера. Все
остальные команды SET_MAX и DEVICE_CONFIGURATION блокируются.
Некоторыеблокировщи-ки записи разрешают прохождение этих команд, а
другие их блокируют. На момент написания книги документация с
перечислением блокируемых команд почти не встречалась.

Аппаратные блокировщики записи, как и все остальные аналитические
инструменты, должны проходить тщательное тестирование, и группа CFTT при
NIST опубликовала спецификацию аппаратных блокировщиков записи (
HYPERLINK “http://” http:// HYPERLINK
“http://www.cftt.nist.gov/hardware_write_bLock.htm”
www.cftt.nist.gov/hardware_write_bLock.htm ). В спецификации содержится
классификация команд АТА (изменяющие, неизменяющие, конфигурационные).
Согласно спецификации, устройство должно блокировать изменяющие команды
и возвращать (не обязательно) признак успеха или неудачи.

Программная блокировка записи

Кроме аппаратных блокировщиков записи также существуют программные. Одно
время инструменты цифровой экспертизы в основном работали в среде DOS и
использовали метод INT 13h для обращения к диску. Для предотвращения
модификации диска во время клонирования и анализа часто использовались
программные блокировщики. В этом разделе будут описаны принципы их
работы и присущие им ограничения.

В основу работы программных блокировщиков записи заложена модификация
таблицы прерываний, используемой для поиска кода сервисных функций BIOS.
В таблице прерываний находятся записи для всех сервисных функций BIOS, и
каждая запись содержит адрес кода соответствующего обработчика.
Например, запись прерывания INT 13h указывает на код записи или чтения
данных с диска.

Программный блокировщик изменяет таблицу прерываний так, чтобы в записи
прерывания 0x13 хранился адрес кода блокировщика (вместо адреса кода
BIOS). Когда операционная система вызывает прерывание INT 13h,
управление передается коду блокировщика; последний анализирует
запрашиваемую функцию. На рис. 3.4 показан пример установки программного
блокировщика записи и блокировки команды записи. Блокировщик записи
пропускает остальные функции, передавая запрос исходному коду BIOS INT
13h.

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

Группа CFTT при NIST разработала требования и провела тестирование
программных блокировщиков записи. Подробности можно найти на сайте:
HYPERLINK “http://” http:// HYPERLINK
“http://www.cftt.nost.gov/software_write_block.htm”
www.cftt.nost.gov/software_write_block.htm .

Запись снятых данных

PAGE 71

Без программного блокировщика записи

Таблица прерываний

Код дисковых функций BIOS

Запись сектора 5

13h

Запись сектора 5

Запись сектора 5

Диск О

С программным блокировщиком записи

Таблица прерываний

13h

Запись сектора 5

Код программного блокировщика записи

if (запись) then выход else продолжить

Код дисковых функций BIOS

Диск О

Рис. 3.4. Таблица прерываний BIOS до и после установки программного
блокировщика, предотвращающего запись на диск

Запись снятых данных

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

Выбор приемника

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

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

PAGE 72

Глава 3. Снятие данных с жесткого диска

заканчиваются скопированные данные. Как правило, перед прямым снятием
данных приемный диск рекомендовалось заполнить нулями, чтобы посторонние
данные (возможно, оставшиеся от предыдущих исследований) не смешивались
сданными из анализируемой системы. Вторая потенциальная проблема со
снятием данных на диск заключается в том, что некоторые операционные
системы (например, Microsoft Windows) пытаются монтировать все диски.
Копия монтируется в системе, из которой снимаются данные, что может
привести к изменению ее содержимого. Кроме того, трудности могли
возникнуть и из-за различий в геометриях исходного и приемного дисков,
потому что некоторые структуры данных описывают местонахождение данных с
использованием параметров геометрии диска.

В настоящее время самым распространенным способом является сохранение
данных в файле на жестком диске или на диске CD-ROM. При выводе в файл
границы данных сразу видны, а операционная система не пытается
автоматически монтировать диск. Такой файл часто называется образом
(image). Многие программы позволяют разбивать файлы образов на меньшие
фрагменты, помещающиеся на один диск CD-ROM или DVD. Некоторые эксперты
стирают диски, на которых хранятся файлы образов, — стирание
гарантирует, что данные не содержат посторонних включений от прошлых
случаев.

Формат файла образа

Сохранив данные в файле, можно выбрать формат образа. Физический образ
(raw image) содержит только данные с исходного диска, что упрощает
сравнение образа с исходными данными. Внедренный образ (embedded image)
содержит данные с исходного устройства и дополнительную служебную
информацию: хеш-коды, пометки даты pi времени. Некоторые программы
создают физический образ и сохраняют служебную информацию в отдельном
файле. Напомню, что хеш-коды (CRC, MD5 и SHA-1) используются для
проверки целостности данных. Примеры форматов образов показаны на рис.
3.5.

^ физический I

образ I_

внедренный Г образ II

физический образ

внешние метаданные

Рис. 3.5. Примеры образов: (А) — физический образ, (В) — внедренный
образ, в котором метаданные чередуются с физическими данными, (С) —
комбинированный образ: данные хранятся в физическом формате, а
метаданные находятся в отдельном файле

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

Запись снятых данных

PAGE 73

EnCase1 (Guidance Software) и SafeBack (NTI). Формат образов других
программ документирован — как, скажем, формат ProDiscover (Technology
Pathway) [Technology Pathways, 2003]. Как правило, аналитические
программы импортируют физические образы, поэтому этот формат
обеспечивает наибольшую гибкость. Программы SMART (ASR Data) и
dcfldd/dccidd снимают данные в физическом формате и создают внешний файл
с дополнительной информацией.

Сжатие файла образа

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

Аналитические программы, используемые для работы со сжатыми образами,
должны поддерживать соответствующий тип сжатия. Большинство общих схем
сжатия требует полной распаковки файла перед его использованием.
Примерами служат утилиты Winzip для Windows и gzip для UNIX. Специальные
алгоритмы сжатия позволяют выполнять распаковку небольшой части сжатого
файла; обычно именно такие алгоритмы применяются в программах снятия
данных, чтобы избежать необходимости полной распаковки всего образа.

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

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

• Снятие данных часто занимает больше времени, потому что программа
должна «на ходу» сжимать обрабатываемые данные.

• Необходимость распаковки изображения при чтении данных замедляет
процесс анализа.

Сетевое снятие данных

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

1 Спецификация формата, используемого программой Expert Witness
(предшественником EnCase), находится по адресу: HYPERLINK
“http://www.asrdata.com/SMART/whitepaper.html”
http://www.asrdata.com/SMART/whitepaper.html .

PAGE 74

Глава 3. Снятие данных с жесткого диска

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

Хеширование и целостность данных

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

Важно понимать, какая же функция отводится хешированию. Хеш-код,
хранящийся в изображении, вовсе не гарантирует, что данные не
подвергались посторонним модификациям. В конце концов, если
злоумышленник изменил образ, он мог пересчитать хеш-коды, даже если они
внедрены в формат образа. Написать соответствующую программу довольно
легко. Для проверки целостности файла образа по хеш-коду потребуется
криптографическая цифровая подпись и доверенный источник. Такое решение
сопряжено с основательными непроизводительными затратами; следовательно,
гораздо проще сохранить хеш-код на ноутбуке. Если кто-то захочет
изменить изображение и пересчитать хеш-код, ему придется получить доступ
к вашему ноутбуку.

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

Учтите, что в процессе хеширования читаются только данные, доступные для
программы. Если из-за аппаратных или программных проблем часть
содержимого диска окажется недоступной, хеш-код диска может совпасть с
хеш-кодом файла образа несмотря на то, что файл образа не представляет
всего содержимого диска. Например, если программа может прочитать только
первые 8 Гбайт 12-гигабайтного диска, она вычислит хеш-код для первых 8
Гбайт, скопирует первые 8 Гбайт данных и вычислит хеш-код для
8-гигабайтного файла образа.

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

Практический пример с использованием dd

PAGE 75

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

Практический пример с использованием dd

Чтобы продемонстрировать процесс снятия данных, я опишу методику снятия
данных утилитой dd. Программа dd считается одной из самых простых и
гибких программ снятия данных, но она работает в режиме командной
строки, а ее освоение несколько усложняется богатыми возможностями
настройки, dd существует во многих версиях UNIX, а также в версии для
Windows1. В данном примере будет рассматриваться Linux-версия.

Фактически программа dd копирует блок данных из одного файла и
записывает его в другой файл. Она не интересуется типом копируемых
данных и ничего не знает о файловых системах и дисках — копируются
только файлы.

dd читает данные по блокам; размер блока по умолчанию равен 512 байтам.
Данные читаются из входного источника, заданного флагом if=. Если флаг
if= не указан, программа получает данные из стандартного ввода, которым
обычно является клавиатура. Данные записываются в выходной файл,
заданный флагом of=. При отсутствии параметра данные записываются в
стандартный вывод, чаще всего на экран. В следующем примере файл
filel.dat копируется в файл file2.dat 512-байтовыми блоками:

# dd if-filel.dat of=file2.dat bs=512 2+0 records in

2+0 records out

Две последние строки показывают, что два полных блока были прочитаны из
файла filel.dat и записаны в файл file2.dat. Если при последней операции
чтения и записи использовался неполный блок, последние две строки
завершались бы суффиксом + 1 вместо +0. Например, если бы файл filel.dat
содержал 1500 байт вместо 1024, результат выглядел бы так:

# dd if-filel.dat of-file2.dat bs=512 2+1 records in

2+1 records out

Обратите внимание: размер выходного файла будет составлять 1500 байт.
Программа dd пытается записывать данные блоками, но если блок заполнен
лишь частично, программа копирует то, что есть.

Источник

В системе Linux для каждого носителя информации и каждого раздела
создается устройство, которое может использоваться в качестве входного
файла. Например, главный диск АТА на первом канале представлен
устройством /dev/hda; если указать это имя устройства с флагом if=,
программа dd скопирует данные с диска в файл. В Microsoft Windows для
жестких дисков файлы устройств не

1 Версия Джорджа Гарнера (George Garner) находится по адресу: HYPERLINK
“http://uscrs.erols” http://uscrs.erols com/gmgarner/ forensics/, а
версия UnxUtils — по адресу: HYPERLINK “http://unxutils.sou”
http://unxutils.sou rceforge net.

PAGE 76

Глава 3. Снятие данных с жесткого диска

создаются но для ссылки на диск можно использовать синтаксис \\.\ —
например, HYPERLINK “file:////./PhysicalDriveO” \\.\PhysicalDriveO .

Размер блока по умолчанию составляет 512 байт, но параметр bs= позволяет
задать произвольное значение. За одну операцию может копироваться как 1
байт, так и 1 гигабайт. Подходит любое значение, но некоторые
обеспечивают более высокое быстродействие по сравнению с остальными.
Диски обычно читают данные блоками по 512 байт, но легко могут читать и
больше. Слишком малые размеры блока неэффективны, потому что они требуют
более частых обращений к диску и приводят к лишним потерям времени в
процессе копирования. Если же выбранное значение окажется слишком
большим, то время будет тратиться на заполнение буфера dd перед
выполнением операции копирования. Эксперименты показали, что оптимальные
значения лежат в интервале от 2 до 8 Кбайт.

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

НРА

Как упоминалось ранее, dd работает только с файлами и ничего не знает о
АТА НРА. В этом разделе будут рассмотрены некоторые способы обнаружения
АТА НРА в Linux.

В сценарии данного примера используется 57-гигабайтный диск, содержащий
120 103 200 секторов. Я поместил в сектор 15 ООО строку «here i am»:

# dd if-/def/hdb bs=512 skip=15000 count=l | xxd 1+0 records in

1+0 records out

00000000: 6865 7265 2069 2061 6d0a 0000 0000 0000 here i am…….

Затем в последних 120 091 200 секторах была создана область НРА. Другими
словами, на диске остались только 12 ООО секторов, доступных для ОС и
приложений. В этом легко убедиться, так как строка в секторе 15 ООО
стала недоступной:

# dd if-/def/hdb bs=512 skip-15000 count=l | xxd 0+0 records in

0+0 records out

Записи не были скопированы, потому что программа не смогла прочитать
данные. Возможны различные варианты обнаружения НРА в Linux. Новые
версии Linux выводят сообщения в журнале dmesg. Учтите, что размер
журнала ограничен, поэтому при выводе большого количества предупреждений
или сообщений об ошибках часть информации будет потеряна. Для нашего
диска результат выглядит так:

# dmesg | less [REMOVED]

hdb: Host Protected Area detected.

current capacity is 12000 sectors (6 MB) native capacity is 120103200
sectors (61492 MB)

Практический пример с использованием dd

PAGE 77

Впрочем, это сообщение выводится не во всех версиях Windows. Другой
способ обнаружения НРА основан на использовании программы hdparm,
входящей в поставку Linux. Программа выводит информацию о жестком диске,
и для получения общего количества секторов необходимо указывать флаг -I.
Полученное значение сравнивается со значением, записанным на диск или
найденным на сайте фирмы-производителя. По выходным данным hdparm также
можно судить о том, поддерживает ли диск НРА (у старых дисков поддержка
НРА отсутствует).

# hdparm -I /dev/hvb [REMOVED]

CHS current addressable sectors: 11088 LBA user addressable sectors:
12000 LBA48 user addressable sectors: 12000 [REMOVED]

Commands/features:

Enabled Supported:

* Host Protected Area feature set

В наклейке на моем диске сказано, что диск содержит 120 103 200
секторов; следовательно, многие секторы оказались недоступными для
адресации. Наконец, можно воспользоваться утилитой diskstat из пакета
The Sleuth Kit. Утилита отображает максимальный фактический адрес и
максимальный адрес, доступный для пользователя:

# diskstat /dev/hdb

Maximum Disk Sector: 120103199 Maximum User Sector: 11999

** HPA Detected (Sectors 12000 – 120103199) ** Для обращения к данным
необходимо сбросить ограничения доступа. Одной из программ, которая
позволяет это сделать, является утилита setmax ( HYPERLINK “http://”
http:// HYPERLINK “http://www.win.tue.nl/~aeb/Linux/setmax.%d1%81”
www.win.tue.nl/~aeb/Linux/setmax.с ). Мы запускаем setmax и задаем
максимальное количество секторов на диске, то есть 120 103 200 для
данного примера. Утилита изменяет конфигурацию жесткого диска, поэтому
при работе с ней необходима крайняя осторожность (в частности, следует
тщательно документировать все выполняемые действия). Также учтите, что
программа не поддерживает временное изменение максимального адреса, так
что вносимые изменения являются постоянными. Если вы намерены
использовать подобную программу, сначала протестируйте ее на других
дисках и только потом переходите к диску, который может содержать ценную
информацию:

# setmax –max 120103200 /dev/hdb

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

Приемник

Выходные данные dd направляются либо в новый файл, либо на другое
устройство хранения информации. Например, следующие два примера
выполняются

PAGE 78

Глава 3. Снятие данных с жесткого диска

в среде Linux. Первый пример копирует в файл содержимое ведущего диска
АТА на первичном канале, а второй пример копирует содержимое того же
диска на ведомый диск АТА на втором канале:

# dd if=/dev/hda of=/mnt/hda.dd bs=2k

# dd if=/dev/hda of=/dev/hdd bs=2k

Если выходной файл не указан, данные выводятся на экран. Эта информация
может использоваться для вычисления хеш-кодов MD5, извлечения
ASCII-строк или отправки данных на удаленную систему по сети. Например,
для хеширования диска можно воспользоваться командой md5sum из поставки
Linux:

# dd if=/dev/hda bs=2k | md5sum

Передача данных на сервер также может осуществляться программой netcat (
HYPERLINK “http://www.atstake.com/research/tools/”
http://www.atstake.com/research/tools/ ) или cryptcat ( HYPERLINK
“http://sf.net/projects/cryptcat” http://sf.net/projects/cryptcat ). В
примере для netcat на доверенном сервере с IP-адресом 10.0.0.1
выполняется следующая команда для открытия сетевого порта 7000 и
сохранения входящих данных в файле:

# nc -1 -р 7000 > disk.dd

Система с исходным диском загружается с надежного компакт-диска Linux.
На ней выполняется команда dd с конвейерной передачей данных программе
netcat, передающей данные серверу 10.0.0.1 на порт 7000. При отсутствии
активности подключение закрывается через три секунды:

# dd if=/dev/hda bs=2k | nc -w 3 10.0.0.1 7000

Обработка ошибок

Если во время чтения входного файла dd обнаруживает ошибку, по умолчанию
копирование данных прерывается. Если в командной строке присутствует
параметр conv=noerror, программа выводит сообщение об ошибке и
продолжает работу. К сожалению, в этом случае поврежденные блоки
пропускаются, образ имеет неверный размер, а данные располагаются по
искаженным адресам.

Для сохранения адресов в образе необходимо использовать флаг sync,
заставляющий dd записывать данные в блочном режиме. Если данных
недостаточно для заполнения целого блока, данные дополняются нулями.
Таким образом, при обнаружении ошибки недействительные данные будут
заменены нулями. Недостаток такого решения заключается в том, что
полученный образ всегда будет кратным размеру блока, что может не
соответствовать фактическому размеру исходного носителя информации.
Например, если я выберу размер блока равным 4 096 байт, но размер моего
(совсем крошечного) диска составляет 6 144 байта, размер файла образа
будет равен 8 192 байта вместо 6 144. Пример командной строки dd с
обработкой ошибок:

# dd if=/dev/hda of=hda.dd bs=2k conv=noerror,sync

Программа dd_rescue, автором которой является Курт Гарлофф (Kurt
Garloff) ( HYPERLINK “http://www.garLoff.de/kurt/Linux/ddrescue”
http://www.garLoff.de/kurt/Linux/ddrescue ), похожа на исходную версию
dd, но режим обработки ошибок включен в ней по умолчанию. Обнаружив
ошибку, программа переходит на меньший размер блока и заполняет нулями
блоки, которые не удалось прочитать. Программа dd_rescue также умеет
копировать данные

Практический пример с использованием dd

PAGE 79

от конца диска к началу — автор утверждает, что это может быть полезно
при наличии поврежденных секторов.

Криптографическое хеширование

Как правило, для выполнения криптографического хеширования файла при
использовании dd приходится пользоваться услугами другой программы
(такой, как md5sum). Криптографический хеш-код образа вычисляется для
последующей проверки его целостности. Джессе Корнблум (Jesse Kornblum) и
Рейд Литцов (Reid Leatzow) из Центра киберпреступности Министерства
обороны США создали версию dd с хешированием копируемых данных. В
настоящее время существует две версии этой утилиты. Исходная версия
dcfldd ( HYPERLINK “http://source-” http://source- HYPERLINK
“http://forge.net/projects/biatchux” forge.net/projects/biatchux )
вычисляет только хеш-коды по алгоритму MD5. Новая версия dccidd (
HYPERLINK “http://www.dc3.gov” http://www.dc3.gov ; также можно
отправить сообщение электронной почты по адресу: HYPERLINK
“mailto:[email protected][email protected] ) умеет параллельно вычислять
хеш-коды MD5, SHA-1 и SHA-256. Переименование программы связано с
реорганизацией лаборатории.

В этих программах работают те же базовые параметры, которые описывались
ранее для dd. Кроме того, были добавлены новые параметры хеширования.
Параметр hashwindow= задает частоту вычисления хеш-кода. Если значение
равно 0, то для всего файла вычисляется один хеш-код. Если значение
параметра представляет собой число байтов, отличное от нуля, то
программа вычисляет промежуточные хеш-коды на заданном расстоянии, а
затем вычисляет итоговый хеш-код. Хеш-коды сохраняются в файле, заданном
параметром hashlog=. Программа dcfldd поддерживает только алгоритм MD5,
но dccidd поддерживает параметр hash= для определения алгоритма
хеширования. По умолчанию выполняется параллельное хеширование MD5 и
SHA-1, но вы можете задать значение md5, shal или sha256.

Например, следующая команда создает образ жесткого диска Linux с
вычислением хеш-кода через каждые 1 Мбайт:

# dcfldd if=/dev/hda of=/mnt/hda.dd bs=2k hashwindow=lM
hashlog=/mnt/hda.hashes

Журнал хеш-кодов имеет следующий формат:

О – 1048576: 970653da48f047f3511196c8a230f64c 1048576 – 2097152:
b6d81b360a5672d80c27430f39153е2с

103809024 – 104857600: b6d81b360a5672d80c27430f39153е2с 104857600 –
105906176: 94al71ec3908687fdlf456087576715b Total:
28dd34393f36958f8fc822ae39800f37c3

Строка начинается с диапазона байтов, для которого вычисляется хеш-код,
и завершается значением хеш-кода. Последнее значение представляет собой
хеш-код всего образа. Файл журнала dccidd имеет несколько иную
структуру: в него включается хеш SHA-1, а поле диапазона дополняется
нулями. Приведу фрагмент файла с окном хеширования, равным 512 байтам
(хеши SHA-1 и MD5 обычно выводятся в одной строке):

000000 – 000511: 5dbdl21cad07429edl76f7fac6al33d6

09cae0d9f2a387bb3436al5aa514bl6f9378efbf

000512 – 001023: 91cf74d0ee95d4b60197e4c0ca710be4

0f71d8729ad39ae094e235ab31a9855b2a5a5900

PAGE 80

Глава 3. Снятие данных с жесткого диска

001024 – 001535: 8a0al0f43b2bcd9el385628f7e3a8693
641b9b828e41cd391f93b5f3bfaf2dlb7b393da0

Упоминавшаяся ранее Windows-версия dd Джорджа Гарнера также содержит
встроенную поддержку MD5. При передаче ключа -md5sum программа Гарнера
хеширует файл по алгоритму MD5. Результат хеширования сохраняется в
файле при помощи ключа -md5out

Итоги

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

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

• МуКеу Technology, Inc. «Technical White Paper: No Write Design Notes.»
2003. HYPERLINK “https://mykeytech.com/nowritepaperl.htmL”
https://mykeytech.com/nowritepaperl.htmL

• Skoudis, Ed, and Lenny Zeltser. Malware: Fighting Malicious Code.
Upper Saddle River: Prentice Hall, 2004.

• Technology Pathways, Inc. «ProDiscover Image File Format». 2003.
HYPERLINK “https://” https:// HYPERLINK
“http://www.techpathways.com/uploads/P%7broDiscoverImageFi”
www.techpathways.com/uploads/P{roDiscoverImageFi LeFormatv4.pdf.

• U.S. Department of Justice. «Test Results for Disc Imaging Tools:
SafeBack 2.18» NCJ 200032, June 2003. HYPERLINK
“https://www.ncjrs.org/pdffilesl/nij720032.pdf”
https://www.ncjrs.org/pdffilesl/nij720032.pdf .

ЧАСТЬ II Анализ томов

Глава 4. Анализ
томов………………………………………………..82

Глава 5. Разделы на персональных компьютерах…………….93

Глава 6. Разделы в серверных системах……………………….117

Глава 7. Многодисковые
тома…………………………………….143

Анализ томов

Настоящая глава открывает вторую часть книги, посвященную анализу томов.
Процесс анализа томов включает просмотр структур данных, задействованных
в определениях разделов, и сборку байтов на носителях информации для
формирования томов. Тома (volumes) используются для хранения файловых
систем и других структурированных данных, которые будут описаны в
третьей части книги, «Анализ файловых систем». В этой главе основные
концепции анализа томов рассматриваются с абстрактных позиций:
изложенные в ней принципы применимы ко всем типам томов. Следующие три
главы будут посвящены конкретным типам разделов и систем формирования
томов.

Введение

Цифровые носители информации особым образом структурируются для
обеспечения эффективной выборки данных. Пользователи чаще всего
сталкиваются с системой томов при установке Microsoft Windows и
созданием разделов на жестком диске. Процесс установки руководит
действиями пользователя при создании разделов (основного и логических),
и в конечном итоге на компьютере появляется список «дисков» или «томов»
для хранения данных. Аналогичный процесс происходит и при установке
операционной системы UNIX. В наше время при хранении больших объемов
информации все чаще применяются программы управления томами, благодаря
которым несколько дисков интерпретируются как один большой диск.

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

Настоящая глава также содержит теоретические обоснования, краткий обзор
программных инструментов и разновидностей методов анализа. В следующих
двух главах более подробно рассматриваются некоторые схемы разделов,
включая разделы DOS, Apple Partitions, разделы BSD и сегменты (slices)
SUN.

Общие положения

PAGE 83

Последняя глава посвящена распределенным дисковым томам, таким как RAID
и disk spanning.

Общие положения Концепция тома

Многотомные системы основаны на двух основных концепциях. Первая — это
объединение нескольких томов в единое целое, а вторая — разбиение томов
на независимые разделы. Термины «раздел» (partition) и «том» (volume)
часто используются как синонимы, но я буду различать эти понятия.

Томом называется совокупность адресуемых секторов, которые могут
использоваться операционной системой (ОС) или приложением для хранения
данных. Секторы тома не обязаны храниться в смежных блоках физического
носителя, хотя при использовании томов может возникнуть такое
впечатление. Примером тома, хранящегося в смежных секторах, служит
жесткий диск. Том также может представлять собой результат объединения и
слияния томов меньшего размера.

Общая теория разделов

Одной из важнейших концепций систем с использованием томов является
создание разделов. Разделом называется совокупность смежных секторов на
диске. По определению раздел также является томом, поэтому эти термины
часто путают. Я буду называть том, которому принадлежит раздел,
родительским томом этого раздела. Разделы используются во многих
ситуациях, в том числе:

• в некоторых файловых системах максимальный размер меньше размера
жесткого диска;

• на многих портативных компьютерах создается специальный раздел для
хранения содержимого памяти при переходе компьютера в спящий режим;

• в системах UNIX разные каталоги хранятся в разных разделах, чтобы
свести к минимуму последствия от возможной порчи файловой системы;

• в системах на базе IA-32 с несколькими операционными системами
(например, Microsoft Windows и Linux) для каждой операционной системы
может потребоваться свой раздел.

Рассмотрим систему Microsoft Windows с одним жестким диском. Том
жесткого диска делится на три тома меньшего размера, в каждом из которых
имеется своя файловая система. Windows присваивает этим томам имена С, D
и Е (рис. 4.1).

Каждая операционная система и аппаратная платформа обычно использует
свой метод создания разделов. Некоторые варианты реализации описаны в
главах 5 и 6, но сейчас мы познакомимся с основными компонентами.
Типичная система разделов содержит одну или несколько таблиц, при этом
каждая запись таблицы описывает один раздел. В данных записи обычно
указывается начальный сектор раздела, конечный сектор раздела (или
длина) и тип раздела. На рис. 4.2 показан пример таблицы с тремя
разделами.

PAGE 84

Глава 4, Анализ томов

Жесткий диск

Раздел 1 Раздел 2 Раздел 3

…../……………… ………………\_____

/ ] l \

Том С: Том D: Том Е:

Рис. 4.1. Жесткий диск разбит на три раздела с присвоенными именами
томов

Рис. 4.2. Таблица с информацией о начале, конце и типе каждого раздела

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

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

Помните, что система разделов зависит от операционной системы и не имеет
отношения к типу интерфейса жесткого диска. Таким образом, система
Windows использует одну систему разделов как для дисков с интерфейсом
АТА, так и для дисков SCSI.

Использование томов в UNIX

Системы UNIX работают с томами не так, как Windows. Этот раздел
предназначен для пользователей, незнакомых с UNIX; в нем приводится
краткий обзор использования томов в UNIX. За дополнительной информацией
следует обратиться к системному администратору UNIX.

Общие положения

PAGE 85

В UNIX пользователь работает не с «дисками» С:, D: и т. д., а с набором
каталогов, иерархия которых начинается с корневого каталога/.
Подкаталоги / являются либо подкаталогами той лее файловой системы, либо
точками монтирования для новых файловых систем и томов. Например,
дисководу CD-ROM в Windows может быть присвоено обозначение Е:, но в
Linux он может монтироваться под именем /mnt/edrom. В результате простое
переключение между каталогами может приводить к переходу с диска на
диск, причем пользователь в большинстве случаев даже и не подозревает об
этом. На рис. 4.3 показано, как организован доступ к жестким дискам и
компакт-дискам в Windows и UNIX.

А)

В)

Том 1 “”J”*

HYPERLINK “file:///Program” \Program Files\ / ‘ \Windows\

Том 1

Том 2

-> /etc/

/mnt/edrom/ ~* /tmp/ ~* /usr/

CD-ROM

Е:

CD-ROM

Том 2

Рис. 4.3. Точки монтирования двух томов и диска CD-ROM (А) — Microsoft
Windows, и (В) — в типичной системе UNIX

Чтобы свести к минимуму последствия от повреждения дисков, а также
повысить эффективность, UNIX обычно разбивает разделы каждого диска на
несколько томов. В томе корневого каталога (/) хранится основная
информация; отдельный том может существовать для домашних каталогов
пользователей (/ home/), а приложения могут находиться в отдельном томе
(/usr/). Однако все системы уникальны, и в них могут использоваться
совершенно различные схемы формирования и монтирования томов. В
некоторых системах используется один большой том для корневого каталога,
а сегментирование системы отсутствует.

Общая теория объединения томов

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

Рассмотрим простой пример. На рис. 4.4 изображены два тома жестких
дисков, которые в сумме содержат три раздела. Разделу 1 присваивается
имя тома С:, а разделы 2 и 3 обслуживаются специальным устройством.
Устройство формирует

PAGE 86

Глава 4. Анализ томов

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

Жесткий диск 1

Жесткий диск 2

Том С: Том О: Том Е:

Рис. 4.4. Два раздела объединяются в один том с последующим разбиением

Адресация секторов

В главе 2 обсуждались методы адресации секторов. В самом
распространенном методе используются адреса ЬВА, которые представляют
собой последовательные числа, начиная с 0 (первый сектор диска). Этот
адрес называется физическим адресом сек гора.

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

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

Основы анализа

PAGE 87

Раздел 1 Начальный адрес: О

Раздел 2 Начальный адрес: 864

Физический адрес: 100 Абсолютный логический адрес: 100 Относительный
логический адрес: 100

Физический адрес: 964 Абсолютный логический адрес: 964 Относительный
логический адрес: 100

Физический адрес: 569 Абсолютный логический адрес: 569 Относительный
логический адрес: Ы/А

Рис. 4.5. Относительные логические адреса отсчитываются от начала
раздела, а абсолютные — от начала диска

Основы анализа

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

У анализа структуры разделов томов имеется еще одно важное применение:
некоторые секторы, не принадлежащие ни одному разделу, могут содержать
данные из предыдущей файловой системы или другую информацию, которую
подозреваемый пытается скрыть. Иногда система разделов может оказаться
поврежденной или стертой, и тогда средства автоматизированного анализа
работать не будут.

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

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

Чтобы проанализировать компоненты системы томов, необходимо найти и
обработать структуры данных с информацией об объединяемых томах и о том,
как именно это делается. Как будет показано в главе 7, существует много
способов объединения томов. Мы займемся поиском данных, не используемых
в процессе объединения и содержащих информацию от предыдущей установки
или скрытую.

PAGE 88

Глава 4. Анализ томов

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

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

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

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

А) В) С)

Раздел 1 Раздел 1 Раздел 1

Раздел 2 Раздел 2 Раздел 2

О) Е)

Раздел 1 Раздел 1

Раздел 2 Раздел 2

Рис. 4.6. Пять вариантов взаимного расположения разделов. Первые три
варианта допустимы, последние два — нет

Третий вариант (рис. 4.6 (Б)), при котором второй раздел начинается
раньше завершения первого, в общем случае недопустим. Секторы двух
разделов перекрываются, что, как правило, свидетельствует о повреждении
таблицы разделов. Чтобы определить, какие разделы допустимы (и есть ли
они вообще), необходимо проанализировать данные в каждом разделе.
Четвертый вариант показан на рис. 4.6 (Е); как правило, он тоже
недопустим. Второй раздел находится внутри первого, и для определения
ошибки необходимо проанализировать содержимое обоих разделов.

Основы анализа

PAGE 89

Получение содержимого разделов

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

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

• if — образ, из которого читаются данные;

• of — выходной файл для сохранения данных;

• bs — размер читаемого блока (512 байт по умолчанию);

• skip — количество блоков (размера bs), пропускаемых перед чтением;

• count — количество блоков (размера bs), копируемых из ввода в вывод.
Чаще всего выбирается размер блока 512 байт, совпадающий с размером
сектора. По умолчанию размер блока в dd тоже равен 512 байтам, но всегда
надежнее указать его явно. Мы воспользуемся параметром skip для указания
начального сектора, в котором начинается раздел, и параметром count для
указания количества секторов в разделе.

Рассмотрим пример системы разделов на базе DOS. Утилита mmls из пакета
The Sleuth Kit выводит содержимое таблицы разделов. Ее выходные данные
будут более подробно описаны далее, но даже сейчас нетрудно понять, что
на диске существуют три раздела файловых систем:

# mmls -t dos diskl.dd

Units are in 512-byte sectors

Slot Start End Length Description

00

0000000000 0000000000 0000000001 Table #0

01

0000000001 0000000062 0000000062 Unallocated

02 00 00 0000000063 0001028159 0001028097 Win95 FAT32 (OxOB)

03

0001028160 0002570399 0001542240 Unallocated

04 00 03 0002570400 0004209029 0001638630 OpenBSD (0xA6)

05 00 01 0004209030 0006265349 0002056320 NTFS (0x07)

Утилита тгтйз упорядочивает содержимое таблицы разделов по начальному
сектору и выделяет секторы, не принадлежащие ни одному разделу. Первые
две строки (00 и 01) описывают основную таблицу разделов и
неиспользуемое пространство между таблицей разделов и первым разделом.
Из листинга видно, что строка 02 определяет раздел с файловой системой
ЕАТ32, строка 04 относится к разделу ОрепВББ, а строка 05 — к разделу с
файловой системой ШТЗ. Строка 03 обозначает нераспределенное дисковое
пространство. Графическое представление этих данных показано на рис.
4.7.

Чтобы извлечь разделы файловых систем из образа диска, следует отметить
начальный сектор и размер каждого раздела и передать их dd:

# dd 1Г-сЛ5к1 .2056320

PAGE 90

Глава 4. Анализ томов

s 1 028 097 ^ 1 542 240 ## 1 638 630 ># 2 056 320

FAT32 Не распределено OpenBSD NTFS

? А

к i к

А

0 63 1 028 160 2 570 400 4 209 030 6 265 349

Рис. 4.7. Структура образа диска из примера

Эти команды берут входные данные из файла diskl.dd и сохраняют вывод в
файлах с именами parti.dd, part2.dd и part3.dd. Во всех случаях размеры
копируемых блоков составляют 512 байт. Перед извлечением первого раздела
dd пропускает 64 блока, а затем копирует следующие 1 028 097 блоков. В
выходных данных m mis мы видели, что раздел начинается с сектора 63,
поэтому вроде бы пропускать нужно только 62 блока. Однако следует
вспомнить, что адресация секторов начинается с 0, поэтому мы пропускаем
63. Расширение .dd указывает на то, что файлы содержат физические
образы, созданные программой dd или ее аналогом.

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

1028159 – 63 + 1 – 1028097

Чтобы понять, для чего нужно прибавлять 1, рассмотрим простой пример:
раздел начинается с сектора 2 и заканчивается в секторе 4. Его размер
равен 3 секторам:

4-2+1 = 3

Программа dd также может использоваться для выборки данных, находящихся
между разделами. Например, из выходных данных mmls мы знаем, что секторы
с 1 028 160 по 2 570 399 не используются. Их содержимое извлекается
командой # dd if-diskl.dd of=unalloci.dd bs=512 skip=1028160
count=1542240

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

Восстановление удаленных разделов

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

Средства восстановления разделов исходят из предположения, что в каждом
разделе находилась файловая система. Многие файловые системы начинаются
со структуры данных с постоянной сигнатурой. Например, файловая система
FAT

Основы анализа

PAGE 91

содержит значения 0x55 и ОхАА в байтах 510 и 511 первого сектора.
Программа восстановления ищет сигнатуры и определяет по ним возможное
начало раздела.

При обнаружении сигнатуры часто выполняются дополнительные проверки с
диапазонами значений, допустимых для некоторых полей структуры данных.
Например, одно из полей файловой системы FAT определяет количество
секторов в кластере; значение поля представляет собой степень 2
(например, 1, 2, 4, 8, 16, 32, 64 или 128). Любое другое значение
свидетельствует о том, что сектор не является частью загрузочного
сектора файловой системы FAT, хотя он и заканчивается сигнатурой 0х55АА.

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

Например, в системе Linux для восстановления разделов применяется
программа gpart ( HYPERLINK
“http://www.stud.uni-hannover.de/user/76201/gpart/”
http://www.stud.uni-hannover.de/user/76201/gpart/ ). Программа gpart
способна идентифицировать несколько файловых систем, для чего она
проверяет содержимое секторов и делает выводы относительно того, какая
система является наиболее вероятной.

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

# gpart -V disk2.dd

* Warning: strange partition table magic 0x0000. […]

Begin scan…

Possible partition(D0S FAT). size(800mb), offset(Omb) type:
006(0x06)(Primary ‘big’ DOS (>32MB)) size: 800mb #s(1638566)
s(63-1638628) chs: (0/l/l)-(101/254/62)d (0/1/1)-(101/254/62)г hex:
00 01 01 00 06 FE 3E 65 3F 00 00 00 A6 00 19 00

Possible partition(DOS FAT). size(917mb). offset(800mb)

type: 006(0x06)(Primary ‘big’ DOS (>32MB))

size: 917mb #s(1679604) s(1638630-3518233)

chs: (102/0/l)-(218/254/62)d (102/0/1)-(218/254/62)г

hex: 00 00 01 66 06 FE 3E DA E6 00 19 00 34 AE 1С 00

Possible partitiondinux ext2). size(502mb). offset(1874mb) type:
131(0x83)(Linux ext2 filesystem)) size: 502mb #s(1028160)
s(3839535-4867694) chs: (239/0/1)-(302/254/63)d
(239/0/1)-(302/254/63)г hex: 00 00 01 EF 83 FE 7F 2E 2F 96 ЗА 00 40 BO
OF 00

Из результатов видно, что на диске, по всей вероятности, существовало
два раздела FAT и один раздел Ext2. Поле в конце строки size: показывает
местонахождение раздела в секторах. Если бы флаг -v не был задан, то эта
информация не

PAGE 92

Глава 4. Анализ томов

выводилась бы. Другая аналогичная утилита — TestDisk Кристофа Гренье
(Christophe Grenier) ( HYPERLINK
“http://www.cgsecurity.org/testdisk.html”
http://www.cgsecurity.org/testdisk.html ). Помните, что
автоматизированное восстановление работает только при простейшем
удалении или повреждении таблицы разделов.

Итоги

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

Разделы

на персональных компьютерах

В предыдущей главе был приведен общий обзор анализа томов и показано,
почему он так важен. Теперь от абстрактного обсуждения томов мы перейдем
к подробностям систем разделов, используемых на персональных
компьютерах. В этой главе будут рассматриваться разделы DOS, разделы
Apple и съемные носители. Для каждой системы будут описаны основные
принципы работы и структуры данных. Если вас не интересуют подробности
структур данных, эти описания можно пропустить. В главе также
перечислены некоторые особые обстоятельства, которые необходимо
учитывать при анализе разделов в этих системах. Следующая глава будет
посвящена системам формирования разделов на серверах.

Разделы в DOS

Наибольшее распространение получила система разделов DOS. Разделы DOS в
течение многих лет использовались на платформе Intel IА32 (то есть
i386/x86), однако официальная спецификация до сих пор отсутствует.
Существует много документов (опубликованных как Microsoft, так и
сторонними источниками), но стандартного описания нет.

Более того, нет не только стандартного описания, но pi стандартного
названия. Компания Microsoft называет диски с подобным типом системы
разделов дисками MBR (Master Boot Record) — в отличие от дисков GPT(GUID
Partition Table), используемых в системах EFI (Extensible Firmware
Interface) и 64-разрядных системах на базе Intel Itanuim (IA64), о
которых речь пойдет в следующей главе [Microsoft, 2004а]. Начиная с
Windows 2000, компания Microsoft также ввела различия между базовыми и
динамическими дисками. Базовым может быть диск MBR или GPT, при этом
разделы диска независимы и автонохмны. Динамические диски,
рассматриваемые в главе 7, могут быть дисками MBR или GPT, а их разделы
могут объединяться в один раздел большего размера. Базовые диски
традиционно ассоциируются с разделами DOS, а диски GPT еще не получили
широкого распространения. Таким образом, если пользоваться современной
терминологией, в этой главе будут рассматриваться базовые диски MBR. Тем
не менее в книге для краткости будет использоваться термин «разделы
DOS».

Разделы DOS применяются в Microsoft DOS, Microsoft Windows, Linux и в
системах FreeBSD и OpenBSD на платформе IА32. Эта система получила
наибольшее распространение, но она же оказалась наиболее сложной. Дело в
том, что система проектировалась в 1980-х годах для малых систем, а
потом постепенно адаптировалась для больших современных систем.
Фактически в ней задействованы два

PAGE 94

Глава 5. Разделы на персональных компьютерах

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

Общий обзор

Здесь будут представлены основные концепции разделов DOS и системные
области с загрузочным кодом, а структуры данных будут описаны далее.

Основные концепции MBR

В первом 512-байтовом секторе диска, на котором создана структура
разделов DOS, хранится основная загрузочная запись MBR (Master Boot
Record). MBR содержит загрузочный код, таблицу разделов и сигнатуру.
Команды загрузочного кода сообщают компьютеру, как обработать таблицу
разделов и где находится операционная система. Таблица разделов содержит
четыре записи, каждая из которых может описывать один раздел DOS. Записи
состоят из следующих полей:

• начальный адрес CHS;

• конечный адрес CHS;

• начальный адрес LBA;

• конечный адрес LBA;

• количество секторов в разделе;

• тип раздела;

• флаги.

Запись таблицы описывает местонахождение раздела в адресах CHS и LBA.
Помните, что адреса CHS применимы только для дисков менее 8 Гбайт, тогда
как адреса LBA позволяют использовать диски, размер которых исчисляется
в терабайтах (Тбайт).

Поле типа определяет тип данных, хранящихся в разделе: например, FAT,
NTFS или FreeBSD. Далее будет приведет более полный список.
Использование поля типа зависит от операционной системы. Скажем, Linux
не обращает на него внимания — файловую систему FAT можно разместить в
разделе с типом NTFS, и она будет смонтирована как FAT. С другой
стороны, Microsoft Windows учитывает значение этого поля и не пытается
смонтировать файловую систему в раздел, если соответствующий тип раздела
не поддерживается. Таким образом, если диск содержит файловую систему
FAT в разделе с типом файловой системы Linux, пользователь не увидит эту
файловую систему FAT в Windows. Данная особенность иногда применяется
для скрытия разделов в Windows. Например, некоторые программы добавляют
лишний бит к типу раздела, поддерживаемому Windows, чтобы раздел не
отображался при повторной загрузке системы.

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

Общий обзор

PAGE 95

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

1 і г

Раздел 1 Раздел 2

Рис. 5.1. Простой диск DOS с двумя разделами и MBR

Концепция расширенного раздела

MBR позволяет описать до четырех разделов. Тем не менее во многих
системах этого количества недостаточно. Допустим, имеется 12-гигабайтный
диск, который пользователь хочет разделить на шесть 2-гигабайтных
разделов, потому что он использует несколько операционных систем.
Описать шесть разделов при помощи четырех записей невозможно.

Именно тот способ, который был выбран для решения этой проблемы, делает
разделы DOS такими сложными. Общий принцип состоит в следующем: в MBR
создается одна, две или три записи для обычных разделов, а затем
формируется «расширенный раздел», заполняющий все оставшееся место на
диске. Прежде чем двигаться дальше, стоит разобраться с некоторыми
терминами. Первичным разделом файловой системы называется раздел,
представленный записью в MBR и содержащий файловую систему или другие
структурированные данные. Первичным расширенным разделом называется
раздел, представленный записью в MBR и содержащий вторичные разделы. На
рис. 5.2 изображены три первичных раздела файловой системы с одним
первичным расширенным разделом.

Первичный Первичный Первичный

раздел раздел раздел

файловой файловой файловой

системы 1 системы 2 системы 3

Первичный расширенный раздел

Рис. 5.2. Диск DOS с тремя первичными разделами файловой системы и одним
первичным расширенным разделом

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

PAGE 96

Глава 5. Разделы на персональных компьютерах

Вторичный раздел файловой системы, также называемый в ^Гт&оукъ
логическим разделом, находится в границах основного расширенного раздела
и содержит файловую систему или другие структурированные данные.
Вторичный расширенный раздел содержит таблицу разделов и дополнительный
раздел файловой системы. Каждый вторичный расширенный раздел
представляет собой «обертку» для вторичного раздела файловой системы; он
описывает местонахождение вторичного раздела файловой системы и
следующего вторичного расширенного раздела.

На рис. 5.3 показано, как работает система вторичных разделов. Вторичный
расширенный раздел 1 содержит таблицу разделов, в которой хранится
информация о вторичном разделе файловой системы 1 и вторичном
расширенном разделе. Вторичный расширенный раздел 2 содержит таблицу
разделов с информацией о вторичном разделе файловой системы 2. Но в
общем случае он также может содержать ссылку на следующий вторичный
расширенный раздел, и так далее, пока не будет распределено все
свободное дисковое пространство.

Вторичный

раздел файловой системы 1

Вторичный Вторичный

раздел раздел

файловой файловой

системы 1 системы 2

Вторичный

раздел

файловой

системы 2

Рис. 5.3. Основной принцип и общая структура вторичных разделов
(расширенных и файловых систем)

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

Давайте объединим два метода определения разделов. Если в системе
используется от одного до четырех разделов, то для их создания
достаточно МВ11 и расширенные разделы не потребуются. Если количество
разделов больше 4, в МВ11 создается до трех первичных разделов файловой
системы, а оставшееся место на диске выделяется под первичный
расширенный раздел.

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

Общий обзор

PAGE 97

Рассмотрим пример. Имеется 12-гигабайтный диск, который требуется
разбить на шесть 2-гигабайтных разделов. Первые три 2-гигабайтных
раздела создаются в первых трех записях МВ11, а оставшиеся 6 Гбайт
выделяются под первичный расширенный раздел, включающий дисковое
пространство от 6 до 12 Гбайт.

Остается определить еще три раздела в формате связанного списка. Мы
используем таблицу разделов в первом секторе первичного расширенного
раздела, создаем вторичный раздел файловой системы в диапазоне от 6
Гбайт до 8 Гбайт и создаем вторичный расширенный раздел в диапазоне от 8
Гбайт до 10 Гбайт. Таблица разделов находится во вторичном расширенном
разделе и содержит записи вторичного раздела файловой системы в
диапазоне от 8 Гбайт до 10 Гбайт и вторичного расширенного раздела в
диапазоне от 10 Гбайт до 12 Гбайт. Таблица разделов находится в
последнем вторичном расширенном разделе и содержит запись последнего
раздела файловой системы в диапазоне от 10 до 12 Гбайт. Схема показана
на рис. 5.4.

2GB

4GB

6GB

8GB

10GB

12GB

Первичный

раздел файловой системы 1

Первичный

раздел файловой системы 2

Первичный

раздел файловой системы 3

Первичный расширенный раздел

Г 1

Вторичный Вторичный

раздел раздел

файловой файловой

системы 1 системы 1

_ Вторичный

Вторичный

раздел

раздел

файловой

файловой

системы 2

системы 2

1

L

Вторичный

раздел

файловой

системы 3

Рис. 5.4. Структура диска с шестью разделами файловой системы

Как утверждается в большинстве документов, расширенная таблица разделов
должна содержать не более одной записи для раздела вторичной файловой
системы и одной записи для вторичного расширенного раздела. На практике
многие операционные системы не будут выдавать ошибку при использовании
более двух записей. В июле 2003 г. я опубликовал 160-мегабайтный образ
диска [Carrier, 2003]

PAGE 98

Глава 5. Разделы на персональных компьютерах

с шестью 25-мегабайтными разделами DOS в списке CFTT Yahoo! Groups
(http:/ HYPERLINK “file:///groups.yahoo.com/group/cftt/”
/groups.yahoo.com/group/cftt/ ). Образ содержал первичный расширенный
раздел с двумя записями вторичных разделов файловых систем и одной
записью вторичного расширенного раздела. Одни системные программы
правильно обрабатывали запись третьего раздела, другие игнорировали его
или вместо 25-мегабайтного раздела обнаруживали раздел объемом 1 Тбайт.
Этот пример показывает, что даже такая распространенная схема, как
разделы DOS, может вызывать проблемы у аналитических программ.

Расширенные разделы обладают специальными типами, которые используются в
их записях таблиц разделов. А чтобы эта сложная схема стала еще сложнее,
существует несколько типов расширенных разделов, среди которых не
различаются типы первичных и вторичных расширенных разделов. Самые
распространенные типы расширенных разделов — «расширенный раздел DOS»,
«расширенный раздел Windows 95» и «расширенный раздел Linux».

Загрузочный код

Загрузочный код диска DOS находится в первых 446 байтах первого
512-байтового сектора, то есть в MBR. В конце сектора находится таблица
разделов. Стандартный загрузочный код Microsoft обрабатывает таблицу
разделов MBR и определяет, для какого раздела установлен флаг загрузки.
Обнаружив такой раздел, загрузчик обращается к его первому сектору и
передает управление находящемуся в нем коду. Код в начале раздела
является специфическим для операционной системы. Вирусы, внедряющиеся в
загрузочный сектор, записывают себя в первые 446 байт MBR, чтобы они
выполнялись при каждой загрузке компьютера.

В наши дни компьютеры с несколькими операционными системами становятся
все более распространенным явлением. Проблема решается двумя способами.
Система Windows записывает в загрузочный раздел код, который дает
возможность пользователю выбрать загружаемую операционную систему.
Другими словами, сначала выполняется загрузочный код в MBR, который
передает управление загрузочному коду Windows. Загрузочный код Windows
дает возможность пользователю выбрать раздел для загрузки системы.

Второй способ основан на модификации кода MBR. Новый код MBR выдает
список возможных вариантов, из которого пользователь выбирает раздел для
загрузки. Как правило, такое решение требует большего объема кода и
использует некоторые свободные секторы, существующие перед началом
первого раздела.

Итоги

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

1. Прочитать MBR из первого сектора диска, идентифицировать и обработать
четыре записи таблицы разделов.

2. При обработке записи расширенного раздела прочитать первый сектор
расширенного раздела и обработать записи его таблицы разделов так же,
как это делается для MBR.

Структуры данных

PAGE 99

3. При обработке записи обычного (не расширенного) раздела выводится его
начальный сектор и размер. Конечный сектор определяется суммированием
этих величин с вычитанием 1.

Структуры данных

От рассмотрения системы разделов DOS мы переходим к подробному описанию
структур, заложенных в основу этой системы. Если структуры данных вас не
интересуют, описание можно пропустить, однако в нем встречается
интересный пример использования расширенных разделов. Материал состоит
из трех подразделов с описанием MBR, расширенных разделов и примером
вывода данных для образа.

Структура данных MBR

Таблицы разделов DOS находятся в MBR и в первом секторе каждого
расширенного раздела. Во всех случаях используется одна и та же
512-байтовая структура. Первые 446 байт зарезервированы для загрузочного
кода. Код должен находиться в MBR, поскольку он используется при запуске
компьютера, однако для расширенных разделов он не нужен, и на его месте
могут храниться скрытые данные. Структура MBR в табличной форме показана
в табл. 5.1.

Таблица 5-1- Структуры данных в таблице разделов DOS

Диапазон байтов Описание Необходимость

0-445 Загрузочный код Нет

446-461 Запись таблицы разделов №1 (см. табл. 5.2) Да

462-477 Запись таблицы разделов №2 (см. табл. 5.2) Да

478-493 Запись таблицы разделов №3 (см. табл. 5.2) Да

494-509 Запись таблицы разделов №4 (см. табл. 5.2) Да

510-511 Сигнатура (0хАА55) Нет

Таблица разделов содержит четыре 16-байтовых записи, структура которых
представлена в табл. 5.2. Адреса CHS необходимы для старых систем, в
которых они используются, но в новых системах они не нужны.

Таблица 5-2. Структура данных записи раздела DOS

Диапазон байтов Описание Необходимость

0-0 Флаг загрузочного раздела Нет

1-3 Начальный адрес CHS Да

4-4 Тип раздела (см. табл. 5.3) Нет

5-7 Конечный адрес CHS Да

8-11 Начальный адрес LBA Да

12-15 Размер в секторах Да

Флаг загрузочного раздела необходим не всегда. Стандартный загрузочный
код компьютера с единственной ОС ищет запись, у которой этот флаг равен
0x80. Например, если на компьютере установлена Microsoft Windows, а диск
разбит на

PAGE 100

Глава 5. Разделы на персональных компьютерах

два раздела, то у раздела с операционной системой (например, HYPERLINK
“file://C:/windows” C:\windows ) будет установлен флаг загрузочного
раздела. С другой стороны, если загрузочный код предлагает пользователю
выбрать раздел для загрузки системы, флаг может оказаться лишним.
Впрочем, некоторые загрузочные программы устанавливают его после того,
как пользователь выберет соответствующий раздел для загрузки.

Начальный и конечный адреса CHS состоят из головки (8 бит), сектора (6
бит) и цилиндра (10 бит). Теоретически для каждого раздела должен быть
задан только один из двух адресов (CHS или LBA). ОС и код загрузки
системы должны определить, какие значения необходимо задать. Например,
Windows 98 и ME используют адреса CHS для разделов, находящихся в первых
7,8 Гбайт диска, a Windows 2000 и последующие системы всегда игнорируют
адреса CHS [Microsoft, 2003]. Некоторые программы создания разделов
стараются задавать адреса обоих типов для обеспечения совместимости.
Использование этих полей зависит от приложения.

Поле типа раздела идентифицирует тип файловой системы, которая должна
находиться в разделе. Список наиболее распространенных типов приведен в
табл. 5.3, а более подробную информацию можно найти в документе
«Partition Types» [Brouwer, 2004].

Таблица 5.3. Некоторые типы разделов DOS

Тип Описание

0x00 Пусто

0x01 FAT12, CHS

0x04 FAT16, 16-32 Мбайт, CHS

0x05 Расширенный раздел Microsoft, CHS

0x06 FAT 16, 32 Мбайт-2 Гбайт, CHS

0x07 NTFS

ОхОЬ FAT32, CHS

0x0с FAT32, LBA

0x0e FAT16, 32 Мбайт-2 Гбайт, LBA

0x0f Расширенный раздел Microsoft, LBA

0x11 Скрытый раздел FAT12, CHS

0x14 Скрытый раздел FAT 16, 16-32 Мбайт, CHS

0x16 Скрытый раздел FAT 16, 32 Мбайт-2 Гбайт, CHS

Oxlb Скрытый раздел FAT32, CHS

Oxlc Скрытый раздел FAT32, LBA

Oxle Скрытый раздел FAT16, 32 Мбайт-2 Гбайт, LBA

0x42 Microsoft MBR, динамический диск

0x82 Solaris х86

0x82 Раздел подкачки Linux

0x84 Данные спящего режима

0x85 Расширенный раздел Linux

0x86 Набор томов NTFS

0x87 Набор томов NTFS

OxaO Спящий режим

Oxal Спящий режим

0xa5 FreeBSD

Охаб OpenBSD

Структуры данных

PAGE 101

Тип

Описание

0ха8 0ха9 Oxab ОхЬ7 0хЬ8 Охее Oxef Oxfb Oxfc

Мае ОБХ

Мае ОБХ В5Р1

Раздел подкачки В5Р1 Диск ЕР1 вРТ Системный раздел ЕР1 Файловая система
Утшге Раздел подкачки HYPERLINK “file:///Zmware” \Zmware

Обратите внимание, сколько разных типов разделов существует для файловых
систем Microsoft в диапазоне от 0x01 до OxOf. Это объясняется тем, что
операционные системы Microsoft используют тип раздела для определения
способа чтения и записи данных в раздел. Как говорилось в главе 2,
Windows может использовать как традиционные, так и расширенные
обработчики прерывания BIOS INT13h. Расширенные обработчики INT 13h
необходимы для работы с дисками объемом более 8,1 Гбайт и применения
адресации LBA (вместо CHS). Следовательно, типы FAT16 0x04 и ОхОЕ
одинаковы, но во втором случае ОС будет использовать расширенные
обработчики при работе с BIOS. Аналогично, типы 0x0В и ОхОС представляют
обычную и расширенную версии FAT32, а типы 0x05 hOxOF— обычную и
расширенную версии расширенных разделов [Microsoft, 2004b]. «Скрытые»
версии этих типов разделов содержат 1 вместо 0 в верхнем полубайте, а
для их создания применяются различные системные программы.

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

Первый пример взят из первого сектора диска. Данные выводятся утилитой
xxd в Linux, но для получения информации также можно было
воспользоваться шестнадцатеричным редактором для Windows или UNIX. В
Linux командная строка выглядела так:

# dd if=disk3.dd bs=512 skip=0 count=l | xxd

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

# dd if=disk3.dd bs=512 skiр=0 count=l | xxd

0000000: eb48 9010 8ed0 bcOO Ь0Ь8 0000 8ed8 8ec0 .H…………..

[…]

0000384: 0048 6172 6420 4469 736b 0052 6561 6400 .Hard Disk.Read.

0000400: 2045 7272 6f72 OObb 0100 b40e cdlO асЗс Error…………

0000464: 41cc 05fe bfOb 3f82 ЗеОО 40b0 Of00 0000 A…..?.>.@…..

0000480: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

0000496: 0000 0000 0000 0000 0000 0000 0000 55aa …………..U.

Четыре записи таблицы разделов выделены жирным шрифтом. Мы видим, что
две последние записи не содержат данных. В табл. 5.5 представлена
расшифровка первых двух записей таблицы разделов (нумерация разделов
продолжает табл. 5.4):

Таблица 5.5. Содержимое первичной таблицы разделов в образе диска

№ Флаг Тип Начальный сектор Размер

5 0x00 0x07 0x0000003f(63) 0x001f6041 (2 056 257)

6 0x00 0x05 0x003e823f (4 096 575) 0x000fb040 (1 028 160)

Запись 5 помечена типом файловой системы Linux (0x83); таким образом,
раздел является вторичным разделом файловой системы, а его начальный
сектор задается по отношению к началу текущего расширенного раздела
(сектор 3 293 325):

3 293 325 + 63 – 3 293 388

Запись 6 помечена типом расширенного раздела DOS, а начальный сектор
этого раздела задается по отношению к первичному расширенному разделу,
который является текущим:

3 293 325 + 4 096 575 = 7 389 900

Структура диска в том виде, в котором она нам известна, показана на рис.
5.7. Прежде чем продолжить, обратите внимание на размеры двух разделов.
В MBR первичный расширенный раздел имеет размер 76 999 545 секторов. В
этой таблице размер следующего вторичного расширенного раздела
составляет всего 1 028 160 секторов. Вспомните, что размер первичного
расширенного раздела складывается из размеров всех вторичных файловых
систем и вторичных расширенных разделов, тогда как размер вторичного
расширенного раздела складывается из размера следующего вторичного
раздела файловой системы и размера области, необходимой для хранения
таблицы разделов.

Пример можно продолжить и проанализировать следующий вторичный
расширенный раздел, находящийся в секторе 7 389 900. Его содержимое
представлено в табл. 5.6.

Структуры данных

PAGE 105

о см со со ю о см ю со

ю со см

ю см со со

О)

см со о о

О) О) 00

со

1

о со о со

со

О)

со

00

см

О)

см о со

Рис. 5.7. Структура диска после обработки второй таблицы разделов (без
соблюдения масштаба)

Таблица 5.6. Содержимое первой вторичной расширенной таблицы разделов в
образе диска

№ Флаг Тип Начальный сектор Размер

7 0x00 0x82 ОхООООООЗг(63) OxOOOfbOOl (1 028 097)

8 0x00 0x05 0x004e327f (5 124 735) OxOOOfbCHO (1 028 160)

Запись 7 описывает раздел подкачки Linux; это вторичная файловая
система, а начальный адрес сектора задается по отношению к текущему
расширенному разделу, то есть сектору 7 389 900: 7 389 900 + 63 = 7 389
963

Запись 8 описывает расширенный раздел файловой системы DOS, поэтому его
адрес начального сектора задается по отношению к первичному расширенному
разделу, то есть сектору 3 293 325: 3 293 325 + 5 124 735 – 8 418 060

Структура диска с информацией из этой таблицы разделов показана на рис.
5.8. Полное содержимое таблицы разделов будет приведено далее, при
рассмотрении программ вывода содержимого таблицы разделов.

Вывод информации о разделах

Познакомившись с внутренней структурой таблицы разделов, давайте
посмотрим, как она обрабатывается некоторыми аналитическими программами.
Те, кто предпочитает обрабатывать структуры данных вручную и не
пользуется вспомогательными программами, могут пропустить этот материал.
Мы рассмотрим две программы для Linux, но эта функция также выполняется
многими Windows-программами (в том числе системами экспертного анализа и
шестнадцатеричными редакторами).

Команда fdisk входит в поставку Linux и отличается от одноименной
программы, поставляемой с системой Windows. Fdisk может работать с
устройством Linux или файлом образа, сгенерированным программой dd. При
запуске с флагом -L

PAGE 106

Глава 5. Разделы на персональных компьютерах

программа выводит список разделов вместо перехода в интерактивный режим
с возможностью редактирования разделов. Флаг – и означает, что
информация должна выводиться в секторах (вместо цилиндров). Для диска с
разделами DOS, который мы обрабатывали вручную, программа выдала
следующий результат: # fdisk -1u disk3.dd

Disk disk3.dd: 255 heads. 63 sectors, 0 cylinders Units = sectors of 1 *
512 bytes

Device Boot Start End Blocks Id System

disk3.ddl 63 2056319 1028128+ 7 HPFS/NTFS

disk3.dd2 * 2056320 2265164 104422+ 83 Linux

disk3.dd3 2265165 3293324 514080 83 Linux

disk3.dd4 3293325 80292869 38499772+ 5 Extended

disk3.dd5 3293388 7389899 2048256 83 Linux

disk3.dd6 7389963 8418059 514048+ 82 Linux swap

disk3.dd7 8418123 9446219 514048+ 83 Linux

disk3.dd8 9446283 17639369 4096543+ 7 HPFS/NTFS

disk3.dd9 17639433 48371714 15366141 83 Linux

о

CM CO CD Ю О CM

Ю CD

LO CO CM CM

LO CM CO CO O) CM CO

о о o> o>

00

CO

о

CO

о

00

о

CM CM

I

CD

00

см o>

CM

о

00

p

NTFS Linux Linux Первичный расширенный раздел

Linux

Ext

Подкачка

Ext

Рис. 5.8. Структура диска после обработки третьей таблицы разделов (без
соблюдения масштаба)

Обратите внимание на некоторые обстоятельства. В выходных данных указан
только первичный расширенный раздел (disk3.dd4). Вторичный расширенный
раздел, в котором находится раздел подкачки Linux, обнаружен, но
информация о нем не выводится. Такой подход приемлем в большинстве
случаев, потому что для анализа абсолютно необходимы только первичный и
вторичный разделы файловых систем, но все же следует помнить, что в
результатах отображаются не все записи таблицы разделов.

Структуры данных

PAGE 107

Выходные данные программы mmls из пакета The Sleuth Kit выглядят
несколько иначе. В них помечаются секторы, не используемые разделами,
указывается местонахождение таблиц разделов и расширенных разделов. Для
диска, использованного в первом примере с fdisk, выходные данные mmls
выглядят так:

# mmls -t dos disk3.dd

Units are in 512-byte sectors

Slot Start End Length Description

00

0000000000 0000000000 0000000001 Table #0

01

0000000001 0000000062 0000000062 Unallocated

02 00 00 0000000063 0002056319 0002056257 NTFS (0x07)

03 00 01 0002056320 0002265164 0000208845 Linux (0x83)

04 00 02 0002265165 0003293324 0001028160 Linux (0x83)

05 00 03 0003293325 0080292869 0076999545 DOS Extended (0x05)

06

0003293325 0003293325 0000000001 Table #1

07

0003293326 0003293387 0000000062 Unallocated

08 01 00 0003293388 0007389899 0004096512 Linux (0x83)

09 01 01 0007389900 0008418059 0001028160 DOS Extended (0x05)

10

0007389900 0007389900 0000000001 Table #2

11

0007389901 0007389962 0000000062 Unallocated

12 02 00 0007389963 0008418059 0001028097 Linux swap (0x82)

13 02 01 0008418060 0009446219 0001028160 DOS Extended (0x05)

14

0008418060 0008418060 0000000001 Table #3

15

0008418061 0008418122 0000000062 Unallocated

16 03 00 0008418123 0009446219 0001028097 Linux (0x83)

17 03 01 0009446220 0017639369 0008193150 DOS Extended (0x05)

18

0009446220 0009446220 0000000001 Table #4

19

0009446221 0009446282 0000000062 Unallocated

20 04 00 0009446283 0017639369 0008193087 NTFS (0x07)

21 04 01 0017639370 0048371714 0030732345 DOS Extended (0x05)

22

0017639370 0017639370 0000000001 Table #5

23

0017639371 0017639432 0000000062 Unallocated

24 05:00 0017639433 0048271714 0030732282 Linux (0x83)

Строки с пометкой Unallocated обозначают пространство между разделами,
а также между концом таблицы разделов и началом первого раздела. В
выходных данных mmls указан как конечный адрес, так и результат, что
упрощает их использование для извлечения содержимого разделов программой
dd.

Результаты mmls сортируются по начальному сектору раздела, поэтому
первый столбец содержит только порядковый номер строки и не имеет
отношения к положению записи в таблице разделов. Во втором столбце
выводится таблица разделов и положение записи в ней. Первое число
определяет таблицу (0 — первичная таблица, 1 — первичная расширенная
таблица), а второе определяет запись в таблицу. Сортировка упрощает
идентификацию секторов, не принадлежащих разделам. Для примера возьмем
следующий образ:

# mmls -t dos diskl.dd Units are in 512-byte sectors

Slot Start End Length Description

00

0000000000 0000000000 0000000001 Table #0

01

0000000001 0000000062 0000000062 Unallocated

02 00 00 0000000063 0001028159 0001028097 Win95 FAT32 (0x0В)

03

0001028160 0002570399 0001542240 Unallocated

04 00 03 0002570400 0004209029 0001638630 OpenBSD (0xA6)

05 00 01 0004209030 0006265349 0002056320 NTFS (0x07)

PAGE 108

Глава 5. Разделы на персональных компьютерах

Из листинга видно, что раздел NTFS находится в позиции перед разделом
OpenBSD, но раздел NTFS начинается после раздела OpenBSD. Также можно
заметить, что запись с пометкой 00:02 отсутствует, а 1 542 240 секторов
между FAT и OpenBSD также помечены как нераспределенные.

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

В этом разделе упоминаются некоторые обстоятельства, которые необходимо
учитывать при анализе диска с разделами DOS. Для таблицы разделов и
загрузочного кода обычно хватает одного сектора, но, как правило, для
MBR и расширенных разделов выделяются 63 сектора, потому что разделы
должны начинаться на границе цилиндра. Следовательно, раздел 0
расширенного раздела или MBR содержит код и таблицу разделов, а секторы
1-62 могут оставаться неиспользуемыми. В неиспользуемых секторах может
храниться дополнительный загрузочный код, но также в них могут
находиться данные от предыдущей установки, нули или скрытые данные.
Windows ХР не стирает данные в неиспользуемых секторах при создании
разделов на диске.

Разделы в большинстве случаев начинаются с сектора 63, и этим
обстоятельством можно воспользоваться для восстановления содержимого
первого раздела, так как при отсутствии таблицы разделов средства,
упоминавшиеся в главе 4, работать не будут. Попробуйте извлечь данные,
начиная с сектора 63. В этом случае в выборку будут включены другие
разделы из образа, но возможно, вам удастся определить фактический
размер раздела по данным файловой систехмы. Извлечение раздела
программой dd осуществляется так: # dd if=disk.dd bs=512 skip=63
of=part.dd

Теоретически расширенные разделы должны содержать только две записи: для
раздела вторичной файловой системы и вторичного расширенного раздела.
Большинство программ создания разделов следуют этим правилам, но
существует возможность создать третий раздел вручную. Microsoft Windows
ХР и Red Hat 8.0 отобразили «лишний» раздел, когда расширенный раздел
содержал более двух записей, однако ни та, ни другая ОС не позволили
создать такую конфигурацию. Протестируйте свои аналитические программы и
убедитесь в том, что в подобных «неправильных» конфигурациях они выводят
информацию обо всех разделах.

Значение в поле типа раздела учитывается не всегда. Windows использует
поле для идентификации разделов для монтирования, но в таких
операционных системах, как Linux, пользователь получает доступ ко всем
разделам. Таким образом, пользователь может поместить файловую систему
FAT в раздел, предназначенный (в соответствии с типом) для хранения
данных спящего режима. Эта файловая система не будет монтироваться в
Windows — только в Linux.

Некоторые версии Windows создают в MBR только один первичный раздел, а
все остальные разделы создают как расширенные. Другими словами, они не
создают три первичных раздела, прежде чем переходить к созданию
расширенных разделов.

Если часть таблицы разделов будет повреждена, возможно, придется таблицы
расширенных разделов искать на диске. Поиск следует производить по
сигнатуре 0хАА55 в двух последних байтах секторах. Обратите внимание: в
файловых системах NTFS и FAT присутствуют в той же позиции первого
сектора. Чтобы

Общий обзор

PAGE 109

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

Итоги

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

Разделы Apple

Компьютеры с операционной системой Apple Macintosh встречаются реже, чем
компьютеры с Microsoft Windows, однако их популярность возросла с
выходом Mac OS X, операционной системы на базе UNIX. Разделы, о которых
пойдет речь, применяются на последних портативных и настольных
компьютерах Apple с системой OS X, более старых системах с Macintosh 9 и
даже портативных устройствах iPod, предназначенных для воспроизведения
аудио в формате МРЗ. Карты разделов также могут использоваться в файлах
образов дисков, используемых в Macintosh при пересылке файлов. Файлы
образов дисков напоминают zip-файлы в Windows или tar-файлы в UNIX. Их
содержимое хранится в виде файловой системы, которая может находиться в
разделе.

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

Общий обзор

Разделы Apple описываются специальной структурой данных — картой
разделов (partition map), находящейся в начале диска. Обработка этой
структуры реализована на уровне «прошивок» (встроенного кода), поэтому
карта не содержит загрузочный код, как в схеме разделов DOS. Каждая
запись карты разделов определяет начальный сектор раздела, размер, тип и
имя тома. Структура данных также содержит информацию о данных,
хранящихся в разделе, — в частности, местонахождение области данных и
загрузочного кода.

PAGE 110

Глава 5. Разделы на персональных компьютерах

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

1 г 1 г …..:

Карта Раздел Раздел Раздел

разделов файловой файловой файловой

системы 1 системы 2 системы 3

Рис. 5.9. Диск Apple с одним разделом, содержащим карту разделов, и
тремя разделами файловых систем

Как будет показано далее, в системах BSD используется другая структура
разделов, называемая разметкой диска. Несмотря на то что Mac OS X
базируется на ядре BSD, в этой системе используется карта разделов
Apple, а не разметки диска.

Структуры данных

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

Запись карты разделов

Карта разделов Apple содержит несколько 512-байтовых структур данных,
каждая из которых представляет один раздел. Карта разделов начинается со
второго сектора диска и продолжается до тех пор, пока не будут описаны
все разделы. Структуры данных разделов хранятся в смежных секторах, и в
каждой записи присутствует общее количество разделов. Структура записи
карты разделов показана в табл. 5.7.

Таблица 5.7- Структура данных записей разделов Apple

Диапазон байтов Описание Необходимость

0-1 Сигнатура (0x504D) Нет

2-3 Зарезервировано Нет

4-7 Общее количество разделов Да

8-11 Начальный сектор раздела Да

12-15 Размер раздела в секторах Да

16-^7 Имя раздела в кодировке ASCII Нет

Общий обзор

PAGE 111

Диапазон байтов

Описание

Необходимость

48-79 80-83

84-87

88-91

92-95

96-99

100-103

104-107

108-111

112-115

116-119

120-135

136-511

Тип раздела в кодировке ASCII Нет Начальный сектор области данных в
разделе Нет

Размер области данных в секторах Нет

Состояние раздела (см. табл. 5.8) Нет

Начальный сектор загрузочного кода Нет

Размер загрузочного кода в секторах Нет

Адрес кода загрузчика Нет

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

Точка входа в загрузочный код Нет

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

Контрольная сумма загрузочного кода Нет

Тип процессора Нет

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

Тип раздела задается в кодировке ASCII, а не целочисленным кодом, как в
других схемах. Коды состояния каждого раздела применимы как к A/UX
(старая операционная система Apple), так и к современным системам
Macintosh. Поле состояния содержит одно из значений, перечисленных в
табл. 5.8 [Apple, 1999].

Таблица 5.8. Коды состояния разделов Apple

Тип Описание

0x00000001 Запись действительна (только A/UX)

0x00000002 Запись выделена (только A/UX)

0x00000004 Запись используется (только A/UX)

0x00000008 Запись содержит загрузочную информацию (только A/UX)

0x00000010 Запись доступна для чтения (только A/UX)

0x00000020 Запись доступна для изменения (Macintosh и A/UX)

0x00000040 Загрузочный код является позиционно-независимым (только A/UX)

0x00000100 Раздел содержит цепочечно-совместимый драйвер (только
Macintosh)

0x00000200 Раздел содержит настоящий драйвер (только Macintosh)

0x00000400 Раздел содержит цепочечный драйвер (только Macintosh)

0x40000000 Автоматическое монтирование при запуске (только Macintosh)

0x80000000 Стартовый раздел (только Macintosh)

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

Чтобы идентифицировать разделы на диске Apple, программа (или человек)
читает структуру данных из второго сектора. Обработка структуры дает
общее количество разделов, после чего извлекается другая информация о
разделах. Обычно первая запись относится к самой карте разделов. Затем
читается следующий сектор, и процесс продолжается до тех пор, пока не
будут прочитаны все разделы. Вот как выглядит содержимое первой записи
карты разделов: # dd if=mac-disk.dd bs=512 skiр=1 | xxd

0000000: 504d 0000 0000 000a 0000 0001 0000 003f PM………….?

PAGE 112

Глава 5. Разделы на персональных компьютерах

0000016 0000032 0000048 0000064 0000080 0000096 […] 4170 706с 6500
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4170
706с 655f 7061 7274 6974 696f 6e5f 6d61 7000 0000 0000 0000 0000 0000
0000 0000 0000 0000 003f 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000

Apple.

Apple_partition_ map………….

На компьютерах Apple используются процессоры Motorola PowerPC, поэтому
данные на них хранятся с обратным порядком байтов. В результате отпадает
необходимость в перестановке байтов, как в разделах DOS. В байтах 0-1
видна сигнатура 0x504d, а в байтах 4-7 — количество разделов, равное 10
(0x0000000а). Байты 8-11 показывают, что первый сектор диска является
начальным сектором раздела, а размер раздела составляет 63 сектора
(0x3f). Разделу присвоено имя «Apple», а тип раздела обозначается
строкой «Apple_partition_map». Из байтов 88—91 видно, что флаги для
раздела не установлены. У других записей, относящихся к конкретным
разделам, заданы коды состояния.

Пример информации о разделах

Для просмотра карты разделов Apple можно воспользоваться программой mmls
из пакета The Sleuth Kit. Вот как выглядят результаты, полученные при
запуске mmls на портативном компьютере iBook с диском емкостью 20 Гбайт:

# mmls -t mac mac-disk.dd MAC Partition Map

Units are in 512-byte sectors

Description Unallocated Apple_pa rt i t i on_map Table

Unallocated Apple_driver43 Apple_driver44 Apple_driver_ATA
Apple_driver_ATA Apple_FWDriver Apple_Driver_IOKit Apple_Patches
Apple_HFS Apple_Free

В этих данных строки отсортированы по начальному сектору, а второй
столбец показывает, какая запись карты содержит описание раздела. В
данном примере записи уже хранятся в отсортированном виде. Из строки 12
видно, что на компьютере Apple mmls выводит информацию о
нераспределенных секторах. Строки О, 2 и 3 были добавлены mmls; в них
выводится информация о местонахождении карты разделов и о свободных
секторах. Перечисленные драйверы используются системой при загрузке.

Для анализа низкоуровневого образа диска в OS X также можно запустить
программу pdisk с флагом -dump:

# pdisk mac_disk.dd -dump mac-disk.dd map block size=-512

#: type name length base (size)

Slot Start End Length

00

0000000000 0000000000 0000000001

01 00 0000000001 0000000063 0000000063

02

0000000001 0000000010 0000000010

03

0000000011 0000000063 0000000053

04 01 0000000064 0000000117 0000000054

05 02 0000000118 0000000191 0000000074

06 03 0000000192 0000000245 0000000054

07 04 0000000246 0000000319 0000000074

08 05 0000000320 0000000519 0000000200

09 06 0000000520 0000001031 0000000512

10 07 0000001032 0000001543 0000000512

11 08 0000001544 0039070059 0039068516

12 09 0039070060 0039070079 0000000020

Общий обзор

PAGE 113

1: Apple_partition_map Apple

2: Apple_Driver43*Macintosh

3: Apple_Dnver43*Macintosh

4: AppleJDri ver_ATA*Macintosh

5: Apple_Driver_ATA*Macintosh

6: Apple_FWDriver Macintosh

7: Apple_Driver_IOKit Macintosh

8: Apple_Patches Patch Partition

9: Apple_HFS untitled

10: Apple_Free

Device block size=512. Number of Blocks=10053

DeviceType=0x0. DeviceId=0x0

Drivers-

1: (P 64 for 23. type-Oxl

2: (P 118 for 36. type-Oxffff

3: @ 192 for 21, type=0x701

4: @ 246 for 34. type=0xf8ff

Как упоминалось во введении, файлы образов дисков Apple (не путайте с
файлами образов, используемыми при анализе файловых систем) также могут
содержать карту разделов. Файл образа представляет собой архивный файл,
который может содержать несколько отдельных файлов (по аналогии с
zip-файлами Windows или tar-файлами UNIX). Файл образа диска может
содержать один раздел с файловой системой или же только файловую систему
без разделов. Тестовый файл образа диска (таким файлам обычно
присваивается расширение .dmg) обладает следующей структурой:

# mmls -t mac test.dmg

MAC Partition Map

Units are in 512-byte sectors

Slot Start End Length Description

00: —– 0000000000 0000000000 0000000001 Unallocated

01: 00 0000000001 0000000063 0000000063 Apple_partition_map

02: —– 0000000001 0000000003 0000000003 Table

03: —– 0000000004 0000000063 0000000060 Unallocated

04: 01 0000000064 0000020467 0000020404 Apple_HFS

05: 02 0000020468 0000020479 0000000012 Applejree

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

Единственная уникальная особенность разделов Apple состоит в том, что
структура данных содержит несколько неиспользуемых полей, которые могут
использоваться для сокрытия небольших объемов данных. Также данные могут
скрываться в секторах между структурой данных последнего раздела и
концом пространства, выделенного для карты разделов. Как и в любой
другой схеме, имя раздела и его тип еще ничего не гарантируют — такой
раздел может содержать все, что угодно.

Итоги

Карта разделов Apple имеет довольно простую структуру, и понять ее
несложно. Структуры данных хранятся в одном месте, а максимальное
количество разделов зависит от того, каким образом производилось
исходное разбиение диска. Программа

63 (Р 1

54 (Р 64

74 (Р 118

54 (Р 192

74 (Р 246 200 (Р 320 512 (Р 520 512 (Р 1032 390668516 (Р 1544 (
18.6G) 0+(Р 39070060

PAGE 114

Глава 5. Разделы на персональных компьютерах

mmls позволяет легко идентифицировать местонахождение разделов Apple на
других компьютерах, а в системе OS X можно воспользоваться программой
pdisk.

Съемные носители

Большинство съемных носителей также содержит разделы, но на них
используются те же структуры данных, что и на жестких дисках. Исключение
из правила составляют дискеты, отформатированные для системы FAT 12 в
Windows и UNIX. Они не имеют таблицы разделов, а весь жесткий диск
рассматривается как один раздел. Образ дискеты можно напрямую
проанализировать как файловую систему. Некоторые портативные флеш-диски
USB («брелковые диски») не имеют разделов и содержат одну файловую
систему, но другие имеют разделы.

Съемные носители большей емкости (скажем, zip-диски Iomega) содержат
таблицы разделов. Структура таблицы разделов на zip-диске зависит от
того, был ли диск отформатирован для Мае или для PC. Диск,
отформатированный для PC, содержит таблицу разделов DOS, и по умолчанию
четвертая запись представляет только один раздел.

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

# mmls -t dos camera.dd

DOS Partition Table

Units are in 512-byte sectors

Slot Start End Length Description

00: —– 0000000000 0000000000 0000000001 Primary Table (#0)

01: —– 0000000001 0000000031 0000000031 Unallocated

02: 00:00 0000000032 0000251647 0000251616 DOS FAT16 (0x06)

Чтобы создать образ карты памяти, достаточно вставить ее в устройство
чтения карт с интерфейсом USB или FireWire и выполнить в Linux команду
dd.

С дисками CD-ROM дело обстоит сложнее из-за большого количества
вариантов. Большинство компакт-дисков использует формат ISO 9660,
поддерживаемый многими операционными системами. Формат ISO 9660
устанавливает жесткие ограничения для имен файлов, поэтому были
разработаны расширения этого формата (такие, как Joliet и Rock Ridge),
обладающие большей гибкостью. Описание компакт-дисков усложняется тем,
что один диск может содержать данные в базовом формате ISO 9660 и в
формате Joliet. А если компакт-диск является гибридным диском Apple, он
также может содержать данные в формате Apple HFS+. Фактическое
содержимое файлов хранится в одном экземпляре, но ссылки на эти данные
присутствуют в нескольких разных местах.

У записываемых компакт-дисков (CD-R) существует понятие сеанса. Диск
CD-R может содержать один или несколько сеансов, а сама концепция сеанса
была разработана для того, чтобы данные к CD-R можно было добавлять
более одного раза. При каждой записи данных на CD-R создается новый
сеанс. В зависимости от операционной системы, в которой используется
диск, каждый сеанс может отображаться в виде раздела. Например, я
воспользовался приложением Apple OS X

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

115

и создал компакт-диск с тремя сеансами. В системе OS X все три сеанса
монтировались как файловые системы. При использовании диска в системе
Linux последний сеанс монтировался по умолчанию, но два других сеанса
также можно было смонтировать, указав их в команде mount. Для
определения количества сеансов на диске можно воспользоваться утилитой
readcd ( HYPERLINK “http://freshmeat.net/projects/”
http://freshmeat.net/projects/ cdrecord/). Когда тот же диск был открыт
в системе Microsoft Windows ХР, система заявила, что он содержит
недопустимую информацию, хотя программа SmartProject ISO Buster (
HYPERLINK “http://www.isobuster.com” http://www.isobuster.com ) увидела
все три сеанса. Даже если многосеансовый диск создавался в Windows,
возможны разные варианты поведения. Таким образом, при анализе CD-R
очень важно использовать программу, позволяющую просмотреть содержимое
всех сеансов, а не полагаться на стандартное поведение той платформы, на
которой осуществляется анализ.

Некоторые компакт-диски также содержат разделы, специфические для
«родной» операционной системы. Например, гибридные CD сочетают формат
ISO с форматом Apple — внутри сеанса используется карта разделов Apple и
файловая система HFS+. К таким дискам применимы стандартные методы
анализа для платформы Apple. Например, вот как выглядит результат
запуска m mis для гибридного диска:

# mmls -t mac cd-slice.dmg

MAC Partition Map

Units are in 512-byte sectors

00 01 02 03 04

Slot Start End Length Description —– 0000000000 0000000000 0000000001
Unallocated

00 0000000001 0000000002 0000000002 Apple_partition_map —– 0000000001
0000000002??????????????????????????????????????????????‹??????????

Многие загрузочные компакт-диски тоже содержат систему разделов
определенной операционной системы. Загрузочные диски Sparc Solaris
содержат структуру Volume Table of Contents в томе ISO, а в начале
загрузочных компакт-дисков Intel может находиться таблица разделов DOS.
Эти структуры используются после загрузки операционной системы с
компакт-диска, а код, необходимый для загрузки системы, хранится в
формате ISO.

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

• Agile Risk Management, «Linux Forensics — Week 1 (Multiple Session
CDRs)». March 19, 2004, HYPERLINK “http://www.agilerm.net/linuxl.html”
http://www.agilerm.net/linuxl.html .

• Apple, «File Manager Rйfйrence». March 1,2004. HYPERLINK
“http://developer.apple.com/documen-”
http://developer.apple.com/documen-
tation/Carbon/Reference/File_Manager/index.html.

• Apple, «Inside Macintosh: Devices». July 3,1996. HYPERLINK
“http://developer.apple.com/documen-”
http://developer.apple.com/documen- tation/mac/Devices/Devices-2.htmL

• Apple, «The Monster Disk Driver Technote». November 22, 1999.
HYPERLINK “http://devel.o-” http://devel.o- HYPERLINK
“http://per.apple.com/technotes/pdf/tnll89.pdf”
per.apple.com/technotes/pdf/tnll89.pdf .

PAGE 116

Глава 5. Разделы на персональных компьютерах

• Brouwer, Andries. «Minimal Partition Table Spйcification». September
16, 1999. HYPERLINK
“http://www.win.tue.nl/~aeb/partitions/partition_tables.html”
http://www.win.tue.nl/~aeb/partitions/partition_tables.html .

• Brouwer, Andries. «Partition Types». December 12, 2004. HYPERLINK
“http://www.win.tue.nl/” http://www.win.tue.nl/
~aeb/partitions/partition_types.html.

• Carrier, Brian. «Entended Partition Test». Digital Forensics Tool
Testing Images, July 2003. HYPERLINK
“http://dftt.sourceforge.net/testl/index.html”
http://dftt.sourceforge.net/testl/index.html .

• CDRoller. Reading Data CD, n.d. HYPERLINK
“http://www.cdroller.com/htm/readdata.html”
http://www.cdroller.com/htm/readdata.html .

• ECMA. «Volume and File Structure of CDROM for Information
Interchange». ISO Spec, September 1998. HYPERLINK
“http://www.ecma-international.org/publications/files/”
http://www.ecma-international.org/publications/files/
ECMA-ST/Ecma-119.pdf.

• Landis, Hale. «How it Works: Master Boot Record». May 6, 2002.
HYPERLINK “http://www.ata-” http://www.ata- HYPERLINK
“http://atapi.com/hiwmbr.htm” atapi.com/hiwmbr.htm .

• Microsoft. «Basic Disks and Volumes Technical Rйfйrence». Windows
Server 2003 Technical Reference, 2004. HYPERLINK
“http://www.microsoft.com” http://www.microsoft.com .

• Microsoft. «Managing GPT Disks in Itamium-based Computers». Windows XP
Professional Resource Kit Documentation, 2004a. HYPERLINK
“http://www.microsoft.com” http://www.microsoft.com .

• Microsoft. «MS-DOS Partitioning Summary». Microsoft Knowledge Base
Article 69912, December 20, 2004b. HYPERLINK
“http://support.microsoft.com/default.aspx?scid=kb;EN-”
http://support.microsoft.com/default.aspx?scid=kb;EN- US;69912.

• Stevens, Curtis, and Stan Merkin. «El Torito: Bootable CD-ROM Format
Specification 1.0». January 25,1999. HYPERLINK
“http://www.phoenix.com/resources/specs-cdrom.pdf”
http://www.phoenix.com/resources/specs-cdrom.pdf .

Разделы в серверных системах

В предыдущей главе было показано, как организовано хранение информации
на персональных компьютерах. Давайте посмотрим, как происходит создание
томов на серверах. В области основных концепций эта глава совершенно не
отличается от предыдущей. Более того, я разделил их только для того,
чтобы материал был представлен по главам среднего размера, и такое
разделение было ничем не хуже других возможных (хотя ничто не мешает
использовать разделы DOS и Apple на серверах). В этой главе мы
познакомимся с системами разделов FreeBSD, NetBSD и OpenBSD; системами
разделов Sun Solaris; а также разделами GPT, поддерживаемыми в
64-разрядных системах Intel Itanium.

Разделы BSD

Компьютерным аналитикам все чаще приходится иметь дело с серверными
системами BSD UNIX — такими, как FreeBSD ( HYPERLINK
“http://www.freebsd.org” http://www.freebsd.org ), OpenBSD ( HYPERLINK
“http://www.openbsd.org” http://www.openbsd.org ) и NetBSD ( HYPERLINK
“http://www.netbsd.org” http://www.netbsd.org ). Такие системы
используют собственные схемы формирования разделов, и в этой части будут
описаны соответствующие структуры данных. На практике чаще встречается
система Linux, но она использует только разделы DOS и не имеет
собственных структур данных.

Многие системы BSD работают на оборудовании IА32 (то есть x86/i386), а
при их проектировании учитывалась возможность их совместного
существования на одном диске с продуктами Microsoft. Такие системы
строятся на базе разделов DOS, упоминавшихся в предыдущей главе. Системы
BSD, работающие на другом оборудовании, по всей вероятности, не будут
использовать разделы DOS, но в книге они не рассматриваются.

Прежде чем переходить к рассмотрению темы, необходимо понять одно важное
обстоятельство: во время работы операционная система может выбрать
разделы, доступ к которым предоставляется пользователю. Как будет
показано, операционная система FreeBSD использует системы разделов DOS и
FreeBSD, тогда как OpenBSD и NetBSD используют только систему разделов
BSD. Для данного раздела необходимо хотя бы общее понимание разделов
DOS.

Общий обзор

Система разделов BSD проще системы разделов DOS, но по своим
возможностям она уступает картам разделов Apple. Необходимые данные
хранятся только в одном секторе, который находится в разделе DOS (рис.
6.1). Это было сделано для

PAGE 118

Глава 6. Разделы в серверных системах

того, чтобы на том же диске могла быть установлена система Windows, а
пользователь мог выбрать загружаемую операционную систему. В таблице
разделов DOS создается запись для разделов FreeBSD, OpenBSD или NetBSD —
типы 0ха5, Охаб и 0ха9 соответственно. Раздел BSD является одним из
первичных разделов DOS.

і г

NTFS FreeBSD

Рис. 6.1. Диск с двумя разделами DOS и тремя разделами BSD внутри
раздела DOS

Если бы я стремился к максимальной строгости в терминологии, стоило бы
сказать, что разделы BSD находятся внутри тома, созданного на основе
раздела DOS. Как объяснялось в главе 4, это один из примеров разбиения
на разделы тома, созданного на базе раздела.

Центральной структурой данных является разметка диска (disk label). Ее
размер составляет минимум 276 байт, и она находится во втором секторе
раздела BSD. В некоторых системах, не использующих платформу IA32, она
может храниться в первом секторе со смещением. В FreeBSD, OpenBSD и
NetBSD используется одна структура данных, но с некоторыми различиями в
реализации. Сейчас я изложу общие положения, а конкретные подробности
будут приведены далее.

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

• начальный сектор раздела BSD;

• размер раздела BSD;

• тип раздела;

• размер фрагмента файловой системы UFS;

• количество фрагментов файловой системы UFS на блок;

• количество цилиндров в группе UFS.

Адрес начального сектора отсчитывается от начала диска, а не от разметки
диска или раздела DOS. Поле типа раздела определяет тип файловой
системы, которая должна находиться в разделе BSD — например, UFS,
область подкачки, FAT или неиспользуемая область. Последние три значения
используются только в том случае, если раздел содержит файловую систему
UFS. Файловая система UFS описывается в главах 16 и 17.

Основные принципы схемы разделов BSD просты. Получение информации
сводится к чтению одной структуры данных и обработке списка разделов.
Впро-

Разделы BSD

119

чем, некоторые проблемы могут возникнуть с доступом к разделам.
Например, в системе с альтернативной загрузкой аналитик должен знать,
обладал ли пользователь доступом к разделу Windows и/или к разделу BSD.
В FreeBSD этот вопрос решается не так, как в OpenBSD и NetBSD. Мы
разберемся, как каждая из этих систем использует данные в разметке
диска, хотя эта тема может быть отнесена к анализу уровня приложений.

FreeBSD

FreeBSD предоставляет пользователю доступ ко всем разделам DOS и BSD на
диске. В терминологии FreeBSD разделы DOS называются сегментами (slice),
а разделы BSD называются просто разделами. Следовательно, если в системе
установлены Windows и FreeBSD, при работе с FreeBSD пользователь будет
иметь доступ сегментам Windows.

Структура разметки диска в FreeBSD используется для организации секторов
только в пределах раздела DOS, содержащего разделы FreeBSD. На первый
взгляд это кажется очевидным, но в действительности это одно из
принципиальных различий между реализациями OpenBSD и FreeBSD. На рис.
6.2 разметка диска описывает три раздела, находящиеся в разделе DOS с
типом раздела FreeBSD, но для описания раздела с типом NTFS она не
нужна.

Разделы DOS

NTFS

FreeBSD

Разделы BSD

Сегмент 1 /dev/ad0s1

Сегмент 2 /dev/ad0s2

: /

/ \

Раздел а /dev/ad0s2a

Раздел d /dev/ad0s2d

Раздел е /dev/ad0s2e

Рис. 6.2. Диск FreeBSD с именами устройств

FreeBSD, как и прочие разновидности UNIX, связывает с каждым разделом и
сегментом специальный файл устройства. Имя этого файла задается в
соответствии с номером раздела DOS и номером раздела BSD. Первичному
диску АТА присваивается базовое имя /dev/adO. Для каждого сегмента,
также называемого разделом DOS, к базовому имени прибавляется буква «s»
и номер сегмента. Например, первый сегмент обозначается именем
/dev/adOsl, а второй — /dev/ad0s2. На любом сегменте с типом раздела
FreeBSD система ищет структуру разметки диска. Разделам в сегменте
присваиваются буквенные обозначения на основании положения их записей в
таблице разделов разметки диска. Например, если второй раздел DOS
принадлежит FreeBSD, первому разделу BSD будет присвоено имя
/dev/ad0s2a, а второму — /dev/ad0s2b. Также иногда для разделов BSD
создается вторая группа имен устройств, не включающая в себя номера
сегментов. Например, имя /dev/adOa может использоваться как сокращенное
обозначение раздела /dev/ad0s2a (если раздел FreeBSD является вторым
разделом DOS).

Некоторые разделы BSD имеют особый смысл. Раздел «а» обычно выполняет
функции корневого, в нем находится загрузочный код. Раздел «Ь» обычно
содержит область подкачки, раздел «с» обычно представляет весь сегмент,
а начиная с «d», разделы могут содержать произвольную информацию. Я
говорю «обычно»,

PAGE 120

Глава 6. Разделы в серверных системах

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

Итак, система FreeBSD предоставляет доступ ко всем разделам DOS и
разделам FreeBSD. В процессе полного анализа системы эксперт должен
проанализировать каждый раздел DOS и каждый раздел BSD, присутствующий в
разметке диска.

NetBSD и OpenBSD

NetBSD и OpenBSD предоставляют пользователю доступ только к записям,
присутствующим в структуре разметки диска BSD. В отличие от разметки
диска FreeBSD, в OpenBSD и NetBSD эта структура может описывать разделы,
находящиеся в любом месте диска. Иначе говоря, разметка диска может
описывать разделы за пределами того раздела DOS, в котором она
находится. В оставшейся части главы я буду упоминать только OpenBSD, но
в действительности речь идет об обеих системах, OpenBSD и NetBSD. Проект
OpenBSD отделился от NetBSD много лет назад.

После загрузки ядра OpenBSD разделы DOS игнорируются. Система использует
их только для обнаружения начала раздела OpenBSD. Следовательно, если в
системе установлены как Windows, так и OpenBSD, а пользователям
предоставлен доступ к разделу FAT из OpenBSD, то раздел FAT будет
присутствовать как в таблице разделов DOS, так и в разметке диска BSD.
Ситуация показана на рис. 6.3 для разделов DOS, показанных на рис. 6.2.
Однако на этот раз в разметке диска потребуется дополнительная запись
для обращения к разделу DOS с типом NTFS.

і

NTFS OpenBSD

т

Рис. 6.3. Диск FreeBSD с именами устройств

Имена файлов устройств в OpenBSD похожи нате, что используются в
FreeBSD. Первичному устройству АТА назначается базовое имя /dev/wdO.
Понятие «сегментов» отсутствует, а имена разделов BSD обозначаются
буквами. Следовательно, первому разделу BSD присваивается имя /dev/wdOa,
а второму — /dev/wdOb. Как и в FreeBSD, первый раздел обычно является
корневым, а второй предназначается для области подкачки. Третий раздел,
/dev/wdOc в нашем примере, является устройством, представляющим весь
диск. Вспомните, что в FreeBSD третий раздел предназначался только для
одного сегмента, или раздела, DOS.

Подведем итог: система OpenBSD предоставляет доступ только к разделам,
описанным в разметке диска OpenBSD. Анализ системы OpenBSD следует
сосредоточить на разделах, перечисленных в разметке диска.

Структуры данных

PAGE 121

Загрузочный код

Загрузочный код в системе BSD «окружает» структуру разметки диска,
находящуюся в секторе 1 тома. В секторе 0 тома хранится загрузочный код,
выполняемый при обнаружении загрузчиком MBR загрузочного раздела с типом
BSD. Если загрузочный код не помещается в секторе 0, он продолжается в
секторе 2 и может продолжаться до начала данных файловой системы, обычно
в секторе 16.

Структуры данных

В этом разделе описываются структуры данных разметки диска BSD и
приводится пример обработки системных данных в системах FreeBSD и
OpenBSD. Также приводятся примеры результатов некоторых служебных
программ.

Разметка диска

Посмотрим, как устроена структура данных, называемая разметкой диска.
Если этот материал вас не интересует, пропустите его и перейдите к
примерам анализа образов дисков. Я начну с общего описания разметки
диска BSD, а затем перейду к подробностям реализации FreeBSD и OpenBSD.
В табл. 6.1 перечислены поля этой структуры данных. Учтите, что
некоторые поля могут быть не задействованы в определении структуры
диска, но при этом необходимы для выполнения других операций.

Таблица 6.1. Структура данных разметки диска BSD

Диапазон байтов Описание Н еобход и м ость

0-3 Сигнатура (0x82564557) Нет

4-5 Тип диска Нет

6-7 Подтип диска Нет

8-23 Имя типа диска Нет

24-39 Имя идентификатора пакета Нет

40-^3 Размер сектора в байтах Да

44-47 Количество секторов в дорожке Нет

48-51 Количество дорожек в цилиндре Нет

52-55 Количество цилиндров в модуле Нет

56-59 Количество секторов в цилиндре Нет

60-63 Количество секторов в модуле Нет

64-65 Количество свободных секторов в дорожке Нет

66-67 Количество свободных секторов в цилиндре Нет

68-71 Количество альтернативных цилиндров в модуле Нет

72-73 Скорость вращения диска Нет

74-75 Коэффициент чередования секторов Нет

76-77 Сдвиг дорожки Нет

78-79 Сдвиг цилиндра Нет

80-83 Время коммутации головок в микросекундах Нет

продоллсепие &

PAGE 122

Глава 6. Разделы в серверных системах

Таблица 6.1 {продолжение)

Диапазон Описание Необходимость

байтов

84-87 Время позиционирования дорожек в микросекундах Нет

88-91 Флаги Нет

92-111 Специфическая информация о диске Нет

112-131 Зарезервировано Нет

132-135 Сигнатура (0x82564557) Нет

136-137 Контрольная сумма Нет

138-139 Количество разделов Да

140-143 Размер загрузочной области Нет

144-147 Максимальный размер суперблока Нет

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

148-163 Раздел BSD №1 (см. табл. 6.2) Да

164-179 Раздел BSD №2 (см. табл. 6.2) Да

180-195 Раздел BSD №3 (см. табл. 6.2) Да

196-211 Раздел BSD №4 (см. табл. 6.2) Да

212-227 Раздел BSD №5 (см. табл. 6.2) Да

228-243 Раздел BSD №6 (см. табл. 6.2) Да

244-259 Раздел BSD №7 (см. табл. 6.2) Да

260-275 Раздел BSD №8 (см. табл. 6.2) Да

276-291 Раздел BSD №9 (см. табл. 6.2) Да

292-307 Раздел BSD №10 (см. табл. 6.2) Да

308-323 Раздел BSD №11 (см. табл. 6.2) Да

324-339 Раздел BSD №12 (см. табл. 6.2) Да

340-355 Раздел BSD №13 (см. табл. 6.2) Да

356-371 Раздел BSD №14 (см. табл. 6.2) Да

372-387 Раздел BSD №15 (см. табл. 6.2) Да

388-^03 Раздел BSD №16 (см. табл. 6.2) Да

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

Структура 16-байтовой записи из таблицы разделов BSD приведена в табл.
6.2.

Таблица 6.2. Структура данных разметки диска BSD

Диапазон Описание Необходимость

байтов

0-3 Размер раздела BSD в секторах Да

4-7 Начальный сектор раздела BSD Да

8-11 Размер фрагмента файловой системы Нет

12-12 Тип файловой системы (см. табл. 6.3) Нет

13-13 Количество фрагментов файловой системы в блоке Нет

14-15 Количество цилиндров файловой системы в группе Нет

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

Структуры данных

PAGE 123

Таблица 6.3. Типы разделов BSD

Тип

Описание

О 1 2 3 4 5 6 7 8 9

10 11 12 13 14

Не используется Область подкачки Version 6 Version 7 System V 4.1BSD
Eighth edition

4.2BSD FFS (Fast File System) Файловая система MSDOS (4.4LFS) 4.4BSD LFS
(Log Structured File System)

Используется, но имеет неизвестное или неподдерживаемое содержимое

OS/2 HPFS

CD-ROM (ISO9660)

Загрузчик

Диск vinum

Самой распространенной файловой системой для FreeBSD и OpenBSD является
42BSD FFS (Fast File System). Для этой системы также создается минимум
один раздел подкачки. Раздел NTFS обычно имеет тип «используется, но
имеет неизвестное содержимое».

Теперь рассмотрим пример системы, в которой установлены как FreeBSD, так
и OpenBSD. Содержимое таблицы разделов DOS выглядит так:

# mmls -t dos bsd-disk.dd Units are in 512-byte sectors

00 01 02 03 04

Slot

00:00 00:01 00:02

Start

0000000000 0000000001 0000000063 0002056320 0008209215

End

0000000000 0000000062 0002056319 0008209214 0019999727

Length

0000000001

0000000062

0002056257

0006152895

0011790513

Description Primary Table (#0) Unallocated Win95 FAT32 (OxOB) OpenBSD
(0xA6) FreeBSD (0xA5)

Мы видим, что диск содержит раздел FAT (1 Гбайт), раздел OpenBSD (3
Гбайт) и раздел FreeBSD (6 Гбайт). В каждом из разделов OpenBSD и
FreeBSD находится структура разметки диска с описанием дополнительных
разделов. Далее будут описаны два раздела BSD.

Пример образа OpenBSD

Начнем с обработки разметки диска OpenBSD. Раздел начинается в секторе 2
056 320, и разметка диска находится во втором секторе:

# dd if=bsd-disk.dd skip=2056321 bs=512 count=l | xxd

0000000: 5745 5682 0500 0000 4553 4449 2f49 4445 WEB…..ESDI/IDE

0000016: 2064 6973 6b00 0000 4d61 7874 6f72 2039 disk.Maxtor 9

0000032: 3130 3234 4434 2020 0002 0000 3f00 0000 1024D4 ….?…

0000048: 1000 0000 ff3f 0000 f003 0000 f02b 3101 …..?…….+1.

0000064: 0000 0000 0000 0000 lOOe 0100 0000 0000 …………….

[… НУЛИ ]

PAGE 124

Глава 6. Разделы в серверных системах

0000128 0000 0000 5745 5682 Ь65е 1000 0020 0000

0000144 0000 0100 501f 0300 8060 lfOO 0004 0000

0000160 0708 1000 е061 0900 d07f 2200 0004 0000

0000176 0108 1000 f02b 3101 0000 0000 0000 0000

0000192 0000 0000 501f 0300 bOel 2b00 0004 0000

0000208 0708 1000 8056 0200 0001 2f00 0004 0000

0000224 0708 1000 0000 0000 0000 0000 0000 0000

0000240 0000 0000 3f4b ЗсОО 00f8 4000 0004 0000

0000256 0708 1000 80a0 OfOO 8057 3100 0004 0000

0000272 0708 1000 4160 lfOO 3f00 0000 0000 0000

0000288 0800 0000 9dae ьзоо 3f43 7d00 0000 0000

0000304 ОаОО 0000 0000 0000 0000 0000 0000 0000

0000320 0000 0000 0000 0000 0000 0000 0000 0000

0000336 0000 0000 0000 0000 0000 0000 0000 0000

0000352 0000 0000 0000 0000 0000 0000 0000 0000

0000368 0000 0000 0000 0000 0000 0000 0000 0000

0000384 0000 0000 0000 0000 0000 0000 0000 0000

0000400 С..] 0000 0000 0000 0000 0000 0000 0000 0000

.WEV. .P. . . . .a.. . .+1.

.?K<. . .wl. bsd bsd. dos page ffs fat. fat freebsd dos. openbsd openbsd. m mis mmls bsd-disk.dd disk label units are in sectors slot start end length description unused msdos swap unknown mm is dd if="bsd-disk.dd" skip="8209216" bs="512" count="l" xxd wev.....ad0s3... ................ ............ f003 f02b .....m...... looe b9ab ....wev......... ........ a073 .....s.. dfb6 a400 .....u.......... ...o............ eboe f60f ......btx....... fa31 c08e dobc ...1.......... oole b900 f3ab fj.f......9w.._. e296 ac98 ldac b608 dleb s....u..u..... ffs. freebsd. the sleuth kit. unallocated microsoft windows unix ntfs ntfs. sun solaris microsystems solaris. efi sparc i386. i386 home usr var devices cwtxdysz cwdysz w x id y a z scsi ufs s sparc: ascii vtoc cachefs solans lba. maxtor yl alt h d sec deee ...... ooof b06b .k.......v.... cdod bdd5 dabe lffe>a….

На платформе Sparc используется обратный порядок байтов, поэтому числа
переставлять не нужно. В первых восьми строках содержится 128-байтовая
метка в кодировке ASCII, описывающая тип жесткого диска. Таблица VTOC
начинается с позиции 128; байты 140-141 показывают, что структура
содержит 8 разделов. В байтах 142-173 перечислены типы (2 байта) и флаги
(2 байта) для каждого раздела. Так, тип первого раздела содержится в
байтах 142-143, и значение поля равно 2, что соответствует разделу /.
Флаги хранятся в байтах 144-145, значение поля равно 0. Байты 146-147
показывают, что второй раздел относится к типу 3 (область подкачки), а
поле флагов в байтах 148-149 равно 1 (раздел не монтируется).

В байтах 436-437 приводится количество головок 15 (OxOf), а в байтах
438-439 — количество секторов на дорожку 63 (0x3f). Эти данные
понадобятся для преобразования адресов цилиндров.

Карта диска начинается с байта 444; начальный цилиндр и размер задаются
4-байтовыми числами. У первого раздела начальный цилиндр равен 2 086
(0x00000826), а размер — 2 142 315 (0x0020b06b). Вспомните, что разделу
назначен тип /. Начальный сектор вычисляется по следующей формуле: 15 *
63 * 2 086 – 1 971 270

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

PAGE 134

Глава 6. Разделы в серверных системах

Описание следующего раздела хранится в байтах 452-459, с начальным
цилиндром 0 и размером 1 048 950 (0x00100176). Это пространство
подкачки, соответствующее «сегменту 1». Третья запись таблицы разделов,
«сегмент 2», обычно представляет весь диск и находится в байтах 460-467.
В нашем примере ее начальный цилиндр равен 0, а размер составляет 10 257
030 секторов.

Существует несколько программ, позволяющих просмотреть содержимое
разметки диска Sparc, но не все они могут использоваться в процессе
экспертизы. Команды Solaris format и prvtoc работают только с
устройствами, но не с файлами образов устройств. С другой стороны,
команда Linux fdisk успешно работает с образами дисков Sparc. Также
можно запустить программу m mis из пакета The Sleuth Kit с параметром -t
sun. Для образа диска из рассматриваемого примера программа m m Is
выдала следующий результат:

# mmls -t sun spare-disk.dd Sun VT0C

Units are in 512-byte sectors

Slot Start End Length Description

00 01 0000000000 0001048949 0001048950 swap (0x03)

01 02 0000000000 0010257029 0010257030 backup (0x05)

02 07 0001050840 0001460024 0000409185 /home/ (0x08)

03 05 0001460025 0001971269 0000511245 /var/ (0x07)

04 00 0001971270 0004113584 0002142315 / (0x02)

05 06 0004113585 0010257029 0006143445 /usrV (0x04)

Структуры данных П386

Перед установкой Solaris в системе i386 необходимо предварительно
создать один или несколько разделов DOS. В типичной установке создается
загрузочный раздел (тип раздела DOS ОхВЕ) и раздел с файловыми системами
(тип раздела DOS 0x82). Загрузочный раздел содержит загрузочный код,
необходимый для запуска системы, и файловая система как таковая в нем
отсутствует. Структура разметки диска находится во втором секторе
раздела файловой системы DOS (тип 0x82) и описывает строение разделов
Sun внутри раздела DOS. Все разделы Sun должны начинаться за началом
раздела DOS. На рис. 6.6 показан диск с тремя разделами DOS; последний
раздел содержит разметку диска и три раздела Sun.

Структура разметки диска занимает 512 байт, и работать с ней удобнее,
чем со Sparc-версией, потому что вся информация о разделах хранится в
одном месте. Другое преимущество 1386-версии состоит в том, что при
хранении информации используется адресация LBA (а не CHS). Помимо этих
различий, две структуры очень похожи. Первые 456 байтов разметки диска
называются оглавлением тома, или VTOC (Volume Table Of Contents); здесь
хранится информация о разделах, их количестве, размере сектора и т. д.
Структура данных разметки диска приведена в табл. 6.14.

Таблица 6.14. Структура данных разметки диска Sun І386

Диапазон байтов Описание Необходимость

0-11 Загрузочная информация Нет

12-15 Сигнатура (0x600DDEEE) Нет

16-19 Версия Нет

Сегменты Sun Solaris

PAGE 135

Диапазон байтов Описание Необходимость

20-27 Имя тома Нет

28-29 Размер сектора Да

30-31 Количество разделов Да

32-71 Зарезервировано Нет

72-83 Раздел 1 (см. табл. 6.15) Да

84-95 Раздел 2 (см. табл. 6.15) Да

96-107 Раздел 3 (см. табл. 6.15) Да

108-119 Раздел 4 (см. табл. 6.15) Да

120-131 Раздел 5 (см. табл. 6.15) Да

132-143 Раздел 6 (см. табл. 6.15) Да

144-155 Раздел 7 (см. табл. 6.15) Да

156-167 Раздел 8 (см. табл. 6.15) Да

168-179 Раздел 9 (см. табл. 6.15) Да

180-191 Раздел 10 (см. табл. 6.15) Да

192-203 Раздел 11 (см. табл. 6.15) Да

204-215 Раздел 12 (см. табл. 6.15) Да

216-227 Раздел 13 (см. табл. 6.15) Да

228-239 Раздел 14 (см. табл. 6.15) Да

240-251 Раздел 15 (см. табл. 6.15) Да

252—263 Раздел 16 (см. табл. 6.15) Да

264-327 Временные штампы (не используется) Нет

328-^55 Метка тома Нет

456-507 Сведения об оборудовании Нет

508-509 Сигнатура (ОхРАВЕ) Нет

510-511 Контрольная сумма Нет

t

Таблица разделов DOS

Раздел FAT

Раздел файловой системы Solaris

Раздел 1

Раздел 2

Раздел 3

/

Разметка диска

Рис. 6.6. Диск i386 Sun с тремя разделами DOS. Последний раздел содержит
разметку диска и три раздела Sun

Каждая из 16 записей разделов имеет структуру, показанную в табл. 6.15.

PAGE 136

Глава 6. Разделы в серверных системах

Таблица 6.15. Структура записи раздела в разметке диска Sun І386

Диапазон байтов Описание Необходимость

0-1 Тип раздела (см. табл. 6.11) Нет

2-3 Флаг (см. табл. 6.12) Нет

4-7 Начальный сектор Да

8-11 Размер в секторах Да

В полях типа и флагов используются те же значения, которые приводились
ранее для структур данных Sparc. Для идентификации разделов в Solaris на
платформе І386 необходимо проанализировать записи разделов VTOC и
определить их структуру по начальному сектору и размеру. Начальный
сектор задается по отношению к разделу DOS (с типом 0x82). В нашем
примере раздел DOS с разметкой диска начинается с сектора 22 496.
Следовательно, разметка диска находится в секторе 22 497:

# dd if=1386-disk.dd bs=512 skip=22497 | xxd

0000000: 0000 0000 0000 0000 0000 0000 eede 0d60 ……………1

0000016: 0100 0000 0000 0000 0000 0000 0002 1000 …………….

0000032: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

0000048: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

0000064: 0000 0000 0000 0000 0200 0000 cOOe 1000 …………….

0000080: 0082 3e00 0300 0100 dOOb 0000 f002 1000 ..>………….

0000096: 0500 0000 0000 0000 309a 7001 0000 0000 ……..0.p…..

0000112: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

0000128: 0000 0000 0400 0000 c090 4e00 2000 faOO ……….N. …

0000144: 0000 0000 0000 0000 0000 0000 0800 0000 …………….

0000160: e090 4801 0041 lfOO 0100 0100 0000 0000 ..H..A……….

0000176: f003 0000 0900 0100 f003 0000 e007 0000 …………….

[… НУЛИ]

0000320: 0000 0000 0000 0000 4445 4641 554c 5420 ……..DEFAULT

0000336: 6379 6c20 3233 3936 3420 616c 7420 3220 cyl 23964 alt 2 […
НУЛИ]

0000448: 0000 0000 0000 0000 0000 0000 0000 0000 ………]…]..

0000464: 0200 0000 1000 0000 3f00 0000 0100 0000 ……..?…….

0000480: 0000 100e 0000 0000 0000 0000 0000 0000 …………….

0000496: 0000 100e 0000 0000 0000 0000 beda a24a ……………]

Данные получены в системе i386, в которой используется прямой порядок
байтов. По значению со смещением 30 мы видим, что таблица содержит 16
разделов (0x10). Первая запись раздела начинается со смещением 72 и
заканчивается со смещением 83. Байты 72-73 показывают, что запись имеет
тип 0x02, то есть представляет корневой раздел. Начальный сектор в
байтах 76-79 равен 1 052 352 (ОхООЮОЕСО). Байты 80-83 указывают размер
раздела; мы видим, что он равен 4 096 512 (0х003е8200). В данной
разметке используются 10 разделов, описание последнего находится в
байтах 180-191. Все временные штампы равны нулю, а имя тома состоит из
слова DEFAULT и параметров геометрии диска.

Для получения информации о местонахождении загрузочного раздела и
разделов файловых систем из образа диска i386 молено воспользоваться
любой программой, работающей с разделами DOS. При запуске mmls для диска
Solaris на платформе i386 был получен следующий результат:

# mmls -t dos i386-disk.dd DOS Partition Table

Сегменты Sun Solaris

PAGE 137

Units are in 512-byte sectors Slot Start End

00 01 02 03 04

00:00

00:01

0000000000 0000000001 0000001008 0000022176 0000022496

0000000000 0000001007 0000021168 0000000320 0024180911

Length Description

0000000001 Primary Table (#0)

0000001007 Unallocated

0000021168 Solaris 8 Boot (OxBE)

0000000320 Unallocated

0024158416 Linux swap / Solaris x86 (0x82)

Напомню, что раздел типа OxBE предназначен для загрузочного кода,
файловая система в нем отсутствует. Файловые системы и структуры
разметки диска хранятся в разделах типа 0x82. Ту же информацию можно
получить, запустив утилиту fdisk в Linux, но fdisk не включает разделы
Solaris в разметку диска. Чтобы просмотреть содержимое файловой системы,
либо извлеките раздел, начиная с сектора 22 496, либо просто вызовите m
mis и укажите смещение с параметром -о:

# mmls -t sun -о 22496 disk8.dd Sun VTOC

Units are in 512-byte sectors

Slot Start End Length Description

00 02 0000000000 0024156719 0024156720 backup (0x05)

01 08 0000000000 0000001007 0000001008 boot (0x01)

02 09 0000001008 0000003023 0000002016 alt sector (0x09)

03 01 0000003024 0001052351 0001049328 swap (0x03)

04 00 0001052352 0005148863 0004096512 / (0x02)

05 05 0005148864 0021532895 0016384032 /usr/ (0x04)

06 07 0021532896 0023581151 0002048256 /home/ (0x08)

Как говорилось ранее, адреса задаются по отношению к началу раздела DOS,
поэтому при извлечении данных программой dd необходимо увеличивать
адреса всех начальных секторов на 22 496. Эксперименты показали, что при
загрузке Linux с диском Solaris i386, подключенным как один из ведомых
(slave) дисков, Linux создает устройства только для первых восьми
разделов Solaris. Для всех последующих разделов устройства не создаются.

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

При анализе разделов Solaris действуют те же особые соображения, что и
при анализе других систем разделов. Структура разметки диска содержит
неиспользуемые поля, в которых могут находиться скрытые данные (хотя
объем этого скрытого пространства невелик).

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

Если местонахождение разметки диска неизвестно, попробуйте провести
поиск по сигнатурам. Сигнатура 0x600DDEEE находится внутри разметки
диска, а сигнатура OxDABE хранится в байтах 508-509.

Итоги

Системы Solaris часто встречаются в корпоративных сетях и часто
становятся объектом экспертного анализа при попытках взлома и
мошенничества. В этой

PAGE 138

Глава 6. Разделы в серверных системах

части книги было показано, как организованы диски Solaris и как вывести
или извлечь соответствующую служебную информацию. Структура разметки
диска относительно проста, а для ее чтения можно воспользоваться
программами fdisk и mmls.

Разделы GPT

Системы с 64-разрядными процессорами Intel Itanium (IA64), в отличие от
систем IA32, не имеют BIOS. Вместо этого в них используется интерфейс
EFI (Extensible Firmware Interface). EFI ( HYPERLINK
“http://www.intel.com/technology/efi”
http://www.intel.com/technology/efi ) работает не только на платформе
Intel, но и на других платформах — например, в системах Sun Sparc. В EFI
применяется система разделов GPT(GUID Partition Table), поддерживающая
до 128 разделов с 64-разрядной адресацией LBA. На случай сбоя в системе
хранятся резервные копии важных структур данных. На момент написания
книги диски GPT применялись на мощных серверах и практически не
встречались в типичных настольных системах.

Общий обзор

Диск GPT состоит из пяти основных областей (рис. 6.7). Первая — защитная
область MBR — начинается в первом секторе диска и содержит таблицу
разделов DOS с единственной записью. Запись представляет раздел типа
ОхЕЕ, распространяющийся на весь диск. Этот раздел существует для того,
чтобы старые компьютеры распознавали диск как используемый и не пытались
форматировать его. В действительности EFI не использует разделы в
традиционном смысле.

Защитная Заголовок Таблица Область Резервная

область MBR GPT разделов раздела область

м / і_і

Рис. 6.7. Диск GPT состоит из пяти областей

Вторая область диска GPT начинается с сектора 1 и содержит заголовок
GPT. Заголовок определяет размер и местонахождение таблицы разделов,
которое фиксируется при создании диска GPT. В системе Windows количество
разделов в таблице ограничивается 128 [Microsoft, 2004]. Заголовок также
содержит контрольную сумму заголовка и таблицы разделов, что позволяет
обнаруживать ошибки и посторонние изменения.

Третья область содержит таблицу разделов. Каждая запись таблицы содержит
начальный и конечный адреса, код типа, имя, флаги атрибутов и значение
GUID. 128-разрядный код GUID является уникальным для данной системы и
задается при создании таблицы разделов.

Четвертая область диска — область раздела. Она занимает наибольшее
дисковое пространство и содержит секторы, распределяемые по разделам.
Начальный и конечный секторы этой области определяются в заголовке GPT.
В последней

Разделы GPT

PAGE 139

области диска хранятся резервные копии заголовка GPT и таблицы разделов.
Резервная область хранится в секторе, следующем за областью раздела.

Структуры данных

В первой области диска GPT используется стандартная таблица разделов
DOS, уже рассматривавшаяся ранее. Диск GPT с таблицей разделов DOS
содержит единственную запись раздела, занимающего весь диск. Пример:

# mmls -t dos gpt-disk.dd

DOS Partition Table

Units are in 512-byte sectors

Slot Start End Length Description

00: —– 0000000000 0000000000 0000000001 Primary Table (#0)

01: 00:00 0000000001 0120103199 0120103199 GPT Safety
Partition (OxEE)

После таблицы разделов DOS следует сектор 1 с заголовком GPT,
описывающим строение диска. Структура данных заголовка представлена в
табл. 6.16.

Таблица 6.16. Структура данных заголовка GPT

Диапазон байтов Описание Необходимость

0-7 Сигнатура («EFI PART») Нет

8-11 Версия Да

12-15 Размер заголовка GPT в байтах Да

16-19 Контрольная сумма заголовка GPT (CRC32) Нет

20-23 Зарезервировано Нет

24-31 Адрес LBA текущей структуры заголовка GPT Нет

32-39 Адрес LBA другой структуры заголовка GPT Нет

40-^7 Адрес LBA начала области раздела Да

48-55 Адрес LBA конца области раздела Нет

56-71 Код GUID диска Нет

72-79 Адрес LBA начала таблицы разделов Да

80-83 Количество записей в таблице разделов Да

84-87 Размер каждой записи в таблице разделов Да

88-91 Контрольная сумма таблицы разделов (CRC32) Нет

92-конец сектора Зарезервировано Нет

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

Заголовок ЄРТ для образа диска выглядит так: # dd і т=др1 HYPERLINK
“http://-disk.de” -disk.de ! Ьб=512 Бкір=1 соип1;=1 | xxd

0000000 0000016 0000032 0000048 0000064 0000080 0000096 […] 4546 4920
5041 5254 0000 0100 5с00 0000 8061 аЗЬО 0000 0000 0100 0000 0000 0000
lfal 2807 0000 0000 2200 0000 0000 0000 feaO 2807 0000 0000 7е5е 4dal
1102 5049 ab2a 79a6 Зеаб 3859 0200 0000 0000 0000 8000 0000 8000 0000
69а5 7180 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

EFI PART, а.

8Y.

.l.q

PI

PAGE 140

Глава 6. Разделы в серверных системах

Первые 8 байт содержат сигнатуру. Байты 12-15 показывают, что размер
заголовка GPT составляет 96 байт (0x5с). Согласно байтам 32-39,
резервная копия заголовка хранится в секторе 120 103 199 (0x0728alaf).
Обратите внимание: этот же сектор был указан в качестве последнего
сектора защитного раздела DOS. Байты 40-47 показывают, что область
раздела начинается с сектора 34 (0x22) и завершается в секторе 120 103
166 (0x0728a0fe). Из байтов 72-79 мы узнаем, что таблица разделов
начинается с сектора 2, а из байтов 80-83 — что таблица содержит 128
(0x80) записей. Байты 84-87 показывают, что размер каждой записи
составляет 128 (0x80) байт; это означает, что для хранения таблицы
потребуются 32 сектора.

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

Таблица 6-17. Структура данных записей таблицы разделов GPT

Диапазон байтов Описание Необходимость

0-15 Код Сию типа раздела Нет

16-31 Уникальный код С11Ю раздела Нет

32-39 Начальный адрес 1ВА раздела Да

4СМ7 Конечный адрес 1ВА раздела Да

48-55 Атрибуты раздела Нет

56-127 Имя раздела в Юникоде Нет

128-разрядное поле типа идентифицирует содержимое раздела. В дисках GPT
разделы используются для хранения как системной информации, так и
файловых систем. Например, каждый компьютер с EFI должен содержать
системный раздел EFI с файлами, необходимыми для инициализации
аппаратной и программной части системы. Значения типов назначаются
фирмами-производителями; к сожалению, централизованного списка в
настоящее время не существует. В спецификации Intel определены типы
разделов, перечисленные в табл. 6.18.

Таблица 6.18. Типы разделов GPT, определенные в спецификации Intel

GUID Описание

00000000-0000-0000-0000-0000000000 Свободная запись

C12A7328-F81F-11D2-BA4B-00A0C93EC93B Системный раздел EFI

024DEE41-33E7-lld3-9D69-0008C781F39F Раздел с таблицей разделов DOS

Компания Microsoft также определила некоторые значения типов,
используемые в ее продуктах (табл. 6.19).

Таблица 6.19. Типы разделов GPT, определенные в спецификации Microsoft
GUID Описание

E3C9E316-05BC-4DB8-817D-f92DF00215AE Зарезервированный раздел
Microsoft (MRP) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 Первичный
раздел (базовый диск) 5808C8AA-7E8F-42E0-85D2-E1E90434CFB3 Раздел
метаданных LDM (динамический диск) AF9B60A0-1431-4F62-BC68-3311714A69AD
Раздел данных LDM (динамический диск)

Разделы GPT

PAGE 141

В системе Windows зарезервированный раздел используется для хранения
временных файлов и данных. Первичный раздел содержит файловую систему.
Первичные разделы схожи с первичными разделами, которые мы видели при
изучении разделов DOS. Раздел метаданных LDB и раздел данных LDM
используются в динамических дисках Microsoft, о которых речь пойдет в
следующей главе. Динамические диски предназначены для объединения
содержимого нескольких дисков в один том.

64-разрядное поле атрибутов разделено на три части. Установка младшего
бита означает, что функционирование системы невозможно без этого
раздела. На основании этого бита система проверяет, можно ли удалить
раздел. Значения битов 1-47 не определены, а биты 48-63 могут содержать
произвольную информацию для раздела данного типа. Каждый тип разделов
использует эти значения по своему усмотрению.

Приведу содержимое записи таблицы разделов в простейшей системе:

# dd if=gpt-disk.dd bs=512 skip=341 dd bs=128 skip=3 count=l | xxd

0000000 0000016 0000032 0000048 0000064 16e3 c9e3 5c0b b84d 817d f92d
f002 15ae 2640 69eb 2f99 1942 afcO d673 7c0b 8ae4 2200 0000 0000 0000
0080 ЗеОО 0000 0000 0000 0000 0000 0000 0000 ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff

В верхней строке (байты 0-15) мы видим код GUID типа раздела, а во
второй (байты 16-31) — код GUID самого раздела. Начальный адрес раздела
хранится в байтах 32-39; раздел начинается с сектора 32 (0x0022).
Конечный адрес раздела задается байтами 40-47 и равен 4 096 ООО
(0х003Е8000).

Пример выполнения mmls:

# mmls -t gpt gpt-disk.dd

GUID Partition Table

Units are in 512-byte sectors

Slot

00 01

Start End Length Description

0000000000 0000000000 0000000001 Safety table

0000000001 0000000001 0000000001 GPT Header

0000000002 0000000033 0000000032 Partition Table 0000000034 0004096000
0004095967

0004096001 0012288000 0008192000

В конце диска находятся резервные копии заголовка GPT и таблицы
разделов. Они следуют в обратном порядке: заголовок GPT хранится в
последнем секторе, а таблица разделов — в предыдущем. В нашем примере
резервный заголовок GPT находится в секторе 120 103 199.

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

На момент написания книги диски GPT встречались крайне редко, и в
документации большинства системных программ ничего не говорится о
поддержке GPT. Linux позволяет разбить диск GPT на разделы для
последующего применения других программ анализа файловой системы. Пакет
The Sleuth Kit тоже поддерживает разделы GPT.

Резервная копия таблицы разделов в дисках GPT упрощает восстановление
системы в случае повреждения исходной таблицы. Неиспользуемые байты

PAGE 142

Глава 6. Разделы в серверных системах

сектора 0, сектора 1 и всех свободных записей в таблице разделов могут
использоваться для хранения скрытых данных.

Итоги

На момент написания книги разделы GPT довольно редко встречались при
проведении расследований и не поддерживались многими средствами
экспертного анализа. Несомненно, в будущем, с переходом многих систем на
64-разрядную базу, ситуация изменится. Разделы GPT существенно
превосходят разделы DOS по гибкости и простоте.

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

• FreeBSD Documentation Project. «FreeBSD Handbooks 2005. HYPERLINK
“http://www.freebsd.org” http://www.freebsd.org .

• Holland, Nick, ed. «OpenBSD Installation Guide». January 2005.
HYPERLINK “http://www.open-” http://www.open- HYPERLINK
“http://bsd.org/faq/faq4.html” bsd.org/faq/faq4.html .

• Intel. Extensible Firmware Interface, Version 1.10, December 1, 2002.
HYPERLINK “http://deve-” http://deve- HYPERLINK
“http://loper.intel.com/technolo” loper.intel.com/technolo gy/efi/.

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

• Marshall Kirk McKusick, George V. Nevile-Neil. The Design and
Implementation of the BSD Operating System. Boston: Addison Wesley,
2005.

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

• Microsoft. «Disk Sectors on GPT Disks». Windows XP Professional
Resource Kit Documentation, 2004. HYPERLINK
“http://www.microsoft.com/resources/documentation/Windows/”
http://www.microsoft.com/resources/documentation/Windows/
XP/alL/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/
aLL/reskit/ en-us/prkd_tro_zkfe.asp.

• Sun. «Solaris 9 System Administration Guide: Basic Administration.
Chapter 31». May 2002. HYPERLINK “http://docs.sun” http://docs.sun
.com/db/doc/806-4073/6jd67r9fn?a=view.

• Sun. «System Administration Guide. Chapter 32: Managing Disks». April
2003. HYPERLINK
“http://docsun.cites.uiuc.edU/sun-docs/C/solaris_9/SUNWaadm/SYSADVl/pll7
.htmL”
http://docsun.cites.uiuc.edU/sun-docs/C/solaris_9/SUNWaadm/SYSADVl/pll7.
htmL

• Winsor, Janice. Solaris System Administrator’s Guide. 3rd edition.
Palo Alto: Sun Microsystems Press, 2000.

Многодисковые тома

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

RAID

Сокращение RAID происходит от слов «Redundant Arrays of Inexpensive
Disks» («Массив недорогих дисковых накопителей с избыточностью»).
Технологии RAID обычно применяются в высокопроизводительных или особо
важных системах. Концепция RAID впервые была предложена в конце 1980-х
годов с целью использования недорогих дисков для достижения показателей
быстродействия и емкости, присущих дорогим высокопроизводительным дискам
[Patterson, et al., 1988]. Основной принцип RAID —использование
нескольких дисков вместо одного для создания избыточности и ускорения
работы с диском. Аппаратный контроллер или программный драйвер
осуществляют логическое объединение дисков, и компьютер видит один
большой том.

Прежде системы RAID использовались только в высокопроизводительных
серверах, но сейчас они все чаще встречаются в настольных системах. Так,
системы Microsoft Windows NT, 2000 и ХР позволяют реализовать некоторые
уровни RAID. Мы начнем с описания технологии, задействованной в работе с
системами RAID, а затем перейдем к вопросам снятия и анализа данных в
системах RAID. При создании разделов в томах RAID могут использоваться
любые методы, представленные в главах 5 и 6.

Уровни RAID

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

PAGE 144

Глава 7. Многодисковые тома

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

Тома RAID уровня 0 объединяют два или более диска, с чередованием
(striping) блочных данных по дискам. При чередовании данных смежные
блоки тома RAID отображаются на блоки, находящиеся на разных дисках.
Например, при двух дисках блок 0 массива RAID соответствует блоку 0 на
диске 1, блок 1 — блоку 0 на диске 2, блок 2 — блоку 1 на диске 1, блок
3 — блоку 1 на диске 2. Так, на рис. 7.1 блоки данных помечены
обозначениями DO, Dl, D2 и т. д. Этот уровень RAID используется в
системах исключительно по соображениям производительности; избыточность
в нем отсутствует, потому что данные хранятся в единственном экземпляре.

RAID О

RAID 1

DO

D1

DO

DO

D2

D3

D1

D1

D4

D5

D2

D2

Диск 1

Диск 2

Диск 1

Диск 2

Рис. 7.1. Том RAID уровня 0 с двумя дисками и чередованием данных и том
RAID уровня 1 с двумя дисками и зеркальным копированием данных

В томах RAID уровня 1 используются два и более диска с зеркальным
копированием данных. Данные, записываемые на один диск, автоматически
дублируются на другом диске; таким образом, оба диска содержат
одинаковые данные. Их содержимое может различаться в секторах, не
задействованных в массиве RAID. В случае сбоя другой диск может
использоваться для восстановления данных. Например, если том RAID уровня
1 содержит два диска, то блок 0 тома RAID соответствует блоку 0 на
дисках 1 и 2, блок 1 тома RAID — блоку 1 на дисках 1 и 2, и т. д. Том
RAID уровня 1 также показан на рис. 7.1.

Тома RAID уровня 2 встречаются редко. В них коды с исправлением ошибок
применяются для восстановления неверных данных, прочитанных с диска.
Данные чередуются по нескольким дискам фрагментами битового уровня, а
дополнительные диски содержат контрольные данные для исправления ошибок.

Тома RAID уровня 3 состоят минимум из трех дисков, один из которых
выделяется для хранения данных контроля четности. Последний используется
для выявления ошибок на двух других дисках и для восстановления
содержимого в случае сбоев. Простой, хотя и неэффективный пример
контроля четности — традиционное сложение. Если имеется два числа, 3 и
4, в сумме они дают 7. Если в какой-то момент сумма окажется отличной от
7, значит, на диске возникла ошибка. Если одно из значений будет
потеряно, его можно будет восстановить, вычтя оставшееся значение из 7.

В массивах RAID уровня 3 данные делятся на байтовые фрагменты и
распределяются (чередуются) по дискам данных. Диск контроля четности
содержит инфор

RAID

PAGE 145

мацию, необходимую для восстановления данных в случае сбоя одного из
дисков. Уровень 3 отчасти напоминает уровень 0, но чередуемые данные
имеют гораздо меньший размер (байты вместо блоков), и в массиве имеется
выделенный диск контроля четности. Пример массива с двумя дисками данных
и одним диском контроля четности показан на рис. 7.2.

RA D3

DO

D1

РО

D2

D3

Р1

D4

D5

Р2

Диск

Диск

Диск

данных 1 данных 2 контроля четности Рис. 7.2. Том RAID уровня 3
с двумя дисками данных и одним диском контроля четности

Распространенный метод вычисления данных четности основан на операции
«исключающего ИЛИ» (XOR). Оператор XOR получает два однобитовых операнда
и генерирует однобитовый результат по правилам, представленным в табл.
7.1. Результат применения XOR к двум значениям, длина которых превышает
один бит, вычисляется независимым применением XOR к каждой паре битов.

Таблица 7.1. Правила вычисления операции XOR

Операнд 1 Операнд 2 Результат

0 0 0

0 1 1

1 0 1

1 1 0

Оператор XOR удобен тем, что если вам известны два из трех значений,
участвующих в операции, по ним можно определить третье значение.
Допустим, имеется три диска данных и один диск контроля четности. Диски
данных содержат числа 1011 0010, 1100 1111 и 1000 0001. Контрольная
сумма этих чисел вычисляется следующим образом:

(1011 0010 X0R 1100 1111) X0R 1000 0001 (0111 1101) X0R 1000 0001 1111
1100

Байт 1111 1100 записывается на диск контроля четности. Если на втором
диске произойдет сбой, хранившийся на нем байт легко восстанавливается:

1111 1100 X0R (1011 0010 X0R 1000 0001) 1111 1100 X0R (ООП ООП) 1100
1111

Тома RAID уровня 4 сходны с уровнем 3, но распределение данных в них
осуществляется по блокам, а не по байтам. На уровне 4 используются два и
более

PAGE 146

Глава 7. Многодисковые тома

диска данных и выделенный диск контроля четности, поэтому его
архитектура не отличается от показанной на рис. 7.2.

Тома RAID уровня 5 сходны с уровнем 4, однако на уровне 5 нет
выделенного диска контроля четности. Все диски поочередно содержат
данные и информацию контроля четности. Например, при трех дисках блок 0
тома RAID соответствует блоку 0 диска 1, блок 1 тома RAID — блоку 0
диска 2, а соответствующий блок контроля четности хранится в блоке 0
диска 3. Следующий блок контроля четности соответствует блоку 1 диска 2,
и в нем содержится результат выполнения операции XOR с блоками 1 дисков
1 и 3. Схема работы томов RAID уровня 5 показана на рис. 7.3.

RAID 5

DO

D1

РО

D2

Р1

D3

Р2

D4

D5

Диск 1

Диск 2

ДискЗ

Рис. 7.3. Том RAID уровня 5 с тремя дисками и распределенным контролем
четности

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

Аппаратная реализация RAID

Один из способов создания томов RAID основан на использовании
специального оборудования.

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

Аппаратные реализации RAID делятся на две основные разновидности:
специальные контроллеры, подключаемые к одной из шин, и устройства,
подключаемые к обычному контроллеру диска (с интерфейсом ATA, SCSI или
FireWire). В обоих случаях жесткие диски подключаются к специальному
устройству, а компьютер взаимодействует с томом RAID, а не с обычными
дисками. На рис. 7.4 представлены логические связи между дисками,
контроллером и томом.

При использовании специального контроллера RAID компьютер проверяет
наличие контроллера во время загрузки. Во многих системах IА32 BIOS
контроллера RAID выводит сообщения на экране, а пользователь может
вызвать экран настройки контроллера и дисков. Операционной системе
понадобятся драйверы контроллера RAID. Диски, созданные одним
контроллером, обычно не могут использоваться с другими контроллерами.
При использовании специального устройства, подключаемого между обычным
контроллером дисков и жесткими дисками, драйверы не потребуются.

RAID

PAGE 147

Том RAID

Аппаратный контроллер RAID

Операционная система

а—”* —”—^

Диск Диск Диск

Рис. 7.4. Благодаря аппаратному контроллеру операционная система
воспринимает диски как единое целое

Снятие данных и анализ

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

Загрузочные компакт-диски Linux содержат драйверы разных контроллеров
RAID, так что проверьте свой любимый дистрибутив и составьте список
поддерживаемых контроллеров. Возможно, вам придется создать собственный
диск или заготовить несколько дисков для разных случаев.

Если вы не располагаете необходимыми драйверами контроллера RAID для
снятия данных «на месте», возможно, диски и контроллер придется взять в
лабораторию. Информация о строении отдельных дисков RAID практически
отсутствует, поэтому при объединении дисков без контроллера могут
возникнуть трудности.

Некоторые секторы диска могут быть не задействованы в томе RAID. В
неиспользуемых секторах могут храниться скрытые данные. Таким образом,
снятие содержимого каждого диска (в дополнение к содержимому тома RAID)
является самым надежным, хотя и не всегда самым простым решением. Если
раскладка данных неизвестна, с идентификацией неиспользуемых секторов
диска могут возникнуть проблемы. Если возможен поиск информации по
ключевым словам, проведите поиск не только по тому RAID, но и по
отдельным дискам.

Программная реализация RAID

Также возможна реализация томов RAID на программном уровне.

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

При программной реализации RAID операционная система объединяет
отдельные диски при помощи специальных драйверов. В этом сценарии ОС
«видит»

PAGE 148

Глава 7. Многодисковые тома

отдельные диски, но показывает пользователю только том RAID. Доступ к
отдельным дискам обычно осуществляется при помощи неструктурированных
устройств UNIX или объектов устройств в Microsoft Windows. Многие
современные операционные системы обеспечивают поддержку RAID; к их числу
относятся Microsoft Windows NT, 2000 и Windows ХР; Apple OS X; Linux;
Sun Solaris; HP-UX и IBM AIX. Программная реализация RAID уступает
аппаратной реализации по эффективности, потому что для вычисления битов
четности и распределения данных приходится задействовать центральный
процессор. Логическая схема программной реализации RAID показана на рис.
7.5.

Операционная система

Том RAID

Программная поддержка RAID

Диск

Диск

\–^

Диск

Рис. 7.5. При программной реализации RAID ОС объединяет диски, сохраняя
доступ к каждому отдельному диску

В Windows 2000 и ХР томами RAID управляет диспетчер логических дисков,
или LDM (Logical Disk Manager). Для работы LDM диски должны быть
отформатированы как динамические; такие диски отличаются от дисков с
разделами DOS, представленных ранее в главе 5. LDM может создавать тома
RAID уровней

0 (чередование), 1 (зеркальное копирование) и 5 (чередование с контролем
четности), хотя поддержка RAID версий 1 и 5 доступна только в серверных
версиях Windows. Динамический диск может использоваться для нескольких
томов RAID, но это маловероятно, если система использует RAID по
соображениям быстродействия или избыточности. Вся конфигурационная
информация в томах RAID системы Windows хранится на дисках, а не в
локальной системе. Диспетчер логических дисков более подробно
рассматривается позднее в этой главе, когда речь пойдет об объединении
дисков.

В Linux поддержка RAID обеспечивается драйверами ядра MD (Multiple
Device). Диски в массивах RAID системы Linux не требуют специального
форматирования и могут содержать обычные разделы DOS. Описание
конфигурации хранится в локальной системе в конфигурационном файле (по
умолчанию /etc/raidtab). Полученному тому RAID назначается новое
устройство, и он может монтироваться как обычный диск. Драйвер MD
поддерживает RAID уровней 0 (чередование),

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

RAID

PAGE 149

Снятие данных и анализ

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

Возможно, при программной реализации RAID вам не понадобится исходное
программное обеспечение для восстановления тома RAID. Например, в Linux
предусмотрена поддержка диспетчера логических дисков Windows (LDM) с
возможностью правильного объединения дисков Windows. Не все версии ядра
Linux поставляются с включенной поддержкой LDM, но ее можно включить при
перекомпиляции ядра. Если вы используете Microsoft Windows для создания
томов RAID, установите аппаратный блокировщик записи для предотвращения
потери данных.

Рассмотрим пример с Windows LDM в Linux. Если загрузить ядро Linux с
поддержкой LDM, в системе создается устройство для каждого раздела RAID.
Вам придется отредактировать файл /etc/raidtab так, чтобы он правильно
описывал конфигурацию RAID и разделы. Например, следующий
конфигурационный файл определяет Windows LDM RAID уровня 0 (чередование)
с двумя разделами (/dev/hdbl и /dev/hddl), с использованием
64-килобайтных блоков:

# cat /etc/raidtab raiddev /dev/mdO

raid-level 0

nr-raid-disks 2

nr-spare-disks 0

persistent-superblock 0

chunk-size 64k

device /dev/hdbl

raid-disk 0

device /dev/hddl

raid-disk 1

В соответствии с этим файлом, устройство /dev/mdO может монтироваться
только для чтения, а для создания его образа можно использовать
программу dd. Процесс использования Linux с Windows LDM более подробно
описан в разделе «Объединение дисков». Аналогичный процесс используется
для реализации программного тома RAID средствами Linux MD в системе
снятия данных. Если скопировать файл raidtab из исходной системы, его
содержимое может быть взято за основу для создания тома RAID в системе,
в которой производится снятие данных.

Программы EnCase (Guidance Software) и ProDiscover (Technology Pathways)
импортируют диски из томов RAID Windows и анализируют их так, как если
бы они были отдельными томами. Такой метод анализа данных лучше работает
в долгосрочной перспективе, потому что он предоставляет доступ к данным,
которые могут быть скрыты на отдельных дисках и будут пропущены, если
ограничиться снятием только одного тома RAID. Впрочем, работа с
программами Linux и другими приложениями, не использующими официальную
спецификацию, всегда сопряжена с определенным риском — программы могут
содержать ошибки, приводящие к искажению исходной версии тома RAID.

PAGE 150

Глава 7. Многодисковые тома

Общие замечания по поводу анализа

Анализ системы с томами RAID может оказаться сложной задачей, поскольку
такие системы встречаются не так часто и имеют разные реализации.
Опробуя разные методы снятия данных, будьте очень осторожны и следите за
тем, чтобы это не привело к модификации исходных дисков. Используйте
аппаратные бло-кировщики записи или перемычки «только для чтения» на
жестких дисках для предотвращения изменений. Также может быть полезно
создать образы отдельных дисков перед созданием образа всего тома RAID.
Образы отдельных дисков могут содержать скрытые данные, не входящие в
том RAID. Случаи со скрытыми данными RAID пока не документированы, но
теоретически такая возможность существует — все зависит от того, какая
система является объектом анализа. Также нельзя исключать, что для
создания тома RAID используется не весь диск. Некоторые системы RAID
ограничиваются частью жесткого диска, чтобы диск было проще заменить в
случае сбоя. Например, система может использовать только 40 Гбайт на
каждом отдельном диске независимо от его фактической емкости (40 или 80
Гбайт). Неиспользуемая область может содержать данные от предыдущего
образа, но в ней также могут находиться скрытые данные.

Итоги

В этом разделе был приведен обзор технологии RAID. Массивы RAID широко
применяются на высокопроизводительных серверах и получают все большее
распространение среди настольных систем, нуждающихся в повышенном
быстродействии или емкости диска. Низкоуровневые подробности не
рассматривались, потому что они зависят от реализации, а единого
стандарта пока не существует. Дополнительная информация приводится в
разделе «Объединение дисков», поскольку в поддержке управления томами
многих систем присутствует интегрированная программная реализация RAID.

Ключевым фактором успешной экспертизы является опыт снятия данных в
системах RAID. Самый простой, хотя и не всегда возможный вариант —
снятие всего тома RAID «на месте» и последующий анализ с применением
стандартных средств. У такого подхода есть свои недостатки: для
сохранения данных необходим диск очень большого размера, а на отдельных
дисках могут находиться данные, не входящие в итоговый том RAID.
Следовательно, безопаснее также произвести снятие данных с отдельных
дисков.

Объединение дисков

В результате объединения (disk spanning) несколько отдельных дисков
выглядят как один большой диск. Объединение дисков часто рассматривается
вместе с RAID, поскольку оно поддерживается многими программными
решениями RAID, однако объединение дисков не обеспечивает ни
избыточности, ни повышенного быстродействия. Оно просто формирует
носители информации большего объема, а некоторые версии позволяют
добавлять новые диски и динамически увеличивать размер файловой системы.

Объединение дисков

PAGE 151

В наше время объединение дисков поддерживается многими операционными
системами. Далее будут рассмотрены программные решения в системах
Microsoft Windows и Linux. Другие системы — такие, как Sun Solaris, IBM
AIX и Apple OSX — также содержат собственные технологии объединения
дисков, но здесь они не рассматриваются. Раздел начинается с описания
основных концепций и определения общих понятий, используемых во всех
реализациях. Затем мы перейдем к конкретным системам Windows и Linux.
Как и в предыдущем разделе, посвященном RAID, не надейтесь найти здесь
ответы на все вопросы — хотя бы потому, что не все ответы известны. Я
всего лишь объясню, как работает объединение дисков; возможно, это
поможет вам понять, почему не существует программы, которая решала бы
все ваши задачи.

Общий обзор

Объединение дисков используется примерно по тем же причинам, по которым
мы используем скоросшиватель вместо блокнота на пружинной спирали. Когда
все страницы блокнота будут исписаны, приходится покупать новый блокнот
и носить его вместе со старым. Если же кончатся страницы в
скоросшивателе, вы можете добавить в него новые страницы и даже
перенести накопившиеся заметки в папку большего размера. При
использовании объединения дисковое пространство новых дисков добавляется
в конец существующего пространства. На рис. 7.6 показан пример с двумя
дисками, каждый из которых содержит 100 блоков данных. Блоки 0-99
хранятся на диске 1, а блоки 100-199 — на диске 2.

DO

D100

D1

D101

D2

D102

D3

D103

D99

D199

Диск 1

Диск 2

Рис. 7.6. Объединение дисков: 100 блоков хранятся на первом диске и еще
100 — на втором Программная поддержка объединения дисков формирует
логический том. Логические тома состоят из нескольких физических дисков
или разделов, последовательно объединяемых друг с другом. Во многих
системах также существуют дисковые группы, то есть группы физических
дисков; только диски, входящие в одну группу, объединяются для создания
логического тома. На рис. 7.7 показано, как

PAGE 152

Глава 7. Многодисковые тома

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

Логический том 1

Логический том 2

Рис. 7.7. Компоненты и связи в системе с объединением дисков

Linux MD

В Linux существует два метода объединения дисков. Драйвер MD, уже
упоминавшийся в связи с системами RAID, также способен выполнять
простейшее объединение дисков, но существует и более совершенная система
LVM (Logical Volume Manager). Обе системы входят в основные дистрибутивы
Linux. В этом разделе будут описаны устройства MD. Мы начинаем с Linux,
потому что драйверы Linux могут использоваться для анализа систем
Windows.

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

Драйвер MD использует обычные разделы DOS, группируя их для создания
тома RAID или объединенного тома. Каждый диск может содержать несколько
разделов и использоваться в некотором томе RAID или логическом томе. В
этой модели не существует дисковых групп. Конфигурационный файл
/etc/raidtab определяет порядок следования разделов; монтирование тома
возможно лишь после задания его конфигурации в файле. Структура
конфигурационного файла идентична той, что описывалась в предыдущем
разделе для RAID, только параметру raid-level присваивается значение
linear. Пример конфигурационного файла для логического тома с двумя
разделами (/dev/hdbl и /dev/hddl):

# cat /etc/raidtab raiddev /dev/mdO

raid-level linear

nr-raid-disks 2

nr-spare-disks 0

persistent-superblock 0

chunk-size 4k

device /dev/hdbl

raid-disk 0

device /dev/hddl

raid-disk 1

Объединение дисков

PAGE 153

Ядро читает конфигурационный файл и создает устройство /dev/mdO, которое
может монтироваться и использоваться как отдельный том, но в
действительности состоит из дискового пространства /dev/hdbl и
/dev/hddl.

Если параметр persistent-superblock равен 0, то все данные конфигурации
устройства содержатся в файле /etc/raidtab. Если он равен 1, то в конце
каждого диска или раздела находятся конфигурационные данные, по которым
механизм автоматической идентификации дисков Linux автоматически создает
устройство MD. Для работы процесса автоматической идентификации в Linux
соответствующий раздел DOS должен относиться к типу Oxfd. Чтобы узнать,
было ли устройство создано при загрузке, просмотрите файл журнала
/var/Log/messages. Процесс автоматической идентификации происходит при
загрузке модуля ядра md.

Если диски или разделы содержат постоянный суперблок, в них создается
1024-байтовая структура, разделенная на секции. Первая секция содержит
параметры объединенного диска или тома RAID — версии, количество дисков,
время создания, идентификаторы. Вторая секция содержит общие сведения —
последнее время обновления, счетчик, состояние тома, количество
работающих и сбойных дисков. В остальных секциях хранится информация о
каждом диске тома, включая основную и дополнительную версии устройства,
роль устройства в томе, состояние диска. Как будет показано в секции
анализа, типичная система Linux обновляет содержимое суперблока при
загрузке, даже если том не монтируется. По содержимому суперблока ядро
может узнать, что диски были отсоединены от системы и установлены в
измененном порядке.

Снятие данных и анализ

При анализе данных на томах MD лучше всего снять содержимое тома как
единого диска или раздела, а затем воспользоваться стандартными
средствами анализа. Проще всего это сделать при наличии постоянного
суперблока; в противном случае вам придется создать в системе снятия
данных файл /etc/raidtab. Если потребуется создать этот файл, попробуйте
получить доступ к каталогу /etc/ на исходном диске и возьмите его за
основу.

После того как конфигурационный файл будет создан, устройство MD
создается командой raidstart. Команда создает в каталоге /dev/
устройство с именем, указанным в файле. Клонирование тома осуществляется
программой dd или ее аналогом. После снятия данных необходимо выполнить
команду raidstop для завершения работы с устройством MD. При наличии
постоянного суперблока следует помнить, что некоторые параметры
обновляются при создании нового устройства командой raidstart. Заранее
создайте резервные образы дисков; попробуйте использовать блокировщики
записи АТА и SCSI, если они у вас имеются.

Если для каждого раздела DOS, входящего в том, поле раздела равно Oxfd,
существует постоянный суперблок, а система настроена на автоматическую
идентификацию устройств MD — устройство будет создано в процессе
запуска. Как и при выполнении команды raidstart, в процессе создания
изменяется время последнего обновления, счетчик и контрольная сумма в
суперблоке. Изменения вносятся даже в том случае, если том MD не
монтируется!

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

PAGE 154

Глава 7. Многодисковые тома

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

Также оказалось, что при использовании дисков MD лучше обойтись без
хранения файла raidtab. Это может быть очень опасно, потому что при
отключении системы и установке новых дисков Linux попытается
обрабатывать их как часть тома. Возможно, стоит внести изменения в
сценарии отключения, чтобы они переименовывали файл raidtab — в этом
случае файл не будет существовать при следующем включении питания.

Для снятия данных с томов MD можно использовать загрузочные
компакт-диски Linux. Некоторые из них обнаруживают тома MD
автоматически, другие этого не делают и требуют создать файл
/etc/raidtab. Если систему можно загрузить с компакт-диска и создать
устройство MD, проведите снятие данных обычным способом. В противном
случае снимите данные с каждого диска и документируйте их
местонахождение, чтобы свести к минимуму изменения дисков из-за их
установки в неверном порядке. Мне так и не удалось воссоздать том MD по
физическим образам исходных разделов и устройствам обратной связи. Это
означает, что вам, возможно, придется восстановить образы на диск и
извлечь данные с дисков в лаборатории.

Linux LVM

Второй механизм объединения дисков в Linux основан на использовании LVM.
В этом разделе описывается архитектура LVM и методы снятия данных.

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

Диспетчер логических томов (LVM) обладает более сложной архитектурой,
чем MD. В нем используются дисковые группы, которые в терминологии LVM
называются группами томов. Разделам DOS, используемым в LVM, назначается
тип раздела 0х8е. Диски и разделы в группах томов делятся на физические
экстенты — равные блоки, размер которых обычно составляет несколько
мегабайт. Каждая система содержит одну или несколько групп томов, при
этом каждая группа представлена подкаталогом в каталоге /dev/.

Логический том состоит из логических экстентов, размер которых совпадает
с размером физических экстентов; между логическими и физическими
экстентами существует однозначное соответствие. На рис. 7.8 показан
логический том, созданный из трех наборов физических экстентов на двух
физических дисках.

Логические тома создаются либо объединением физических экстентов, либо
чередованием (с объединением последовательных логических экстентов на
разных дисках). Скажем, на 2-гигабайтном томе первые 1,5 Гбайт могут
размещаться на диске 1, а последние 500 Мбайт — на диске 2. С другой
стороны, на томе с чередованием могут использоваться два диска объемом 1
Гбайт: первый мегабайт размещается на диске 1, второй — на диске 2,
третий — снова на диске 1, и т. д. Логический том представляется файлом
устройства в подкаталоге группы томов в /dev/.

Сведения о конфигурации логического тома хранятся как в локальной
системе, так и на дисках. Локальная конфигурация хранится в файле
/etc/Lvmtab и ка

Объединение дисков

PAGE 155

талоге /е^/Ь/гтгёаЬ.с!/. Конфигурационный файл имеет двоичный формат и
обновляется утилитами ЬУМ, такими как удттрогг., удБсап и удспапде.
Дисковая структура находится в начале диска и содержит информацию о
диске, о группе томов, к которой он принадлежит, и о логических томах,
входящих в группу. Ни одно из полей структуры не содержит временных
штампов, поэтому структура не обновляется при создании логического тома,
как это происходит с устройствами 1УШ.

_____________(_____________________________________________ I

Рис. 7.8. 1_\/М делит физические диски на физические экстенты,
отображаемые на логические экстенты в логическом томе

Снятие данных и анализ

Анализ систем LVM открывает больше возможностей для автоматизации, чем
для устройств MD. Дальнейшее описание базируется на моем опыте работы с
текущими версиями LVM и было проверено у разработчиков LVM1. LVM
содержит служебные программы vgexport и vgimport, которые должны
использоваться при перемещении дисков между системами, но для снятия
данных с дисков они не нужны. Программа vgexport удаляет локальные файлы
конфигурации тома и записывает слово «-EXPORT» в имя группы томов на
диске. Для проведения экспертизы при удалении дисков из анализируемой
системы этот шаг не обязателен.

Чтобы провести анализ тома LVM, следует либо удалить диски из системы и
разместить их в доверенной системе Linux, либо загрузить анализируемую
систему с загрузочного компакт-диска Linux с поддержкой LVM. Как
упоминалось при обсуждении LVM, безопаснее настроить систему так, чтобы
она не выполняла автоматического монтирования и конфигурации логических
томов. Выполните команду vgscan в системе, в которой производится
анализ, для проведения поиска логических томов. Команда автоматически
создает файл /etc/ Lvmtab и конфигурационные файлы в
каталоге/etc/Lvmtab.d/. После создания конфигурационных файлов выполните
команду vgchange -а у для активизации найденных томов. При работе с LVM
местонахождение и конфигурация ведущих/ ведомых дисков несущественны.
Содержимое активного тома копируется командой dd с устройства тома в
/dev/. По моему опыту, выполнение команд vgscan и vgchange не приводит к
изменению кодов MD5 дисков. Далее приводится последовательность команд
при загрузке системы с использованием пакета Penguin Sleuth Kit
(обратите внимание: Penguin Sleuth Kit не имеет отношения

1 Переписка с Хайнцем Мауэльсхагеиом (Heinz Mauelshagen) и Э. Дж.
Льюисом (A. J. Lewis), 17 ноября 2003 г.

PAGE 156

Глава 7. Многодисковые тома

к аналитическому пакету The Sleuth Kit). Пакет Penguin Sleuth Kit
доступен по адресу: HYPERLINK “http://www.linux-forensics.com”
http://www.linux-forensics.com .

# vgscan

vgscan — reading all physical volumes (this may take a while…)

vgscan — found inactive volume group “vg_big2”

vgscan — “/etc/1vmtab” and “/etc/1vrntab.d” successfully created

vgscan — WARNING: This program does not do a VGDA backup of your volume
group

Учтите, что в будущих версиях поведение LVM может измениться, поэтому
протестируйте все процедуры перед выполнением действий в реальной
системе и создайте резервные копии дисков перед объединением томов.

Microsoft Windows LDM

Компания Microsoft впервые включила поддержку объединения дисков в
Windows NT. В этом разделе описывается архитектура LDM и методы снятия
данных.

Динамические диски

Диспетчер логических дисков (LDM) отвечает за управление логическими
томами в Windows 2000 и ХР. LDM поддерживает простые тома (аналоги
обычных разделов), объединение дисков, RAID уровня 0 (чередование), RAID
уровня 1 (зеркальное копирование) и RAID уровня 5. Технологии RAID уже
упоминались ранее в этой главе, а здесь они будут описаны более
подробно.

К категории базовых относятся диски, описанные в главах 5 и 6. Базовые
диски содержат таблицу разделов DOS или GPT, а каждый раздел является
самостоятельным. Базовые диски не могут использоваться в LDM.
Динамический диск содержит дополнительные структуры данных для создания
разделов, пригодных для формирования логических томов.

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

В первом секторе любого динамического диска в системе IA32 находится
таблица разделов DOS. Благодаря ей старые системы узнают о том, что диск
используется. Таблица содержит всего одну запись, представляющую весь
диск, с типом раздела 0x42. Область раздела LDM и база данных находятся
в разделе DOS, как показано на рис. 7.9. Для просмотра таблицы разделов
можно воспользоваться программой mmls из пакета The Sleuth Kit:

# mmls -t dos vdisk.dd DOS Partition Table

Units are in 512-byte sectors

Slot Start End Length Description

00: —– 0000000000 0000000000 0000000001 Primary Table (#0)

01: —– 0000000001 0000000062 0000000062 Unallocated

02: 00:00 0000000063 0120101939 0120101877 Win LVM / Secure
FS(0x42)

В системах IA64 (Intel Itanium и т. д.) на динамических дисках создаются
разделы GPT для области разделов и базы данных LDM. Для этих разделов
предусмотрены специальные типы.

Объединение дисков

PAGE 157

Раздел DOS, тип 0x42

/ \

Область раздела LDM

База данных LDM

Рис. 7.9. Строение динамического диска в системе IA32: структуры данных
LDM находятся внутри раздела DOS

Windows поддерживает только одну дисковую группу, в которую
автоматически включаются все динамические диски. Область разделов
динамического диска разбивается на динамические разделы, а динамические
разделы одного или нескольких дисков группируются для формирования
логических томов (рис. 7.10). Очень важно различать термины,
используемые компанией Microsoft для динамических дисков и разделов DOS.
В схеме разделов DOS Microsoft называет логическими томами разделы,
создаваемые внутри расширенных разделов, тогда как в динамических дисках
логическими томами называются все разделы, которые могут содержать
файловую систему или другие данные.

Динамический диск 1

Динамический диск 2

Динамические разделы

Дисковая группа

Рис. 7.10. Логический том 1F>М формируется из динамических разделов,
входящих в дисковую группу

База данных LDM

В базе данных LDM хранятся определения динамических разделов и правила
создания логических томов. Компания Microsoft не опубликовала точного
описания строения базы данных LDM, но Интернет-группы идентифицировали
некоторые внутренние структуры данных (одна из групп, Linux NTFS,
доступна по адресу: HYPERLINK “http://Linux-ntfs.sourceforge.net”
http://Linux-ntfs.sourceforge.net ). Из опубликованных справочных
руководств Microsoft [Solomon and Russinovich, 2000] известно, что база
данных LDM состоит из четырех основных частей. Приватный заголовок
сходен с загрузочным сектором файловой системы. Он описывает уникальные
характеристики диска и логического тома. Эта структура содержит
уникальный идентификатор диска (GUID) и имя дисковой группы. Windows
содержит только одну дисковую группу, имя которой определяется именем
компьютера. Далее следует оглавление, состоящее из 16 секторов. По
данным Соломона и Руссиновича, оглавление «содержит информацию о
строении базы данных», то есть о следующей части LDM.

PAGE 158

Глава 7. Многодисковые тома

Область базы данных содержит описания дисков, разделов, компонентов и
томов. Для каждого динамического диска (как DOS, так и GPT) в базе
данных создается запись диска. Записи разделов описывают структуру
разделов на динамических дисках. Записи компонентов описывают процесс
объединения разделов. Каждая запись раздела содержит ссылку на
используемую ей запись компонента. Записи компонентов существуют для
объединения, чередования и зеркального копирования. Наконец, записи
томов описывают логические тома, то есть результат применения
компонентов к разделам.

Рассмотрим пример с двумя динамическими дисками. Имеется логический том,
первая часть которого занимает 15 Мбайт на диске 1, вторая — 10 Мбайт на
диске 2, а последняя часть — 20 Мбайт на диске 1 (конечно, эти цифры
гораздо меньше тех, которые используются в реальных ситуациях).
Структура логического тома показана на рис. 7.10. Программа Microsoft
dmdiag ( HYPERLINK “http://www.microsoft.com/” http://www.microsoft.com/
windows2000/techinfo/reskit/tools/existing/dmdiag-o.asp) предназначена
для вывода информации о записях в базе данных. Результат ее работы
выглядит так:

Disk: Diskl rid=0.1027 updated=0.1222

assoc: diskid=6a565b54-b83a-4ebb-95eb-842ede926e88

flags:

Disk: Disk2 rid=0.1063 updated=0.1112

assoc: diskid=533fe4ab-0409-4ea6-98b3-9648bbc3bdl2

flags:

Эти две записи относятся к двум физическим дискам. Диску 1 присвоен
идентификатор 0.1027, а диску 2 — идентификатор 0.1063.

Group: hashDgl rid=0.1025 update=0.1028

id: dgid=d4f40362-7794-429a-a6ad-a6dfc0553cee

diskset: id=00000000-0000-0000-0000-000000000000

copies: nconfig=all nlog-al1

minors: >= 0

Запись определяет группу дисков и показывает, что имя дисковой группы
определяется именем компьютера (hash).

Subdisk: Diskl-01 rid=0.1109 updated=0.1112 info: disk=0.1027
offset-0 len=30720 hidden=0 assoc: plex=0.1107 (column=0 offset=0)

Subdisk: Diskl-02 rid-0.1121 updated=0.1122 info: disk=0.1027
offset-0 len=40960 hidden=0 assoc: plex=0.1107 (column=0
offset-51200)

Эти две записи являются записями разделов для физического диска с именем
Diskl (ID:0.1027). Для обоих записей параметр plex со значением 0.1107
определяет запись компонента, используемую для создания логического
тома. Первая запись (идентификатор 0.1109) определяет 15-мегабайтный
раздел со смещением сектора 0 и размером 30 720 секторов. Вторая запись
(идентификатор 0.1121) определяет 20-мегабайтный раздел со смещением 30
720 и размером 40 960 секторов.

Subdisk: Disk2-01 rid-0.1111 updated=0.1112 info: disk=0.1063
offset-0 len=20480 hidden=0 assoc: plex=0.1107 (column=0
offset-30720)

Запись определяет раздел для динамического диска Disk2 (ID:0.1063) с
идентификатором 0.1111, смещением 0 секторов и размером 20 480 секторов.
Связи

Объединение дисков

PAGE 159

между физическим диском и записями динамических разделов показаны на
рис. 7.11. Направление стрелки означает, что запись динамического
раздела содержит указатель на физический диск.

Plex: Volume-01 rid=0.1107 update=0.1124

type: 1ayout=CONCAT

state: state=ACTIVE

assoc: vol=0.1105

Физический диск Дискі ID: 0.1027

Динамический раздел Дискі-01 ID: 0.1109

Динамический раздел Диск1-02 ID: 0.1121

Физический диск Диск2 ID: 0.1063

Динамический раздел Диск2-01 ID: 0.1111

Рис. 7.11. Связи между физическим диском и записями динамических
разделов в базе данных ЮМ

Физический диск Дискі ID: 0.1027

Физический диск Диск2 ID: 0.1063

Динамический раздел Диск1-01 ID: 0.1109

Динамический раздел Диск1-02 ID: 0.1121

Компонент Том1-01 ID: 0.1107

Динамический раздел Диск2-01 ID: 0.1111

Логический том Том1 ID: 0.1105

Рис. 7.12. Связи между записями базы данных ЮМ (указатели на другие
объекты обозначены стрелками)

Приведенный фрагмент является записью компонента объединения дисков
(ССЖСАТ), описывающей способ создания логического тома посредством
объединения динамических разделов. Мы видим идентификатор 0.1107,
который встречался

PAGE 160

Глава 7. Многодисковые тома

в каждой из записей разделов. Также видно, что он ассоциируется с
идентификатором тома 0.1105, описание которого приводится далее.

Volumel riсЮ. 1105 update=0.1124 mountname=F:

len=92160 guid=e40794d0-6e3c-4788-af3d-ff49d2ce769d

parttype=7 usetype=gen

state=ACTIVE

read=SELECT

writeback

Volume: info: type: state: policies: flags:

База данных завершается последним фрагментом, содержащим запись
логического тома. В записи указана точка монтирования F:\h длина 92 160
секторов. Тому присвоен идентификатор 0.1105 и имя Volumel. Связи между
записями показаны на рис. 7.12. Учтите, что все диски группы содержат
одинаковые записи базы данных.

Итоговая организация логического тома показана на рис. 7.13. Обратите
внимание: последовательность разделов в логическом томе не соблюдается.

Диск1

Диск1-01 Диск1-02

Размер: 30720 Размер: 40960

Диск2-01 Размер: 20480

Диск2

Том1

Смещение: 0 Смещение: 30720 Смещение: 51200

Размер: 30720 Размер: 20480 Размер: 40960

Рис. 7.13. Диск LDM с двумя физическими дисками, тремя динамическими
разделами и одним логическим томом

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

Снятие данных и анализ

Анализ любого логического тома довольно сложен, особенно при программной
реализации, а воссоздание тома в режиме «только для чтения» является
отнюдь не тривиальной задачей. Как упоминалось ранее в разделе,
посвященном RAID, анализ системы проще всего выполняется при снятии
данных с логического тома и применении стандартных средств анализа. Тем
не менее в Windows это не всегда возможно, потому что система пытается
монтировать диски при загрузке. Снятие смонтированной файловой системы
может привести к порче образа, а монтирование способно вызвать
модификацию данных. Перемещение дисковых групп LDM между компьютерами
также сопряжено с некоторым риском. В Windows в любой момент времени
поддерживается только одна дисковая группа, а динамические диски
добавляются в локальную группу, если она существует [Microsoft, 2003].
Следовательно, если динамические диски из исходной системы импортируются
в систему анализа, использующую динамические диски, они будут включены в
локальную группу дисков, а ОС запишет новые данные в базу данных LDM.

Объединение дисков

PAGE 161

Ядро Linux включает поддержку объединения дисков LDM, хотя она и не
всегда включается по умолчанию. Если в вашем дистрибутиве объединение
дисков отключено, возможно, вам придется перекомпилировать ядро. Если
ядро поддерживает LDM, Linux прочитает базу данных и создаст устройства
для каждого динамического раздела каждого динамического диска. Например,
если загрузить Linux с двумя дисками из предыдущего примера, в системе
будут созданы устройства /dev/hdbl, /dev/hdb2 и /dev/hddl. Затем
создается файл /etc/raidtab с описанием структуры, чтобы драйвер ядра MD
мог создать одно устройство. Если /dev/ hdbl содержит первый раздел,
/dev/hddl — второй, а /dev/hdb2 — третий, то файл raidtab выглядит так:
raiddev /dev/mdO

raid-level linear

nr-raid-disks 3

nr-spare-disks 0

persistent-superblock 0

chunk-size 4k

device /dev/hdbl

raid-disk 0

device /dev/hddl

raid-disk 1

device /dev/hdbl

raid-disk 2

В случае «линейных» томов RAID размер фрагмента (chunk-size) задается
произвольно, но параметр должен существовать. Программы EnCase (Guidance
Software) и ProDiscover (Technology Pathways) умеют импортировать
отдельные образы из логических томов Windows и объединять их.

Если используется только объединение дисков, вы можете вручную извлечь
разделы и скомбинировать их из дисковых образов. Информацию о строении
тома можно получить при помощи программы dmdiag.exe, но программа
работает только в Windows и требует, чтобы диски были смонтированы. По
этой причине мы воспользуемся другой программой из Linux. Группа Linux
NTFS разработала программу Ldminfo ( HYPERLINK
“http://h*nux-ntfs.sourceforge.net/status.html%23ldmtools”
http://h*nux-ntfs.sourceforge.net/status.html#ldmtools ), которая
анализирует записи базы данных LDM динамического диска Windows и выводит
подробную информацию с ключом -dump. Программа работает с любыми
неструктурированными устройствами или дисковыми образами массива дисков,
потому что базы данных на всех дисках содержат одинаковые записи. Она
выводит такую же подробную информацию, как и dmdiag.exe, но мы
сосредоточимся на информации о структуре тома из предыдущего примера: #
ldminfo –dump diskl.dd

VOLUME DEFINITIONS :

Volume Size: 0x00016800 (45 MB)

Diskl-01 VolumeOffset: 0x00000000 Offset: 0x00000000 Length: 0x00007800
Diskl-01 VolumeOffset: 0x00007800 Offset: 0x00000000 Length: 0x00005000
Diskl-02 VolumeOffset: 0x00000800 Offset: 0x00007800 Length: OxOOOOAOOO

Из результатов видно, что том содержит два диска и три раздела. Диск
нетрудно воссоздать, потому что он использует объединение без разбиения
данных. Ранее из результатов выполнения m mis для образа диска мы
видели, что область разделов начинается в секторе 63. Следовательно, к
смещениям в выходных данных

PAGE 162

Глава 7. Многодисковые тома

Ldminfo необходимо прибавлять 63, потому что смещения задаются
относительно начала области разделов. Чтобы получить данные первого
раздела, мы извлекаем 30 720 секторов (0x7800) из области разделов
первого диска:

# dd if-diskl.dd skip=63 count=30720 > span.dd

Вторая часть дискового массива является первой частью второго диска. Мы
присоединим ее содержимое к данным первого диска. Таким образом, следует
извлечь первые 20 480 секторов (0x5000) из области разделов второго
диска:

# dd if=disk2.dd skip=63 count=20480 » span.dd

Последняя часть массива находится в области разделов первого диска. Она
также будет присоединена к данным, извлеченным со второго диска. Данные
начинаются с сектора 30 720 (0x7800) области разделов; следовательно,
нам нужен сектор 30 783 по отношению к началу диска, а его длина
составляет 40 960 секторов.

# dd if-diskl.dd skip=30783 count=40960 » span.dd

Полученный образ span.dd обрабатывается как обычный образ файловой
системы. Если доступна поддержка LDM уровня ядра, я рекомендую сначала
опробовать этот путь, прежде чем браться за ручную обработку. Также
учтите, что при разработке многих вспомогательных драйверов сторонних
разработчиков и утилит LDM подробные спецификации Microsoft
отсутствовали, поэтому правильность их работы не гарантирована.

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

• Lewis, A.J. «The LVM HOWTO». The Linux Documentation Project,
2002-2004. HYPERLINK “http://tldp.org/H0WT0/LVM-H0WT0/”
http://tldp.org/H0WT0/LVM-H0WT0/ .

• Microsoft, «Description of Disk Groups in Windows Disk Managements
Microsoft Knowledge Base Article 222189, November 21, 2003. HYPERLINK
“http://support.rnicrosoft.com/” http://support.rnicrosoft.com/
kb/222189.

• Microsoft. Microsoft Windows XP Professional Resource Kit
Documentation, 2004. HYPERLINK “http://www.microsoft.com/resources/%5e”
http://www.microsoft.com/resources/^

prork_overview.asp.

• Ostergaard, Jakob. The Software-RAID HOWTO». The Linux Documentation
Project, June 3, 2004. HYPERLINK
“http://www.tldp.org/H0WT0/Software-RAID-H0WT0.html”
http://www.tldp.org/H0WT0/Software-RAID-H0WT0.html .

• Patterson, David A., Garth Gibson and Randy H.Katz. «A Case for
Redundant Arrays of Inexpensive Disks (RAID)». ACMSIGMOD International
Conference on Management of Data, June 1988.

• PC Guide. «Redundant Arrays of Inexpensive Disks». April 17,2001.
HYPERLINK “http://www.pc-” http://www.pc- HYPERLINK
“http://guide.com/ref/hdd/perf/raid/index.htm”
guide.com/ref/hdd/perf/raid/index.htm .

• Solomon, David, and Mark Russinovich. Inside Microsoft Windows 2000.
3rd ed. Redmond: Microsoft Press, 2000.

• HYPERLINK “http://Sourceforge.net” Sourceforge.net . «LDM
Documentations Linux NTFS Project, 2002. HYPERLINK “http://Linux-”
http://Linux- ntf???????????????????????????????????????????

ЧАСТЬ III

Анализ файловых систем

Глава 8. Анализ файловых систем……………………………..164

Глава 9. FAT: основные концепции и анализ……………….198

Глава 10. Структуры данных FAT…………………………………235

Глава 11. NTFS: основные концепции………………………….250

Глава 12. NTFS:
анализ……………………………………………..273

Глава 13. Структуры данных NTFS………………………………317

Глава 14. Ext2 и Ext3: концепции и анализ…………………..352

Глава 15. Структуры данных Ext2 и Ext3………………………399

Глава 16. UFS1 и UFS2: концепции и анализ…………………422

Глава 17. Структуры данных UFS1 и UFS2…………………….448

Анализ файловых систем

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

Что такое файловая система?

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

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

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

Что такой файловая система?

PAGE 165

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

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

Категории данных

При рассмотрении различных типов файловых систем полезно иметь эталонную
модель, упрощающую сравнение разных файловых систем (скажем, FAT и
Ext3). Кроме того, наличие эталонной модели упрощает поиск
доказательств. В нашей эталонной модели будут задействованы пять
категорий: данные файловой системы, содержимого, метаданные, данные имен
файлов и прикладные данные. Любая информация файловой системы
принадлежит к одной из перечисленных категорий в зависимости от того,
какую роль она играет в файловой системе. Мы будем использовать эти
категории при описании файловых систем, хотя некоторые системы (а
именно, FAT) не так хорошо соответствуют эталону, как другие системы.
Инструментарий The Sleuth Kit (TSK) тоже базируется на тех же
категориях.

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

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

Категория метаданных включает данные с описаниями файлов; иначе говоря,
это данные, описывающие другие данные. В частности, к метаданным
относится информация о местонахождении содержимого файла, его размере,
времени и дате последнего чтения или записи в файл, контроле доступа и
т. д. Метаданные не включают ни фактического содержимого файла, ни его
имени. Примерами структур данных этой категории являются записи
каталогов FAT, записи NTFS MFT (Master File Table), структуры i-узлов
UFS и Ext3.

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

PAGE 166

Глава 8. Анализ файловых систем

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

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

Отношения между пятью категориями данных показаны на рис. 8.1.

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

Категория прикладных данных

Информация о местонахождении и размерах

Квоты

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

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

Категория данных содержимого

file1.txt

file2.txt

Временные штампы и адреса

Временные штампы и адреса

Содержимое 1

Содержимое 2

Содержимое 1

Рис. 8.1. Взаимодействие пяти категорий данных

Необходимые и вспомогательные данные

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

Что такой файловая система?

PAGE 167

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

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

Некоторые ОС требуют, чтобы некоторые значения обязательно задавались,
но это не означает, что эти данные являются необходимыми. К примеру,
очень строгая (и вымышленная) ОС может отказаться монтировать файловые
системы с файлами, время последнего обращения к которым относится к
будущему. Другая ОС не обратит внимания на проблемы с временем,
смонтирует файловую систему и сохранит в ней данные. Microsoft Windows
требует, чтобы все файловые системы FAT начинались с некоторого блока
данных, хотя последний используется только в том случае, если файловая
система является загрузочной. С другой стороны, в Linux подобные
требования отсутствуют.

Если рассматривать происходящее с этой точки зрения, становится
очевидно, что аналитик должен хорошо знать не только тип файловой
системы, но и ОС, записывающую данные в файловую систему. Если мы
говорим о восстановлении файлов, недостаточно узнать, как восстановить
удаленный файл в файловой системе FAT, — задайтесь вопросом, как
восстановить файл, удаленный Windows 98 в файловой системе FAT. Система
FAT реализована во многих операционных системах, и каждая из них может
использовать свою методику удаления файлов. Например, большинство ОС
ограничиваются минимальным набором действий, необходимых для удаления
файла, но другие системы могут уничтожать все данные, ассоциированные с
файлом. В обоих случаях конечным результатом будет действительная
файловая система FAT.

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

Методы анализа и категории данных

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

PAGE 168

Глава 8. Анализ файловых систем

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

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

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

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

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

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

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

Категория данных содержимого

PAGE 169

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

В пакет TSK входит утилита fsstat, выводящая данные из категории
файловой системы. Объем выводимой информации зависит от типа файловой
системы; примеры будут приведены в следующих главах.

Категория данных содержимого

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

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

Анализ данных содержимого проводится с целью восстановления удаленных
данных и проведения низкоуровневого поиска. Объем данных содержимого
относительно велик, поэтому анализ обычно проводится в
автоматизированном режиме. Например, если эксперт может проанализировать
содержимое 512-байтового сектора за 5 секунд, то при 12-часовом рабочем
дне на анализ 40-гигабайтного диска ему потребуется 388 дней.

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

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

Логические адреса файловой системы

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

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

PAGE 170

Глава 8. Анализ файловых систем

На рис. 8.2 показан том с 17 секторами и их логическими адресами. Внизу
приведены логические адреса файловой системы. Вымышленная файловая
система создает блоки данных, каждый из которых состоит из двух
секторов, причем присваивание адресов начинается с сектора 4. Эта очень
маленькая файловая система завершается в секторе 15, а сектор 16
образует резервное пространство тома.

Логический адрес тома

Логический адрес файловой

0 12 3 4 5 6 7 8 9 10 11 12 13 14 15 16

0 1 2 3 4 5

Рис. 8.2. Пример тома, в котором файловая система назначает адреса
группам из двух секторов, а некоторые секторы исключаются из логической
адресации

Стратегии выделения

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

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

0 1 г 3 4 5 6 7

І

Последний выделенный блок

Пример выделения 8 блоков данных

Выделено

Свободно

Рис. 8.3.

Категория данных содержимого

PAGE 171

В похожей стратегии поиска следующего доступного блока поиск начинается
не с начала, а с последнего выделенного блока данных. Например, после
выделения блока данных 3 на рис. 8.3 поиск начнется с блока 4, а не с 0.
В нашем примере с театром поиск продолжится не с первого ряда, а с
последнего забронированного места. Даже если во время поиска будет
возвращен билет на первый ряд, он не будет продан до того, как поиск
достигнет последнего места. Такой алгоритм лучше сбалансирован для
восстановления данных, потому что блоки данных в начале файловой системы
выделяются заново лишь после выделения всех блоков до ее конца.

Стратегия оптимальной подгонки ищет смежные блоки данных, объем которых
позволит сохранить заданное количество данных. Такой способ хорошо
работает, если количество блоков известно заранее, но при увеличении
размера файла новые блоки данных, скорее всего, будут выделены в другом
месте, и файл все равно фрагментируется. Если алгоритм не может найти
смежный блок нужного размера, он может использовать стратегию поиска
первого или следующего доступного блока. Обычно именно такой алгоритм
применяется при бронировании мест в театре. Кассир перебирает пустые
места, пока не найдет достаточно соседних мест для вей группы. Скажем,
если бы в примере на рис. 8.3 потребовалось выделить два блока данных,
то файл попал бы в блоки данных 4 и 5 и не был бы разбит между блоками 1
и 4.

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

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

Поврежденные блоки данных

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

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

PAGE 172

Глава 8. Анализ файловых систем

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

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

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

Просмотр блоков данных

Метод просмотра блоков данных применяется в тех случаях, когда эксперту
известен адрес возможного местонахождения улик — например, выделенный
определенному файлу или имеющий особое значение. Скажем, во многих
системах FAT32 сектор 3 не используется файловой системой и заполняется
нулями, однако в нем могут храниться скрытые данные. Просмотр
содержимого сектора 3 покажет, присутствуют ли в нем данные, отличные от
нуля.

Принцип проведения такого рода анализа очень прост. Эксперт вводит
логический адрес файловой системы, а программа вычисляет смещение в
байтах или адрес сектора для указанного блока данных. Затем программа
переходит к указанной позиции и читает данные. Для примера рассмотрим
файловую систему, в которой блок данных 0 хранится со смещением 0, а
размер каждого блока данных равен 2 048 байт. Смещение блока данных 10
составит 20 480 байт (рис. 8.4).

2 048

•- 20 480 байт -•

0 1 2 3 4 5 6 7 8 9 10 11

This is the content of data unit 10. It is all ASCII text.

Рис. 8.4. Просмотр содержимого блоков данных 10

Данная функция выполняется многими программами, в том числе
шестнадца-теричными редакторами и средствами анализа. В частности,
программа dcat из пакета ТБК позволяет просмотреть конкретный блок
данных в низкоуровневом или шестнадцатеричном формате.

Поиск в логической файловой системе

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

Категория данных содержимого

PAGE 173

где они находятся. При поиске в логической файловой системе каждый блок
данных проверяется на присутствие некоторой фразы или значения. На рис.
8.5 каждый блок данных проверяется на присутствие строки «{ЪгепБЮз».

Присутствует ли строка «йэгег^св» в этом блоке данных?

I

0 1 2 3 4 5 6 7 8 9 10 11

Рис. 8.5. При поиске в логической файловой системе каждый блок данных
проверяется на присутствие заранее известного значения

Традиционно эта методика поиска называлась «физическим поиском», потому
что в ней используется физический порядок секторов; на мой взгляд, этот
термин верен только для отдельных дисков, но не для систем с
объединением дисков и массивов RAID. В таких системах порядок следования
секторов не соответствует их физическому порядку, и лучше использовать
более точный термин.

К сожалению, файлы не всегда занимают смежные блоки данных, и во
фраг-ментированном файле искомое значение может оказаться разбитым на
две несмежных блока. В этом случае при поиске в логической файловой
системе оно обнаружено не будет. Как будет показано далее, задача
решается поиском в логических файлах. Многие программы анализа позволяют
выполнять поиск как по логическим томам, так и по логическим файлам.
Чтобы определить, какой режим поиска используется вашей программой,
попробуйте провести поиск по ключевым словам в тестовых образах,
размещенных на моем сайте DFTT (Digital Forensic Tool Testing) [Carrier,
2004].

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

Состояние выделения блоков данных

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

На рис. 8.6 изображена битовая карта первых 12 блоков данных. В этой
структуре каждый блок данных представлен одним битом. Если бит равен 1,
значит, блок данных выделен, а если 0 — свободен. Если потребуется
извлечь содержимое всех свободных блоков данных, мы извлечем блоки 2, 6,
7 и 11.

PAGE 174

Глава 8. Анализ файловых систем

Блоки данных

.•о;; 2 3 4 111 6 7 8 0 10 11

і ///

Битовая .. .. карта ‘ ‘ 0 1 1 1 0 0 1 1 1 0

Рис. 8.6. Чтобы извлечь содержимое свободных блоков данных, мы
просматриваем битовую карту выделения и извлекаем блоки с заданным
значением

Функция извлечения содержимого свободного пространства файловой системы
поддерживается многими программами цифровой экспертизы, хотя определения
«свободного пространства» могут быть разными. Я заметил, что некоторые
программы считают свободными любые данные, не принадлежащие файлам,
включая данные категории файловой системы и метаданные. С другой
стороны, некоторые программы восстанавливают удаленные файлы и считают
их блоки данных выделенными, хотя с технической точки зрения эти блоки
свободны. А вы знаете, как ваша программа интерпретирует свободные
данные?

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

Порядок выделения блоков данных

Ранее я уже упоминал некоторые стратегии, используемые ОС при выделении
блоков данных. В общем случае выбор стратегия зависит от ОС и является
объектом анализа прикладного уровня. Например, Windows ME и Windows 2000
могут использовать разные стратегии выделения блоков данных для системы
FAT, но при этом каждая из систем создает действительную файловую
систему FAT.

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

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

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

Категория данных содержимого

PAGE 175

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

Запись метаданных 1

Запись метаданных 2

0 1 Я. 3 4 5 6 7 8 9 10 11

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

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

Методы надежного удаления

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

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

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

PAGE 176

Глава 8. Анализ файловых систем

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

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

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

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

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

Общая информация

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

Логическая адресация файлов

Ранее я упоминал о логических адресах файловой системы, назначаемых
блокам данных. Блок данных, выделенный файлу, также обладает логическим
адресом файла, который отсчитывается от начала файла, которому выделен
данный блок. Например, если файлу выделены два блока данных, то первому
блоку назначается логический адрес файла 0, а второму — логический адрес
файла 1. Для формирования уникального логического адреса файла
необходимо задействовать имя или адрес метаданных файла. Пример показан
на рис. 8.8, дополняющем предыдущий пример. На рисунке изображены два
файла с пятью выделенными блоками данных. Обратите внимание: логический
адрес файловой системы 1 не выделен файлу, поэтому он не имеет
логического адреса файла.

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

PAGE 177

Логический адрес тома

Логический адрес файловой системы

Логический адрес файла

0 12 3 4 5 6 7 8 9 10 11 12 13 14 15 16

0 1 2 3- 4 5

\

г

0 1 0 1 2

Выделено

filel .jpg

index.html

Свободно

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

Резервное пространство

Резервное пространство (slack space) — один из модных терминов цифровой
экспертизы, который наверняка приходилось слышать читателю. Резервное
пространство возникает в ситуации, когда размер файла не кратен размеру
блока данных. Система обязана выделить файлу полный блок данных, даже
если реально задействована будет лишь малая его часть; неиспользуемые
байты в последнем блоке данных называются резервным пространством.
Например, если размер файла составляет 100 байт, система должна выделить
ему полный блок данных размером 2048 байт, а последние 1948 байт
попадают в резервное пространство.

Почему резервное пространство представляет интерес для эксперта? Потому
что компьютеры «ленивы». Некоторые из них не стирают содержимое
неиспользуемых байтов, и резервное пространство содержит данные,
оставшиеся от предыдущих файлов или содержимого памяти. Вследствие
архитектуры, используемой в большинстве компьютеров, в резервном
пространстве имеется две интересные области. Первая находится между
концом файла и концом сектора, в котором этот файл заканчивается. Вторая
состоит из секторов, не содержащих данных файлов. Наличие этих двух
областей объясняется тем, что жесткие диски имеют блочную структуру, а
запись в них может осуществляться только фрагментами, кратными 512 байт
(размер сектора). В предыдущем примере ОС не может записать на диск
только 100 байт, она должна записать все 512 байт. По этой причине 100
байт приходится дополнять 412 байтами данных. Представьте, что вы
покупаете товар в магазине, в котором имеются коробки только одного
размера; чем меньше товар, тем больше упаковочного материала придется
положить в коробку, чтобы она была полной.

Первая область резервного пространства интересна тем, что способ
заполнения неиспользуемой части сектора определяется операционной
системой. Наиболее очевидный метод заключается в заполнении сектора
нулями, что и происходит в большинстве ОС. Некоторые старые ОС (а
именно, DOS и ранние версии Windows) заполняли остаток сектора данными
из памяти. Эта область резервного пространства называлась резервом RAM
[NTI, 2004], а теперь она обычно заполняется нулями. Резервное
пространство с содержимым памяти может содержать пароли и другие данные,
не предназначенные для записи на диск.

PAGE 178

Глава 8. Анализ файловых систем

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

Рассмотрим файловую систему ШТБ с 2048-байтовым кластером и 512-байтовым
сектором. Файл состоит из 612 байт, поэтому он использует весь первый
сектор и 100 байт второго сектора в кластере. Оставшиеся 412 байт
второго сектора заполняются данными по усмотрению ОС. Третий и четвертый
секторы ОС может заполнить нулями, а может и оставить в них данные из
удаленного файла. Это показано на рис. 8.9: серым цветом помечено
содержимое файла, а белым — резервное пространство.

Кластер 4910

Сектор 1 Сектор 2 Сектор 3 Сектор 4 Рис. 8.9. Резервное
пространство 612-байтового файла с 2048-байтовым кластером

При описании резервного пространства часто приводится аналогия с
видеомагнитофоном [Kruse, 2003]. Представьте, что вы ночью записываете
60-минутный эпизод нового сериала. Вы смотрите записанную программу и
перематываете ленту в начало. Позднее на ленту записывается 30-минутная
программа. После записи лента «выделяется» под 30-минутную программу,
однако в конце остаются еще 30 минут от предыдущей передачи.

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

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

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

После того как структура метаданных файла будет найдена, восстановление
проходит просто. Фактически оно не отличается от чтения содержимого
существующего файла. В примере на рис. 8.10 (А) в записи метаданных
удаленного файла остались адреса блоков данных, что позволяет легко
прочитать его содержимое. На рис. 8.10 (В) показан пример, в котором ОС
стерла адреса после удаления

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

PAGE 179

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

А)

Запись метаданных 67

9 009 10 003

В)

Запись метаданных 67

Блок

Блок

Блок

Блок

данных

данных

данных

данных

9 009

10 003

9 009

10 003

Рис. 8.10. Два сценария: (А) — указатели на данные не были стерты при
освобождении записи, (В) — указатели на данные потеряны

При восстановлении файлов по метаданным необходима осторожность, потому
что структуры метаданных и блоки данных могут быть десинхронизированы
из-за того, что блоки были выделены новым файлам. Рассмотрим пример на
рис. 8.10. Содержимое блока данных 9009 будет перезаписано, если этот
блок будет выделен записи метаданных 70 — несмотря на то, что запись 67
продолжает ссылаться на него. При попытке восстановить содержимое
метаданных 67 мы получим данные из файла, использующего запись
метаданных 70.

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

При восстановлении удаленных файлов иногда бывает трудно выявить факт
повторного выделения блока данных. Чтобы причина стала более понятной,
рассмотрим серию выделений и удалений. Запись метаданных 100 выделяет
блок данных 1000 и сохраняет в нем данные. Затем файл, связанный с
записью метаданных 100, удаляется; запись 100 и блок данных 1000
освобождаются. В записи метаданных 200 создается новый файл, которому
также выделяется блок данных 1000. Позднее и этот файл удаляется.
Проанализировав систему, мы обнаружим в ней две свободные записи
метаданных с одинаковыми адресами блока данных (рис. 8.11 (А)).

Даже если удастся определить, что запись 200 выделила блок данных
позднее записи 100, мы не знаем, была ли она последней в цепочке
выделений. Допустим, запись 300 выделила блок данных 1000 после того,
как он был освобожден записью 200. После этого файл был удален.
Возникает ситуация, показанная на рис. 8.11 (В): три свободные записи
метаданных ссылаются на один адрес блока данных.

Затем в системе создается новый файл, которому выделяется запись 300 с
новым блоком данных 2000. Если проанализировать систему в этом
состоянии, мы не найдем никаких доказательств, что запись 300 когда-то
была связана с блоком данных 1000, хотя содержимое блока данных
относится именно к записи 300. Мы узнаем лишь то, что блок выделялся
записям 100 и 200 (рис. 8.11 (С)).

PAGE 180

Глава 8. Анализ файловых систем

А)

В)

Запись 100

Блок данных 1 ООО (Запись 200)

Запись 200

Запись 100

Запись 200

С)

Запись 300

Блок данных 1 000 (Запись 300)

Запись 100

Запись 200

Блок данных 1 000 (Запись 300)

Свободно

Запись 300;

Блок данных2 000 (Запись 300)

Выделено

Рис. 8.11. Последовательность состояний при выделении и освобождении
блоков данных: в состоянии (С) неясно, к какой записи метаданных
относятся данные в блоке 1000

Этот пример показывает, что, даже если свободная структура метаданных
по-прежнему содержит адрес блока данных, очень трудно определить,
относится ли содержимое блока к этому файлу или другому, созданному
после освобождения структуры метаданных. Чтобы проверить правильность
восстановления, можно попытаться открыть файл в том приложении, в
котором (по вашим предположениям) он был создан. Если новый файл занял
один из блоков удаленного файла и записал в него свои данные, скорее
всего, внутренняя структура файла будет повреждена и открыть его не
удастся.

Многие программы предоставляют функции восстановления файлов. К
сожалению, информация о процедурах, используемых для восстановления при
отсутствии метаданных, практически не публикуется, поэтому вы должны
протестировать и сравнить программы из своего инструментария. В этом вам
помогут тестовые образы на сайте Dti1 (Digital Forensic Tool Testing).

Сжатые и разреженные файлы

Некоторые файловые системы позволяют хранить данные в сжатом формате,
чтобы они занимали меньше места на диске. Сжатие файлов может
происходить как минимум на трех уровнях. На самом высоком уровне данные
сжимаются в файловом формате. В качестве примера можно привести файлы
JPEG: данные графического изображения хранятся в сжатом виде, а
заголовок файла — нет. На следующем уровне внешняя программа сжимает все
содержимое файла и создает новый файл1. Перед использованием сжатый файл
необходимо распаковать в другой файл.

1 Примеры внешних программ сжатия файлов — WinZip ( HYPERLINK
“http://www.winzip.com” www.winzip.com ) и gzip ( HYPERLINK
“http://www.gnu.org/” http://www.gnu.org/ software/gzip/gzip.html).

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

PAGE 181

Последний и самый низкий уровень сжатия — сжатие данных на уровне
файловой системы. В этом случае приложение, записывающее данные, не
знает, что файл будет храниться в сжатом виде. В файловых системах
используются два стандартных метода сжатия. Наиболее очевидное решение —
применение к блокам данных стандартных алгоритмов сжатия, используемых
для файлов. Во втором методе файловая система не выделяет физический
блок данных, который должен быть заполнен одними нулями. Файлы, в
которых пропускаются блоки данных, заполненные одними нулями, называются
разреженными файлами] пример показан на рис. 8.12. Существует несколько
способов реализации разреженных файлов. Например, UFS (Unix File System)
записывает 0 в поле, в котором обычно хранится адрес блока. Ни одному
файлу не может быть выделен блок 0; ОС знает, что ноль означает блок,
заполненный одними нулями.

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

Содержимое файла 2938270192837 0000000000000 0081927314514

Сохраненные данные

2938270192837 0081927314514

Рис. 8.12. Файл хранится в сжатом формате: блоки данных, заполненные
одними нулями, не записываются на диск

Шифрование файлов

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

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

1 Распространенные примеры — PGP ( HYPERLINK “http://www.pgp.com”
www.pgp.com ) и GPG ( HYPERLINK “http://www.gpg.org” www.gpg.org ).

2 Примеры — PGP Disk ( HYPERLINK “http://www.pgp.com” www.pgp.com ),
шифрованные дисковые образы Macintosh ( HYPERLINK “http://www.apple.com”
www.apple.com ) и зашифрованные образы Linux AES.

PAGE 182

Глава 8. Анализ файловых систем

копии незашифрованных данных во временных файлах или свободных блоках
[Casey, 2002; Wolfe, 2004].

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

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

Поиск метаданных

Во многих случаях анализ метаданных выполняется потому, что мы нашли имя
файла, ссылающееся на конкретную структуру метаданных, и хотим получить
дополнительную информацию о файле. Таким образом, нужно найти запись
метаданных и обработать ее. Например, при просмотре содержимого каталога
мы обнаружили файл badstuff.txt и теперь хотим узнать его содержимое и
дату создания. Многие программы автоматически выполняют такого рода
поиск при составлении списков имен файлов в каталогах и позволяют
отсортировать результаты по значениям метаданных.

Конкретная процедура поиска зависит от файловой системы, так как
метаданные могут храниться в разных местах. В TSK для вывода структур
метаданных используется программа istat. На рис. 8.13 изображена
файловая система со структурами метаданных, обнаруженными в блоке 371.
Программа читает блок данных и выводит содержимое двух записей
метаданных. Одна запись представляет удаленный файл, а другая —
существующий каталог.

Блок данных 37

101010101110 100000101011 010101010000 001101001011 101011111100

Удален Тип Размер Время последней записи Блок данных 1 Блок данных 2

Yes File 1 389 Jan 03 2004 03:12:03 300140 0

No Dir 315 668 Jan 03 2004 03:12:15 300 147 300 148

Рис. 8.13. Процесс просмотра содержимого записи метаданных

Просмотр логических файлов

После обнаружения метаданных можно просмотреть содержимое файла; для
этого следует прочитать блоки данных, выделенные файлу. Обычно это
делается при поиске улик в содержимом файла. Допустим, мы определили
адрес блока данных файла badstuff.txt и теперь хотим ознакомиться с его
содержимым.

Этот процесс работает как в категории метаданных, так и в категории
данных содержимого. На рис. 8.14 перечислены блоки данных, связанные с
записями метаданных 1 и 2. Многие графические программы объединяют эту
процедуру

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

PAGE 183

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

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

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

0 1 2 3 4 В в 7 8 9 10 11

Содержимое записи метаданных 1:

Содержимое записи метаданных 2:

2 -,—

3 4 6

5,, III!

Рис. 8.14. Объединение информации из метаданных и блоков данных
позволяет просмотреть содержимое файла

Поиск в логических файлах

Предыдущие методы подразумевают, что вам известен конкретный файл и вы
хотите просмотреть его содержимое. Нередко возникает обратная задача —
найти файл на основании его содержимого (например, найти все файлы,
содержащие слово «ЬгепзюБ»). В таких ситуациях применяется поиск в
логических файлах. Он основан на тех же принципах, что и просмотр
логических файлов, но вместо просмотра содержимого в файле ищется
конкретное значение.

Своим названием этот метод сильно напоминает поиск в логической файловой
системе. Действительно, эти методы очень похожи, только в данном случае
поиск в блоках данных производится в порядке их использования файлами, а
не в порядке их следования в томе. На рис. 8.15 изображены две записи
метаданных и выделенные им блоки данных. В данном случае поиск
осуществляется в блоках 2, 3, 4 и 6 как в едином наборе. Преимущество
такого вида поиска перед поиском в логической файловой системе состоит в
том, что он находит данные, фрагмен-тированные по блокам данных или
секторам. Допустим, мы ищем слово «ЬгепБЮБ», которое начинается в блоке
данных 4 и заканчивается в блоке 6. При поиске в логической файловой
системе оно найдено не будет, потому что оно не содержится в смежных
блоках данных. Разновидностью этого вида поиска является поиск файла с
известным хеш-кодом МБ5 или БНА-!.

PAGE 184

Глава 8. Анализ файловых систем

Не забывайте, что логические адреса файлов присваиваются только
выделенным блокам данных. Это означает, что для поиска того же значения
в свободных блоках данных следует провести поиск в логическом томе.
Например, поиск в логических файлах на рис. 8.15 не затронет блоки 0 и
1, поэтому необходимо провести второй поиск, который включал бы блоки 0,
1, 7, 9, 10, 11 и т. д.

Присутствует ли

строка «йэгепвюэ» Чему равен хеш-код

в этом файле? или МР5 файла?

0 1 2 3 4 В 6 7 8 9 10 11

Содержимое записи метаданных 1:

2 3 4 6

ШІІІіІІІІІІІІ

SICS

ИИ11І

form

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

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

Анализ свободных метаданных

Если поиск проводится в содержимом удаленных файлов, не ограничивайтесь
именами удаленных файлов из содержимого каталога. Примеры будут
приведены в разделе «Категория данных имен файлов», а пока достаточно
сказать, что имя удаленного файла может быть использовано заново прежде,
чем его структура метаданных. Следовательно, ваши улики могут находиться
в свободной записи метаданных, однако вы не увидите их, потому что эта
запись не связана с именем. Многие программы анализа выводят список
свободных записей метаданных для проведения поиска или просмотра. Для
получения списка свободных структур данных в TSK используется программа
Us.

Поиск и сортировка по атрибутам метаданных

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

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

PAGE 185

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

Время обращения к файлу легко изменить в любой системе, но оно часто
содержит полезную информацию. Предположим, мы проверяем гипотезу, что
злоумышленник получил доступ к компьютеру в 20:13 и установил в системе
вредоносный код; для этого можно провести поиск всех файлов, созданных
между 20:13 и 8:23. Если за этот промежуток времени не будет найдено ни
одного подозрительного файла или мы найдем посторонний файл, созданный в
другое время, это означает, что неверно задано время создания файла или
неверна наша гипотеза (а возможно, и то и другое).

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

Некоторые программы составляют временные диаграммы файловых операций.
Как правило, количество точек данных на диаграмме для каждого файла
совпадает с количеством временных штампов. Например, если в метаданных
хранится время последнего обращения, последней записи и последней
модификации, на диаграмме создаются три точки данных. В пакете TSK для
построения временных диаграмм файловых операций используется программа
mactime. Пример выходных данных mactime для каталога HYPERLINK
“file://C:/Windows” C:\Windows :

Wed Aug 11 2004 19:31:58 34528 .a. /system32/ntio804.sys

34392 .a. /system32/ntio412.sys

С..]

Wed Aug 11 2004 19:33:27 2048 mac HYPERLINK
“file:///bootstat.dat” /bootstat.dat

1024 mac /system32/config/default.LOG 1024 mac
/system32/config/software.L0G

Wed Aug 11 2004 19:33:28 262144 ma. /system32/config/SECURITY

262144 ma. /system32/config/default

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

Прежде чем пытаться увязывать временные штампы и записи журналов с
разных компьютеров, необходимо понять, как файловая система хранит
временные штампы. Некоторые временные штампы хранятся в формате UTC; это
означает, что для определения фактического времени необходимо знать
смещение часового пояса, в котором находится компьютер. Например, если я
обращаюсь к файлу в 14:00 в Бостоне, штат Массачусетс, ОС зафиксирует,
что обращение произошло в 19:00 в формате UTC, потому что Бостон смещен
на пять часов назад по отношению к времени UTC. Когда эксперт будет
анализировать файл, он должен преобразовать 19:00 к местному времени. В
других файловых системах время хранится с учетом местного часового
пояса, и в данном примере в них будет храниться значение 14:00. У
некоторых программ также возникают проблемы с летним временем.

PAGE 186

Глава 8. Анализ файловых систем

Еще одна стандартная задача — поиск файлов, в которые некоторому
пользователю разрешена запись. Результат поиска покажет, какие файлы
могли быть созданы подозреваемым (предполагается, что ОС соблюдает
разрешения доступа, а подозреваемый не имеет прав администратора). Также
возможно проведение поиска по идентификатору владельца. Обычно такие
операции используются при расследовании действий конкретного
пользователя.

Если ранее мы провели поиск в логической файловой системе и обнаружили
интересные данные в одном из блоков, можно попытаться найти адрес этого
блока в метаданных. Возможно, поиск покажет, какому файлу был выделен
блок данных, после чего можно будет найти другие блоки данных,
принадлежащие тому же файлу. Пример показан на рис. 8.16; улики были
обнаружены в блоке данных 34. Поиск в метаданных показывает, что блок
был выделен структуре 107 наряду с блоками данных 33 и 36. Если ОС не
стирает адреса при удалении файлов, этот процесс также поможет найти
освободившуюся запись метаданных. Программа 1*гтс1 из пакета ТБК
выполнит эту работу за вас.

Структуры метаданных

105 Блоки: 03,04,05,10

106 Блоки: 38,39,40

107 Блоки: 30,33,34

108 Блоки: 36

31 32 33 34 35 36 37 38

Рис. 8.16. Поиск в структурах метаданных позволит узнать, какой из них
был выделен заданный блок данных

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

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

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

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

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

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

187

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

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

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

Методы надежного удаления

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

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

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

Один из важных этапов анализа имен файлов — определение местонахождение
корневого каталога, необходимого для поиска файла по полному имени.
Например, в Windows каталог С:\ является корневым каталогом диска С:. В
каждой файловой системе используется свой способ определения
местонахождения корневого каталога.

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

В этом разделе мы рассмотрим общие концепции категории имен файлов. Эта
категория относительно проста; нас интересует только метод
восстановления файлов по именам.

PAGE 188

Глава 8. Анализ файловых систем

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

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

На рис. 8.17 показаны два имени файлов и три записи метаданных. Файл
favo-rites.txt удален, а его имя ссылается на свободную запись
метаданных. Мы можем попытаться восстановить его содержимое, используя
методы восстановления по метаданным. Обратите внимание: содержимое,
связанное с записью метаданных 2, тоже можно восстановить, но его имя
уже утрачено. В этом разделе рассматриваются некоторые проблемы,
связанные с восстановлением файлов по именам.

badstuff.txt

г

Запись метаданных 1

Запись метаданных 2

0 1 2 3 А 5 6 7 8 9 10 11

Выделено

Свободно

Рис. 8.17. Поиск в структурах метаданных позволит узнать, какой из них
был выделен заданный блок данных

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

Допустим, имеется файл, в структуре имени файла которого присутствует
имя fUel.dat; структура ссылается на запись метаданных 100 (рис. 8.18
(А)). Файл был удален, а обе структуры (имени файла и метаданных) были
освобождены, однако указатель в структуре имени файла не был стерт.
Новый файл fUe2.dat создается в новой структуре данных, и ему заново
выделяется запись метаданных 100 (рис. 8.18 (В)). Позднее файл file2.dat
также был стерт, а его структуры имени файла и метаданных освободились
(рис. 8.18 (С)). Если проанализировать систему в этом состоянии, мы
найдем в ней две структуры имени файла, ссылающиеся на одну запись
метаданных. Неизвестно, какому файлу принадлежит содержимое, адрес
которого хранится в записи метаданных 100— filel.dat или file2.dat.

Категория имен файлов 189

А)

Запись 100

Блок данных 1000

В)

file1.dat

к,

Блок данных 1000

Запясь100 (file2.dat) -?

С)

file1.dat

file2.dat

Блок данных 1 000 (file2.dat)

Запись 100 (file2.dat) -?

| Свободно |

Выделано

Рис. 8.18. Последовательность состояний при создании и удалении файлов:
в состоянии (В) две структуры имен файлов ссылаются на одну структуру
метаданных. Невозможно определить, к какой из них относится содержимое
файла

Чтобы ситуация стала еще более запутанной, продолжим этот пример. Файл
file3.dat создается в новой записи метаданных 200 и блоке данных 1000 из
предыдущего примера (рис. 8.19 (А)). Файл file3.dat удаляется, и
структура имени файла передается файлу file4.dat (который нас не
интересует). Затем создается файл file5.dat с записью метаданных 100 и
блоком данных 1000 (рис. 8.19 (С)). Файл file5.dat тоже удаляется.
Наконец, создается файл file6.dat, которому повторно выделяется та же
структура имени файла, что и file5.dat, но этот файл использует новую
запись метаданных 300 и новый блок данных 2000 (рис. 8.19(С)).

А)

file1.dat

file2.dat

fl1e3.dat

Запись 200

Запись 100

Блок данных

(file2.dat) * 1000 (file3.dat)

/

В)

file1.dat

file2.dat

ь ЗаписЫОО —Р Блок данных

, (fHe5.dat}

1000 (fife5.dat)

/

Запись 200 (file3.dat)

С)

file1.dat

file2.dat

№4М

ffle6.dat

Запись 200 (file3.dat)

Запись 300 (file6.dat)

Запись 100 (file5.dat)

-? Блок данных 1 000 (file5.dat)

Блок данных 2 000

Свободно

Рис. 8.19. Последовательность состояний при создании и удалении файлов:
в состоянии (С) нарушается синхронизация некоторых указателей

PAGE 190

Глава 8. Анализ файловых систем

Предположим, что система анализируется в этом состоянии. Мы сталкиваемся
со следующими проблемами:

• На блок данных 1000 ссылаются две записи метаданных, и мы не знаем,
какая из них была последней; также неизвестно, существовали ли другие
записи метаданных, ссылавшиеся на нее с момента повторного выделения.

• На запись метаданных 100 ссылаются две структуры имен файлов, и мы не
знаем, какая из них была последней; также неизвестно, существовали ли
другие записи, ссылавшиеся на нее с момента повторного выделения. В
нашем примере последним был файл file5.dat, но он более не существует.

• На запись метаданных 200 не ссылается ни одна структура имени файла,
поэтому мы не можем определить имя хотя бы одного файла, которому она
была выделена.

Эти проблемы могут повлиять на работу эксперта в нескольких отношениях.
Представьте программу анализа, которая читает список файлов в каталоге и
выводит рядом с каждым именем соответствующие временные штампы.
Информация о времени и содержимом filel.dat и file2.dat будет неверной,
потому что она в действительности относится к файлу file5.dat, имя
которого более не существует. Значения, связанные с записью метаданных
200, не будут присутствовать в списках файлов, потому что с этой записью
не связана структура имени. Именно из-за таких ситуаций я разделил
категории имен файлов и метаданных; было бы неправильно считать, что
между ними существует более тесная связь.

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

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

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

Получение списка имен файлов

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

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

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

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

191

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

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

Эта методика поддерживается большинством программ анализа, причем многие
программы объединяют информацию из категории имен файлов с информацией
из категории метаданных — например, чтобы в одном представлении с
именами файлов выводились пометки даты и времени. На рис. 8.20 показан
пример анализа: при обработке блока данных 401 были обнаружены два
имени. Нас интересует файл favorites.txt; мы видим, что его метаданные
находятся в записи 3. В нашей файловой системе соответствующая структура
метаданных находится в блоке данных 200. Мы обрабатываем информацию из
соответствующего блока данных, получая размер и адреса содержимого этого
файла.

Блок данных 401

101010101110 100000101011 010101010000 001101001011 101011111100

Блок данных 1

Удален Имя Метаданные

No badstuff.txt 1

Yes favorites.txt 3

101000110111 010001010101 010010010101 101101011011 100101110001

Удален Тип Размер Последняя запись Блок данных 1 Блок данных 2

N0 File 2 001 Jan03,2004 03:12:03 1 003 1 004

Рис. 8.20. Чтобы получить список имен файлов, мы обрабатываем содержимое
каталога и извлекаем имена (а иногда и связанные с ним метаданные)

Данный метод анализа поддерживается многими программами. В пакете TSK
для вывода имен существующих и удаленных файлов используется программа
fis.

Поиск имен файлов

Список имен файлов удобен в том случае, если вы знаете имя искомого
файла, но это не всегда так. Если полное имя файла неизвестно, можно
провести поиск по известной части. Например, мы можем знать расширение
файла или его имя, но без каталога. В результате поиска выводится список
файлов, удовлетворяющих критерию поиска. Скажем, если в ситуации на рис.
8.20 провести поиск по расширению .txt, программа просмотрит каждую
запись и выведет как badstuff.txt, так

PAGE 192

Глава 8. Анализ файловых систем

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

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

Другая разновидность поиска в этой категории — поиск имени файла,
которому была выделена заданная запись метаданных. Это может быть
необходимо, если вы обнаружили улики в блоке данных, а затем нашли
структуру метаданных, которой он был выделен. После обнаружения
структуры метаданных среди имен файлов ищется полное имя файла, которому
был выделен блок с уликами. Задача решается программой ггтс! пакета ТБК.

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

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

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

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

Методы надежного удаления

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

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

Категория прикладных данных

В некоторых файловых системах хранятся данные, традиционно относящиеся к
прикладной категории. Эти данные не являются необходимыми для файловой

Методы поиска на прикладном уровне

193

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

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

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

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

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

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

Журналы файловой системы могут пригодиться при расследованиях, хотя до
настоящего времени они еще не использовались в полной мере. В журналах
содержится информация о недавно происходивших событиях файловой системы,
а эта информация может помочь при реконструкции недавнего инцидента.
Большинство программ анализа не обрабатывает содержимое журналов
файловой системы. В пакет TSK входят программы jls и jcat, выводящие
содержимое некоторых журналов.

Методы поиска на прикладном уровне

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

PAGE 194

Глава 8. Анализ файловых систем

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

Оба метода основаны на том факте, что многие файлы имеют четко
определенный формат и включают сигнатуру, уникальную для данного типа
файла. Сигнатура может использоваться для определения типа неизвестного
файла. Команда file, присутствующая во многих системах семейства UNIX,
содержит базу данных сигнатур для идентификации структуры неизвестных
файлов ( HYPERLINK “http://ftp.astron.com/pub/fiLe”
ftp://ftp.astron.com/pub/fiLe ).

Восстановление файлов на прикладном уровне

Извлечением данных (data carving) называется процесс поиска во фрагменте
данных начальной и конечной сигнатуры для известных типов файлов. В
результате строится список файлов, содержащих одну из сигнатур. Как
правило, эта процедура выполняется со свободным пространством файловой
системы и позволяет аналитику восстанавливать файлы, на которые не
ссылается ни одна структура метаданных. Например, изображение в формате
JPEG содержит стандартный заголовок и завершитель. Если аналитику
потребуется восстановить удаленные графические изображения, он сохранит
в файле содержимое свободных блоков и запустит программу извлечения
данных. Программа ищет заголовки JPEG и извлекает данные, находящиеся
между заголовком и завершителем.

Примером программы, выполняющей такую операцию, является программа
foremost ( HYPERLINK “http://foremost.sourceforge.net”
http://foremost.sourceforge.net ), разработанная специальными агентами
Крисом Кендаллом (Kris Kendall) и Джессе Корнблумом (Jesse Kornblum) из
Бюро специальных расследований ВВС США. Программа foremost анализирует
файловую систему или дисковый образ на основании содержимого
конфигурационного файла, в котором создается запись для каждой
сигнатуры. В записи указывается известное значение заголовка,
максимальный размер файла, признак учета регистра символов в заголовке,
типичное расширение этого типа файлов и необязательный завершитель.
Например, для файлов JPEG запись выглядит так: jpg у 2000000
HYPERLINK “file:///xff/xd8” \xff\xd8 HYPERLINK “file:///xff/xd9”
\xff\xd9

Это означает, что файл имеет типичное расширение .jpg, в его заголовке и
завершителе учитывается регистр символов, заголовок равен 0xffd8, а
завершитель — 0xffd9. Максимальный размер файла составляет 200 000 байт,
и если заголовок не найден в пределах этого смещения, извлечение данных
прерывается. В наборе данных на рис. 8.21 заголовок JPEG расположен в
двух первых байтах сектора 902, а завершитель — в середине сектора 905.
Содержимое секторов 902,903,904 и в начале сектора 905 извлекается как
изображение JPEG.

Сектор 901 Сектор 902 Сектор 903 Сектор 904 Сектор 905 Сектор 906

0xffd8…

…0xffd9

Рис. 8.21. Блоки физических данных, анализ которых обнаруживает
графическое изображение в формате JPEG в секторах 902-905

Аналогичная программа Lazarus из пакета The Coroner’s Toolkit (
HYPERLINK “http://www.porcu-” http://www.porcu- HYPERLINK
“http://pine.org/forensics/tct.htmL” pine.org/forensics/tct.htmL ),
автор — Дэн Фармер (Dan Farmer), просматривает

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

PAGE 195

каждый сектор низкоуровневого образа и выполняет для него команду file.
В результате создаются группы смежных секторов, относящихся к одному
типу. Конечный результат работы программы представляет собой список с
указанием каждого сектора и его типа. Фактически программа дает
возможность сортировать данные по их содержимому. Концепция интересная,
однако программа написана на Perl и иногда работает довольно медленно.

Сортировка файлов по типу

Тип файлов может использоваться для упорядочения файлов в файловой
системе. Если вы ищете файлы конкретного типа, отсортируйте их на
основании структуры содержимого. Например, для каждого файла можно
выполнить команду file и сгруппировать однотипные файлы: в одну группу
входит графика, в другую — исполняемые файлы, и т. д. Такая возможность
предусмотрена во многих программах анализа, но не всегда ясно, как
осуществляется сортировка: по расширению или по сигнатуре файла.
Программа sorter из пакета TSK сортирует файлы по сигнатуре.

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

В оставшихся главах книги мы рассмотрим способы хранения данных в
системах FAT, NTFS, Ext2/Ext3 и UFS и применим к ним структуру из пяти
категорий. В табл. 8.1 приведены имена структур данных в каждой
категории данных для файловых систем, описанных в книге.

Таблица 8.1. Структуры данных в файловых системах, описанных в книге
(деление по категориям)

Файловая Содержимое Метаданные Имя файла Прикладные

система

данные

ExtX Суперблок, Блоки, битовая I-узлы, карта Записи Журнал

дескриптор карта блоков i-узлов, каталога

группы

расширенные атрибуты

FAT Загрузочный сектор, Кластеры, FAT Записи каталога, FAT Записи
каталога

NTFS $Воо^ Кластеры, $MFT, $mfTMirr, $FILE NAME, Дисковые

$\/о1ите, $Bitmap $STANDARD $IDX ROOT, квоты,

$А«Юег

INFORMATION,

$DATA,

$ ATTRIBUTE

LIST, $SECURITY

DESCRIPTOR $IDX

ALLOCATION, $ BITMAP журнал, журнал изменений

UFS Суперблок, Блоки, фраг- I-узлы, карта Записи —

дескриптор менты, битовая карта блоков, битовая карта фрагментов
i-узлов, расши- каталога

группы

ренные атрибуты

PAGE 196

Глава 8. Анализ файловых систем

Существуют и другие файловые системы, которые не вошли в книгу, но могут
встретиться в вашей работе. Например, HFS+ — стандартная файловая
система компьютеров Apple. Компания Apple опубликовала структуры данных
и подробности строения файловой системы [Apple, 2004]. ReiserFS — одна
из файловых систем Linux, по умолчанию используемая некоторыми
дистрибутивами (например, SUSE [Reiser, 2003]). В стандартной
документации ReiserFS приводится мало информации о структурах данных,
эти структуры документировали Флориан Бух-гольц (Florian Bucholz) [2003]
и Герсон Курц (Gerson Kurz) [2003]. Еще одна файловая система для Linux
— JFS ( Journaled File System) — была разработана в IBM (не путайте ее с
файловой системой JFS, разработанной IBM для AIX). IBM документировала
структуру файловой системы [IBM, 2004].

Итоги

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

Таблица 8.2. Выбор метода поиска в зависимости от типа искомых улик
Требуется найти Категория данных Метод поиска

Файл по имени, расширению или каталогу

Существующий или удаленный файл по временным штампам

Существующий файл по значению, присутствующему в содержимом

Существующий файл по хеш-коду БНА-1

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

Свободные данные по содержимому (без учета типа приложения)

Имя файла

Имя файла и метаданные

Поиск по имени файла или вывод

содержимого каталога

Поиск по атрибутам метаданных

Имя файла (с использованием метаданных и данных содержимого) Имя файла
(с использованием метаданных и данных содержимого) Имя файла (с
использованием метаданных и данных содержимого)

Прикладные данные и содержимое

Данные содержимого

Поиск по логическим файлам

Поиск по логическим файлам с хеш-кодами

Поиск по логическим файлам с восстановлением по метаданным и поиском в
логической файловой системе

Восстановление на прикладном

уровне (извлечение данных)

в свободных блоках

Поиск в логической файловой

системе

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

197

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

• Apple. «Technical Note TNI 150-HFS Plus Volume Format». March 2004.
HYPERLINK “http://” http:// HYPERLINK
“http://developer.apple.com/technotes/tn/tnll50.htmL”
developer.apple.com/technotes/tn/tnll50.htmL

• Buchholz, Florian, «The Structure of the Reiser File System». August
17, 2003. HYPERLINK
“http://www.cerias.purdue.edu/homes/florian/reiser/reiserfs.php”
http://www.cerias.purdue.edu/homes/florian/reiser/reiserfs.php .

• Carrier, Brian. «Digital Forensic Tool Testing Images», 2004.
HYPERLINK “http://dftt.source-” http://dftt.source- HYPERLINK
“http://forge.net” forge.net .

• Casey, Eoghan. «Practical Approaches to Recovering Encrypted Digital
Evidences International Journal of Digital Evidence, 1 (3), 2002.
HYPERLINK “http://www.ijde.org” http://www.ijde.org .

• IBM. «Journaled File System Technology for Linux». 2004. HYPERLINK
“http://www.ibm.com/” http://www.ibm.com/ developerworks/oss/jfs/.

• Kruse, Warren. «Computer Forensics Primer». CSI 30th Annual Computer
Security Conference, November 3, 2003. HYPERLINK
“http://csiannual.com/classes/jl.pdf”
http://csiannual.com/classes/jl.pdf .

• Kurz, Gerson. «ReiserFS Docs», 2003. HYPERLINK
“http://p-nand-q.com/download/rfstool/rei-”
http://p-nand-q.com/download/rfstool/rei- serfs_docs.html.

• Reiser, Hans. «Reiser4». 2003. HYPERLINK “http://www.namesys.com”
http://www.namesys.com .

• Wolfe, Hank. «Penetrating Encrypted Evidence*. Journal of Digital
Investigation, 1(2), 2004.

FAT: основные концепции и анализ

FAT (File Allocation Table) — одна из простейших файловых систем,
встречающихся во многих операционных системах. FAT является основной
файловой системой операционных систем Microsoft DOS и Windows 9х, но в
NT, 2000 и ХР по умолчанию используется система NTFS (New Technologies
File System), которая будет рассмотрена позднее. FAT поддерживается
всеми версиями Windows и многими системами UNIX, и экспертам еще
придется иметь с ней дело в течение нескольких лет (несмотря на то, что
FAT уже не является стандартной файловой системой настольных систем
Windows). FAT часто встречается в картах памяти цифровых фотоаппаратов и
«брелоковых дисках» USB. Многие пользователи знакомы с основными
концепциями FAT, но не знакомы с основными «тайниками» для скрытия
данных, проблемами адресации и другими нетривиальными аспектами. В этой
главе будут представлены общие концепции и методы анализа FAT на основе
модели данных с пятью категориями. Низкоуровневые структуры данных будут
описаны в главе 10. Вы можете читать эти главы параллельно, одну за
другой или пропустить описания структур данных.

Введение

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

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

Категория файловой системы

PAGE 199

файла и другие метаданные. Содержимое файлов и каталогов хранится в
блоках данных, называемых кластерами. Если файлу или каталогу выделяется
более одного кластера, остальные кластеры находятся при помощи структуры
данных, называемой FAT. Структура FAT используется как для идентификации
следующих кластеров в файлах, так и для определения состояния выделения
кластеров. Таким образом, она задействована как в категории содержимого,
так и в категории метаданных. Существует три версии FAT: FAT12, FAT16 и
FAT32. Они отличаются друг от друга прежде всего размером записей в
структуре FAT. Мы изучим связи между структурами данных более подробно,
а их общая схема показана на рис. 9.1.

Записи каталогов

Кластеры

Структура FAT

Кластер 34

file1.dat 4 000 байт Кластер 34 —i

35 EOF

Кластер 35

Рис. 9.1. Отношения между записями каталогов, кластерами и FAT

Файловая система FAT делится на три физические области (рис. 9.2).
Первая область называется зарезервированной; в ней хранятся данные из
категории файловой системы. В FAT12 и FAT16 зарезервированная область
занимает всего 1 сектор, но формально ее размер определяется в
загрузочном секторе. Вторая область — область FAT — содержит основные и
резервные структуры FAT. Она начинается в секторе, следующем за
зарезервированной областью, а ее размер определяется количеством и
размером структур FAT. Третья область — область данных — содержит
кластеры, выделяемые для хранения файлов и содержимого каталогов.

Зарезервированная Область Область область FAT данных

Рис. 9.2. Физическая структура файловой системы FAT

Категория файловой системы

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

PAGE 200

Глава 9. FAT: основные концепции и анализ

Общие концепции

В файловой системе FAT данные, относящиеся к категории файловой системы,
хранятся в структуре данных загрузочного сектора. Загрузочный сектор
располагается в первом секторе тома и является частью зарезервированной
области файловой системы. Microsoft называет некоторые данные первого
сектора блоком параметров BIOS, или ВРВ (BIOS Parameter Block), но для
простоты я буду использовать термин загрузочный сектор.

Загрузочный сектор содержит данные, принадлежащие ко всем категориям
модели, поэтому их описание откладывается до рассмотрения
соответствующих категорий. Не существует поля, которое идентифицировало
бы версию файловой системы (FAT12, FAT16 или FAT32). Тип определяется
только вычислениями с данными загрузочного сектора. Я приведу формулу в
конце главы, потому что в ней задействованы некоторые концепции, которые
мы еще не рассматривали.

В FAT32 загрузочный сектор содержит дополнительные данные, в том числе
адрес резервной копии загрузочного сектора, а также основной и
дополнительный номера версии. Резервная копия загрузочного сектора
используется при повреждении версии в секторе 0; согласно документации
Microsoft она всегда должна находиться в секторе 6, чтобы при
повреждении стандартного экземпляра программы могли автоматически найти
ее. Структура данных загрузочного сектора рассматривается в главе 10.

Файловые системы FAT32 также содержат структуру данных FSINFO с
информацией о местонахождении следующего доступного кластера и общем
количестве свободных кластеров. Точность этих данных не гарантирована;
они всего лишь служат рекомендацией для операционной системы. Их
структуры данных описаны в следующей главе.

Необходимые данные загрузочного сектора

Одной из первых задач при анализе файловой системы FAT должна стать
идентификация трех физических областей. Зарезервированная область
начинается в секторе 0 файловой системы, а ее размер указан в
загрузочном секторе. В FAT 12/16 она обычно занимает всего 1 сектор, а в
FAT32 для нее резервируются несколько секторов.

Область FAT содержит одну или несколько структур FAT и начинается в
секторе, следующем за зарезервированной областью. Ее размер вычисляется
умножением количества структур FAT на размер одной структуры; оба
значения хранятся в загрузочном секторе.

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

Структура области данных в FAT 12/16 и FAT32 несколько различается. В
FAT 12/16 начало области данных зарезервировано для корневого каталога,
а в FAT32 корневой каталог может находиться в произвольном месте области
данных (хотя обычно он все же находится в начале). Динамический размер и
местонахождение корневого каталога позволяют FAT32 адаптироваться к
появлению

Категория файловой системы

PAGE 201

поврежденных секторов в начале области данных и увеличивать размер
каталога до необходимого размера. Корневой каталог FAT 12/16 обладает
фиксированным размером, заданным в загрузочном секторе. Начальный адрес
корневого каталога FAT32 хранится в загрузочном секторе, а его размер
определяется по структуре FAT. На рис.9.3 показаны разные поля
загрузочного сектора, используемые для определения структуры файловых
систем FAT12/16 и FAT32.

FAT12/16

Зарезервированная область

е Корневой Область каталог FAT і

Область данных

Зарезервированные секторы

Количество FAT* Размер FAT

Количество записей корневого каталога

Количество секторов в файловой системе

FAT32

Зарезервированная область

Область FAT

Корневой каталог

Область данных

Зарезервированные секторы

Количество FAT* Размер FAT

Начальный адрес корневого каталога

Количество секторов в файловой системе

Рис. 9.3. Структура файловой системы FAT и данные загрузочного сектора,
используемые для вычисления начальных адресов и размеров

Вспомогательные данные загрузочного сектора

Помимо информации о структуре системы в загрузочном секторе хранится
много вспомогательных данных. Эти данные не являются необходимыми для
сохранения и чтения файлов, существуют исключительно для удобства и
могут содержать неверную информацию. Одно из таких значений — строка из
8 символов, называемая меткой OEM. В ней может храниться обозначение
системы, создавшей экземпляр FAT, но это значение не является
обязательным. Например, система Windows 95 заносит в это поле строку
«MSWIN4.0», Windows 98 — строку «MSWIN4.1», а Windows ХР и 2000 —
«MSDOS5.0». Я выяснил, что команда Linux mkfs.msdos заполняет его
строкой mkdosfs, некоторые флэш-диски USB записывают случайные данные, а
некоторые карты памяти цифровых фотоаппаратов используют имена,
напоминающие модель камеры. Значение можно легко изменить в
шестнадцатеричном редакторе, но оно поможет определить, на каком типе
компьютера была отформатирована дискета. Некоторые версии Windows
требуют, чтобы значение было обязательно задано.

PAGE 202

Глава 9. FAT: основные концепции и анализ

Файловым системам FAT назначается 4-байтовый серийный номер тома,
который в соответствии со спецификацией Microsoft определяется временем
создания файловой системы с использованием текущего времени, хотя
операционная система, создающая файловую систему, может задать любое
значение. Тестирование показало, что разные версии Windows ведут себя
по-разному. Так, система Windows 98 вела себя так, как сообщает Крейг
Уилсон (Craig Wilson) [Wilson, 2003]: серийный номер представлял собой
результат сложения полей даты и времени в определенном порядке. Формула
приводится в разделе «Загрузочный сектор» главы 10. В Windows ХР этот
алгоритм не использовался. Windows использует серийный номер тома при
работе со съемными носителями и определяет факт замены диска.

Также в загрузочном секторе присутствует поле из 8 символов, содержащее
строку «FAT12», «FAT16», «FAT32» или «FAT». Большинство систем,
создающих экземпляры FAT, корректно заполняют эту строку, но это не
обязательно. Существует только один способ определения фактического типа
системы — вычисление по формуле, к которой мы придем позже. Последним
идентификационным маркером является 11-символьная метка тома, которую
вводит пользователь при создании файловой системы. Метка тома также
хранится в корневом каталоге файловой системы. Я заметил, что при
добавлении метки тома в ХР она записывается только в корневой каталог,
но не в загрузочный сектор.

Загрузочный код

Загрузочный код в файловой системе FAT чередуется со структурами данных
файловой системы [Microsoft, 2003е]. В этом FAT отличается от файловых
систем UNIX, где используется полностью изолированный загрузочный код.
Первые три байта загрузочного сектора содержат машинный код команды
перехода, которая заставляет процессор обойти конфигурационные данные и
передать управление основному загрузочному коду. Как будет видно из
структуры данных в следующей главе, загрузочный сектор занимает 512
байт, причем байты 62-509 в FAT12/16 и байты 90-509 в FAT32 не
используются. Эти байты содержат загрузочный код, а в F АТ32
дополнительный загрузочный код может находиться в секторах, следующих за
загрузочным сектором.

Файловые системы FAT обычно содержат загрузочный код даже в том случае,
если они не являются загрузочными — в этом случае код выводит сообщение
о том, что для загрузки системы следует вставить другой диск.
Загрузочный код FAT получает управление от загрузочного кода MBR,
находит и загружает нужные файлы операционной системы.

Пример образа

В этом разделе я воспользуюсь данными из тестового образа FAT32. В пакет
TSK (The Sleuth Toolkit) входит программа fsstat, которая выводит
большую часть данных из категории файловой системы. Пример результата,
выданного программой fsstat для тестового образа:

# fsstat -f fat fat-4.dd FILE SYSTEM INFORMATION

File System Type: FAT OEM Name: MSDOS5.0 Volume ID: 0x4cl94603

Категория файловой системы

PAGE 203

Volume Label (Boot Sector): NO NAME Volume Label (Root Directory): FAT
DISK File System Type Label: FAT32

Backup Boot Sector Location: 6 FS Info Sector Location: 1 Next Free
Sector (FS Info): 1778 Free Sector Count (FS Info): 203836 Sectors
before file system: 100800

File System Layout (in sectors) Total Range: 0 – 205631

* Reserved: 0 – 37 ** Boot Sector: 0

** FS Info Sector: 1 ** Backup Boot Sector: 6

* FAT 0: 38 – 834

* FAT 1: 835 – 1631

* Data Area: 1632 – 205631

** Cluster Area: 1632 – 205631 *** Root Directory: 1632 – 1635

CONTENT-DATA INFORMATION

Sector Size: 512

Cluster Size: 1024

Total Cluster Range: 2 – 102001

[REMOVED]

Из листинга видно, что первой копии FAT предшествуют 38
зарезервированных секторов. В зарезервированной области находится
резервная копия загрузочного сектора и структура данных FSINFO. В
файловой системе находится две структуры FAT, расположенные в секторах
38-834 и 835-1631. Область данных начинается в секторе 1632 и состоит из
1024-байтовых кластеров.

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

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

Для определения конфигурации файловой системы FAT необходимо найти и
обработать загрузочный сектор, структуры данных которого приведены в
главе 10. Обработка загрузочного сектора упрощается тем, что он
находится в первом секторе файловой системы и содержит простейшие поля.
Существует две версии загрузочного сектора, причем обе хорошо
документированы. На основании данных из загрузочного сектора вычисляется
местонахождение зарезервированной области, области FAT и области данных.

Структура данных FAT32 FSINFO также может предоставить некоторые
сведения о недавно выполненных операциях; ее местонахождение указано в
загрузочном секторе. Как правило, FSINFO хранится в секторе 1 файловой
системы. В FAT32 также существуют резервные копии обеих структур данных.

PAGE 204

Глава 9. FAT: основные концепции и анализ

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

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

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

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

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

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

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

При обыске в доме подозреваемого в шкафу был найден жесткий диск. В
процессе снятия данных выяснилось, что первые 32 сектора диска
повреждены и прочитать их не удастся. Вероятно, подозреваемый положил
диск в шкаф после сбоя и воспользовался новым диском, но мы хотим
проанализировать старый диск на наличие улик. На компьютере
подозреваемого установлена система Windows ME, соответственно,
используется файловая система FAT. Этот сценарий показывает, как найти
файловую систему далее в том случае, если таблицы разделов не
существует.

Чтобы найти начало файловой системы FAT, мы проведем поиск по сигнатурам
0x55 и ОхАА в последних двух байтах загрузочного сектора. При проведении
только одного поиска следует ожидать большого количества ложных
совпадений. Если диск заполнен случайными данными, можно ожидать, что
сигнатура будет встречаться

Категория файловой системы

PAGE 205

каждые 65 536 секторов. Для уменьшения количества ложных совпадений
можно увеличить сигнатуру или использовать другие данные. Сценарий
показывает, что второй способ хорошо подходит для FAT32, потому что
шаблон сигнатур хранится в зарезервированной области файловой системы.
Конечно, программы автоматизированного поиска сделали бы то же самое
быстрее, но мы выполним поиск вручную.

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

# sigfind -о 510 55АА disk-9.dd

Block size: 512 Offset: 510

Block: 63 (-)

Block: 64 (+1)

Block: 65 (+1)

Block: 69 (+4)

Block: 70 (+1)

Block: 71 (+1)

Block: 75 (+4)

Block: 128504 (+128429)

Block: 293258 (+164754)

[…]

Первый экземпляр сигнатуры найден в секторе 63; это логично, потому что
первый раздел обычно начинается в секторе 63. Мы читаем содержимое
сектора и отображаем его на структуру данных загрузочного сектора.
Выясняется, что в секторе 6 хранится резервная копия загрузочного
сектора, а в секторе 1 файловой системы — структура FSINFO. Также мы
узнаем, что файловая система содержит 20 482 812 секторов. Структура
данных FSINFO имеет такую же сигнатуру, как и загрузочный сектор,
поэтому в секторе 64 тоже найдено совпадение.

Совпадения также обнаруживаются в секторах 69 и 70, содержащих резервные
копии загрузочного сектора и FSINFO на расстоянии шести секторов от
оригинала. Блоки 65 и 71 заполнены нулями (кроме сигнатур). Совпадение в
блоке 128 504 оказывается ложным; при просмотре мы видим случайные
данные. Таким образом, на основании информации о расположении
загрузочного сектора и относительного местонахождения резервных копий
можно сделать вывод, что файловая система занимает на диске секторы с 63
по 20 482 874. Теперь можно просмотреть остальные совпадения в выходных
данных sigfind: […]

Block: 20112453 (+27031) Block: 20482875 (+370422)

Block: 20482938 (+63) Block: 20482939 (+1) Block: 20482940 (+1) Block:
20482944 (+4) Block: 20482945 (+1) Block: 20482946 (+1) Block: 20482950
(+4) Block: 20513168 (+30218)

В пропущенной части были многочисленные ложные совпадения. Мы видим, что
в секторе 20 482 875 обнаружено совпадение. Этот сектор находится за
концом

PAGE 206

Глава 9. FAT: основные концепции и анализ

предыдущей файловой системы, которая завершается в секторе 20 482 874.
Однако закономерность совпадений, начиная с сектора 20 482 875,
отличается от предыдущих: следующее совпадение найдено со смещением 63
сектора, а потом следуют несколько близких совпадений. Просматриваем
сектор 20 482 875 и выясняем, является ли совпадение ложным:

# dd if

0000000

0000016

0000032

0000048

[…]

0000416

0000432

0000448

0000464

0000480

0000496

disk-9.dd bs=512 skip=20482875 count=l | xxd

088c 039a 5f78 7694 8f45 bf49 e396 OOcO …._xv..E.I….

889d ddcO 6d36 60df 485d adf7 46dl 3224 … .m6\H]. .F.2$

3829 95cd ad28 d2a2 dc89 f357 d921 cfde 8)…(…..W.!..

df8e lfd3 303e 8619 641e 9c2f 95b4 d836 ….0>..d../…6

3607 e7be 1177 db5f llc9 fbal c913 la3d da81 143d 00c7 7083 9d42 330c
0287 0001 clff Obfe ffff 3f00 0000 fc8a 3801 0000 clff 05fe ffff 3b8b
3801 7616 7102 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 55aa

.w.

.B3..

3.v.q.

.U.

Совпадение легко принять за ложное, но обратите внимание на четыре
завершающие строки и вспомните, о чем говорилось в главе 5 при
обсуждении разделов DOS. Этот сектор содержит расширенную таблицу
разделов, а таблица начинается с сектора 446. В таблицах разделов DOS
используется та же сигнатура, что и в загрузочных секторах FAT.
Обработав две ненулевые записи таблицы, мы узнали бы, что раздел FAT32
находится в секторах 20 482 938-40 965 749, а расширенный раздел — в
секторах 40 965 750-81 931 499. Это подтверждает результаты sigfind:
совпадение было найдено в секторе 20 482 938, а затем еще несколько
совпадений со смещениями 1, 6 и 7 секторов для структуры данных FSINFO и
резервных копий. На рис. 9.4 показано графическое представление этого
примера. На нем изображены две файловые системы, обнаруженные нами, а
также некоторые ложные совпадения и расширенные таблицы разделов.

FAT32 #1

FAT32 #2

Загрузочный Ложные сектор, FSINFO совпадения и резервные копии

Сектор с сигнатурой загрузочного сектора

Раширенная Загрузочный Ложные Раширенная

таблица сектор, совпадения таблица

разделов 1 Р81ЫРО разделов 2 и резервные копии

Рис. 9.4. Результаты поиска сигнатуры загрузочного сектора FAT на диске,
не содержащем таблицы разделов

Этот пример показывает, что файловую систему FAT32 можно найти при
наличии загрузочного сектора. Поиск 2-байтовой сигнатуры выдает много
ложных совпадений, но FAT32 несколько упрощает задачу, потому что мы
ожидаем найти совпадения со смещением 1,6 и 7 секторов от структуры
данных FSINFO и резервных копий. С FAT 12/16 дело обстоит сложнее;
резервные структуры в этих системах

Категория содержимого

PAGE 207

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

Категория содержимого

К этой категории относятся данные, составляющие содержимое файла или
каталога. В файловой системе FAT блоки данных называются кластерами.
Кластер (cluster) представляет собой группу смежных секторов, количество
которых равно степени 2 — например, 1,2,4,8,16,32 или 64. Согласно
спецификации Microsoft, максимальный размер кластера равен 32 Кбайт.
Каждому кластеру присваивается адрес; для первого кластера он равен 2.
Другими словами, кластеров с адресами О и 1 не существует. Все кластеры
находятся в области данных файловой системы, последней из трех областей.

Поиск первого кластера

Найти первый кластер (с адресом 2) сложнее, чем кажется на первый
взгляд, потому что он расположен не в начале файловой системы; кластер
находится в области данных. В зарезервированной области и области FAT,
находящихся перед областью данных, адреса кластеров не используются.
Файловая система FAT дает пример того, что не каждому логическому адресу
тома соответствует логический адрес файловой системы. Как будет показано
в главе 11, в NTFS ситуация изменилась — в этой системе первый кластер
также является первым кластером файловой системы.

В FAT 12/16 и FAT32 используются разные процедуры поиска адреса сектора
2. В файловой системе FAT32 кластер 2 начинается с первого сектора
области данных. Предположим, имеется файловая система с 2048-байтовыми
кластерами и областью данных, начинающейся с сектора 1224. Кластеру 2
будет соответствовать адрес сектора 1224, а кластеру 3 — адрес сектора
1228 (рис. 9.5).

FAT12/16

Зарезервированная Область Корневой Область

область FAT каталог данных

/ \

Сектор 1224 Сектор 1256 / Кластер 2

FAT32

Зарезервированная Область Область область_FAT_данных

Сектор 1224 / Кластер 2

Рис. 9.5. В файловой системе РАТ12/16 кластер 2 следует за корневым
каталогом, а в РАТ32 кластер 2 является первым сектором области данных

PAGE 208

Глава 9. FAT: основные концепции и анализ

Адреса кластеров и секторов

Как мы только что обсуждали, адресация кластеров начинается только с
области данных. Следовательно, для адресации данных в зарезервированной
области и области FAT пришлось бы использовать либо две разные схемы
адресации, либо «наименьшее общее кратное», которым является адрес
сектора (логический адрес тома). Выполнять все операции с адресами
секторов достаточно удобно; именно эта схема используется во внутренней
работе всех системных программ и операционных систем, потому что им
нужно знать, где находятся данные по отношению к началу тома. Некоторые
программы, в том числе пакет TSK, выводят все адреса в виде адресов
секторов, чтобы было достаточно только одной схемы адресации.

Чтобы выполнить преобразования между адресами кластеров и секторов,
необходимо знать адрес сектора для кластера 2 и количество секторов в
кластере. Базовая формула расчета адреса сектора для кластера С выглядит
так: (С – 2) * (кол-во секторов в кластере) + (сектор кластера 2)
Обратная формула для преобразования сектора S в кластер: ( (S – сектор
кластера 2) / (кол-во секторов в кластере) ) + 2

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

Итак, мы знаем, как найти кластер. Теперь необходимо определить, какие
кластеры выделены, а какие остаются свободными. Состояние выделения
кластера определяется по структуре FAT. Обычно FAT существует в двух
копиях, и первая копия начинается после зарезервированной области
файловой системы. FAT более подробно рассматривается в главе 10, но
необходимую информацию я приведу здесь.

Структура FAT используется для многих целей, но базовая концепция
проста: каждый кластер файловой системы представлен одной записью.
Например, запись таблицы 481 соответствует кластеру 481. Каждая запись
таблицы представляет собой одно число, максимальное значение которого
зависит от версии FAT. В файловых системах FAT12 используются
12-разрядные записи, в FAT16 — 16-разрядные, а в FAT32 запись таблицы
состоит из 32 разрядов (из которых используются только 28).

Если запись таблицы равна 0, кластер не выделен файлу. Если она равна
0xff7 для FAT12, 0xfff7 для FAT 16 или OxOfff fff7 для FAT32, кластер
помечен как поврежденный и не может выделяться файлам. Все остальные
значения означают, что кластер выделен, а их интерпретация будет
рассмотрена позднее, в разделе «Категория метаданных».

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

При выделении кластеров ОС использует определенный алгоритм.
Тестирование систем Windows 98 и Windows ХР показало, что в обоих
случаях использовался алгоритм поиска следующего доступного кластера.
Этот алгоритм ищет первый доступный кластер, начиная от предыдущего
выделенного кластера. Предположим, кластер 65 выделен новому файлу, а
кластер 62 свободен. Следующий поиск начнется с кластера 66, а кластер
62 на некоторое время останется свободным (рис.

Категория содержимого

PAGE 209

9.6). Процесс выделения кластеров зависит от многих факторов, и
идентифицировать точный алгоритм трудно.

Чтобы найти свободный кластер для выделения файлу, ОС сканирует FAT и
ищет запись, содержащую 0. Вспомните, что в резервной области FAT32
хранится структура данных FSINFO с номером следующего свободного
кластера, которым операционная система может руководствоваться при
поиске. Если потребуется перевести кластер в свободное состояние,
система находит соответствующую запись в структуре FAT и заполняет ее
нулями. Большинство операционных систем не стирает содержимое кластеров
при освобождении, если только эта операция не реализована как функция
надежного удаления информации.

61 62 63; ;64 – «я * «о 66 67

Свободно

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

Рис. 9.6. Поиск свободного кластера начинается не от начала файловой
системы, а с последнего выделенного кластера

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

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

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

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

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

PAGE 210

Глава 9. FAT: основные концепции и анализ

Поврежденные блоки данных необходимо анализировать в файловых системах
любого типа, но Microsoft сообщает, что некоторые защищенные приложения
хранят информацию в кластерах FAT, помеченных как поврежденные. По этой
причине программа ScanDisk для Windows не проверяет, действительно ли
повреждены помеченные секторы [Microsoft, 2004b]. Некоторые версии
команды format для Windows сохраняют статус поврежденных кластеров при
повторном форматировании файловой системы.

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

Область Область FAT данных

t t

Кластер 2 Кластер X

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

Чтобы узнать, присутствуют ли в системе неиспользуемые секторы, вычтите
адрес сектора для кластера 2 из общего количества секторов и разделите
разность на количество секторов в кластере. Если деление выполняется с
остатком, значит, неиспользуемые сектора присутствуют:

(общее количество секторов – адрес сектора для кластера 2) / (количество
секторов в кластере)

Скрытые данные также могут храниться между концом последней
действительной записи основной структуры FAT и началом резервной копии
или же между концом последней записи резервной FAT и началом области
данных. Чтобы вычислить объем неиспользуемого пространства, сравните
размер каждой структуры FAT, указанный в загрузочном секторе, с
размером, необходимым для хранения фактического количества секторов в
файловой системе. Например, в файловой системе FAT32, которую мы ранее
анализировали командой fsstat, каждой копии FAT было выделено 797
секторов. Каждая запись таблицы в файловой системе FAT32 занимает четыре
байта, следовательно, каждый 512-байтовый сектор содержит 128 записей. В
каждой таблице помещается 797 секторов * 128 (записей/сектор) = 102 016
записей

Из выходных данных fsstat видно, что количество кластеров равно 102 002,
следовательно, в таблице имеется 14 неиспользуемых записей, а их общий
размер составляет 64 байта.

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

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

PAGE 211

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

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

Имеется файловая система FAT 16, требуется найти первый сектор кластера
812. У нас есть только шестнадцатеричный редактор, не имеющий
специальных функций поддержки файловой системы FAT.

Первым шагом станет просмотр загрузочного сектора, расположенного в
секторе 0 файловой системы. В результате обработки сектора мы узнаем,
что он содержит шесть зарезервированных секторов, две копии FAT и каждая
копия FAT занимает 249 секторов. Каждый кластер состоит из 32 секторов,
а корневой каталог содержит 512 записей.

Теперь нужно заняться вычислениями. Первая копия FAT начинается в
секторе 6 и заканчивается в секторе 254. Вторая копия FAT начинается в
секторе 255 и заканчивается в секторе 503. Далее следует корневой
каталог. Корневой каталог содержит 512 записей; каждая запись (как будет
показано далее) занимает 32 байта, поэтому каталог располагается в
секторах 504-535, а область данных начинается в секторе 536.

Первый кластер области данных обладает адресом 2. Соответственно,
искомый кластер 812 будет 810-м кластером области данных. Так как каждый
кластер занимает 32 сектора, кластер 812 смещен от начала области данных
на 25 920 секторов. Наконец, мы прибавляем начальный адрес области
данных и определяем, что кластер 812 начинается в секторе 26 456 и
продолжается до сектора 26 487. Структура диска показана на рис. 9.8.

Сектор Сектор Сектор Сектор Сектор Сектор 6 255 504 536
568 26 456

t t t t \ t

Зарезервировано FAT 1 FAT 2 I Кластер 2 Кластер 812

Корневой каталог

Рис. 9.8. Структура диска в примере с поиском кластера 812

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

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

PAGE 212

Глава 9. FAT: основные концепции и анализ

Записи каталога

Записью каталога называется структура данных, создаваемая для каждого
файла и каталога. Ее размер равен 32 байтам; в структуре хранятся
атрибуты файла, его начальный кластер, дата и время. Запись каталога
занимает важное место в категории метаданных и имен файлов — ведь в этой
структуре содержится имя файла. Записи каталогов могут находиться в
любом месте области данных, потому что они хранятся в кластерах,
выделенных каталогам. В файловой системе FAT каталоги интерпретируются
как особая разновидность файлов. Структура данных записей каталогов
подробно описывается в главе 10.

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

Структура записи каталога содержит поле атрибутов. Для каждого файла
можно задать значения семи атрибутов, хотя ОС (или программа анализа)
могут проигнорировать некоторые из них. Мы начнем с рассмотрения
обязательных атрибутов — игнорировать эти атрибуты нельзя, потому что
они влияют на процесс обработки записей каталогов. Атрибут каталога
используется для идентификации записей каталогов, относящихся к
каталогам (в отличие от файлов). Кластеры, ассоциированные с записью
каталога, должны содержать новые записи каталогов. Атрибут длинного
имени файла является признаком записей особого типа, имеющих другую
структуру. Эта тема подробно рассматривается в разделе «Имя файла».
Последний обязательный атрибут предназначен для хранения метки тома;
согласно спецификации, он может быть установлен только у одной записи. Я
заметил, что в Windows ХР задаваемая пользователем метка тома
сохраняется именно здесь, а не в загрузочном секторе. Если ни один из
этих атрибутов не установлен, значит, запись относится к обычному файлу.

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

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

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

PAGE 213

обязательно и измеряется с точностью до дня; наконец, согласно
спецификации время последней модификации является обязательным и
измеряется с точностью до двух секунд. Никаких спецификаций по поводу
того, при каких операциях должно обновляться то или иное время, не
существует, поэтому каждая ОС, в которой используется FAT, реализует
собственную политику обновления этих значений. В Windows 95+ и NT+
обновляются все временные штампы, a DOS и Windows 3.1 обновляют только
время последней модификации. Время хранится с учетом местного часового
пояса; это означает, что его не нужно преобразовывать в зависимости от
местонахождения компьютера.

Статус выделения записи каталога определяется ее первым байтом. Для
выделенной записи в первом байте хранится первый символ имени файла, а
при ее освобождении он заменяется кодом 0хе5. Именно по этой причине
программы восстановления FAT требуют ввести первую букву имени файла.

Цепочки кластеров

В записи каталога указывается начальный кластер файла, а структура FAT
используется для поиска остальных кластеров в файле. Как упоминалось
ранее, для выделенных кластеров запись FAT отлична от нуля. Ненулевая
запись содержит адрес следующего кластера файла, маркер конца файла или
значение, показывающее, что кластер содержит поврежденные секторы. Чтобы
найти следующий кластер файла, достаточно найти запись кластера в FAT и
определить, является ли он последним кластером в файле или за ним
имеется другой кластер. Структура данных FAT и допустимые значения более
подробно рассматриваются в главе 10.

Допустим, файл хранится в секторах 40,41 и 45. Чтобы прочитать
содержимое файла, мы сначала обращаемся к полю начального кластера в
записи каталога, значение которого равно 40. По размеру файла можно
определить, что файл хранится в нескольких кластерах, поэтому мы
обращаемся к записи FAT кластера 40. Запись содержит значение 41; это
означает, что кластер 41 является вторым кластером в файле. Судя по
размеру файла, необходим еще один кластер, поэтому мы обращаемся к
записи FAT кластера 41 и находим значение 45. Запись FAT кластера 45
содержит маркер конца файла (EOF), потому что этот кластер является
последним в файле. Последовательный список кластеров иногда называют
цепочкой кластеров] пример показан на рис. 9.9.

FAT

39 0

40 41

41 45

42 43

43 EOF

44 0

45 EOF

Запись каталога

FILE1.DAT

Начало: 40 Размер: 6 013

Рис. 9.9. Таблица FAT с цепочкой кластеров 40-41-45

PAGE 214

Глава 9. FAT: основные концепции и анализ

Максимальный размер файловой системы FAT зависит от размера записей FAT.
Размер записи определяет максимальный адрес следующего кластера в
цепочке; таким образом, адреса кластеров ограничены. В файловой системе
FAT32 используются только 28 бит 32-разрядной записи, поэтому она
позволяет адресовать только 268 435 456 кластеров (на самом деле немного
меньше, потому что некоторые значения зарезервированы для маркера EOF и
поврежденных кластеров).

Каталоги

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

Первые две записи каталога предназначены для элементов «.» и «..». Эти
обозначения хорошо знакомы пользователям, работающим в режиме командной
строки. Имя «.» обозначает текущий каталог, а имя «..» — родительский
каталог. В действительности они представляются записями каталога с
установленным атрибутом каталога, но, похоже, система Windows не
обновляет значения после их создания. Временные штампы создания,
обращения и модификации сохраняют значения, заданные в момент создания
каталога. Это поведение также может использоваться для проверки времени
создания каталога, значение которого должно совпадать со значениями «.»
и «..». Впрочем, подтвердить время последней модификации каталога
невозможно, потому что записи «.» и «..» не обновляются при каждой
модификации каталога. Ситуация показана на рис. 9.10: время создания
dirl отличается от времени создания записей «.» и «..». Пользователь мог
сделать это с целью маскировки своих действий, или же дата могла быть
модифицирована каким-то приложением в системе.

Кластер 110 Кластер 196

Имя Время создания Кластер Имя Время
создания Кластер

dir2 ~3/30/04 01:29:(31~ 128 ~” ~~4/1 /04
09:27:0(Г~ 196

dirl 4/03/0411:47:40 196 ‘ 4/1/04
09:27:00 110

file8.dat I 3/30/04 20:41:12 | 112 | | file1.dat | 4/3/04 12:58:23
| 297 ~

Рис. 9.10. Время создания записи каталога не совпадает с временем
создания записей «.» и «..»

Адреса записей каталогов

Как упоминалось ранее, существует только один стандартный способ
адресации записей каталогов: использование полного имени файла или
каталога, с которым она ассоциируется. При этом возникают минимум две
проблемы, которые будут рассмотрены в этом разделе.

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

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

PAGE 215

Такое решение отлично работает для обычных операций с файловой системой,
но аналитику нередко требуется решить обратную задачу — найти все
свободные записи каталогов. Здесь возникает первая проблема. При
освобождении записи каталога первая буква имени пропадает. Если каталог
содержит два файла, A-1.DAT и B-1.DAT, которые были удалены, обе записи
будут содержать одинаковое имя _-l.DAT. Таким образом, возникает
конфликт уникальности имен.

Вторая проблема возникает при удалении каталога и освобождении его
записи. В этом случае не остается указателя на файлы и каталоги,
находившиеся в удаленном каталоге, поэтому у них не будет адреса. На
рис. 9.11 (А) запись каталога ссылается на кластер 210. Каталог
удаляется, а запись каталога позднее выделяется заново; в новом варианте
она указывает на кластер 400 (рис. 9.11 (В)). Свободные записи каталогов
в кластере 210 остаются, однако их не удастся найти простым перемещением
по дереву каталогов. Но даже если эти записи будут найдены, адресов у
них не будет. Такие файлы называются зависшими.

А)

Кластер 45

Кластер 210

45

210

26

45

bad.jpg 105

fjle1.txt 211

dirl 210

file2.txt 250

good.jpg 153

file3.txt 273

В)

Кластер 45

Кластер 210

45

26

bad.jpg 105

newfile 400

good.jpg 153

210

45

file1.txt 211

file2.txt 250

file3.txt 273

Рис. 9.11. (А) — существующий каталог и его содержимое; (В) — состояние
системы после удаления каталога и повторного выделения его записи в
родительском каталоге

Чтобы найти зависшие файлы, необходимо проанализировать все секторы
области данных. Стандартного способа не существует; один из вариантов
заключается в анализе первых 32 байтов каждого сектора (не кластера!) и
их сравнении с полями записи каталога. Если данные лежат в правильном
диапазоне, обрабатывается остаток сектора. При просмотре секторов могут
обнаружиться записи в резервном пространстве кластеров, которые были
выделены другим файлам. Другой аналогичный способ — просмотр первых 32
байтов каждого кластера для отыскания записей «.» и «..», которые
являются первыми двумя записями каждого каталога (пример будет приведен
далее). Этот способ позволяет найти только первый кластер каталога, но
не его фрагменты.

Один из способов решения подобных проблем основан на использовании
другого метода адресации. Например, в TSK используется метод, который
также применяется в некоторых версиях UNIX; предполагается, что каждый
кластер и сектор может быть выделен каталогу. Таким образом, можно
представить, что каждый сектор разделен на 32-байтовые записи, в которых
могут храниться записи каталогов, а каждой записи сопоставлен уникальный
адрес. Первой 32-байтовой записи первого сектора ставится в соответствие
адрес 0, второй — адрес 1, и т. д.

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

PAGE 216

Глава 9. FAT: основные концепции и анализ

присваивается адрес 2 (потому что именно такой способ используется в
большинстве файловых систем UNIX), а первой записи первого сектора
присваивается адрес 3. На рис. 9.12 секторы 520 и 1376 представлены в
расширенном виде, с показом адресов содержащихся в них записей. Каждый
512-байтовый сектор вмещает 16 структур записей каталогов, поэтому в
секторе 520 хранятся записи 3-18.

Сектор 520

13 699^ 13 700-13 70Г

Сектор 1 376

Область FAT Область данных

Рис. 9.12. Адреса, назначаемые записям каталогов, определяются сектором
и местонахождением записи внутри сектора

Пример образа

Следующий вывод istat, полученный для файла тестового образа,
демонстрирует данные, существующие для типичного файла FAT. Запись
каталога для этого файла анализируется в главе 10, а здесь приводится
отформатированный результат:

# istat -f fat fat-4.dd 4 Directory Entry: 4 Allocated

File Attributes: File. Archive

Size: 8689

Name: RESUME-1.RTF

Directory Entry Times: Written: Wed Mar 24 06:26:20 2004

Accessed: Thu Apr 8 00:00:00 2004

Created: Tue Feb 10 15:49:40 2004

Sectors:

1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659
1660 1661 1662 1663

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

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

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

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

PAGE 217

шинстве стратегий выделения, конкретное поведение зависит от ОС и не
может контролироваться структурами данных файловых систем. Прежде чем
делать какие-либо предположения об алгоритмах выделения, необходимо
протестировать конкретную ОС. Я приведу свои наблюдения для Windows 98 и
ХР.

Выделение записей каталогов

В Windows 98 используется стратегия выделения первой доступной записи, а
поиск свободных записей начинается от начала каталога. Windows ХР
использует стратегию следующей доступной записи, а поиск свободных
записей начинается от последней выделенной записи. Добравшись до конца
цепочки кластеров, Windows ХР заново начинает сканирование от начала
каталога. Если Windows 98 или ХР не могут найти свободную запись
каталога, выделяется новый кластер.

Различия между этими методами выделения записей показаны на рис. 9.13,
где запись 3 была выделена после записи 4. При выделении следующей
записи Windows 98 проводит сканирование от начала кластера и выделяет
запись каталога 3. Windows ХР начнет с записи 4 и выделит запись 5.

ШШШЩШШШЩШШШШШж Запись каталога 1

2

Запись каталога 3

Запись каталога 4

Запись каталога 5

Запись каталога 6

Свободные

Выделенные

Последняя – выделенная запись

Рис. 9.13. Последней была выделена запись каталога 4. В Windows 98
следующей будет выделена запись 3, а в Windows ХР — запись 5

При переименовании файла в Windows для нового имени создается новая
запись, а запись старого имени освобождается. Аналогичное поведение
прослеживается при создании нового файла или каталога в Windows командой
Создать из контекстного меню: сначала система создает запись с именем по
умолчанию (скажем, Текстовый документах!:), а затем освобождает ее при
вводе пользователем настоящего имени.

У Windows ХР есть одна интересная особенность: при создании файла из
приложения Windows создаются две записи. Первая запись содержит все
значения, кроме размера и начального кластера. Эта запись освобождается,
после чего создается вторая запись с размером и начальным кластером. Это
происходит при сохранении файла из приложения, но не из командной
строки, посредством перетаскивания или командой меню.

При удалении файла в первый байт записи каталога заносится значение
0хе5. Windows не изменяет другие значения в записи каталога, хотя другие
ОС могут

PAGE 218

Глава 9. FAT: основные концепции и анализ

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

Обновление временных штампов

Запись каталога содержит три значения времени: последнего обращения,
последней модификации и создания. В спецификации FAT требования к этим
значениям минимальны, но статья Microsoft Knowledge Base 299648
описывает их поведение в Windows [Microsoft, 2003d]. Временные штампы не
являются обязательными, а их значения могут не соответствовать
действительности.

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

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

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

Время последнего обращения (а точнее, дата, поскольку значение имеет
точность до суток) обновляется чаще остальных. Это происходит при каждом
открытии файла. Например, если щелкнуть на файле правой кнопкой мыши для
просмотра его свойств, время последнего обращения обновляется. При
перемещении файла на другой том время последнего обращения для нового
файла тоже обновляется, потому что Windows читает исходное содержимое
перед его записью на новый том. С другой стороны, если перемещение
происходит в пределах тома, дата обращения не изменяется, потому что
новый файл использует те же кластеры. При копировании или перемещении
файла дата обращения обновляется как в исходном, так и в итоговом файле.
У этого простого правила есть единственное исключение: в Windows ХР дата
обращения не обновляется при копировании

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

PAGE 219

файла. С другой стороны, Windows 98 обновляет время обращения исходного
файла при создании итогового файла. Некоторые версии Windows можно
настроить таким образом, чтобы время последнего обращения не
обновлялось.

Что касается каталогов, я заметил, что даты задаются в момент создания
каталога и в дальнейшем практически не обновляются. Даже когда для
каталога выделяются новые кластеры или в каталоге появляются новые
файлы, время модификации не обновляется.

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

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

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

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

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

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

Во-вторых, согласно спецификации дата и время последнего обращения и
создания не являются обязательными и могут быть равны 0. Как и в
большинстве других систем, временные штампы могут быть легко изменены
пользователем. Один из документов Microsoft рекомендует разработчикам
сохранять время обращения к файлу перед его открытием; это позволит
восстановить его, если приложение не сможет прочитать файл [Microsoft,
2003а]. Для подтверждения временных штампов следует использовать
дополнительные данные прикладного уровня. Более того, на платформах
Microsoft не существует единой, согласованной процедуры обновления
временных штампов.

Windows использует в качестве времени модификации последний момент
изменения содержимого в локальной системе. В результате копирования
может появиться файл со временем создания, соответствующим времени
копирования,

PAGE 220

Глава 9. FAT: основные концепции и анализ

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

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

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

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

Обнаружив запись каталога, заполненную нулями, Microsoft Windows не
отображает дальнейшие данные. Следовательно, при желании можно без
особого труда создать каталог с несколькими файлами и использовать
остальную часть пространства каталога для хранения скрытых данных. Чтобы
обнаружить подобные тайники, сравните выделенный размер каталога с
количеством созданных файлов. Все данные, скрытые подобным образом,
должны выявляться в результате поиска в логической файловой системе.

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

В Windows ХР запись каталога с атрибутом метки тома может использоваться
для скрытия данных. В конце концов, это самая обычная запись каталога с
полем для хранения начального кластера цепочки. Если вручную
отредактировать это поле, занести в него адрес неиспользуемого кластера,
а затем перейти к FAT и вручную отредактировать содержимое таблицы для
создания цепочки, программа ScanDisk в Windows ХР не выдаст каких-либо
предупреждений или ошибок. Цепочка кластеров останется выделенной. В
общем случае, если запись каталога не ссылается на цепочку кластеров,
программа ScanDisk помещает ее в каталог

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

PAGE 221

потерянных кластеров. В Windows 98 программа ScanDisk обнаруживает
кластеры, выделенные записям с атрибутом метки тома, и удаляет их.

Другая интересная особенность Windows ХР и атрибута метки тома
заключается в том, что количество записей с этим атрибутом может быть
произвольным, и они могут располагаться в произвольных местах. Согласно
спецификации, файловая система должна содержать только одну запись с
этим атрибутом, находящуюся в корневом каталоге, но система не
контролирует соблюдение этого требования. Таким образом, вы можете
создать в разных каталогах разные записи с атрибутом метки тома и
использовать их для скрытия данных. В Windows 98 программа ScanDisk
обнаруживает такие записи и оповещает пользователя. В настоящее время
эти действия приходится выполнять вручную, но возможно, в будущем
появятся программы для их автоматизации. На сайте Dtl У ‘ (Digital
Forensic Tool Testing) имеется тестовый образ для меток томов FAT
[Carrier, 2004b].

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

Дата создания файловой системы

Имеется файловая система FAT, содержащая незначительный набор файлов и
каталогов. Возможно, дело в том, что файловая система мало
использовалась, была недавно отформатирована или в ней присутствуют
скрытые данные. Чтобы проверить вторую гипотезу, мы анализируем
временные штампы записи каталога с атрибутом метки тома, находящейся в
корневом каталоге. Программа выводит запись каталога как обычный файл, и
мы видим, что форматирование было выполнено за две недели до снятия
данных с диска. Это объясняет малое количество имен файлов, однако в
системе все равно могут присутствовать скрытые данные, а также данные,
оставшиеся от предыдущей файловой системы (их поиск рассматривается в
следующем сценарии).

Поиск удаленных каталогов

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

Я сделаю это с помощью TSK, но вы можете воспользоваться любой
программой, которая позволяет ограничить поиск свободным пространством и
искать шестнадцатеричные сигнатуры. В TSK первая задача решается
программой dis:

# dis -f fat fat-10.dd > fat-10.dl s

Поиск будет проводиться по первым четырем байтам каталога,
соответствующим ASCII-кодам «. » (точка с тремя пробелами). В
шестнадцатеричном представлении эта сигнатура имеет вид 0х2е202020.
Поиск сигнатуры в свободном пространстве осуществляется программой
sigfind:

# sigfind -b 512 2е202020 fat-10.dls Block size: 512 Offset: О

PAGE 222

Глава 9. FAT: основные концепции и анализ

Block: 180 (-)

Block: 2004 (+1824)

Block: 3092 (+1088)

Block: 3188 (+96)

Block: 19028 (+15840)

[…]

Просмотрим содержимое сектора 180 образа fat-10.dLs (не исходного
образа файловой системы). Оно выглядит так: # dd if-fat-10.dls skiр=180
count=l | xxd

0000000: 2е20 2020 2020 2020 2020 2010 0037 5daf . ..7].

0000016: Зс23 Зс23 0000 5daf Зс23 4П9 0000 0000 ~ hO$A0J‘ 0 0 i ¤„ ue.ueVth”th–th?th th¤th¦th?thEthu?u?ueaeUeaeNENEN?E?e§e§e?u?u?u!e!eUe§e› eaeaeaeae”?u?u?uU * 1/4 * hO$A0J• ???????????????????????????????a·u· hO$A0JF@? ???? ???? ` n   ? a ae ae 0 6 R p z „ ¬ E O TH e o * 4 ?¬ ¶ A E O TH e ?(?a?oe ?(???oe ?(???oe ? ? ? ? ? th u?u?u?ueu?u?u?u?ueu?u?u?uaeUOUOUOu?u?u?ueIAe?u?u?u?u?u?u?u?u?u?u?u?u?u?u ?u1/2 ????(? t ? hO$A0JF6I hO$A0J’ hO$A0J’ | I 8 | I ? O U TH a a i o - , 2 ? ¤ E U hO$A0J™=I a ???? ???? ???? ???? @? A ?oI oI &I 2I 4I ^I kI mI —I ¤I ¦I ?I YI eI eI " $ ( , , $ ( , 0 4 hO$A hO$A0J™A, 0 4 B D ?4 B f hO$A0JA'D F H J L N P ‡ I H T Z \ ^ ` f h n r ? ? ? ? ® ? A TH o ?????????????f h ? ’ ¦ A O e 0 D Z ¤ A O i hO$A

e ue th 0 Z l ?l n r A O ?????????y?????????y?????????y?????????????????????????????????????????? ?????????(?O O O ) @?- ? 8? E? l? ? ¦? ?? U? ae? @ X ? A E ??? ??? ??? ??? ??? ??? ??? ??? B L ue ® ? TH o hO$A4ќ ў ? ? ? ? ? ?????????y???????????????????????????????????(?? ? ? ? ? ? ? ? - 2 6 N h ” \ h ¬ ? $

N$

%

“%

|%

?%

?%

Oe%

P&

l&

o&

u&

e(

i(

\*

p*

?*

Ae*

oe*

+

N+

V+

?+

¦+

U+

ae+

:,

@,

¶,

3/4,

O,

o,

0-

:-

I-

o-

j/

z/

®/

U/

hO$A0J™HU/

u5

6

7

*7

87

^7

`7

h7

j7

p7

r7

t7

;

?;

?;

’;

¬;

AE;

I;

I;

a;

a;

e;

p>

?>

?>

1/4>

AE>

?

?

?

,?

hO$A0J™,–;

?;

?;

?;

?;

 ;

c;

¤;

¦;

?;

?;

¬;

AE;

E;

I;

I;

a;

a;

?a;

ae;

e;

e;

i;

i;

?;

o;

o;

oe;

o;

u;

ue;

th;

H

LH

H

 H

cH

?H

?H

oH

?I

THI

J

,J

TJ

VJ

?J

AeJ

aeJ

oJ

K

,K

.K

6K

8K

>K

@K

BK

NK

TK

zK

?K

EK

OeK

ueK

$L

&L

(L

|L

hO$A0J’

hO$A0J™?|L

~L

?L

1/4L

AL

AeL

OL

THL

aL

aeL

BM

VM

bM

dM

hM

AM

AeM

EM

FN

HN

LN

ON

&O

.O

pP

?P

¬P

AP

Q

8Q

†Q

?Q

AQ

aeQ

R

(R

‚R

’R

?R

°R

DS

NS

~S

?S

?S

US

T

T

T

AeT

OT

?U

”U

:V

DV

FV

jV

cW

AW

EW

IW

eX

oX

6Z

@Z

I[

Oe[

O\

a\

oe\

]

]

*]

2]

n]

i]

oe]

^

J^

d^

x^

‚^

I^

ae^

D_

R_

V_

x_

?_

?_

`

“`

h`

r`

U`

a

a

a

a

a

a

a

-a

7DW

IY

]

n]

?]

i]

p^

ae^

x_

U`

a

a

a

a

a

-a

Ha

????????????????-a

*a

4a

Ja

Ra

pa

za

a

?a

®a

ua

b

(b

2b

bb

lb

zb

&e

:e

‚e

?e

®e

Ee

xg

h

h

h

h

h

0h

Uh

?h

uh

i

i

Ii

ai

Pj

Zj

k

(k

Pk

Rk

Tk

®k

°k

hO$A0JF

hO$A0JF-Ha

Ja

Ra

za

?a

lb

xg

 g

Eg

og

h

h

h

Uh

uh

?p

q

????(?°k

ok

ok

ok

Jl

’l

Ol

Ul

$m

Lm

?n

¬n

Un

en

®o

AEo

aep

?p

op

up

uep

q

q

q

q

q

>q

Nq

fq

“r

,r

8r

Br

vr

?r

-s

Ds

et

u

Jx

px

rx

1/4x

3/4x

ox

ox

dy

$z

Pz

`z

tz

~z

-{

.{

B{

L{

q

>q

¦u

$z

~z

aez

oz

L{

?{

A{

?|

}

r}

O}

~

8~



6?

oe„

J‡

p‡

†‡

o?

F‰

n‰

–‰

?‰

L{

1/4{

A{

?|

i|

o|

}

}

~

~

$~

8~





D

T

h

r

”

¤

th

?

f?

v?

??

”?

¶?

AE?

L‚

V‚

oe„

&…

6…

J…

T…

v…

†…

a…

?…

?†

¤†

J‡

p‡

r‡

z‡

|‡

‚‡

„‡

†‡

o?

*‰

:‰

F‰

R‰

T‰

?‰

?‰

U‰

@U‰

ae‰

i‰

$?

.?

6?

†? ?? E? I? ‹ -‹ ? ? ? R? X? c? ?? o? o? ”? L‘ Z‘ \‘ ¤‘ ?‘ E‘ Ue‘ ae‘ ue‘ ’ E’ Ue’ “ 4“ U“ 5?‰ ue‰ L? ?? TH? .‹ ae‹ &? h? ?? ”? ¤‘ ’ h’ –’ °’ E’ Ue’ 4“ c• A– U“ Ue“ TH“ ” "” *” ,” 8” ”

D”

F”

’”

?”

 ”

?”

1/4”

A–

I–

,—

Z—

\—

^—

t—

$?

B?

J?

o?

,™

V™

?™

?™

?™

 ™

z?

??

Z?

h?

X?

^?

I?

??

O?

a?

!

!

“!

Ec

Oec

hO$A0J?@? ? ? ? ? ? ? ? ? ? ? ? ? ????? ? ? ? ? ? ? ? ? ?o? z? ?? Oec uec F 1/4? O? a? a? th? © ????????????????Oec uec thc F F F F F F &F rF |F O¤ i¤ oY ¦ ?¦ Ae¦ E¦ TH¦ § "§ x§ ~§ A§ O§ ? ? 4? H? n? |? ?? 1/4? th? © "© (© R© Z© °© ¶© i© o© ,? 2? d? n? ? ?? ,« b« f« ?« ¬ ,¬ 1/4 O ® $® ae® o® ? hO$A0J‘>?

?

?

?

?

?

?

?

?????????y???????????????????????????????????(??

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?????????y???????????????????????????????????(??

?

?

?

?

?

?

?????????y???????????????????????????????????(?0?

2?

TH?

?

H?

d?

z?

??

\?

??

t1/4

O1/4

 ? EA aA Ae aAe ?????????y???????????????????????????????????(?? ? D? X? Z? a? ae? P° R° V° ¦° ®° Oe° ae° 6± D± oe? ? ?? ¬? TH? ? ? ? >?

t?

??

??

°?

A?

O?

µ

µ

–µ

µ

1/4µ

d?

f?

n?

p?

v?

x?

z?

2z?

†?

??

??

A?

\?

`?

¤?

??

??

t1/4

x1/4

1/41/4

A1/4

O1/4

@? ?? ??  ? A? ?? hA pA uA A 0A DA EA aA aeA A `A bA xA zA OA OA Ae Ae Ae Ae RAe rAe sAe zAe ?Ae Ae ?Ae Ae ?Ae ?Ae UAe UAe aAe hO$A0J‘6aAe cAe oAe /A 0A 6A 7A iA jA ?A A A ¤A ¦A OA uA uA AE AE AE BAE CAE uAE vAE xAE zAE eAE 'C (C 0C 9C ;C hC qC rC sC C ?C ?C ?C OeC *C ueC yC yC E 'E ?E FE IE gE pE qE “E ”E FE ¤E ?E IE IE OE OE OE iE iE ueE yE E E 5E hO$A0J™EaAe A ¤A xAE .C yC nE WE E BE IE NE aE jI I –I -I ?I ,I ?I aI 6Oe nOe U ’a ¶a ia 5E 6E TE UE E E E BE TE `E bE rE tE IE THE aE eE eE uE ueE E E E E NE bE tE vE ‚E „E ?E aE oE oE thE I I I jI |I ~I ?I ?I I I .I 0I I

FI

–I

?I

?I

?I

5?I

?I

¶I

?I

AI

AeI

OeI

OI

UI

UeI

-I

2I

DI

FI

RI

TI

\I

^I

`I

bI

jI

?I

?I

1/4I

AeI

AEI

EI

EI

OI

OeI

eI

eI

iI

iI

,I

@I

RI

TI

`I

bI

jI

lI

nI

pI

xI

?I

aI

6Oe

nOe

¶a

ia

?a

oa

ua

a

a

a

.e

Pe

Ze

hO$A0J›;ia

a

Pa

.e

Pe

*i

?n

Ro

4u

ue

“ue

bue

uey

Ze

be

fe

ve

i

“i

?i

Uei

>i

ni

?n

On

?o

o

?o

¦o

8o

Ro

fo

|o

co

¬o

?o

1/4o

Io

Ueo

oeo

u

u

u

“u

&u

4u

Hu

pu

ue

ue

ue

ue

-ue

ue

“ue

,ue

bue

th

4th

a

???????????????????????????????????

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

6????????????

?

?

?

?

?

?

?

?

?

%1$ ?

?

?

?

?

?

?

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A5?

?

?

?

?

?

?

??

?

?

?

?

?

?

??

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

?

????????

?

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J’

hO$A0J’H*

)?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

????????????????????????????

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J’

hO$A0J’H*

hO$A0J™6?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J?@?

hO$A0J¤>*

*?

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

????

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

@?oey#?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

????

?

?

?

?

?

????

??????????????(??

?

?

?

?

?

????

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

&?

?

?

?

?

?

????

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

????

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

#?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?????????????????

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0Ja2?

?

?

?

?

?

?

?

??????(??

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

??????????????????????????

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J?$?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

????????(??

?

?

?

?

?

?

??????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

??????????????????????????

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J™%?

?

?

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

??????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

??????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

,?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J &?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J•

%?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

????(??

?

?

?

?

?

?

?

?

?

?

??

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

hO$A0J?!?

?

?

?

?

?

?

?

?

?

??

?

E

ue

hO$A

$1$If

*

I

TH

*

I

?

TH

>TH

i

th

oe?ae?oeaeUeOe?aeI?ae?oe?ae?oeaeoe?I?ae?oe?OeAeoe?oeI3/4?®?¤?¤?Oe????Oe

hO$A0J•

hO$A0J’

hO$A0Ju

?

?

hO$A0J•

hO$A0J’

hO$A0J®>*

?????

?????

hO$A0J =(кластер 75 – кластер 2) * 2 (секторов в кластере) + сектор 1632
– сектор 1778 Программа dstat из пакета TSK отображает состояние
выделения и адрес кластера для любого сектора. Если запустить ее для
сектора 1778, будет получен следующий результат:

# dstat -f fat fat-4.dd 1778 Sector: 1778

Not Allocated Cluster: 75

Записи каталогов

В записях каталогов FAT хранятся имя и метаданные файла или каталога.
Эти записи создаются для каждого файла или каталога в системе и хранятся
в кластерах, выделенных родительскому каталогу файла. Структура данных
записи поддерживает короткие имена по схеме 8 + 3 (8 символов имени, 3
символа расширения). Если файл имеет более сложное имя, в дополнение к
обычной записи каталога (SFN) создаются записи LFN (Long File Name).
Версия записи каталога для длинных имен будет описана в следующем
разделе. В табл. 10.5 перечислены поля, входящие в базовую структуру
записи каталога.

PAGE 242

Глава 10. Структуры данных FAT

Таблица 10.5, Структура данных базовой записи каталога FAT

Диапазон Описание Необходимость

0-0 Первый символ имени файла в кодировке ASCII и состояние выделения
(0хе5 или 0x00, если запись не выделена) Да

1-10 Символы 2-11 имени файла в кодировке ASCII Да

11-11 Атрибуты файла (см. табл. 10.6) Да

12-12 Зарезервировано Нет

13-13 Время создания (десятые доли секунды) Нет

14-15 Время создания (часы, минуты, секунды) Нет

16-17 День создания Нет

18-19 День последнего обращения Нет

20-21 Старшие 2 байта адреса первого кластера (0 для FAT 12 и FAT 16) Да

22-23 Время последней модификации (часы, минуты, секунды) Нет

24-25 День последней записи Нет

26-27 Младшие 2 байта адреса первого кластера Да

28-31 Размер файла (0 для каталогов) Да

Первый байт структуры данных используется как признак выделения. Если он
равен 0хе5 или 0x00, значит, запись каталога свободна. В противном
случае байт содержит первый символ имени файла. Обычно имена файлов
задаются в кодировке ASCII, но они также могут содержать символы
национальных алфавитов, для чего используются кодовые страницы Microsoft
[Microsoft, 2004]. Если в этом байте имени файла содержится символ 0хе5,
вместо него используется код 0x05. Если имя файла короче 8 символов,
неиспользуемые байты обычно заполняются ASCII-кодом пробела 0x20.

Поле размера файла занимает 4 байта, следовательно, максимальный размер
файла равен 4 Гбайт. У каталогов поле размера равно 0, и для определения
количества выделенных им кластеров следует использовать структуру FAT.
Поле атрибутов содержит один или несколько флагов, перечисленных в табл.
10.6.

Таблица 10.6. Флаги поля атрибутов в записи каталога

Флаг Описание Необходимость

0000 0001 (0x01) Доступ только для чтения Нет

0000 0010 (0x02) Скрытый файл Нет

0000 0100 (0x04) Системный файл Нет

0000 1000 (0x08) Метка тома Да

0000 1111 (0x0f) Длинное имя файла Да

0001 0000 (0x10) Каталог Да

0010 0000 (0x20) Архивный файл Нет

Старшие два бита в байте атрибутов зарезервированы. Записи каталогов с
установленным атрибутом длинного имени имеют другую структуру, которая
будет описана в следующем разделе. Обратите внимание: атрибут длинного
имени представляет собой поразрядную комбинацию первых четырех
атрибутов. Ком

Записи каталогов

PAGE 243

пания Microsoft выяснила, что старые ОС игнорируют записи каталогов со
всеми установленными битами и введение нового атрибута не создаст
проблем.

Компонент даты во временных штампах представляет собой 16-разрядное
значение, состоящее из трех частей (рис. 10.2 (А)). Младшие 5 бит
определяют день месяца (диапазон допустимых значений 1-31). Биты 5-8
определяют месяц (допустимые значения — 1-12). Биты 9-15 определяют год;
их значение прибавляется к 1980. Диапазон допустимых значений 0-127
позволяет представлять годы с 1980 по 2107. Преобразование даты 1 апреля
2005 года в шестнадцатеричный формат показано на рис. 10.2 (В).

А)

Год (0-127)

Месяц (1-12)

День (1-31)

15 14 13 12 11 10 9

8765 43210

В)

Исходная дата: 1 апреля 2005 г.

Обычн. Десятичн. Шести. Двоичн.

1 1 0x01 0 0001

April 4 0x04 0100

2005 25 0x19 001 1001

ООН 001 0 100 0 0001

Итог: 0x3281

Рис. 10.2. Строение даты и преобразование 1 апреля 2005 г. в формат даты
FAT

Время тоже задается 16-разрядной величиной, состоящей из трех
компонентов. Пять младших битов определяют секунды (измеряемые в
2-секундных интервалах). Диапазон допустимых значений 0-29 позволяет
представить значения из диапазона 0-58 с двухсекундными интервалами.
Следующие 6 бит определяют минуты (допустимые значения — 0-59).
Последние 5 бит определяют часы (допустимые значения — 0-23). Структура
поля времени продемонстрирована на рис. 10.3 (А). Пример преобразования
времени 10:31:44 в формат FAT показан на рис. 10.3 (В).

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

Рассмотрим низкоуровневое содержимое двух записей из корневого каталога.
Местонахождение корневого каталога в файловой системе FAT32 задается в
загрузочном секторе:

# dcat -f fat fat-4.dd 1632 | xxd […]

1 Пример — «Decode from Digital Detective» ( HYPERLINK
“http://www.digital-detective.co.uk” https://www.digital-detective.co.uk
).

PAGE 244

Глава 10. Структуры данных FAT

0000000 0000016 0000032 0000048 4641 5420 4449 534b 2020 2008 0000 0000
FAT DISK …..

0000 0000 0000 874d 252b 0000 0000 0000 …….MX+……

6245 5355 4d45 2d31 5254 4620 ООаЗ 347e RESUME-1RTF ..4-

4a30 8830 0000 4a33 7830 0900 П21 0000 .0.0…..0…!..

A)

Часы (0-23)

Минуты (0-59)

Секунды (0-29)

15 14 13 12 11

10 9 8 7 6 5

4 3 2 1 0

В)

Исходное время: 10:31:44 AM Обычн. Десятичн. Шести. Двоичн.

44 31 10

22

31

10

0x16 0x01 f ОхОа

1 0110 01 1111 01010

0101 0 011 111 1 оно

Итог: 0x53f6

Рис. 10.3. Строение времени и преобразование 10:31:44 в формат времени
FAT

В первых двух строках приведена запись каталогов, поле атрибутов которой
в байте 11 содержит двоичное значение 0000 1000 (0x08), что
соответствует атрибуту метки тома. Мы также видим, что время и дата
последней модификации содержатся в байтах 22-25 строки 2. Время
модификации метки тома может соответствовать времени создания файловой
системы. Обратите внимание: метка тома в загрузочном секторе содержит
строку «NO NAME».

Третья и четвертая строки представляют вторую запись каталога. Нетрудно
увидеть, что она представляет файл «RESUME-1.RTF». Поле атрибутов в
байте 43 содержит значение 0000 0010 (0x20); установлен только бит
архивного файла. Байт 45 определяет десятые доли секунды во времени
создания файла, поле равно 163 (ОхаЗ). Байты 46-47 содержат время
создания 0х7е34, что соответствует 15:49:40. День создания в байтах
48-49 равен 0x304а, то есть 10 февраля 2004.

Содержимое байтов 52-53 и 58-59 показывает, что файл начинается с
кластера 9 (0x0000 0009), а байты 60-63 — что размер файла составляет
8689 байт (0x0000 21fl). Для получения списка всех кластеров файла
следует обратиться к FAT. Кластер 9 содержит 36-байтовое смещение в
структуре FAT32, тогда как ранее мы уже определили, что основная копия
FAT начинается с сектора 38. Содержимое этого сектора выглядит так: #
dcat -f fat fat-4.dd 38 | xxd […]

0000032: ffff ffOf OaOO 0000 ObOO 0000 OcOO 0000 …………….

0000048: OdOO 0000 OeOO 0000 0000 Of00 1000 0000 …………….

0000064: 1100 0000 ffff ffOf 1300 0000 1400 0000 …………….

Запись таблицы для кластера 9 находится в байтах 36-39. Значение 10
(0x0000 000а) означает, что кластер 10 является следующим кластером в
цепочке. Запись кластера 10 находится в байтах 40-43, ее значение равно
11 (0x0000 000b). Мы

Записи каталогов для длинных имен файлов

PAGE 245

видим, что файлу выделяется серия смежных кластеров вплоть до записи 17
(байты 68-71), содержащей маркер конца файла (OxOfff ffff). Можно
убедиться в правильности количества кластеров, сравнив размер файла с
выделенным пространством. Файлу выделено девять 1024-байтовых кластеров;
таким образом, для хранения файла из 8 689 байт выделено 9 216 байт
дискового пространства.

Теперь попробуем просмотреть те же данные с использованием TSK.
Вспомните, что в TSK вместо адресов кластеров используются адреса
секторов. Чтобы преобразовать кластер 9 в адрес сектора, необходимо
знать адрес сектора для кластера 2, который равен 1632:

(кластер 9 – кластер 2) * 2 (секторов в кластере) + сектор 1632 – сектор
1646

Программа fsstat из пакета TSK выводит содержимое структур FAT. Выходные
данные fsstat уже приводились ранее при обсуждении категории данных
файловой системы, но вывод, относящийся к FAT, не был показан. Вот как
он выглядит:

# fsstat -f fat fat-4.dd […]

1642-1645 (4) -> EOF 1646-1663 (18) -> EOF 1664-1681 (18) -> EOF […]

В выходных данных fsstat видна цепочка кластеров файла RESUME-1.RTF,
состоящая из секторов 1646-1663 и завершающаяся маркером конца файла.
Размер каждого кластера равен 2 секторам; число в круглых скобках
показывает, что цепочка состоит из 18 секторов.

Программа istat из пакета TSK выводит подробную информацию о записях
каталогов; вывод этой программы представлен в следующем листинге. Файл
RESUME-1.RTF занимает вторую запись в корневом каталоге, и согласно
принятой в TSK схеме адресации метаданных ему соответствует адрес 4:

# istat -f fat fat-4.dd 4 Directory Entry: 4 Allocated

File Attributes: File. Archive

Size: 8689

Name: RESUME-1.RTF

Directory Entry Times: Written: Wed Mar 24 06:26:20 2004

Accesses: Thu Apr 8 00:00:00 2004

Created: Tue Feb 10 15:49:40 2004

Sectors:

1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659
1660 1661 1662 1663

Записи каталогов для длинных имен файлов

Стандартные записи каталога позволяют представить файл, имя которого
состоит из 8 символов, а расширение — из 3. Если имя имеет большую длину
или содержит

PAGE 246

Глава 10. Структуры данных FAT

специальные символы, для него требуются особые записи каталогов — записи
LFN (Long File Name). Помимо всех записей LFN для файла также создается
обычная запись, причем записи LFN должны предшествовать обычной записи.
Поля LFN-версии записи каталога перечислены в табл. 10.7.

Таблица 10.7. Структура данных записи каталога LFN в FAT

Диапазон Описание Необходимость

0-0 Порядковый номер и признак выделения (0хе5, Да

если запись свободна)

1-10 Имя файла, символы 1-5 (Unicode) Да

11-11 Атрибуты файла (OxOf) Да

12-12 Зарезервировано Нет

13-13 Контрольная сумма Да

14-25 Имя файла, символы 6-11 (Unicode) Да

26-27 Зарезервировано Нет

28-31 Имя файла, символы 12-13 (Unicode) Да

Поле порядкового номера содержит счетчик записей, необходимых для
хранения имени файла. Первой записи соответствует порядковый номер 1.
Порядковый номер увеличивается на 1 для каждой записи LFN вплоть до
последней, в которой он объединяется со значением 0x40 поразрядной
операцией OR. При выполнении этой операции результат содержит 1 во всех
разрядах, в которых хотя бы один из двух операндов содержит 1.

Записи LFN располагаются в обратном порядке перед записью короткого
имени файла. Следовательно, первая запись, которую вы находите в
каталоге, является последней записью LFN для файла и имеет наибольший
порядковый номер. Неиспользуемые символы дополняются кодами Oxff, а имя
завершается символом NULL при наличии свободного места.

Поле атрибутов записи LFN должно быть равно OxOF. Контрольная сумма
вычисляется с использованием короткого имени файла и должна быть
одинаковой для всех записей LFN. Если контрольная сумма записи LFN не
совпадает с контрольной суммой соответствующего короткого имени,
возможно, использование ОС без поддержки длинных имен привело к
повреждению каталога. Алгоритм вычисления контрольной суммы перебирает
символы имени, на каждом шаге сдвигает текущую контрольную сумму на один
бит вправо и прибавляет ASCII-код следующей буквы. В программном коде С
это выглядит так: с – 0;

for (i – 0; i file.txt:foo Как говорилось в главе 11, атрибуты $DATA могут
шифроваться для предотвращения постороннего доступа к данным или
сжиматься для экономии места. При использовании любого из этих режимов в
заголовке атрибута устанавливается соответствующий флаг. При
использовании шифрования также создается атрибут $LOGGED_STREAM_UTILITY
с ключом шифрования. На рис. 12.4 показан файл с двумя зашифрованными
атрибутами $DATA. Если в записи существует несколько атрибутов $DATA,
все они используют один криптографический ключ.

$OBJЈCTJD{64) Идентификатор атрибута: 6 Резидентный

Идентификатор атрибута; 4 Нерезидентный Зашифрован

Кластеры: 6822 – 6843

, v ; $0АТА(128)……

Идентификатор ‘атрибута:-10 Нерезидентный Зашифрован

Кластеры: 6873

Запись M FT 28

z.

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

Signature: FILE Flags: Inuse Link: 1

SSTANDARDJNFЦRMATION (16) Идентификатор атрибута: 5 Резидентный

Флаги: Архивный, Зашифрован Код безопасности: 258 Родительская запись
\А?Т. 5 Создан:

Вт 20 Июля 11:41:15 2004 Модификация файла:

Вт 20 Июля 11:42:46 2004 Модификация МРТ:

Вт 20 Июля 11:42:46 2004 Обращение:

Вт 20 Июля 11:42:46 2004

OTLSJMAME (48) Идентификатор атрибута: 5

Флаги: Архивный Имя:

Родительская запись \А?7\ 5 Создан:

Вт 20 Июля 11:41:15 2004 Модификация файла:

Вт 20 Июля 11:41:08 2004 Модификация МРТ:

Вт 20 Июля 11:41:08 2004 Обращение:

Вт 20 Июля 11:41:15 2004

$LOGQED UTfUTY \ STREW (266) ~ Идентификатор – атрибута: 9

Кластеры: 7813-7814

Рис. 12.4. Файл с двумя зашифрованными атрибутами $DATA

Атрибут $ATTRIBUTE_LIST

Атрибут $АТШВиТЕ_ДБТ используется в случае, если для хранения всех
атрибутов файла или каталога требуется более одной записи МЕТ. Файл или
каталог

PAGE 290

Глава 12. NTFS: анализ

может иметь до 65 536 атрибутов, и все атрибуты могут не поместиться в
одной записи MFT. Как минимум в записи должен храниться заголовок
каждого атрибута. Содержимое может быть нерезидентным, но иногда даже
для хранения заголовков требуется несколько записей MFT. Эта ситуация
часто возникает при фрагментации нерезидентных атрибутов и удлинении
списков серий.

Идентификатор типа атрибута $ ATT RIВ UT E_LIST равен 32; это второе по
величине значение. Следовательно, этот атрибут всегда будет находиться в
базовой записи MFT. Он содержит список всех атрибутов файла, кроме
самого себя. В каждом элементе списка хранится тип атрибута и адрес
записи MFT, в которой он расположен. В заголовках не-базовых записей MFT
указывается адрес базовой записи MFT.

Ситуация усложняется тем, что в результате сильной фрагментации даже для
хранения одного списка серий может потребоваться несколько записей MFT;
обычно такое происходит только с атрибутами $DATA. В таких случаях
каждая не-базо-вая запись MFT содержит обычный атрибут $DATA, но в
атрибуте указывается его смещение в файле. Заголовок атрибута содержит
поле с начальным номером виртуального кластера (VCN, Virtual Cluster
Number) серии, который соответствует логическому адресу файла.
Предположим, файлу требуются две записи MFT для хранения списка серий
его атрибута $DATA. Первая запись вмещает серии первых 500 Мбайт
атрибута, а вторая запись содержит остальные серии. В заголовке атрибута
второй записи будет указано, что его серии начинаются с 500-мегабайтной
точки полного атрибута $DATA.

На рис. 12.5 изображена базовая запись MFT с номером 37. Базовая запись
содержит атрибуты $STANDARD_IN FORMATION и $ ATT RI В UT E_LIST, причем
список последнего состоит из пяти элементов. Первый элемент
соответствует уже обработанному атрибуту $STANDARD_INF0RMATI0N. Второй
элемент соответствует атрибуту $FILE_NAME, расположенному в записи 48.
Третий и четвертый элементы списка соответствуют одному атрибуту $DATA,
а пятый — другому элементу $DATA. Чтобы узнать, какому атрибуту $DATA
соответствует каждая запись, достаточно обратиться к полю идентификатора
(ID). Первые 284 Мбайт первого атрибута $DATA описываются в записи 48, а
остаток атрибута — в записи 49.

37

$STD_1NFQ (Id: 0)

$ATTR1BUTE_L1ST (Id: 4)

Тип: 16 Id: 0 Запись: 37

Тип: 48 Id: 2 Запись: 48

Тип: 128 Id: 3 Запись: 48

Тип: 128 Id: 3 Запись: 49

Тип: 128 Id: 5 Запись: 50

48

49

50

$FILE_NAME (Id: 2)

$DATA (Id: 3 Смещение: 0)

$DATA (Id: 3 Смещение: 284 201 984)

$DATA (Id: 5 Смещение: 0)

Рис. 12.5. Список атрибутов из пяти элементов. Для представления файла
используются три дополнительных записи MFT, и одному из атрибутов $DATA
потребовалось две записи для его списков серий

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

PAGE 291

Атрибут $SECURITY_DESCRIPTOR

Атрибут $SECURITY_DESCRIPTOR в основном встречается в файловых системах
Windows NT, потому что в NTFS версии 3.0 и далее этот атрибут
сохраняется только для сохранения совместимости. В Windows дескрипторы
безопасности используются для описания политики контроля доступа,
действующей в отношении файла или каталога. В более старых версиях NTFS
дескриптор безопасности файла хранился в атрибуте $SECURITY_DESCRIPTOR,
обладающем идентификатором типа 80. В более новых версиях NTFS
дескрипторы безопасности хранятся в одном файле, потому что многие файлы
обладают одинаковым дескриптором безопасности, и было бы неэффективно
хранить его в одном экземпляре для каждого файла.

Файл $ Sec иге

Как упоминалось в предыдущем разделе, дескрипторы безопасности
используются для определения политики контроля доступа к файлам или
каталогам. В NTFS версий 3.0+ дескрипторы безопасности хранятся в файле
метаданных файловой системы $Secure, представленном записью MFT 9.

Атрибут $STANDARD_INFORMATION любого файла или каталога содержит
числовой код, называемый идентификатором безопасности (Security ID). Его
значение используется для индексирования файла $Secure для поиска
соответствующего дескриптора. Обратите внимание: эти 32-разрядные
идентификаторы безопасности отличаются от идентификаторов безопасности
Windows (SID), присваиваемых системой пользователям. Идентификаторы
безопасности уникальны только в рамках файловой системы, тогда как коды
SID глобально-уникальны.

Файл $Secure содержит два индекса ($SDH и $SII) и один атрибут $DATA
($SDS). Атрибут $DATA содержит дескрипторы безопасности, а два индекса
используются при ссылках на дескрипторы. Индекс $SII сортируется по
идентификатору безопасности, хранящемуся в атрибуте
$STANDARD_INF0RMATI0N каждого файла. Индекс $SII используется для поиска
дескриптора безопасности файла при известном идентификаторе
безопасности. С другой стороны, индекс $SDH сортируется по хеш-коду
дескриптора безопасности. ОС использует этот индекс, когда к файлу или
каталогу применяется новый дескриптор безопасности. Если хеш-код нового
дескриптора найти не удается, система создает новый дескриптор и
идентификатор безопасности и включает их в оба индекса.

Приведу результат выполнения istat для файла $Secure в небольшой
системе: # istat -f ntfs ntfs2.dd 9 […]

Attributes:

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

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

Type: $DATA (128-8) Name: $SDS Non-Resident size: 266188

10016 10017 10018 10019 10020 10021 10022 10023

10024 10025 10026 10027 10028 10029 10030 10031

10032 10033 10034 10035 10036 10037 10038 10039

[…]

Type: $INDEX_R00T (144-11) Name: $SDH Resident size: 56 Type:
$INDEX_R00T (144-14) Name: SSII Resident size: 56 Type:
$INDEX_ALLOCATION (160-9) Name: $SDH Non-Resident size: 4096

PAGE 292

Глава 12. NTFS: анализ

8185 8186 8187 8188 8189 8190 8191 8192

Type: $INDEX_ALLOCATION (160-12) Name: $SII Non-Resident size:
4096

8196 8197 8198 8199 8200 8201 8202 8203

Type: $BITMAP (176-10) Name: $SDH Resident size:8

Type: $BITMAP (176-13) Name: $SDH Resident size:8

В выходных данных istat мы видим 200-килобайтный атрибут $DATA с копиями
дескрипторов безопасности и двумя индексами $SDH и $SSI.

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

В завершение этого раздела я приведу результат выполнения istat для
типичного файла, в данном случае это будет файл HYPERLINK
“file://C:/boot.ini” C:\boot.ini . Для простоты описания выходные данные
разделены на несколько фрагментов.

# istat -f ntfs ntfsl.dd 3234 MFT Entry Header Values: Entry: 3234
Sequence: 1

$LogFile Sequence Number: 103605752 Allocated File Links: 1

В этой части приводятся данные заголовка записи MFT; мы видим, что его
порядковый номер равен 1, то есть это первый файл, которому выделялась
данная запись. Значение LSN ( SLogFile Sequence Number) соответствует
времени последнего изменения файла; это значение используется журналом
файловой системы.

$STANDARD_INFORMATION Attribute Values: Flags: Hidden. System. Not
Content Indexed Owner ID: 256 Security ID: 271 Quota Charged: 1024

Last User Journal Update Sequence Number: 4372416 Created: Thu Jun 26
10:22:46 2003

File Modified: Thu Jun 26 15:31:43 2003 MFT Modified: Tue Nov 18
11:03:53 2003 Accessed: Sat Jul 24 04:53:36 2004

В этой части приводятся данные из атрибута $STAN DARD_IN FORMATION,
включая флаги и информацию о владельце. Идентификатор безопасности
используется для поиска данных по индексу $Secure. Мы также видим
порядковый номер последнего обновления журнала, который изменяется при
изменении файла. Значение используется журналом изменений (см. раздел
«Категория прикладных данных»).

$FILE_NAME Attribute Values: Flags: Archive Name: boot.ini

Parent MFT Entry: 5 Sequence: 5 Allocated Size: 0 Actual
Size: 0 Created: Thu Jun 26 10:22:46 2003

File Modified: Thu Jun 26 10:22:46 2003 MFT Modified: Thu Jun 26
10:22:46 2003 Accessed: Thu Jun 26 10:22:46 2003

В этой части выводятся данные из $FILE_NAME. Обратите внимание:
временные штампы отличаются от тех, что присутствуют в $STAN DARD_IN
FORMATION, а размеры равны 0. Также видно, что родительский каталог
представлен записью MFT 5, что соответствует корневому каталогу.

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

PAGE 293

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

Этот раздел посвящен алгоритмам выделения метаданных. Как и остальные
алгоритмы выделения, они определяются на прикладном уровне, а не на
уровне файловой системы. К метаданным относятся три стратегии выделения:
первые две связаны с выделением записей MFT и атрибутов, а третья — с
обновлением временных штампов.

Выделение записей MFT и атрибутов

Начнем с выделения записей MFT. Я обнаружил, что Windows выделяет записи
MFT по алгоритму поиска первой доступной записи, начиная с 24. Записи
0-15 зарезервированы, и для них установлен флаг выделения, даже если эти
записи и не используются, а записи 16-23 обычно не выделяются.
Пользовательские файлы начинаются с записи 24, а размер таблицы
увеличивается по мере необходимости. При освобождении записи никакие
данные не изменяются (кроме флага, идентифицирующего ее как
используемую). Следовательно, временные штампы и список серий на этой
стадии еще можно восстановить. При выделении записи ее содержимое
стирается, а значения, оставшиеся от предыдущего файла, пропадают.

Что касается выделения памяти для атрибутов в записях MFT, Microsoft
сортирует записи по типу атрибутов и упаковывает их друг в друга. Если
атрибут $DATA в конце записи является резидентным и его размер
уменьшается, то в конце записи можно найти его старое содержимое (кроме
конечного маркера Oxffffffff). Когда из-за увеличения размеров атрибут
преобразуется из резидентного в нерезидентный, содержимое записи MFT
остается до тех пор, пока не будет заменено другими атрибутами.

Обновление временных штампов

Ранее я уже говорил, что временные штампы хранятся в атрибутах $STAN
DARD_IN FORMATION и $FILE_NAME. При просмотре свойств файла в Windows
отображаются данные из $STANDARD_INF0RMATI0N, причем только три из
четырех. Я опишу результаты проведенных тестов для временных штампов из
$STANDARD_INFORMATION и их обновления. Значения в $FILE_NAME обновляются
при создании и перемещении файла, но мне так и не удалось однозначно
определить правила их обновления.

Обновление временных штампов NTFS в Windows производится по аналогии с
файловыми системами FAT. Время создания задается для нового файла. Если
новый файл создается «с нуля» или в результате копирования, время его
создания устанавливается равным текущему времени. При перемещении файла
(даже на другой том) сохраняется время создания исходного файла.

Время последней модификации обновляется при модификации атрибута $DATA,
$INDEX_R00T или $1NDЕХ_АLLOCATI0N. При перемещении или копировании файла
его содержимое не изменяется, и новый файл сохраняет исходное время
модификации. Если файл содержит несколько атрибутов $DATA, время также
обновляется при модификации дополнительных атрибутов (то есть отличных
от атрибута по умолчанию). При изменении других атрибутов или имени
файла значение должно остаться прежним.

Время модификации MFT обновляется при изменении любого атрибута; я также
заметил, что оно обновляется, когда приложение открывает файл, не
изменяя

PAGE 294

Глава 12. NTFS: анализ

его содержимого. При переименовании или перемещении файла в пределах
тома значение обновляется из-за изменения атрибута $FILE_NAME. Если файл
перемещается на другой том, время модификации MFT остается неизменным.
Учтите, что этот временной штамп не показывается при просмотре свойств
файлов в Windows, но многие программы анализа отображают его.

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

Итак, при создании файла «с нуля» все временные штампы
$STANDARD_IN-F0RMATI0N и $FILE_NAME устанавливаются равными текущему
времени. При копировании файла для исходной версии обновляется время
последнего обращения, а у копии — время последнего обращения и создания.
Временные штампы модификации файла и MFT сохраняют исходные значения.
Таким образом, время создания файла может относиться к более позднему
моменту, чем время последней модификации. При перемещении файла в
пределах тома изменяется время обращения и модификации MFT. Если файл
перемещается на другой том, время обращения обновляется, а время
модификации MFT остается прежним. При удалении файла временные штампы по
умолчанию не обновляются. В отдельных случаях я замечал, что время
последнего обращения обновилось, но мне не удалось выявить
закономерность.

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

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

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

После успешного поиска записи в таблице можно переходить к обработке
атрибутов. Для хранения атрибутов файла или каталога может потребоваться
несколько записей MFT; атрибут $ATTRIBUTE_LIST также может содержать
адреса

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

PAGE 295

дополнительных записей. Обработка записи МРТ начинается с заголовка,
после чего ищется первый атрибут. Далее мы читаем заголовок атрибута,
определяем его тип и соответствующим образом обрабатываем содержимое.
Местонахождение второго атрибута определяется по длине первого атрибута.
Процедура повторяется до тех пор, пока не будут обработаны все атрибуты.
На рис. 12.6 приведен пример с указанием длин атрибутов. За последним
атрибутом следует маркер ОхййЖ

56 152

264 344

1 023

Запись MFT

Oxffffffff

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

Смещение атрибута: 56

і $STANDARD_ INFORMATION (16)

Резидентный Длина атрибута: 96 Длина содержимого: 72

$FlLEJNlAME (48)

Резидентный Длина атрибута: 112 Длина содержимого: 84

$РАТА(128)

Нерезидентный Длина атрибута: 80

Серия 1: 3@824 198 Серия 2: 2@825 157

Рис. 12.6. Процесс обработки записи на примере записи MFT базового файла
(с приведенными длинами атрибутов)

Основные метаданные хранятся в атрибуте $STANDARD_INFORMATION, а
содержимое файла — в атрибуте (или атрибутах) $DATA. Например, для
получения временных штампов или информации о владельце файла следует
обратиться к атрибуту $STAN DARD_INF0RMATI0N. За информацией о
содержимом файла следует обращаться к атрибуту $DATA. Атрибут $FILE_NAME
пригодится для проверки даты создания файла и определения родительского
каталога.

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

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

Если с поиском $MFT и $MFTMirr возникнут проблемы, можно попытаться
найти в файловой системе кластеры, начинающиеся с сигнатуры «FILE» в
кодировке ASCII. К сожалению, не существует простого способа определить,
какой записи MFT соответствует найденный блок, если таблица MFT была
фрагментирована.

PAGE 296

Глава 12. NTFS: анализ

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

Любой файл или каталог может содержать дополнительные атрибуты $DATA
(кроме атрибута по умолчанию). Дополнительные атрибуты могут
использоваться как для законных целей, так и для сокрытия данных (в
Windows их значения не отображаются). Некоторые тестовые образы NTFS,
размещенные на сайте DFTT (Digital Forensic Tool Testing) [Carrier,
2003], содержат записи с несколькими атрибутами $DATA; используйте их со
своими программами и проверьте, отображаются ли значения всех атрибутов.
Тестовые образы также помогут узнать, просматривают ли ваши программы
значения атрибутов при поиске по ключевым словам.

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

В NTFS поиск свободных записей MFT является простой задачей, потому что
все данные находятся в одной таблице. В этом NTFS отличается от файловой
системы FAT, в которой метаданные могут находиться в любом месте
файловой системы. Обнаружив свободную запись MFT, мы узнаем из атрибута
$FILE_NAME ее исходное имя и адрес записи MFT. В частности, это помогает
определять контекст поиска — например, отобрать все записи MFT,
созданные в заданном временном промежутке. Поиск может вернуть свободные
записи, и знание полного пути принесет больше пользы, чем один адрес
записи.

NTFS также упрощает восстановление содержимого, связанного с удаленными
файлами. Если атрибут $DATA файла был резидентным, он сохраняется в
записи MFT, и нам не придется беспокоиться о том, что его кластеры были
выделены другому файлу. Обнаружив запись MFT, мы найдем содержимое. К
сожалению, для данных свыше 700 байт атрибут $DATA обычно становится
нерезидентным. Размер большинства файлов, содержащих улики, оказывается
больше 700 байт.

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

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

Эти три сценария показаны на рис. 12.7. В записи 90 хранится резидентный
атрибут, содержимое которого стирается при выделении записи MFT. Запись
91

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

PAGE 297

содержит нерезидентный атрибут, содержимое которого можно восстановить
методами прикладного уровня, если запись MFT была выделена заново до
кластеров, занимаемых атрибутом. Запись 92 является базовой для записи
93, атрибут $DATA сильно фрагментирован, а его описание присутствует в
обеих записях. Если какая-либо из этих записей будет выделена заново,
восстановить атрибут $DATA не удастся.

$РАТА

90

91

Резидентное содержимое атрибута

$DATA

А,

Кластеры с нерезидентным содержимым атрибута

$ATTR_LIST $DATA

$DATA

Вторая часть фрагментированного содержимого

Первая часть фрагментированного содержимого

Рис. 12.7. Возможные способы хранения содержимого $DATA

Что касается повторного выделения записей MFT в Windows, свободные
записи с малыми адресами используются раньше записей с большими
адресами. Таким образом, успешное восстановление файлов с меньшими
адресами MFT менее вероятно. Если атрибут $DATA был резидентным, то
повторное выделение записи MFT приводит к потере данных. Для
нерезидентных атрибутов даже после повторного выделения записи MFT еще
остается вероятность восстановления прикладными методами.

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

Временные штампы не обновляются при удалении файла, поэтому по ним
невозможно определить время удаления файла. Атрибут $FILE_NAME содержит
набор временных штампов, которые обновляются в момент создания или
перемещения файла или каталога. По ним можно выявить попытки изменения
времени создания в атрибуте $STANDARD_INF0RMATI0N. Время хранится в
формате UTC, поэтому программа анализа должна преобразовать время к
часовому поясу, в котором изначально находился компьютер. Это упростит
сопоставление временных штампов с данными журналов и других систем.

PAGE 298

Глава 12. NTFS: анализ

Шифрованные и сжатые атрибуты могут создать проблемы для эксперта. Если
пароль пользователя неизвестен, попробуйте поискать расшифрованные копии
зашифрованных файлов в свободном дисковом пространстве. Многие программы
анализа поддерживают работу с шифрованными и сжатыми файлами. Сжатые
файлы могут не обладать резервным пространством, и методы восстановления
прикладного уровня не будут работать с удаленными данными, хранившимися
в сжатом формате. Также протестируйте поисковые функции вашего
инструментария и проверьте, проводят ли они поиск внутри сжатых файлов.

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

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

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

Первым шагом должно стать извлечение содержимого свободного пространства
файловой системы для проведения поиска. Если программа поиска
поддерживает режим поиска только в свободном пространстве, этот шаг не
потребуется. Для решения этой задачи мы воспользуемся программой dis из
пакета TSK:

# dis -d ntfs ntfs9.dd > ntfs9.dls

Теперь можно переходить к поиску старых записей MFT. Каждая запись MFT
начинается с ASCII-сигнатуры «FILE». Для проведения поиска можно
воспользоваться стандартной утилитой типа g rep или же снова прибегнуть
к программе sigfind. Мы воспользуемся sigfind, потому что эта программа
позволяет отобрать совпадения с нулевым смещением от начала сектора.
Преобразование сигнатуры «FILE» из кодировки ASCII в шестнадцатеричный
формат дает 0х46494с45.

# sigfind -о 0 46494с45 ntfs9.dls

Поиск дает несколько совпадений, в том числе одно в секторе 412. Чтобы
показать, как обрабатываются результаты, я поэтапно опишу всю процедуру
анализа. Если вас интересуют структуры данных NTFS, вернитесь к этому
примеру после чтения следующей главы. Содержимое сектора 412 выглядит
так (с разбиением структуры данных на части):

# dd if-ntfs9.dls skip=412 count=2 | xxd

0000000: 4649 4c45 3000 0300 Ь6е5 1000 0000 0000 FILE0………..

0000016: 0100 0100 3800 0100 0003 0000 0003 0000 ….8………..

0000032: 0000 0000 0000 0000 0400 0000 4800 0000 …………H…

0000048: 0500 6661 0000 0000 ..fa….

Этот фрагмент содержит заголовок записи MFT. Флаг в байтах 22-23
показывает, что запись была выделена (0x0001 в прямом порядке байтов)
перед форматированием, а байты 20-21 — что первый атрибут начинается со
смещением 56 байт (0x0038). Заголовок первого атрибута:

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

PAGE 299

1000 0000 6000 0000

0000 0000 0000 0000 4800 0000 1800 0000 ……..Н.

0000048: 0000064: […]

0000144: Ь049 0000 0000 0000 .1 ……

Первый атрибут относится к типу $STANDARD_INFORMATION (0x0010), а его
длина составляет 96 байт (0x0060). Атрибут можно проанализировать на
предмет содержащихся в нем временных штампов. Далее мы смещаемся на 96
байт вперед, от байта 56 к байту 152:

0000144: 3000 0000 7000 0000 0…р…

0000160: 0000 0000 0000 0200 5800 0000 1800 0100 ……..X…….

0000176: 0500 0000 0000 0500 d064 f7b9 eb69 с401 ………d…i..

[…]

0000240: ОЬОЗ бсОО 6500 7400 7400 6500 7200 3100 ..1.e.t.t.e.r.l.

0000256: 2е00 7400 7800 7400 ..t.x.t.

Второй атрибут относится к типу $FILE_NAME (0x0030), а его длина
составляет 112 байт (0x0070). Мы видим, что родительский каталог этого
файла соответствует записи MFT 5, то есть корневому каталогу. В атрибуте
содержится имя файла «letterl.txt». Далее мы переходим на 112 байт
вперед от начального смещения 152, к байту 264:

0000256 0000272 0000288

4000 0000 2800 0000

0000 0000 0000 0300 1000 0000 1800 0000 …………….

6dd4 12е6 d9d5 d811 а5с7 00b0 dOld e93f m…………..?

Третий атрибут $0BJECT_ID относится к типу $0BJECT_ID (0x0040), а его
длина составляет 40 байт (0x28). Следующий атрибут начинается со
смещения 304:

8000 0000 с801 0000 0000 1800 0000 0100 …………….

ае01 0000 1800 0000 4865 бсбс 6f20 4d72 ……..Hello Mr

204a 6f6e 6573 2c0a 5765 2073 6861 бсбс Jones..We shall

0000304 0000320 0000336 […]

Последний атрибут относится к типу $DATA (0x0080), а его длина
составляет 456 байт (0x01с8). Содержимое атрибута начинается с байта 328
строкой «Hello Mr. Jones». Все содержимое файла хранится в записи MFT,
поскольку атрибут является резидентным. Если бы он был нерезидентным,
нам пришлось бы обрабатывать список серий и искать кластеры в образе
файловой системы. Структура записи показана на рис. 12.8.

56

152

264 304

760

1 023

Запись MFT

Oxffffffff

$STANDARD_ INFORMATION (16)

Резидентный Длина атрибута: 96

$OBJECTJP (64)

Резидентный Длина атрибута: 40

$РАТА(128)

Резидентный Длина атрибута: 456

$FlLEJNAME (48)

Резидентный Длина атрибута: 112

Рис. 12.8. Структура записи МГТ, обнаруженной в свободном дисковом
пространстве

PAGE 300

Глава 12. NTFS: анализ

В этом сценарии производился поиск следов файлов, существовавших до
момента форматирования тома. Мы нашли сигнатуру «FILE», существующую в
записях MFT, и разобрали одну запись вручную. Структуры данных каждого
атрибута подробно описаны в следующей главе.

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

К категории имен файлов относятся данные, связывающие имя файла с его
содержимым. До настоящего момента мы рассматривали способы хранения
данных и метаданных в NTFS, но сейчас необходимо разобраться, как же имя
связывается с файлом. Для упорядочения содержимого каталогов в NTFS
используются индексы (см. главу 11). Индекс NTFS представляет собой
набор структур данных, отсортированных по некоторому ключу. Дерево
содержит один или несколько узлов, хранящихся в атрибутах $INDEX_R00T и
$INDEX_ALL0CATI0N. Атрибут $INDEX_R00T всегда определяет корневой узел
дерева, a $INDEX_ALL0CATI0N — индексные записи, используемые для
хранения других узлов. Атрибут $В1ТМАР описывает состояние выделения
индексных записей. Каждый узел дерева содержит список индексных
элементов.

Индексы каталогов

KaTajiorNTFS представлен обычной записью MFT, у которой установлен
специальный флаг в заголовке и в атрибутах $STANDARD_IN FORMATION и
$FILE_NAME. Индексные элементы в индексе каталога содержат адрес ссылки
на файл и атрибут $FILE_NAME. Вспомните, что атрибут $FILE_NAME содержит
имя файла, временные штампы, размер и основные флаги. Windows обновляет
временные штампы и размеры, чтобы они соответствовали действительности.
Если система Windows настроена на обязательное использование имени из
пространства имен DOS, индекс содержит несколько атрибутов $FILE_NAME
для одного файла. Атрибутам $INDEX_R00T, $IN-DEX_ALL0CATI0N и $В1ТМАР
присваивается одно имя $130. Эти структуры данных представлены в главе
11, а их формальные описания приводятся в главе 13.

На рис. 12.9 показана простая двухуровневая структура каталога, в
которой корневой узел находится в атрибуте $INDEX_R00T, а атрибут
$INDEX_ALL0CATI0N содержит две индексные записи. Элементы индексной
записи 0 содержат имена, «меньшие» hhh.txt, а элементы индексной записи
1 — имена, «большие» hhh.txt Обратите внимание: файл eeeeeeeeeeee.txt не
входит в пространство имен DOS, поэтому для него создается
дополнительная запись.

При добавлении или удалении файла из каталога дерево реструктурируется
так, чтобы данные хранились в отсортированном порядке. Это может
привести к перемещению элементов в индексных записях и замене данных в
удаленных файлах. У каждого узла дерева имеется поле заголовка, которое
идентифицирует последний выделенный элемент. На рис. 12.9 некоторые
элементы (ccc.txt в $INDEX_R00T и qqq.txt в индексной записи 1)
находятся в свободном пространстве. Файл qqq.txt удален, но файл ccc.txt
продолжает существовать, он находится в индексной записи 0. Чтобы
понять, почему это происходит, обратитесь к разделу «Индексы» главы 11.

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

PAGE 301

$INDEX_ROOT

iii.txt kkk.txt Y qqq.txt

Элемент: 60 Элемент: 73 Л Элемент: 29

Индексная aaa.txt ccc.txt eeeeeeeeeeee.txt ееееее~1 .txt V

запись 0 Элемент: 45 Элемент: 58 Элемент: 48 Элемент: 48 /V

Рис. 12.9. Двухуровневое дерево каталога

Корневой каталог

В любой файловой системе для поиска файла по полному пути необходимо
знать местонахождение корневого каталога. Корневой каталог NTFS всегда
находится в записи MFT 5; ему присваивается имя «.». Запись обладает
стандартными атрибутами $INDEX_R00T, $1NDЕХ_АLL0CATI0N и $В1ТМАР. В этом
каталоге находятся все файлы метаданных файловой системы (хотя они и
скрыты от большинства пользователей).

Ссылки на файлы и каталоги

В NTFS файлу может быть присвоено более одного имени; это происходит при
создании жесткой ссылки (hard link). Жесткая ссылка не отличается от
исходного имени файла, и для нее в индексе родительского каталога
создается запись, которая указывает на ту же запись MFT, что и исходное
имя. Счетчик ссылок в заголовке записи MFT увеличивается на 1 при
создании жесткой ссылки, причем запись не освобождается до тех пор, пока
ее счетчик ссылок не уменьшится до 0. Другими словами, если исходное имя
файла удаляется, но жесткая ссылка продолжает существовать, файл удален
не будет. Запись MFT содержат по одному атрибуту $FILE_NAM Е для каждого
из имен своих жестких ссылок. Жесткие ссылки создаются только в пределах
того же тома.

В NTFS 3.0+ появился новый механизм точек подключения (reparse points),
которые могут использоваться для создания ссылок на файлы, каталоги и
тома. Точка подключения представляет собой специальный файл или каталог,
содержащий информацию о том объекте, на который он ссылается. Точки
подключения могут связываться с файлами и каталогами, находящимися на
том же томе, другом томе или на удаленном сервере. Точки подключения
также могут использоваться для монтирования тома в каталог вместо буквы
диска (например, Е:\). Символическая ссылка представляет собой точку
подключения, связывающую два

PAGE 302

Глава 12. NTFS: анализ

файла; переход (junction) — точку подключения, связывающую два каталога;
наконец, точка монтирования связывает каталог с томом. Механизм Windows
Remote Storage Server использует точки подключения для описания
местонахождения файла или каталога на сервере.

Точки подключения представляют собой специальные файлы, а в их атрибутах
$STANDARD_INFORMATION и $FILE_NAME устанавливаются соответствующие
флаги. Кроме того, они содержат атрибут $REPARSE_POINT с информацией о
местонахождении целевого файла или каталога. Структура данных атрибута
$REPARSE_POINT обсуждается в главе 13.

В NTFS информация о точках подключения хранится в индексе из файла
метаданных файловой системы \$Extend\$Reparse. Индекс сортируется по
файловым ссылкам, но не содержит сведений о местонахождении целевых
файлов.

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

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

В NTFS версий 3.0+ существует дополнительный метод адресации файлов и
каталогов (кроме стандартной адресации по именам каталогов/файлов или
адресов записей MFT). Приложение или ОС может присвоить файлу уникальный
128-разрядный идентификатор объекта, который в дальнейшем используется
для ссылок на объект даже в случае его переименования или перемещения на
другой том. Продукты Microsoft используют идентификаторы объектов при
внедрении файлов. Идентификатор может использоваться для ссылки на
внедренный файл даже после его перемещения.

У файла или каталога, которому присваивается идентификатор объекта,
создается атрибут $0BJECT_ID. Он содержит идентификатор объекта, а также
может содержать дополнительную информацию об исходном домене и томе, на
котором он был создан. Если потребуется найти файл по идентификатору
объекта, обратитесь к индексу \$Extend\$0bjId. Индекс содержит записи
для всех присвоенных идентификаторов объектов в файловой системе.

Этот метод адресации может повлиять на работу эксперта, так как может
возникнуть необходимость в поиске файла по идентификатору объекта. На
момент написания книги мне не известна ни одна программа, которая
позволяла бы проводить поиск файлов по идентификатору объекта.

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

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

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

PAGE 303

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

Небольшие каталоги состоят из одного узла, находящегося в атрибуте
$IN-DEX_R00T. Если записи не помещаются в этом атрибуте, ОС перемещает
их в индексную запись в атрибуте $INDEX_ALLOCATION. На этой стадии
В-дерево по-прежнему содержит только один узел, a $INDEX_R00T не
содержит элементов, кроме пустого элемента, ссылающегося на дочерний
узел. После заполнения индексной записи выделяется вторая запись, и
атрибут $INDEX_R00T используется в качестве корневого узла, дочерними
узлами которого являются две индексные записи. После заполнения этих
индексных записей выделяется третья, в результате чего корневой узел
будет содержать три дочерних узла.

В протестированных мной системах временные штампы и размеры в атрибуте
$FILE_NAME обновлялись с той же частотой, что и значения в атрибуте
$STAN-DARDJNFORMATION в записи MFT файла. За дополнительной информацией
обращайтесь к подразделу «Алгоритмы выделения» раздела «Категория
метаданных».

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

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

Как было показано в этом разделе и в предыдущей главе, анализ имен
файлов и индексов в NTFS является довольно сложным процессом. Он
начинается с поиска корневого каталога, представленного записью MFT 5. В
процессе обработки каталога мы просматриваем содержимое атрибутов
$INDEX_R00T и $INDEX_ALLOCATION и обрабатываем индексные элементы. В
этих атрибутах хранятся списки, называемые индексными записями и
соответствующие узлам дерева. Каждая индексная запись содержит один или
несколько индексных элементов. Индексные записи также могут содержать
свободные индексные элементы; в заголовке записи указывается, где
находится последний выделенный элемент. Состояние выделения индексных
записей определяется по атрибуту $В1ТМАР каталога. Существующие файлы
могут ассоциироваться не только с выделенными, но и со свободными
индексными элементами, потому что каталоги хранятся в виде В-деревьев,
требующих повторной сортировки при добавлении и удалении файлов.

Имя файла также может соответствовать точке подключения — ссылке или
точке монтирования. Целевой объект точки подключения определяется в
атрибуте $REPARSE_POINT записи MFT. Компания Microsoft определила
некоторые типы точек подключения, но возможны и другие типы,
специфические для конкретных приложений.

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

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

PAGE 304

Глава 12. NTFS: анализ

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

При обнаружении имени удаленного файла NTFS предоставляет ряд
преимуществ по сравнению с другими файловыми системами. Порядковый номер
в ссылке показывает, происходило ли повторное выделение записи MFT после
удаления файла. Если запись выделялась заново, скорее всего, ее данные
относятся к другому файлу. В других файловых системах нам пришлось бы
гадать, сохранилась синхронизация или нет. Другое преимущество
заключается в том, что в индексе существует атрибут $FILE_NAME с полным
набором временных штампов и флагов. Следовательно, даже если запись MFT
была выделена заново, а данные файла были стерты, базовая информация все
же остается.

При поиске удаленных файлов в каталоге программа должна проверить два
возможных места. Первое — свободные области каждого узла в дереве
индекса каталога, а второе — свободные записи MFT. Если имя файла было
стерто из индекса, но запись MFT еще существует, мы можем определить,
что файл находился в каталоге, обратившись к адресу MFT родительского
каталога в атрибуте $FILE_NAME. Убедитесь в том, что ваша программа
анализа проводит обе проверки при поиске удаленных файлов в каталогах.

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

Ваша лаборатория собирается обновить свой инструментарий анализа
файловых систем, и вам поручено протестировать новые программы. В
процессе расследования вы решаете протестировать программу Digital
Investigator 4000 (DI4K), а для подтверждения результатов
воспользоваться программой FSAnalyzer 1000 (FSA1K), которая применялась
до настоящего времени. На анализируемом компьютере с файловой системой
NTFS найден каталог с многочисленными уликами. Сравнение содержимого
каталога в двух программах выявляет ряд различий:

1. Удаленный файл aaa.txt не показывается в выходных данных DI4K, но
присутствует в выводе FSA1K.

2. Две программы выводят разные временные штампы файла mmm.txt. В DI4K
они относятся к более раннему моменту, чем в FSA1K.

3. Удаленный файл HYPERLINK “http://www.txt” www.txt показывается в
выходных данных DI4K, но отсутствует в выводе FSA1K.

Для существующих файлов результаты совпадают. Чтобы разобраться в
причинах происходящего, мы запускаем шестнадцатеричный редактор и
начинаем разбирать индекс каталога. После ручной обработки атрибутов
$INDEX_R00T и $INDEX_ALL0CATI0N выясняется, что индекс имеет структуру,
показанную на рис. 12.10(A).

Из содержимого каталога видно, отчего возникла первая проблема.
Программа FSA1K вывела файл aaa.txt как удаленный, несмотря на то, что
он про

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

PAGE 305

должает существовать. Вероятно, свободная запись появилась после
удаления другого файла и перемещения элемента aaa.txt по узлу. Более
новая программа ВЫК нашла существующую запись aaa.txt и не стала
выводить свободную запись.

А)

hhh.txt

mmm.txt

Элемент: 51 X Элемент: 31

Номер: 8

Номер: 3

aaa.txt

aaa.txt

Элемент: 45 X Элемент: 45

Номер: 5

Номер: 5

iii.txt

qqq.txt qqq.txt

Элемент: 60 X Элемент: 29 Элемент: 29

Номер: 2

Номер: 4 Номер: 4

В) ._.

Запись MFT 29 Использ.: О Номер: 4 Имя: qqq.txt Родитель: 36

Запись MFT 30 Использ.: О Номер: 7 Имя: HYPERLINK “http://www.txt”
www.txt Родитель: 36

Запись MFT 31 Использ.: О Номер: 4 Имя: rrr.txt Родитель: 56

Рис. 12.10. Каталог, для которого две программы выводят разную
информацию: (А) — структура, (В) — записи MFT

Вторая проблема относится к временным штампам файла mmm.txt. Мы видим,
что индексный элемент находится в корневом узле индекса, а его
метаданные хранятся в записи MFT 31, показанной на рис. 12.10 (В). Мы
обрабатываем атрибут $STANDARD_INFORMATION записи MFT 31 и находим
временные штампы, выведенные программой FSA1K. Просмотр временных
штампов в атрибуте $FILE_NAME индексного элемента обнаруживает временные
штампы, выведенные в DI4K. Чтобы узнать, какая информация была более
точной, мы сравниваем порядковые номера индексного элемента и записи
MFT. Выясняется, что у индексного элемента порядковый номер равен 3, а у
записи MFT — 4. Следовательно, запись MFT была выделена заново после
удаления файла mmm.txt, программа DI4K это заметила и вывела данные из
атрибута $FILE_NAME индексного элемента.

Третья проблема относилась к новому файлу HYPERLINK “http://www.txt”
www.txt ; тем не менее в индексе такого файла нет. Вспомните, что
говорилось ранее о «зависании» удаленных файлов NTFS, происходящем из-за
перезаписи удаленных имен в индексах. Мы ищем запись MFT для имени
HYPERLINK “http://www.txt” www.txt ; для этого в логической файловой
системе проводится поиск строки « HYPERLINK “http://www.txt%c2%bb”
www.txt» в Unicode. В результате поиска обнаруживается запись MFT 30, в
которой указана запись родительского каталога 36 — запись того самого
каталога, который мы анализируем. Можно сделать вывод, что новая
программа DI4K не только выводит информацию о свободных элементах в
индексе, но и ищет зависшие файлы.

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

PAGE 306

Глава 12. NTFS: анализ

Категория прикладных данных

К уникальным особенностям файловой системы NTFS относится поддержка
многих возможностей прикладного уровня. Речь идет о возможностях,
повышающих эффективность работы операционной системы или приложений, но
которые тем не менее не обязательно включать в файловую систему. Ни одна
из возможностей прикладного уровня не является необходимой в отношении
главного предназначения файловой системы — сохранения и загрузки файлов.
Более того, пользователь или приложение может заблокировать некоторые из
возможностей прикладного уровня. В этом разделе рассматриваются дисковые
квоты, журналы файловой системы и протоколирование изменений;
соответствующие структуры данных будут описаны в главе 13. Я буду
называть данные «необходимыми», если они критичны для работы функции
прикладного уровня, а не для реализации основной функции файловой
системы (сохранения-выборки данных).

Дисковые квоты

В NTFS включена поддержка квот дискового пространства. Квоты
устанавливаются администратором для ограничения места на диске,
доступного для каждого пользователя. Часть информации о квотах хранится
в данных файловой системы, другие данные хранятся в файлах прикладного
уровня (например, в реестре Windows). В версиях NTFS, предшествовавших
3.0, запись MFT 9 представляла файл метаданных файловой системы $Quota,
но в версиях 3.0+ этот файл хранится в каталоге \$Extend, а для его
представления может использоваться любая запись MFT.

В файлах $Quota для управления информацией квот используются два
индекса. Первому индексу присваивается имя $0, и он связывает код SID с
идентификатором владельца (на этот раз речь идет о «типичном» коде SID
системы Windows, а не об идентификаторе безопасности файловой системы,
упоминавшемся выше). Второй индекс с именем $Q связывает идентификатор
владельца с информацией о выделенном и расходуемом дисковом
пространстве.

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

Данные квот не являются необходимыми, поскольку операционная система не
нуждается в них при использовании файловой системы. Например, другая ОС
может смонтировать файловую систему NTFS и не обновить квоты при
создании файла пользователем. Квоты могут пригодиться при экспертном
анализе — например, по ним можно определить, кто из пользователей
сохранял в системе большие объемы данных. Например, если вы обнаружили
систему с несколькими учетными записями пользователей и большим
количеством пиратских фильмов, по файлам квот можно будет определить,
кто из пользователей создавал файлы. Ту же информацию можно получить
простым анализом атрибута $STANDARD_IN FORMATION каждого файла. Система
квот по умолчанию не активна, поэтому в большинстве систем эти данные не
существуют.

Журналы файловых систем

Для повышения надежности файловой системы компания Microsoft включила в
NTFS поддержку журналов. Как говорилось в главе 8, журнал файловой
системы

Категория прикладных данных

PAGE 307

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

Файл журнала NTFS представлен записью MFT 2; ему присвоено имя $LogFUe.
Эта запись MFT не имеет специальных атрибутов, а содержимое журнала
хранится в атрибуте $DATA. Я обнаружил, что размер файла журнала
составляет около 1-2 % общего размера файловой системы. О содержимом
журнала известно очень мало, хотя компания Microsoft опубликовала
кое-какую высокоуровневую информацию в своих руководствах и в книге
«Inside Windows 2000».

Файл журнала делится на две основные части: область рестарта и
протокольную область. Как показано на рис. 12.11, область рестарта
содержит две копии структуры данных, которая помогает ОС выбрать
транзакции для анализа при выполнении отката. В ней содержится указатель
на последнюю заведомо успешную транзакцию в протокольной области.

$LogFile I—I-1-1-1-

Запись MFT I—I-1-J L–

Нерезидентный атрибут $DATA

Область Протокольная рестарта область

Рис. 12.11. Структура атрибута $РАТА файла $1_одП1е, содержащего журнал
ШРБ

Протокольная область содержит серию записей. Каждой записи соответствует
логический порядковый номер (Ь5Ы), который представляет собой уникальное
64-разрядное значение. Номера ЬБЫ назначаются в порядке возрастания.
Протокольная область имеет конечный размер, и когда в конце файла не
остается места для создания новой записи, она помещается в начало файла.
В этой ситуации запись в конце файла журнала будет обладать большим
номером Ь8Ы, чем у записи в начале файла. Другими словами, номера
назначаются записям на основании времени их создания, а не расположения
в файле. Записи, ставшие ненужными, заменяются при повторном заполнении
журнала.

PAGE 308

Глава 12. NTFS: анализ

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

• создание файла или каталога;

• изменение содержимого файла или каталога;

• переименование файла или каталога;

• изменение любых данных, хранящихся в записи MFT файла или каталога
(идентификатор пользователя, параметры безопасности и т. д.).

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

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

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

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

Журнал не содержит пользовательских данных, которые являются
нерезидентными и хранятся во внешних кластерах, поэтому он не может
использоваться для восстановления файлов. В нем хранится содержимое
резидентных атрибутов для отмены недавних изменений. На момент написания
книги мне неизвестна ни одна программа анализа, которая бы умела
использовать данные в файле журнала, потому что не все структуры данных
документированы. Впрочем, кое-какую информацию можно найти простым
просмотром строк ASCII или Unicode в файле (см. раздел «Файл $LogFile»
главы 13).

Категория прикладных данных

PAGE 309

В заголовке каждой записи МРТ хранится последний номер для файла. В
частности, его значение приводилось в выходных данных 1Б1а1 в
приведенных ранее примерах. По этому значению можно определить
относительный порядок изменения двух файлов.

Транзакция 2, записи обновления

Транзакция 1, записи обновления

Транзакция 1, запись закрепления

Область рестарта

Протокольная область

‘ Запись обновления

Неиспользуемая запись

Рис. 12.12. Пример $LogFlle с двумя транзакциями за последней записью
контрольной точки. Одна из транзакций не была закреплена

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

Журнал может предоставить информацию о последних изменениях в файловой
системе. Тем не менее невозможно предсказать, как долго будут
существовать файлы до их перезаписи, но самое худшее — неизвестна
структура этого файла. Следовательно, даже если вы найдете улики,
возможно, их будет трудно интерпретировать. Значение LSN в заголовке
записи MFT файла позволяет восстановить порядок редактирования. Чем
больше число, тем позднее редактировался файл.

Журнал изменений

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

В Windows любое приложение может включать и отключать механизм журнала
по своему усмотрению. По умолчанию он отключен. С журналом ассоциируется

PAGE 310

Глава 12. NTFS: анализ

64-разрядное число, которое изменяется при каждом включении или
отключении. При помощи этого числа приложение может определить, что
из-за отключения журнала некоторые изменения оказались потерянными. При
отключении журнала Windows удаляет файл в Windows 2000 и ХР.

Журнал изменений хранится в файле \$Extend\$UsrJrnl. Обычно этому файлу
не выделяется одна из зарезервированных записей MFT, и он обладает двумя
атрибутами $DATA. Первый атрибут с именем $Мах содержит базовую
информацию о журнале. Второй атрибут с именем $J содержит сам журнал в
виде списка записей переменного размера. Каждая запись содержит имя
файла, время изменения и тип изменения. Длина записи зависит от длины
имени файла. Каждая запись обладает 64-разрядным порядковым номером
обновления, или USN (Update Sequence Number). Номера USN используются
для индексирования записей в журнале и хранятся в атрибуте
$STANDARD_INFORMATION модифицированного файла. USN соответствует
смещению внутри журнала в байтах, что позволяет легко найти запись по
USN (потому что все записи имеют разные размеры). Запись не содержит
информации о том, какие данные изменились; указывается только тип
изменений.

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

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

Трудно заранее сказать, сколько информации можно извлечь из этого файла;
нет гарантии, что механизм журнала будет включен. Более того, при его
отключении Windows удаляет содержимое файла, причем отключение может
производиться любым приложением. Если все же допустить, что журнал был
включен и его содержимому можно доверять, содержимое журнала может
пригодиться для реконструкции недавних событий. Для файла сохраняется
только время последней модификации или создания, а журнал может
содержать информацию о многих изменениях, хотя точные описания этих
изменений не будут известны.

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

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

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

PAGE 311

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

В этом примере создается файл HYPERLINK “file:///dirl/filel.dat”
\dirl\filel.dat ; предполагается, что каталог dirl уже существует в
корневом каталоге. Размер файла составляет 4000 байт, а размер кластера
равен 2048 байт.

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

2. Мы читаем из MFT первую запись (файл $МПГ) и обрабатываем ее для
определения структуры остальных записей MFT. Информация хранится в
атрибуте $DATA.

3. Для нового файла выделяется запись MFT. Чтобы найти неиспользуемую
запись, мы обрабатываем атрибут $В1ТМАР файла $МПГ. Первая свободная
запись (304) выделяется новому файлу, а соответствующий бит карты
устанавливается в 1.

4. Происходит инициализация записи MFT 304, для чего мы находим запись в
MFT и стираем ее содержимое. В записи создаются атрибуты
$STAN-DARD_INFORMATION и $FILE_NAME, а временные штампы инициализируются
текущим временем. В заголовке записи MFT устанавливается флаг
использования.

5. Далее для файла необходимо выделить два кластера; при этом
используется атрибут $DATA файла $Bitmap, находящийся в записи MFT 6.
Два смежных кластера, 692 и 693, находятся с использованием алгоритма
оптимального подбора. Соответствующие биты карты для кластеров
устанавливаются равными 1. В кластеры записывается содержимое файла, и
атрибут $DATA обновляется адресами кластеров. В записи MFT обновляются
временные штампы.

6. На следующем шаге создается информация об имени файла. Информация
dirl ищется в корневом каталоге, находящемся в записи MFT 5. Мы читаем
атрибуты $INDEX_R00T и $INDEX_ALL0CATI0N и перемещаемся по
отсортированному дереву. После обнаружения индексного элемента dirl из
него берется адрес записи MFT 200. Обновляется время последнего
обращения к каталогу.

7. Обработка атрибута $INDEX_R00T записи MFT 200 дает местонахождение
файла filel.dat. Для файла создается новый индексный элемент, и все
дерево сортируется заново. Это может привести к перемещению индексных
элементов внутри узла. У нового индексного элемента в поле базового
адреса указана запись MFT 304, а временные штампы и флаги заданы
соответствующим образом. Для каталога обновляется время последней
модификации и обращения.

8. Каждый из перечисленных этапов может сопровождаться созданием записей
в журнале файловой системы $LogFile и журнале изменений
\$Extend\$UsrJrnl. Если в системе поддерживаются квоты, новый размер
файла включается в квоту пользователя в файле \$Extend\$Quota.

Связи между компонентами и итоговое состояние системы показаны на рис.
12.13.

PAGE 312

Глава 12. NTFS: анализ

200

304

Битоваяя карта записи MFT

Журнал $LogFile

filel .dat, атрибут $DATA

Кластер 692

Кластер 693

Рис. 12.13. Состояние системы после создания файла HYPERLINK
“file:///dirl/fjlel.dat” \dirl\fjlel.dat

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

Теперь посмотрим, что происходит при удалении файла HYPERLINK
“file:///dirl/filel.dat” \dirl\filel.dat

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

2. Мы читаем из MFT первую запись (файл $МПГ) и обрабатываем ее для
определения структуры остальных записей MFT. Информация хранится в
атрибуте $ DATA.

3. Далее необходимо найти каталог dirl, поэтому мы обрабатываем запись
MFT корневого каталога (5) и перемещаемся по индексу в атрибутах
$INDEX_R00T и $INDEX_ALL0CATI0N. Из обнаруженного элемента dirl берется
адрес записи MFT 200. Обновляется время последнего обращения к каталогу.

4. Мы обрабатываем атрибут $INDEX_R00T записи MFT 200 и ищем в нем
элемент filel.dat. Выясняется, что адрес MFT файла соответствует записи
304.

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

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

PAGE 313

6. Запись MFT 304 освобождается сбросом флага использования. Также
обрабатывается атрибут $DATA файла $Bitmap, и в нем обнуляется бит
данной записи.

7. Обрабатываются нерезидентные атрибуты записи MFT 304; соответствующие
кластеры переводятся в свободное состояние в битовой карте файла
\$Bitmap. В нашем примере освобождаются кластеры 692 и 693.

8. Каждый из перечисленных этапов может сопровождаться созданием записей
в журнале файловой системы $LogFUe и журнале изменений
\$Extend\$UsrJrnl. Если в системе поддерживаются квоты, новый размер
файла вычитается из квоты пользователя в файле \$Extend\$Quota.

Итоговое состояние показано на рис. 12.14. Обратите внимание: при
удалении файла в NTFS Windows не стирает указатели. Таким образом, связь
между записью MFT и кластером сохраняется, а связь между именем файла и
записью MFT тоже продолжала бы существовать, если бы запись не была
потеряна в результате пересортировки.

Битовая карта записи MFT

Журнал $LogFile

200

304

file1.dat, атрибут $DATA

Кластер 692

ШШШШшШ

Рис. 12.14. Состояние системы после удаления файла HYPERLINK
“file:///dirl/filel.dat” \dirl\filel.dat . Серым цветом помечены
освобождающиеся блоки

PAGE 314

Глава 12. NTFS: анализ

Разное

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

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

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

У NTFS есть один большой недостаток: при исключении имени файла из
индекса родительского каталога индекс сортируется заново, и информация
об имени может быть потеряна. В этом случае имя удаленного файла
пропадает из исходного каталога. Тем не менее недостаток отчасти
компенсируется тем, что все записи MFT хранятся в одной таблице, что
упрощает поиск всех свободных записей. Кроме того, каждая запись
содержит атрибут $FILE_NAME с базовым адресом родительского каталога. А
это означает, что при нахождении свободной записи обычно удается
определить ее полный путь, если только записи ее родительских каталогов
не были повторно выделены новым файлам или каталогам.

Другое обстоятельство, которое необходимо учитывать при восстановлении
удаленных файлов в NTFS — поиск дополнительных атрибутов $DATA. Для
тестирования программ восстановления файлов в NTFS можно воспользоваться
тестовыми образами с сайта DFTT [Carrier 2004]. Образ содержит удаленные
файлы с несколькими атрибутами $DATA, на которые не ссылается ни один
индексный элемент.

Чтобы восстановить все удаленные файлы в NTFS, необходимо провести в MFT
поиск свободных записей. После обнаружения свободной записи имя
определяется по атрибуту $FILE_NAME и адресу родительского каталога.
Указатели на кластеры продолжают существовать, и если данные еще не были
перезаписаны, их удастся восстановить. Восстановление возможно даже при
сильной фрагментации файла. Если значение атрибута было резидентным,
данные не будут перезаписаны вплоть до повторного выделения записи MFT.
Если для хранения атрибутов файла требуется более одной записи MFT, для
полного восстановления могут потребоваться другие записи. В Windows для
записей MFT используется алгоритм выделения первой доступной записи,
поэтому записи MFT с малыми номерами выделяются чаще, чем записи с
большими номерами.

При восстановлении файлов или просмотре удаленного содержимого могут
пригодиться данные журнала файловой системы или журнала изменений.
Журнал изменений не всегда активен, но в нем можно найти информацию о
времени удаления и последнего редактирования файла.

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

Проверки целостности применяются в расследованиях для идентификации
поврежденных образов или выявления фактов постороннего вмешательства. В
этом

Итоги

315

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

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

Каждый выделенный кластер должен входить в серию кластеров. Каждый
выделенный кластер NTFS является частью файла или каталога, и проверка
целостности должна подтвердить этот факт. У каждой выделенной записи MFT
должны быть установлены флаг использования и соответствующий бит
атрибута $В1ТМАР. Кроме того, у каждой выделенной записи MFT для каждого
имени файла должен существовать элемент в индексе каталога. Даже файлы
метаданных файловой системы должны быть представлены именами в своих
родительских каталогах.

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

Итоги

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

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

PAGE 316

Глава 12. NTFS: анализ

С другой стороны, из-за общей сложности системы эксперту труднее
объяснить, где именно были найдены улики.

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

• Carrier, Brian. «NTFS Keyword Search Test #1». Digital Forensic Tool
Testing, October 2003. HYPERLINK “http://dftt.sourceforge.net”
http://dftt.sourceforge.net

• Carrier, Brian. «NTFS Undelete (and leap year) Test #1». Digital
Forensic Tool Testing, February 2003. HYPERLINK
“http://dftt.sourceforge.net” http://dftt.sourceforge.net

• Microsoft. «Recovering NTFS Boot Sector on NTFS Partitions». Knowledge
Base Article 153973,2003. HYPERLINK
“http://support.microsoft.com/default.aspx?sdd=kb;EN-US;ql53973”
http://support.microsoft.com/default.aspx?sdd=kb;EN-US;ql53973

• Microsoft MSDN Library. «FILETIME». 2004. HYPERLINK
“http://msdn.microsoft.com/Library/” http://msdn.microsoft.com/Library/
en-us/sysinfo/base/filetime_str.asp.

Также см. раздел «Библиография» главы 11.

Структуры данных NTFS

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

Базовые концепции

Этот раздел посвящен основным концепциям структур данных NTFS. Сначала
мы рассмотрим некоторые особенности строения больших структур данных,
повышающие их надежность, а затем обсудим строение записи MFT и
заголовка атрибута.

Маркеры

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

PAGE 318

Глава 13. Структуры данных NTFS

Структуры данных, использующие маркеры, содержат заголовочные поля с
указанием текущей 16-разрядной сигнатуры и массива исходных значений.
Когда структура данных записывается на диск, сигнатура увеличивается на
1, два последних байта каждого сектора копируются в массив, а на их
место записывется сигнатура. При чтении структуры данных ОС убеждается в
том, что два последних байта каждого сектора совпадают с сигнатурой,
после чего восстанавливает исходные данные из массива. На рис. 13.1
показана структура данных с реальными данными и версия, записываемая на
диск. Во второй структуре два последних байта каждого сектора заменены
сигнатурой 0x0001.

Исходная структура данных

Сигнатура: 0x0000

Массив: 0x0000, 0x0000, 0x0000

Сектор 0 Сектор 1 Сектор 2

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

Сигнатура: 0x0001

Массив: 0x3596, 0х7А12, 0xBF81

Сектор 0 Сектор 1 Сектор 2

Рис. 13.1. Структура данных, состоящая из нескольких секторов: исходные
значения и сигнатуры, записанные в два последних байта каждого сектора

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

Записи MFT (файловые записи)

Как упоминалось в главах И и 13, главная файловая таблица MFT (Master
File Table) является основной структурой данных NTFS; в ней создается
запись для каждого файла и каталога в системе. Записи MFT имеют
фиксированный размер и содержат минимальный набор полей. В настоящее
время размер записей составляет 1024 байт, но формально он определяется
в загрузочном секторе. В каждой записи MFT используются проверочные
маркеры, поэтому в дисковой версии

Базовые концепции

PAGE 319

структуры данных два последних байта каждого сектора заменяются
сигнатурой (см. предыдущий раздел). Поля записи МРТ перечислены в табл.
13.1.

Таблица 13.1. Структура данных базовой записи MFT

Диапазон Описание Необходимость

0-3 Сигнатура («FILE») Нет

4-5 Смещение массива маркеров Да

6-7 Количество элементов в массиве маркеров Да

8-15 Номер LSN для $LogFile Нет

16-17 Порядковый номер Нет

18-19 Счетчик ссылок Нет

20-21 Смещение первого атрибута Да

22-23 Флаги (использования и каталога) Да

24-27 Используемый размер записи MFT Да

28-31 Выделенный размер записи MFT Да

32-39 Адрес базовой записи Нет

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

42-1023 Атрибуты и маркеры Да

В качестве стандартной сигнатуры используется строка «FILE», но в
записях, в которых программа chkdsk обнаружила ошибки, также может
содержаться строка «BAAD». В следующих двух полях содержатся маркеры, а
массив замененных байтов обычно хранится после байта 42. Смещения
задаются по отношению к началу записи.

Номер LSN используется в журнале файловой системы (см. раздел «Категория
прикладных данных» главы 12). В журнале фиксируются обновления
метаданных в файловой системе; эта информация ускоряет восстановление
поврежденных файловых систем.

Порядковый номер увеличивается при каждом выделении и освобождении
записи. Счетчик ссылок определяет число каталогов, содержащих записи для
данной структуры MFT. Число увеличивается на 1 для каждой жесткой
ссылки, создаваемой для файла.

Первый атрибут файла находится по смещению, заданному относительно
начала файла. За первым атрибутом следуют остальные; чтобы найти их,
следует сместиться вперед на величину, указанную в поле размера в
заголовке атрибута. За последним атрибутом находится признак конца файла
Oxffffffff. Если файлу требуется более одной записи MFT, то в
дополнительные записи включается базовый адрес основной записи.

Поле флагов содержит только два значения. Бит 0x01 устанавливается в том
случае, если запись используется, а бит 0x02 — если запись представляет
каталог.

Давайте рассмотрим низкоуровневое содержимое записи MFT. Мы
воспользуемся программой icat из пакета TSK (The Sleuth Kit) и
просмотрим атрибут $ DATA файла $MFT, соответствующего записи 0. Чтобы
задать любой атрибут в TSK, достаточно добавить идентификатор типа
атрибута после адреса записи MFT. В данном случае атрибут $DATA обладает
типом 128. # icat -f ntfs ntfsl.dd 0-128 | xxd

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

PAGE 320

Глава 13. Структуры данных NTFS

0100 0100 3800 0100 Ь801 0000 0004 0000 0000 0000 0000 0000 0600 0000
0000 0000 5800 0000 0000 0000 1000 0000 6000 0000

0000016: 0000032: 0000048: С..]

0000496: 3101 Ь43а 0500 0000 ffff ffff 0000 5800 0000512: 0000 0000 0000
0000 0000 0000 0000 5800 С.]

0001008: 0000 0000 0000 0000 0000 0000 0000 5800

В выходных данных используется прямой порядок байтов, поэтому байты
чисел необходимо поменять местами. Листинг начинается с сигнатуры
«FILE», а байты 4 и 5 показывают, что массив данных, замененных
маркерами, хранится в записи MFT со смещением 48 байт (0x0030). Из
байтов 6-7 видно, что массив состоит из 3 элементов. Байты 16-17
показывают, что порядковый номер записи MFT равен 1; иначе говоря, это
первое использование записи. Счетчик ссылок (байты 18-19) равен 1; это
означает, что запись обладает единственным именем. Байты 20-21
показывают, что первый атрибут начинается со смещения 56 (0x0038).

Флаги в байтах 22-23 показывают, что запись используется в настоящий
момент. Поле базовой записи (байты 32-39) равно 0, то есть сама запись
является базовой. Байты 40-41 показывают, что следующий идентификатор
атрибута равен 6. Следовательно, мы можем предположить, что запись
содержит атрибуты с идентификаторами от 1 до 5.

С байта 48 начинается массив данных, замененных маркерами. Первые два
байта определяют сигнатуру (0x0058). За ними следуют 2-байтовые группы
исходных данных, которые должны быть записаны на место сигнатур. Мы
обращаемся к двум последним байтам каждого сектора (байты 510-511 и
1022-1023) и видим, что в обоих случаях в них содержится сигнатура
0x0058. Маркеры заменяются значением 0x0000, взятым из массива. После
массива с байта 56 начинается первый атрибут. Атрибуты файла завершаются
на байте 504 признаком конца файла Oxffff ffff. Остальные байты записи
равны 0.

Для просмотра произвольной записи MFT в TSK можно воспользоваться
программой dd в сочетании с icat для перехода к нужному смещению. При
этом размер блока устанавливается равным 1024, то есть размеру каждой
записи MFT. Например, команда для просмотра записи 1234 выглядит так: #
icat -f ntfs ntfsl.dd 0 | dd bs-1024 skip=1234 count-1 | xxd

Заголовок атрибута

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

Первые 16 байт атрибутов обоих типов совпадают. Содержащиеся в них поля
перечислены в табл. 13.2.

Базовые концепции

PAGE 321

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

Заголовок атрибута

Запись MFT I

Неиспользуемое пространство

т

t t

$STD_INFO $DATA $FILE_JMAME

Рис. 13.2. Типичный файл с различными заголовками

Таблица 13.2. Структура начальных 16 байт атрибута

Диапазон Описание Необходимость

0-3 Идентификатор типа атрибута Да

4-7 Длина атрибута Да

8-8 Флаг нерезидентного атрибута Да

9-9 Длина имени Да

10-11 Смещение имени Да

12-13 Флаги Да

14-15 Идентификатор атрибута Да

Заголовок содержит базовую информацию об атрибуте, включая тип, размер и
местонахождение имени. Размер используется для поиска следующего
атрибута в записи МРТ; за последним атрибутом следует специальная
последовательность 0xffff Флаг нерезидентного атрибута устанавливается
равным 1, если атрибут является нерезидентным. Поле флагов указывает,
является ли атрибут сжатым (0x00001), зашифрованным (0x4000) или
разреженным (0x8000). Идентификатор атрибута представляет собой число,
уникальное для данного атрибута в данной записи МРТ. Смещение имени
задается относительно начала атрибута. Поля резидентного атрибута
перечислены в табл. 13.3.

Таблица 13.3. Структура данных резидентного атрибута

Диапазон Описание Необходимость

0-15 Общий заголовок (см. табл. 13.2) Да

16-19 Размер содержимого Да

20-21 Смещение содержимого Да

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

0000000: 1000 0000 6000 0000 0000 1800 0000 0000 ………..

0000016: 4800 0000 1800 0000 305а 7alf f63b с301 Н…….OZz..;..

PAGE 322

Глава 13. Структуры данных МТРБ

В первых четырех байтах содержится тип атрибута 16 (0x10),
соответствующий $5ТАМ0АК0_1МР0КМАТЮМ. Байты 4-7 показывают, что размер
атрибута равен 96 байтам (0x60). Из байта 8 видно, что атрибут является
резидентным (0x00), а из байта 9 — что ему не присвоено имя (0x00).
Флаги и идентификаторы в байтах 12-13 и 14-15 заполнены нулями. Байты
16-19 показывают, что длина содержимого атрибута составляет 72 байта
(0x48), а байты 20-21 — что атрибут начинается со смещением 24 байта
(0x18). Выполним несложную проверку: 24 байта смещения в сумме с 72
байтами длины содержимого составляют 96 байт, то есть длину атрибута,
указанную в заголовке.

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

Таблица 13.4. Структура данных нерезидентного атрибута

Диапазон Описание Необходимость

0-15 Общий заголовок (см. табл. 13.2) Да

16-23 Начальный виртуальный номер кластера (УСЫ) списка серий Да

24-31 Конечный номер УСЫ списка серий Да

32-33 Смещение списка серий Да

34-35 Размер блока сжатия Да

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

40-47 Выделенный размер содержимого атрибута Нет

48-55 Фактический размер содержимого атрибута Да

56-63 Инициализированный размер содержимого атрибута Нет

Вспомните, что У СИ представляет собой другое название для логических
адресов файлов, о которых говорилось в главе 8. Начальный и конечный
номера У СИ используются в тех случаях, когда для описания одного
атрибута требуется несколько записей МП”. Например, если атрибут $0АТА
сильно фрагментирован и его серии не помещаются в одной записи МП”, для
него может быть выделена вторая запись МРТ. Вторая запись содержит
атрибут $0АТА с начальным номером УСЖ, который следует за конечным
номером У СИ первой записи. Пример приводится в разделе «$АТТКШиТЕ_Ы8Т».
Поле размера блока сжатия описано в главе 11; оно необходимо только для
сжатых атрибутов.

Смещение списка серий задается относительно начала атрибута. Формат
списка серий чрезвычайно эффективен, но простотой он не отличается.
Список имеет переменную длину не менее 1 байта. Первый байт структуры
данных разделен на старшие и младшие 4 бита. Младший полубайт содержит
размер (в байтах) поля длины серии, следующего за байтом заголовка.
Старший полубайт содержит размер (в байтах) поля смещения серии,
следующего за полем длины. Пример показан на рис. 13.3.

Значения задаются в кластерах, а поле смещения является знаковым
значением, заданным по отношению к предыдущему смещению. Например,
смещение первой серии атрибута задается по отношению к началу файловой
системы,

Базовые концепции

PAGE 323

а смещение второй серии — по отношению к предыдущему. У отрицательного
числа старший бит равен 1; если вы собираетесь ввести значение на
калькуляторе, чтобы преобразовать его, прибавьте столько единиц, сколько
потребуется для формирования полного 32- или 64-разрядного числа.
Например, если значение равно ОхИ, на калькуляторе вводится значение
Oxfffffffl.

0010 0001

Байт 1 Байт 2 Байт 3 Байт 4

Длина Смещение серии серии

Рис. 13.3. Первый байт серии показывает, что поле длины занимает 1 байт,
а поле смещения — 2 байта

Чтобы просмотреть содержимое нерезидентного атрибута, давайте вернемся к
ранее проанализированной записи и перейдем к атрибуту $DATA. Содержимое
атрибута показано далее (смещения скорректированы по отношению к началу
атрибута):

0000000: 8000 0000 6000 0000 0100 4000 0000 0100 …Г…..Q…..

0000016: 0000 0000 0000 0000 ef20 0000 0000 0000 ……………

0000032: 4000 0000 0000 0000 ООсО 8300 0000 0000 @……………

0000048: ООсО 8300 0000 0000 ООсО 8300 0000 0100 …………….

0000064: 32с0 1еЬ5 За05 2170 lblf 2290 015f 7е31 2…:.!р..”.._~1
0000080: 2076 ed00 2110 8700 00b0 6е82 4844 7е82 v..!…..n.HD~.

Первые 4 байта показывают, что атрибут относится к типу 128 (0x80), а
вторая группа из 4 байт — что его общий размер равен 96 байтам (0x60).
Байт 8 равен 1; это означает, что атрибут является нерезидентным.
Нулевой байт 9 означает, что длина имени атрибута равна 0;
следовательно, перед нами атрибут $DATA по умолчанию, а не ADS. По
нулевым флагам (байты 12-13) мы определяем, что атрибут не зашифрован и
не сжат.

Нерезидентная информация начинается с байта 16. Байты 16-23 показывают,
что начальный номер VCN для этого набора серий равен 0. Конечный номер
VCN задается байтами 24-31; в данном примере он равен 8431 (0x20ef).
Байты 32-33 показывают, что смещение списка серий составляет 64 байта
(0x0040) от начала. Байты 40-47,48-55 и 56-63 предназначены для
выделенного, фактического и инициализированного размеров содержимого; в
них хранится одно и то же значение 8 634 368 байт (0х0083с000).

В байте 64 начинается сам список серий. Я снова приведу соответствующий
фрагмент:

0000064: 32с0 1еЬ5 За05 2170 lblf

Вспомните, что первый байт делится на старшие и младшие 4 бита, в
которых хранится размер остальных полей. Младший полубайт байта 64
показывает, что поле длины серии состоит из 2 байт, а старший полубайт —
что поле смещения состоит из 3 байт. Чтобы определить длину серии, мы
анализируем байты 65-66 и получаем 7872 кластера (OxlecO). Следующие три
байта (67-69) дают смещение 342 709 (0х053аЬ5). Следовательно, первая
серия начинается с кластера 342 709 и продолжается 7 872 кластера.

PAGE 324

Глава 13. Структуры данных NTFS

Структура данных следующей серии начинается после завершения текущей, то
есть с байта 70. Мы видим, что поле длины состоит из 1 байта, а поле
смещения — из 2 байт. Значение длины хранится в байте 71 и равно 112
(0x70). Величина смещения хранится в байтах 72-73 и равна 7963 (Oxlflb).
Смещение является знаковой величиной и задается по отношению к
предыдущему смещению; прибавляя 7963 к 342 709, мы получаем 350 672.
Следовательно, вторая серия начинается с кластера 350 672 и продолжается
112 кластеров. Остаток списка серий вы можете расшифровать
самостоятельно.

Стандартные атрибуты файлов

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

Атрибут $STAN DARD_INFORMATION

Атрибут $STANDARD_INFORMATION (идентификатор типа 16) всегда является
резидентным. В нем хранятся основные метаданные файлов или каталогов.
Атрибут существует в каждом файле или каталоге; как правило, он
находится в первой позиции списка атрибутов из-за наименьшего
идентификатора типа. Поля атрибута (необязательные) перечислены в табл.
13.5.

Таблица 13.5. Структура данных атрибута $STANDARDJNFORMATION

Диапазон Описание Н еобход и м ость

0-7 Время создания Нет

8-15 Время модификации файла Нет

16-23 Время модификации MFT Нет

24-31 Время обращения к файлу Нет

32-35 Флаги (см. табл. 13.6) Нет

36-39 Максимальное количество версий Нет

40-43 Номер версии Нет

44-47 Идентификатор класса Нет

48-51 Идентификатор владельца (версия 3.0+) Нет

52-55 Идентификатор безопасности (версия 3.0+) Нет

56-63 Изменение квоты (версия 3.0+) Нет

64-71 Номер USN (Update Sequence Number) Нет

Значения временных штампов задаются в сотнях наносекунд, прошедших с 1
января 1601 г., в формате UTC. Эти поля также присутствуют и в атрибуте
$FILE_NAME, но именно этот набор штампов выводится Windows при просмотре
свойств файла и обновляется системой. Идентификаторы используются как
функ-

Стандартные атрибуты файлов

PAGE 325

циями прикладного уровня, так и системой безопасности. Идентификатор
безопасности используется для индексирования файла $Secure; не путайте
его с кодом SID системы Windows. Значения флагов перечислены в табл.
13.6.

Таблица 13.6. Флаги атрибута $STANDARD_INFORMATJON

Флаг Описание Необходимость

0x0001 Только для чтения Нет

0x0002 Скрытый файл Нет

0x0004 Системный файл Нет

0x0020 Архивный файл Нет

0x0040 Устройство Нет

0x0080 Обычный файл Нет

0x0100 Временный файл Нет

0x0200 Разреженный файл Нет

0x0400 Точка подключения Нет

0x0800 Сжатый файл Нет

0x1000 Автономный файл Нет

0x2000 Содержимое не индексируется для ускорения поиска Нет

024000 Зашифрованный файл Нет

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

Рассмотрим пример атрибута $STANDARD_INF0RMATI0N. Для вывода его
содержимого можно воспользоваться программой icat и указать тип
атрибута. В этом случае icat автоматически скрывает стандартный
заголовок и выводит только содержимое. Содержимое атрибута
$STANDARD_INFORMATION для файла $MFT выглядит так:

# icat -f ntfs ntfsl.dd 0-16 | xxd

0000000: 305a 7alf f63b c301 305a 7alf f63b c301 OZz..:..OZz..;..

0000016: 305a 7alf f63b c301 305a 7alf f63b c301 OZz..;..OZz..;..

0000032: 0600 0000 0000 0000 0000 0000 0000 0000 …………….

0000048: 0600 0000 0001 0000 0000 0000 0000 0000 …………….

0000064: 0600 0000 0000 0000 ……..

В первых 8 байтах указано время создания файла; оно совпадает для всех
четырех временных штампов. Байты 32-35 содержат поле набора флагов
0x00000060; в нем установлены биты скрытого и системного файла, что
вполне естественно для файла метаданных файловой системы. Байты 36-39 и
40-43 показывают, что версии не используются, а из байтов 44-47 видно,
что идентификатор класса равен 0. Идентификатор владельца (байты 48-51)
равен 0, а идентификатор безопасности (байты 52-55) равен 1. Остальные
значения равны 0, что вполне естественно для $МгЛГ, потому что эта
запись обычно не учитывается в пользовательских квотах, а в большинстве
систем журналы изменений по умолчанию отключены, из-за чего номера иБИ
не назначаются.

PAGE 326

Глава 13. Структуры данных NTFS

Атрибут $FILE_NAME

Атрибут $FILE_NAME (идентификатор типа 48) выполняет две функции.
Во-первых, он включается в записи MFT для хранения имени файла и
информации о родительском каталоге; во-вторых, он используется в
индексах каталогов. При использовании в записях MFT атрибут не содержит
никакой необходимой информации, но в индексах эта информация
присутствует.

Для стандартных файлов и каталогов этот атрибут находится на второй
позиции и всегда является резидентным. Если для хранения файла требуется
несколько записей MFT, атрибут $ATTRIBUTE_LIST будет находиться между
$STANDARD_INFORMATION и этим атрибутом. Поля атрибута $FILE_NAME
перечислены в табл. 13.7.

Таблица 13.7. Структура данных атрибута $FILE_NAME

Диапазон Описание Необходимость

0-7 Базовый адрес родительского каталога Нет

8-15 Время создания файла Нет

16-23 Время модификации файла Нет

24-31 Время модификации МП” Нет

32-39 Время обращения к файлу Нет

40-47 Выделенный размер файла Нет

48-55 Реальный размер файла Нет

56-59 Флаги (см. табл. 13.6) Нет

60-63 Точка подключения Нет

64-64 Длина имени Да/Нет

65-65 Пространство имен (см. табл. 13.8) Да/Нет

66+ Имя Да/Нет

Последние три поля необходимы в тех случаях, когда атрибут используется
в индексе каталога, но не при его использовании в записи MFT для файла.
В поле флагов применяются те же значения, что и в атрибуте
$STANDARD_INFORMATION (см. ранее).

Байт пространства имен указывает, по каким правилам строится имя файла.
Допустимые значения приведены в табл. 13.8.

Таблица 13.8. Значения поля пространства имен атрибута $FILE_NAME

Код Описание

пространства

имен

0 POSIX: в имени учитывается регистр символов; допустимы любые символы
Unicode, кроме / и NULL

1 Win32: регистр символов не учитывается; допустимо большинство символов
Unicode, кроме некоторых специальных символов (/, \, :, >, 0) Да

Последние 8 байт элемента, Номер УСЫ дочернего узла в $ШОЕХ_АЬ Да

начиная с 8-байтовой ЮСАТЮЫ (поле существует только

границы при установленном флаге)

Атрибуты и структуры данных индексов

PAGE 337

Базовый адрес ссылается на запись MFT, которой соответствует индексный
элемент. В индексных элементах этого типа используются стандартные
флаги: 0x01 — признак наличия дочерних узлов, и 0x02 — признак последней
записи в списке.

Теперь рассмотрим остаток содержимого атрибутов $INDEX_R00T и
$INDEX_AL-L0CATI0N, которые были частично проанализированы ранее. Начнем
с атрибута $INDEX_R00T:

# icat -f ntfs ntfsl.dd 7774-144 | xxd

0000000: 3000 0000 0100 0000 0010 0000 0400 0000 0……………

0000016: 1000 0000 aOOO 0000 aOOO 0000 0100 0000 …………….

0000032: c51e 0000 0000 0500 7800 5a00 0100 0000 ……..x.Z…..

0000048: 5ele 0000 0000 0300 e03d ca37 5029 c401 x……..-.7P)..

0000064: 004c c506 0202 c401 e09a 2a36 5029 c401 .L……..*6P)..

0000080: d0e4 22b5 096a c401 0004 0000 0000 0000 ……….

0000096: 7003 0000 0000 0000 2120 0000 0000 0000 p…….!…….

0000112: 0c02 4d00 4100 5300 5400 4500 5200 7e00 ..M.A.S.T.E.R.-.

0000128: 3100 2e00 5400 5800 5400 0000 0000 0300 1…T.X.T…….

0000144: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

0000160: 1800 0000 0300 0000 0400 0000 0000 0000 …………….

[…]

Первые 32 байта уже обработаны; начальные 16 байт образуют заголовок
$IN-DEX_R00T, а следующие 16 байт — заголовок узла. Байты 32-37
показывают, что элемент относится к записи MFT 7877 (0х1ес5). Байты
40-45 показывают, что размер индексного элемента равен 120 байтам
(0x78), поэтому в выходных данных он завершается в байте 152. Байты
26-27 показывают, что размер атрибута равен 90 байтам (0x5а). Флаг в
байте 28 сообщает о наличии дочернего узла, адрес которого содержится в
последних 8 байтах элемента, но мы уже об этом знаем благодаря флагу в
заголовке узла.

Атрибут $FILE_NAME находится в байтах 48-137, а байты 144-151 завершают
индексный элемент и содержат номер VCN дочернего узла (кластер 0). В
качестве имени файла приводится строка «MASTER~1.TXT». Байты 152-175
содержат пустой индексный элемент, а флаг в байте 164 равен 3; он
указывает на то, что элемент завершает список и имеет дочерний узел.
Байты 168-175 содержат адрес дочернего узла (VCN 4). В нем находятся две
индексные записи, которые мы видели в атрибуте $INDEX_ALLOCATION.
Строение этого атрибута показано нарис. 13.7.

Заголовок Индексный элемент

узла MASTER-1 .TXT (MFT: 7 877)

\ Номер VCN дочернего узла: О

V J V Номер VCN дочернего узла: 4 $INDEX_ROOT | | I I

Рис. 13.7. Строение атрибута $INDEX_ROOT для рассматриваемого каталога

Процесс можно было бы повторить для каждой индексной записи в атрибуте
$INDEX_ALLOCATION. Вместо этого мы рассмотрим кое-какие интересные
данные, следующие за заголовком узла. Ранее было показано, что индексные
элементы в индексной записи 0 заканчиваются на смещении 2296, но узлу
выделены еще

PAGE 338

Глава 13. Структуры данных NTFS

1776 байт, в которых может содержаться информация об удаленных именах
файлов. Попробуем просмотреть неиспользуемую область и найти в ней
действительные индексные элементы. Содержимое атрибута со смещением 2400
выглядит так:

0002400 0002416 0002432 0002448 0002464 0002480 0002496 bele 0000 0000
0600 6800 5400 0000 0000 ……..h.Т.

5ele 0000 0000 0300 908b bf37 5029 c401 004c c506 0202 c401 e09a 2a36
5029 c401 30a7 6410 9c4a c401 003c 0000 0000 0000 003a 0000 0000 0000
2120 0000 0000 0000 0903 7000 7300 6100 7000 6900 2e00 6400 6c00 6c00
6500 0000 2513 0000 0000 ObOO

.L.. O.d.

..7P). .*6P).

..p.s.a.p. 1.1.Є…Х.

Индексный элемент относится к файлу в записи MFT 7870 (Охlebe), а файл
называется psapi.dll. Вследствие природы механизма пересортировки
индексов мы не можем сказать, был ли файл удален или перемещен в другую
позицию из-за добавления или удаления файла. На этот вопрос можно
ответить только после анализа всех остальных индексных элементов. TSK
отображает все элементы, а пользователь может самостоятельно
разобраться, почему элемент был освобожден. Впрочем, программа Autopsy
фильтрует вывод TSK и отображает только уникальные имена.

На рис. 13.8 показаны отношения между индексными элементами $INDEX_R00T
и индексными записями $INDEX_ALLOCATION. Мы видим, что корневой узел
индекса содержит два элемента. Любой файл с именем, меньшим
MASTER~1.TXT, находится в индексной записи с номером VCN 0, а любой файл
с большим именем — в индексной записи VCN 4. В конце индексной записи
VCN 0 присутствует свободное пространство, в котором мы нашли данные
файла psapi.dll. Обратите внимание на то, что это имя больше
MASTER~1.TXT; вероятно, на момент его сохранения в этом узле корневой
узел содержал другой элемент.

Заголовок узла

Заголовок $INDEX_ROOT

$INDEX_ROOT

Индексный элемент MASTER-1 .TXT (MFT: 7 877) Номер VCN дочернего узла: О

Индексный элемент Признак конца списка Номер УСЫ дочернего узла: 4

$INDEX ALLOCATION

Заголовок индексной записи VCN:0 Заголовок узла

Свободный индексный элемент psapi.dll (MFT: 7 870)

Заголовок узла

Заголовок индексной записи VCN:4

Рис. 13.8. Строение индексных элементов в примерах

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

PAGE 339

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

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

Файл $МПГ представлен записью МРТ 0. Он уже рассматривался в начале
главы, потому что этот файл абсолютно необходим для операций с каждым
файлом в файловой системе. Примеры выходных данных 1Б1а1 для файла $МПГ
приводились в главе 12. Файл обладает стандартными атрибутами, а в
атрибуте $0АТА содержится таблица МРТ.

Файл $МПГ содержит только один уникальный атрибут $В1ТМАР. В нем
хранится информация о состоянии выделения записей МРТ. Если бит,
представляющий запись, установлен, значит, запись выделена, а если бит
равен 0 — запись свободна. Для просмотра атрибута $В1ТМАР можно
воспользоваться программой ка! и указать тип атрибута 176:

# каг -1 г^б HYPERLINK “http://ntfsl.dc” ntfsl.dc ! 0-176 | ххс1

0000000: 1111 0011 1111 1111 1111 1111 1111 1111 …………….

0000016: 1111 1111 1111 1111 1111 1111 1111 1111 …………….

[…]

Файл $Воо1 представлен записью МРТ 7; в его атрибуте $0АТА хранится
содержимое загрузочного сектора и загрузочный код. Атрибут всегда
начинается с сектора 0, в котором хранится структура данных загрузочного
сектора. Остальные секторы используются для хранения загрузочного кода.
В табл. 13.18 перечислены поля загрузочного сектора.

Таблица 13.18. Структура данных загрузочного сектора

Диапазон Описание Необходимость

0-2 Машинная команда перехода к загрузочному коду Нет (если файловая
система

Файл $MFT

Файл $Boot

не является загрузочной)

3-10 11-12

13- 13

14- 15

Имя OEM

Количество байт в секторе Количество секторов в кластере Количество
зарезервированных секторов (Microsoft требует, чтобы поле было равно 0)
Не используется (Microsoft требует, чтобы поле было равно 0) Дескриптор
носителя Не используется (Microsoft требует, чтобы поле было равно 0)

Не используется (по данным Microsoft поле не проверяется)

Нет Да Да Нет

16-20

Нет

21- 21

22- 23

Нет Нет

24-31

Нет продолжение &

PAGE 340

Глава 13. Структуры данных NTFS

Таблица 13.18 {продолжение)

Диапазон

Описание

Необходимость

40-47 48-55 56-63

64- 64

65- 67

68- 68

69- 71 72-79 80-83 84-509 510-511

32-35

36-39

Не используется (Microsoft требует, чтобы поле было равно 0)

Не используется (по данным Microsoft поле не проверяется)

Общее количество секторов в файловой системе

Адрес начального кластера MFT

Адрес начального кластера атрибута $DATA

зеркальной копии MFT

Размер записи MFT (файловой записи)

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

Размер индексной записи

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

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

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

Загрузочный код

Сигнатура (0хаа55)

Да Да Нет

Да

Нет

Да

Нет

Нет

Нет

Нет

Нет

Нет

Нет

Неиспользуемые поля соответствуют полям блокаВРВ (BIOS Parameter Block)
загрузочного сектора FAT. В документации Microsoft указано, что для
монтирования файловой системы некоторые из этих полей должны быть
обязательно равны 0, но формально эти значения не обязательны для
функционирования файловой системы, и Microsoft могла не проверять эти
значения. Я убедился в том, что Windows ХР отказывается монтировать
диск, если содержимое этих полей отлично от 0.

Среди параметров, хранящихся в загрузочном секторе, важнейшими являются
размер каждого сектора и кластера. Без них поиск и идентификация данных
в файловой системе в принципе невозможны. Следующие важные параметры —
начальный адрес MFT и размер каждой записи MFT. До настоящего времени во
всех версиях Windows размер записей MFT всегда составлял 1024 байта, но
это поле существует для того, чтобы размер записи можно было легко
сменить в будущем. Также обратите внимание на заданный адрес атрибута $
DATA файла $MFTMirr. С его помощью программа восстановления информации
может определить, где находится резервная копия $МПГ.

Поля, в которых хранятся размеры записи MFT и индексных записей, имеют
специальный формат. Если значение больше 0, оно представляет количество
кластеров, используемых для хранения каждой структуры данных. Если
значение меньше 0, оно представляет двоичный логарифм количества байт в
каждой структуре данных. Чтобы вычислить количество байт, следует взять
модуль отрицательного числа (то есть изменить знак) и возвести число 2 в
указанную степень. Например, если значение равно -10, то размер
структуры данных составит 210= 1024 байта. Этот способ применяется в тех
случаях, когда размер кластера больше одной записи MFT или индексной
записи.

Рассмотрим пример содержимого загрузочного сектора. Вывод istat для
файла $Boot уже приводился в главе 12; воспользуемся программой icat для
вывода атрибута $DATA (тип 128):

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

PAGE 341

# icat -f ntfs ntfsl.dd 7-128 I xxd

0000000

0000016

0000032

0000048

0000064

0000080

0000096

[…]

0000448

0000464

0000480

0000496

[…]

eb52 904e 5446 5320 2020 2000 0202 0000 .R.NTFS …..

0000 0000 00f8 0000 3f00 ffOO 3f00 0000 ……..?…?…

0000 0000 8000 8000 4060 lfOO 0000 0000 ……..Г……

Ь53а 0500 0000 0000 10d8 0700 0000 0000 .:…………..

0100 0000 0400 0000 947c 2250 8422 5004 ………|”P.”P.

0000 0000 fa33 c08e dObc 007c fbb8 c007 …..3…..|….

8ed8 e816 00b8 OOOd 8ec0 33db c606 OeOO ……….3…..

6d70 7265 7373 6564 OOOd 0a50 7265 7373 mpressed…Press

2043 7472 62cb 416c 742b 4465 6c20 746f Ctrl+Alt+Del to

2072 6573 7461 7274 OdOa 0000 0000 0000 restart……..

0000 0000 0000 0000 83a0 Ь3с9 0000 55aa …………..U.

В первой строке отображается имя OEM (строка «NTFS»), за которым следует
несколько пробелов в кодировке ASCII (0x20). Это стандартное имя,
которое присваивается системой Windows. Байты 11-12 сообщают количество
байт в каждом секторе — оно равно 512 (0x0200). Байт 13 показывает, что
один кластер состоит из двух секторов, то есть размер кластера
составляет 1024 байта. Байты 40-47 показывают, что общее количество
секторов в файловой системе равно 2 056 256 (0x001 f6040); таким
образом, объем файловой системы составляет 1 Гбайт. Байты 48-55
показывают, что MFT начинается с кластера 342 709 (0х00053аЬ5), а байты
56–63 — что атрибут $DATA зеркальной копии MFT начинается с кластера
514 064 (0x0007d810).

Байт 64 определяет размер каждой записи MFT. Напомню, что способ
кодирования этой величины определяется ее знаком. В данном случае
значение равно 1, поэтому оно определяет количество кластеров в записи
MFT; следовательно, каждая запись занимает 1024 байта. В байте 68
хранится размер каждой индексной записи в каталоге. Значение равно 4, то
есть каждая индексная запись состоит из 4 кластеров.

Байты 72-79 содержат серийный номер файловой системы; в нашем примере он
равен 0х0450228450227С94. В остальных байтах хранится загрузочный код, а
байты 510-511 содержат сигнатуру 0хАА55, которая совпадает с сигнатурой
FAT.

Файл $AttrDef

Файл метаданных файловой системы $AttrDef (запись MFT 4) определяет
имена и идентификаторы атрибутов файловой системы. Атрибут $DATA этого
файла представляет собой список записей, поля которых перечислены в
табл. 13.19.

Таблица 13.19. Структура данных записей $AttrDef

Диапазон Описание Необходимость

0-127 Имя атрибута Да

128-131 Идентификатор типа Да

132-135 Правило отображения Нет

136-139 Правило сортировки Нет

140-143 Флаги (см. табл. 13.20) Да

144-151 Минимальный размер Нет

152-159 Максимальный размер Нет

PAGE 342

Глава 13. Структуры данных NTFS

Если размеры атрибута не ограничены, минимальный размер будет равен О, а
максимальный — Oxffffffffffffffff. Биты, устанавливаемые в поле флагов,
перечислены в табл. 13.20.

Таблица 13.20. Поле флагов в записях атрибута $AttrDef

Значение

Описание

0x02 0x04 0x08

Атрибут может использоваться в индексах Атрибут всегда является
резидентным Атрибут может быть нерезидентным

Правило сортировки используется при нахождении атрибута в индексах.
Атрибут $DATA для файла $AttrDef в нашем тестовом образе имеет следующее
содержимое:

# icat -0000000: 0000016: 0000032: 0000048: 0000064: 0000080: 0000096:
0000112: 0000128: 0000144:

f ntfs ntfsl.dd 2400 5300 5400 4400 5f00 4900 4100 5400 4900 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000
0000 0000 3000 0000 0000 4-128 I xxd

4100 4y00 4400 4100 5200 4e00 4600 4f00 5200 4d00 4f00 4e00 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0000 4000 0000 0000 4880 0000 0000 0000

Первое определение относится к атрибуту $5ТАМР/А1Ш_1МР0КМАП0М. Байты
128-131 определяют тип атрибута 16 (0x10). Флаги в байтах 140-143
означают, что атрибут всегда является резидентным. Согласно байтам
144-151 минимальный размер атрибута равен 48 байтам (0x30), а
максимальный — 72 байтам (0x48).

Файл $ВНхпар

Файл $В1ТМАР, представленный записью МЕТ 6, содержит атрибут $Р/АТА с
информацией о состоянии выделения кластеров. Данные битовой карты
делятся на 1-байтовые блоки; младший бит каждого байта соответствует
кластеру, который следует за кластером, соответствующим старшему биту
предыдущего байта.

Для примера рассмотрим два байта с двоичными значениями 00000001 и
00000011. Младший бит первого байта, соответствующий кластеру 0, равен
1. Следующие 7 бит (справа налево) равны 0, то есть кластеры 1-7
свободны. У второго байта два младших бита, соответствующих кластерам 8
и 9, равны 1. Как видите, битовая карта читается от младших бит справа
налево, а после старшего бита анализ переходит к следующему байту.

Чтобы узнать состояние выделения заданного кластера, необходимо
определить, в каком байте карты находится соответствующий бит. Для этого
адрес кластера нацело делится на 9. Например, информация о кластере 5
будет храниться в байте 0 битовой карты, а информация о кластере 18 — в
байте 2. Номер бита определяется остатком от деления. Например, при
делении 5 на 8 остаток был равен 5, а при делении 18 на 8 остаток был
равен 2. На рис. 13.9 приведен наглядный пример вычисления бит для
кластеров 5 и 74.

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

PAGE 343

Кластер 5: Байт: 5/8 = 0 Смещение: 5-8×0 =

1111 0101

Кластер 74: Байт: 74 / 8 = 9 Смещение: 74 – 8 х 9 :

1000 ООН

f5 ff 70 00 00 fl ff ff ff 83 13 50

01 23456789 10 11 Рис. 13.9. Пример проверки состояния выделения
для кластеров 5 и 74

Располагая информацией о строении битовой карты, возвращаемся к нашей
тестовой файловой системе. Для просмотра содержимого атрибута $DATA мы
воспользуемся программой icat:

# icat -f ntfs ntfsl.dd 6-128 | xxd

ffff ffff ffff ffff ffff ff3f 0000 0000 ………..?….

0000 fOff ffff ffff ffff ffff ffff ffff …………….

ffff ffff ffff ffff ffff ffff ffff ffff …………….

ffff ffff ffff ffff 0300 0000 ffff ffff …………….

ffff ffff ffff ffff ffff ffff ffff ffff …………….

ffff ffff ffff ffff ffff ffff ffff ffff …………….

0000000 0000016 0000032 0000048 0000064 0000080 […]

Все начальные биты содержат 1; загрузочный сектор находится в первых 8
Кбайт файловой системы, поэтому вполне логично, что эти кластеры
выделены. В байте 11 мы видим значение 0x3f, или 00111111 в двоичном
представлении. Этот байт соответствует кластерам 88-95 файловой системы.
Шесть младших битов установлены в 1; это означает, что кластеры выделены
для использования. Седьмой и восьмой биты (кластеры 94 и 95) равны 0.
Следующие шесть байт заполнены нулями, то есть кластеры этих битов
свободны. Байт 18 содержит значение ОхЮ, или 1111 0000 в двоичном
представлении.

Файл $Volume

Файл $Volume (запись MFT 3) обладает двумя уникальными атрибутами,
которые будут описаны в этом разделе.

Атрибут $VOLUMEJ4AME

Предполагается, что атрибут $VOLUME_NAME (идентификатор типа 96)
создается только в файле $Volume. В нем хранится имя тома в кодировке
Unicode UTF-16, и ничего более. В тестовом образе его содержимое
выглядит так:

# icat -f ntfs ntfsl.dd 3-96 | xxd

0000000: 4e00 5400 4600 5300 2000 4400 6900 7300 N.T.F.S. 0000016: 6b00
2000 3200 k. .2.

.D.I.s.

В данном примере файловой системе присвоено имя «NTFS Disk 2».

Атрибут $VOШ М E_IN FORMATION

Второй атрибут, уникальный для файла $ Volume, — $V0LUME_INF0RMATI0N
(идентификатор типа 112). В этом атрибуте хранится версия файловой
системы. В табл. 13.21 перечислены поля атрибута $V0LUME_INF0RMATI0N.

PAGE 344

Глава 13. Структуры данных NTFS

Таблица 13.21. Структура данных атрибута $VOLUME_INFORMATION

Диапазон Описание Н еобход и м ость

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

8-8 Основная версия Да

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

10-11 Флаги (см. табл. 13.22) Нет

В Windows NT основная версия равна 1, а дополнительная — 2. В Windows
2000 основная версия равна 3, а дополнительная — 0. В Windows ХР
используется основная версия 3, а дополнительная — 1. Флаги,
используемые в этой структуре данных, перечислены в табл. 13.22.

Таблица 13.22. Флаги поля $VOLUME_INFORMATION

Значение Описание

0x0001 Флаг обновления

0x0002 Изменение размера $1_одРПе (журнал файловой системы)

0x0004 Обновление тома

0x0008 Монтирование в 1ЧТ

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

0x0020 Восстановление идентификаторов объектов

0x8000 Изменяется спкс!5к

Атрибут $V0LUME_INFORMATION в тестовой файловой системе содержал
следующие данные:

# icat -f ntfs ntfsl.dd 3-112 | xxd

0000000: 0000 0000 0000 0000 0301 0000 …………….

Согласно байтам 8 и 9, файловая система обладает номером версии 3.1, что
соответствует ХР. Поле флагов заполнено нулями.

Файл $ObjId

Как было показано в главе 12, на файл можно ссылаться не только по
имени, но и по идентификатору объекта. Идентификаторы позволяют найти
файл даже после его переименования. Файл \$Extend\$ObjId содержит индекс
с именем $0, связывающий идентификатор объекта файла с записью MFT. Как
правило, для представления файла $0bjld не используются
зарезервированные записи MFT.

Индекс содержит типичные атрибуты $INDEX_R00T и $INDEX_ALLOCATION. В
табл. 13.23 перечислены поля элементов этого индекса.

Таблица 13.23. Структура данных индексных записей атрибута $ObjId

Диапазон Описание Необходимость

0-1 Смещение информации файла Да

2-3 Размер информации файла Да

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

8-9 Размер индексного элемента Да

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

PAGE 345

Диапазон Описание Необходимость

10-11 Размер идентификатора объекта Да

12-15 Флаги (см. табл. 13.16) Да

16-31 Идентификатор объекта Да

32-39 Базовый адрес файла Да

40-55 Исходный идентификатор тома Нет

56-71 Исходный идентификатор объекта Нет

72-87 Исходный идентификатор домена Нет

Поле флагов содержит стандартные биты: 0x01 при наличии дочерних узлов и
0x02 для последнего элемента в списке. Далее приводятся некоторые
индексные элементы атрибута $1М0ЕХ_1ЮОТ (заголовок узла не показан):

0000000: 2000 3800 0000 0000 5800 1000 0000 0000 .8…..X

0000016: Ге24 Ь024 е292 Ге47 95ас е507 4ЬГ5 6782 .$.$…6

0000032: 0300 0000 0000 0300 0000 0000 0000 0000

0000048: 0000 0000 0000 0000 0000 0000 0000 0000

0000064: 0000 0000 0000 0000 0000 0000 0000 0000

0000080: 0000 0000 0000 0000 2000 3800 0000 0000

0000096: 5800 1000 0000 0000 а162 Зс15е сс!с1а (1811

0000112: 883с ООЬО сКШ е93Г а400 0000 0000 0100

0000128: Ге24 Ь024 е292 Ге47 95ас е507 4Ы5 6782

0000144: а162 Зс15е сс!с1а (1811 883с ООЬО с101с1 е93Г

0000160: 0000 0000 0000 0000 0000 0000 0000 0000

Байт 8 показывает, что длина элемента равна 88 байтам (0x58), а в байтах
16-31 хранится 16-байтовый идентификатор объекта. Байты 32-37 определяют
адрес записи МРТ для данного идентификатора, он равен 3. Этот индексный
элемент соответствует атрибуту $ОВйЕСТ_10, описанному в разделе «Атрибут
$ОВ^СТ_Ш». Остальные поля этого элемента равны 0, а следующий элемент
начинается с байта 88.

Файл $(2исЯа

Файл \$Ех1епс1\$0ио1а используется механизмом пользовательских квот. Для
него используется обычная (не зарезервированная) запись МРТ. Файл
содержит два индекса; оба используют стандартные атрибуты $1М0ЕХ_1Ю0Т и
$1М0ЕХ_А1_1_0САТЮМ для хранения своих индексных элементов. Индекс $0
связывает код 8Ш с идентификатором владельца, а индекс $0 связывает
идентификатор владельца с информацией квот. В табл. 13.24 перечислены
поля индексных элементов индекса $0.

Таблица 13.24. Структура данных элементов индекса $0 файла $Quota

Диапазон Описание Необходимость

0-1 Смещение идентификатора владельца (OFF) Да

2-3 Длина идентификатора владельца Да

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

8-9 Размер индексного элемента Да

10-11 Размер SID (L) Да

продолжение &

PAGE 346

Глава 13. Структуры данных NTFS

Таблица 13.24 {продолжение)

Диапазон Описание Необходимость

12-15 Флаги (см. табл. 13.16) Да

16-(16+L+1) SID Да

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

В этих индексных элементах используются те же флаги, которые приводились
ранее для имен файлов. Флаг 0x01 является признаком наличия дочерних
узлов, а флаг 0x02 — признаком последнего элемента в списке. Если
дочерний узел существует, то последние 8 байт используются для хранения
кода VCN дочернего узла.

Первый индексный элемент индекса $0 выглядит так:

0000000: 1с00 0400 0000 0000 2000 0с00 0000 0000 ……………

0000016: 0101 0000 0000 0005 1200 0000 0401 0000 …………….

0000032: 1с00 0400 0000 0000 2000 0с00 0000 0000 ……………

0000048: 0101 0000 0000 0005 1300 0000 0301 0000 …………….

[…]

Байты 0-1 показывают, что идентификатор владельца хранится со смещением
28 (0x1с) от начала элемента, а байты 2-3 — что его длина составляет 4
байта. Байты 8-9 показывают, что длина индексной записи равна 32 байтам
(0x20), а байты 10-11 — что код SID занимает 12 байт (0x0с). Код SID
хранится в байтах 16-27, а байты 28-31 содержат идентификатор владельца
260 (0x0104). Второй элемент списка начинается с байта 32, а его
идентификатор владельца находится в байтах 60-63 и равен 259 (0x0103).

Индекс $Q связывает идентификатор владельца с информацией о квотах. В
табл. 13.25 перечислены поля индексных элементов $Q.

Таблица 13.25. Структура данных элементов индекса $Q файла $Quota

Диапазон Описание Необходимость

0-1 Смещение информации квот Да

2-3 Размер информации квот Да

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

8-9 Размер индексного элемента Да

10-11 Размер идентификатора владельца (4 байта) Да

12-15 Флаги (см. табл. 13.16) Да

16-19 Идентификатор владельца Да

20-23 Версия Нет

24-27 Флаги квот (см. табл. 13.26) Да

28-35 Байты, начисляемые пользователю Да

36-43 Время последнего начисления Нет

44-51 Мягкий порог Да

52-59 Жесткий порог Да

60-67 Время превышения Да

68-79 SID Да

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

PAGE 347

В индексных элементах используются стандартные флаги: 0x01 — признак
наличия дочерних узлов, и 0x02 — признак последней записи в списке.
Флаги квот перечислены в табл. 13.26.

Таблица 13.26. Флаги квот в индексных элементах $Q

Флаг Описание

0x00000001 Используются лимиты по умолчанию

0x00000002 Достигнут лимит

0x00000004 Идентификатор удален

0x00000010 Отслеживание использования данных

0x00000020 Обеспечение правил использования данных

0x00000040 Запрос на отслеживание

0x00000080 Создание записи в журнале при достижении порога

0x00000100 Создание записи в журнале при достижении лимита

0x00000200 Устаревшая информация

0x00000400 Поврежденные данные

0x00000800 Незавершенные операции удаления

Далее приводится пример индексного элемента из тестового образа, который
уже использовался для индекса $0. Данные взяты из атрибута
$1М0ЕХ_А1_1_0САТЮМ, данные заголовка удалены. Приведенная информация
взята из списка элементов и соответствует идентификатору владельца,
показанному в предыдущем примере.

0000000 0000016 0000032 0000048 0000064 0000080 0000096 0000112 0000128
0000144 1400 ЗсОО 0000 0000 5000 0400 0000 0000 0301 0000 0200 0000 0100
0000 0028 0500 0000 0000 401Ь 7сЗс 7751 с401 ffff ffff ffff ffff ffff
ffff ffff ffff 0000 0000 0000 0000 0101 0000 0000 0005 1300 0000 1400
ЗсОО 0000 0000 5000 0400 0000 0000 0401 0000 0200 0000 0100 0000 0094
6602 0000 0000 90fe 8bdf d769 c401 ffff ffff ffff ffff ffff ffff ffff
ffff 0000 0000 0000 0000 0101 0000 0000 0005 1200 0000 [email protected]. /dev/null m.c
1/lrwxrwxrwx root root /root/.bash_history -> /dev/null […]

У двух файлов в каталоге /usr/man/.Ci зарегистрировано время изменения
08:51:56, при этом указан идентификатор пользователя 1010. Обычно
программа построения временной диаграммы преобразует идентификатор в имя
пользователя, как в двух нижних строках, где идентификатор 0
преобразован в строку root. В процессе поиска в системе обнаруживается
tar-файл с подозрительным каталогом. Идентификатор пользователя,
ассоциированный с файлом, может быть сменен командой chown; впрочем,
даже если идентификатор пользователя присутствует в файле паролей, это
еще не доказывает, что файл был создан именно этим пользователем. Если
мы хотим знать, кто создал подозрительный каталог, следует
проанализировать разрешения родительского каталога. В данном случае
родительским каталогом является каталог /usr/local/, принадлежащий
привилегированному

PAGE 376

Глава 14. Ext2 и Ext3: концепции и анализ

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

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

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

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

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

Записи каталогов

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

Каждый каталог начинается с записей «.» и «..», обозначающих текущий и
родительский каталог соответственно. За ними следуют записи всех файлов
и подкаталогов в данном каталоге. Корневой каталог всегда размещается в
индексном узле 2.

Запись каталога имеет динамическую длину, потому что файл может обладать
именем произвольной длины, от 1 до 255 символов. По этой причине в
структуре данных присутствует поле, определяющее длину имени и
местонахождение следующей записи каталога. Длина записей округляется до
числа, кратного 4. На рис. 14.6 изображен каталог с тремя файлами.
Первые две записи предназначены для каталогов «.» и «..», а последняя
запись ссылается на конец выделенного блока. Пространство за файлом
c.txt не используется.

При удалении файла или каталога его имя требуется модифицировать, чтобы
ОС не пыталась выводить информацию об этом файле. ОС скрывает запись
каталога, увеличивая длину предыдущей записи, чтобы она ссылалась на
запись после скрываемой. Так, на рис. 14.6(B) файл b.txt был удален, а
указатель в a.txt был увеличен и переведен на c.txt. При выводе
содержимого каталога запись b.txt пропускается, но данные в ней еще
существуют.

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

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

PAGE 377

кратной 4. Если зарезервированная длина записи превышает необходимую на
величину, превышающую размер добавляемой записи, запись размещается в
неиспользуемом пространстве. Для примера рассмотрим новый каталог с
4096-байтовым блоком, содержащим записи «.» и «..». Параметры этих
записей перечислены в табл. 14.1.

А)

г

г

г

г

і посіє 410 іпосіе 900 a.txt іпосіе 419 b.txt іпосіе 429 c.txt іпосіе
482

В)

г і г

г

іпосіе 410 іпосіе 900 a.txt іпосіе 419 b.txt Іпосіе 429 c.txt іпосіе
482

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

Таблица 14.1. Параметры записей только что созданного каталога

Имя Длина имени Длина записи

1 12

2 4084

Последняя запись «..» обладает длиной 4084 байта, потому что она должна
указывать на конец блока, хотя реально требуется всего 12 байт.
Следовательно, новая запись каталога будет добавлена со смещением 12
байт от начала записи «..», а ее длина выбирается так, чтобы она
ссылалась на конец блока. Параметры записей каталога после создания
нового файла приведены в табл. 14.2.

Таблица 14.2. Параметры записей после создания нового файла

Имя Длина имени Длина записи

1 12

2 12

Filel.dat 8 4072

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

PAGE 378

Глава 14. Ext2 и Ext3: концепции и анализ

Далее приводится результат выполнения fis для одного из каталогов
тестового образа. В выходных данных присутствует один удаленный файл (он
помечен префиксом *). В первом столбце отображается тип файла — сначала
по данным из записи каталога, затем по данным из индексного узла.
Обратите внимание на совпадение этих типов у удаленного файла; возможно,
индексный узел еще не был выделен повторно:

# fis -f linux-ext3 -a ext3.dd 69457

d/d 69457:

d/d 53248:

г/г 69458: acbdefg.txt г/г * 69459: file two.dat d/d 69460: subdirl
г/г 69461: RSTUVWXY

Ссылки и точки монтирования

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

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

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

Примеры жестких и мягких ссылок показаны на рис. 14.7. Слева изображена
жесткая ссылка hardlink.txt, указывающая на файл filel.txt. Справа
изображена мягкая ссылка на тот же файл, но на этот раз в схеме
появляется промежуточный уровень. Файл softlink.txt обладает собственным
индексным узлом, содержащим путь к файлу. Обратите внимание: на рисунке
(В) у обоих индексных узлов счетчик ссылок равен 1. В действительности
символическая ссылка сохранит адрес HYPERLINK “file:///filel.txt”
/filel.txt в индексном узле, потому что путь короче 60 символов.

Как упоминалось в главе 4, в каталогах UNIX могут храниться как файлы,
так и точки монтирования томов. Рассмотрим каталог dirl из файловой
системы с именем FS1. Если файловая система FS2 смонтирована в каталоге
dirl, при переходе пользователя в этот каталог и выводе его содержимого
будут выведены файлы из FS2. Даже если в FS1 каталог dirl содержит
собственные файлы, при монтировании FS2 они отображаться не будут. На
рис. 14.8 (А) каталог dirl содержит три графических файла, но на рис.
14.8 (В) пользователь видит вместо них три файла из корневого каталога
тома FS2.

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

PAGE 379

А)

В)

file1.txt

hardlink.txt

file1.txt

Узел: 1234 Ссылки: 2

softlink.txt

Узел: 1234 Ссылки: 1

file1.dat contents

Узел: 2591 Ссылки: 1

file1.dat contents HYPERLINK “file:///file1.txt” /file1.txt

Блок 450 Блок 450 Блок 967

Рис. 14.7. Жесткая (А) и мягкая (В) ссылки на файл filel.txt

А)

В)

FS1

FS1

/dirt/

filel .jpg

file2.jpg

file3.jpg

/dirt/

FS2

filel .jpg

file2.jpg

file3.jpg

fileXYZ1.dat

fileXYZ2.dat

fileXYZ3.dat

Рис. 14.8. В РБ1 каталог содержит три файла, но при монтировании в нем
РБ2 эти три файла не видны

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

Хеш-деревья

При создании файловой системы вместо описанной реализации на базе
списков пользователь может выбрать реализацию на базе хеш-деревьев. Если
файловая

PAGE 380

Глава 14. Ext2 и Ext3: концепции и анализ

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

Хеш-деревья ExtX сходны с В-деревьями, упоминавшимися в главе 11; за
информацией о том, как деревья используются в каталоге, обращайтесь к
этому разделу. Главное различие между хеш-деревьями и В-деревьями
состоит в том, что в хеш-деревьях файлы сортируются по хеш-кодам имен
файлов, а не по самим именам. В ExtX реализована экспериментальная
поддержка В-деревьев, аналогичных В-деревьям ШТЗ, но в этой главе она не
обсуждается, потому что эта возможность еще не стала стандартной.

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

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

Индексное хеш-дерево содержит до трех уровней. Структуры данных
дескрипторов узлов и пример каталога приводятся в главе 15.

Блок О

Дескрипторы узлов

А *’ 1 г 1 г 1 г 1

a.txt b.txt q.txt r.txt

/

/

/

/ /’

> /

c.txt r.txt m.txt n.txt d.txt w.txt

Рис. 14.9. Каталоге хеш-деревьями и двумя листовыми узлами. В дереве
используются стандартные записи каталогов, что позволяет обрабатывать
его как обычный каталог

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

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

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

PAGE 381

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

При удалении файла длина предыдущей записи увеличивается таким образом,
чтобы она ссылалась на запись, следующую за удаленной. Это единственное
действие, которое переводит запись в свободное состояние. В файловой
системе Ext2 Linux стирает указатель индексного узла, в Ext3 это не
делается. Перестановка неиспользуемых записей с целью сжатия каталога не
производится.

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

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

Если наряду с существующими файлами потребуется обработать свободные
записи, указанный размер записи игнорируется; вместо него вычисляется
фактическая длина записи, которая и определяет величину смещения.
Например, если последний символ имени находится в байте 34, то переход
осуществляется к байту 36. После перехода к границе следует отобразить
содержимое на структуру данных записи каталога и провести простейшие
проверки того, могут ли данные относиться к записи каталога. Если
проверка дает положительный результат, запись обрабатывается, а если нет
— следует сместиться еще на 4 байта и проверить новую запись. Эта
процедура в конечном счете приведет к границе, указанной в предыдущей
записи каталога.

На рис. 14.10 изображены две выделенные записи, между которыми находятся
две свободные записи. Между записями каталогов остается неиспользуемое
пространство, поэтому найти имена простым переходом к следующей
4-байтовой границе после каждой записи не удастся.

Г

1 1 г

1 ,-*

a.txt

b.txt

04xt d.txt

Рис. 14.10. Список записей каталога: две свободные записи между двумя
выделенными записями. Чтобы найти имена в свободных записях, потребуется
последовательное перемещение в неиспользуемом пространстве

Состояние выделения записи каталога определяется тем, указывает ли на
нее другая выделенная запись. Первые две записи в каждом каталоге («.» и
«..») всегда являются выделенными. Обнаружив интересующий файл, можно
просмотреть его метаданные по адресу индексного узла.

PAGE 382

Глава 14. Ext2 и Ext3: концепции и анализ

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

Значения указателей позволяют сделать некоторые предположения
относительно порядка удаления файлов. На рис. 14.11 показаны шесть
возможных комбинаций удаления трех смежных файлов. В верхней части
рисунка изображено начальное состояние с четырьмя выделенными записями
каталога. Число под каждым блоком представляет «адрес» записи, введенный
для удобства описания каждого сценария. Серые блоки изображают свободные
записи, а числа — порядок их удаления. Например, в сценарии (А) первым
был удален файл в записи 1, а длина записи 0 была увеличена так, чтобы
она ссылалась на запись 2. Затем была удалена запись 2, а длина записи 0
была увеличена до ссылки на запись 3. Наконец, запись 3 была удалена, а
длина записи 0 была увеличена так, чтобы она ссылалась на запись после
3. Показанное состояние (А) отличается от всех остальных возможных
комбинаций последовательности удаления этих файлов.

А)

В)

С)

D)

Е)

F)

Рис. 14.11. Шесть комбинаций относительного порядка освобождения трех
смежных записей каталога. Только последовательности 1-3-2 и 2-3-1
приводят к одному конечному состоянию

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

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

В ЕхЬХ найти имена удаленных файлов несложно, а в Ех13 номер индексного
узла не стирается; возможно, это позволит получить информацию о времени
удаления

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

PAGE 383

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

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

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

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

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

Исходное местонахождение перемещенного файла

Во время анализа системы Linux, подвергшейся взлому, обнаружен файл
snif-ferlog-l.dat, содержащий сетевые пакеты. Другие файлы каталога
обладают именами вида log-001.dat и не содержат сетевых данных.
Содержимое каталога выглядит так:

# fis -f linux-ext3 ext3-8.dd 1840555

г/г 1840556: log-001.dat

г/г 1840560: log-002.dat

г/г 1840566: log-003.dat

г/г 1840569: log-004.dat

г/г 32579: sniffer1og-l.dat

г/г 1840579: log-005.dat

г/г 1840585: log-006.dat

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

PAGE 384

Глава 14. Ext2 и Ext3: концепции и анализ

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

У родительского каталога и остальных файлов адреса индексных узлов
находятся где-то около 1 840 500, но файл snifferlog-l.dat обладает
адресом 32 579. Согласно стратегии выделения, используемой в Linux,
файлы обычно создаются в индексных узлах той же группы, к которой
принадлежит родительский каталог. Следовательно, либо файл
snifferlog-l.dat был изначально создан в другом родительском каталоге, а
потом перемещен в текущий каталог, либо он был создан в текущем
каталоге, а группа блоков была заполнена до предела.

По результатам fsstat мы определяем, что каталог журналов принадлежит к
группе блоков 113, в которой 99 % индексных узлов и 48 % блоков
свободны. Маловероятно, чтобы группа была заполнена в момент создания
файла, если только с того момента не произошло массовое удаление файлов:

Group: 113:

Inode Range: 1840545 – 1856832

Block Range: 3702784 – 3735551

Free Inodes: 16271 (99*)

Free Blocks: 15728 (48*)

Более подробный анализ индексного узла snifferlog-l.dat (32 579)
показывает, что узел входит в группу блоков 2:

Group: 2:

Inode Range: 32577 – 48864 Block Range: 65536 – 98303 Free Inodes: 16268
(99*) Free Blocks: 0 (0*)

Напрашивается предположение, что файл был создан в каталоге группы
блоков 2, а затем перемещен в группу блоков 113. Таким образом, мы
попробуем найти в группе блоков 2 каталоги, которые могли бы быть
родительскими каталогами по отношению к snifferlog-l.dat. В пакете TSK
для решения этой задачи используется программа ils, выводящая подробную
информацию об индексных узлах из заданного интервала. При запуске мы
задаем интервал для группы блоков, в которой производится поиск, и
отфильтровываем все результаты, не относящиеся к каталогам. Ключ -m
преобразует данные режима в наглядный формат, понятный для пользователя,
а ключ -а ограничивает поиск используемыми индексными узлами. Утилита g
rep отфильтровывает все результаты, не относящиеся к каталогам (по
содержимому пятого столбца).

# ils -f linux-ext3 -m -a ext3-8.dd 32577-48864 | grep “|d”
101325771168931drwxrwxr-x14[500150010140961
|01326551168931drwxrwxr-x121500150010140961
101325771168771drwxr-xr-x121500150010140961

Первый столбец содержит фиктивное имя для каждой записи. Свободные
записи помечаются строкой «dead», а выделенные — строкой «alive». Третий
столбец содержит адрес индексного узла. Обычно результаты ils
обрабатываются утилитой mactime для построения временных диаграмм,
поэтому их формат не слишком удобен для пользователя.

Для просмотра трех каталогов мы воспользуемся программой fis. Каталог в
индексном узле 32577 представляется наиболее перспективным.

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

PAGE 385

# Лб -Г Іілих-ехгЗ HYPERLINK “http://ext3-8.dc” ext3-8.dc ! 32577

г/г 32578

г/г 32582

г/г 32580

г/г 32581

ол!у_1і уе^ісе.трЗ до^-Мпдег.трЗ 1іс_Ю_кіП .трЗ diamoлds_foгeveг.mpЗ

На первый взгляд похоже на невинный каталог с музыкой из фильмов о
Джеймсе Бонде в формате МРЗ… но обратите внимание на индексные узлы и
вспомните, что мы знаем о стратегиях выделения индексных узлов и записей
каталогов. При выделении индексных узлов используется стратегия поиска
первого доступного узла в группе блоков. Файл с содержимым сетевых
пакетов находился в индексном узле 32 579, расположенном между
оп1у_Нуе_1уу1се.трЗ и Ис^о_ктII.трЗ. Также обратите внимание, что
HYPERLINK “http://gol.dfinger.mp3” gol.dfinger.mp3 обладает большим
номером индексного узла, чем остальные файлы, и находится в середине
каталога. Более того, длина имени HYPERLINK “http://gol.dfinger.mp3”
gol.dfinger.mp3 равна 14 символам, а длина snifferlog-l.dat — 16
символам; это означает, что оба файла поместились бы в записи каталога
одного размера.

При анализе файлов выясняется, что файл оп1у_11уе_1ууке.трЗ является
исполняемым, а другие файлы содержат журналы сетевых пакетов в том же
формате, что и snifferlog-l.dat. Кроме того, временные штампы HYPERLINK
“http://onlyJ.ive_twice.mp3” onlyJ.ive_twice.mp3 предшествуют временным
штампам snifferlog-l.dat, а временные штампы Ис_1:о_ки1..трЗ следуют за
snifferlog-l.dat.

Группа блоков 2

Содержимое каталога

оп1у_1іУЄ_^ісе.трЗ 32 578

доШіпдег.трЗ 32 582

1 іс^о_кі 11 .трЗ 32 580

йіагогк^тогеуег.трЗ 32 581

Индексный узел 32 577

Группа блоков 113

Содержимое каталога

1og-001.dat 1 840 556

1og-002.dat 1 840 560

log-003.dat 1 840 566

log-004.dat 1 840 569

sniffer1og-l.dat 32 579

1og-005.dat 1 840 579

1og-006.dat 1 840 585

Рис. 14.12. Файл snifferlog-l.dat перемещен из каталога в группу блоков
2

На основании собранной информации выдвигается следующая гипотеза: файл
snifferlog-l.dat был создан после файла HYPERLINK
“http://onlyJ.we_twice.mp3” onlyJ.we_twice.mp3 , после чего был создан
файл Ис^о_кіІІ.трЗ. Через некоторое время после создания файла
diamonds_for

PAGE 386

Глава 14. Ext2 и Ext3: концепции и анализ

ever.mp3 файл snifferlog-l.dat был перемещен в каталог, находящийся в
группе блоков ИЗ. После его перемещения был создан файл goldfinger.mp3,
который заменил запись каталога и получил следующий доступный индексный
узел. М-и С-время индексного узла 32 577 совпадают с данными файла
goldfinger.mp3, причем в обоих случаях они следуют за временными
штампами файла snifferlog-l.dat. Ситуация показана на рис. 14.12: запись
каталога в группе ИЗ ссылается на индексный блок в группе 2. Мы все еще
не знаем, как произошло перемещение файла и всегда ли он существовал под
текущим именем или ранее он был замаскирован под МРЗ-файл. Возможно,
анализ исполняемого файла прольет свет на эти вопросы.

Порядок удаления файлов

В процессе анализа системы Linux был обнаружен каталог с именем
/usr/local/ .oops/. Для системы Linux такой каталог нетипичен, поэтому
мы просмотрим его содержимое. В каталоге обнаруживаются восемь удаленных
файлов; все соответствующие индексные узлы были выделены новым файлам,
что основательно усложнит процесс восстановления. Впрочем, сейчас нас
интересует исключительно способ удаления файлов. В результате анализа
записей каталогов были получены значения, представленные в табл. 14.3.
Имена приводятся в порядке их следования в каталоге.

Таблица 14.3. Параметры свободных записей каталогов в рассматриваемом
сценарии

Байт Имя Указанная длина Необходимая длина

12

1012 12

24 config.dat 20 20

44 readme.txt 104 20

64 allfiles.tar 20 20

84 random.dat 64 20

104 mytools.zip 44 20

124 delete-files.sh 24 24

148 sniffer 876 16

164 passwords.txt 860 860

По этим данным можно сделать ряд общих наблюдений. Если указанная длина
записи свободной записи каталога соответствует ее фактической длине
(вычисленной на основании имени), то следующая запись каталога была
удалена после нее. Например, запись config.dat была удалена раньше, чем
readme.txt, потому что в противном случае длина записи config.dat была
бы увеличена на 20 для поглощения места, занимаемого readme.txt.
Следовательно, мы знаем, что файл config.dat был удален раньше
readme.txt, allfiles.tar — раньше random.dat, a delete-files.sh — раньше
sniffer.

Также можно заметить, что файл mytools.zip был удален после
delete-files.sh, но до sniffer. Мы знаем это, потому что длина записи
mytools.zip была увеличена до 44 для поглощения удаленной записи
delete-files.sh. Если бы запись sniffer была удалена перед mytools.zip,
то длина mytools.zip возросла бы с учетом этого факта. Также мы видим
что файл passwords.txt был удален раньше sniffer, a random.dat — после

Категория прикладных данных

PAGE 387

mytools.zip. Наконец, файл readme.txt был удален раньше sniffer, потому
что длина записи readme.txt указывает на sniffer.

Потратив немного времени на определение относительного порядка удалений,
мы приходим к выводу, что файлы удалялись в алфавитном порядке. Мы не
знаем порядка удаления aLLfiLes.tar, config.dat и delete-files.sh, но
зато нам известно, что они были удалены раньше других файлов, а в
отсортированном списке имен эти файлы занимают первые три места.
Следовательно, эти файлы могли быть удалены при отображении в окне
отсортированного списка или же командой типа rm *. Команда rm удаляет
файлы, и мои эксперименты показали, что удаление производится в
алфавитном порядке. Скорее всего, файлы удалялись не один за одним, а из
сценария или окна файлового менеджера. Если бы между удалениями
создавались другие файлы, интерпретировать результаты было бы намного
труднее.

Категория прикладных данных

В Ext3 поддерживается только одна функция прикладного уровня — журналы
файловой системы. В Ext2 журналы отсутствуют, а другие функции
прикладного уровня (например, квоты) реализуются на основе обычных
пользовательских файлов.

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

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

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

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

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

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

PAGE 388

Глава 14. Ext2 и Ext3: концепции и анализ

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

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

Суперблок журнала

Дескриптор Номер: 840

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

Блок закрепления Номер: 840

Дескриптор Номер: 839

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

Блок закрепления Номер: 839

Рис. 14.13. Журнал Ext3 с двумя транзакциями

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

Структуры данных и пример журнала приводятся в главе 16. В пакете Т8К
для вывода содержимого журнала используется программа ^б. Пример ее
вывода для образа файловой системы:

# jls JBlk 0: 1 2 З 4 5 6 7 8 9 [.

-f linux-ext3 /dev/hdb2 Description Superb!ock (seq: 0) Allocated
Descriptor Block (seq: 295) Allocated FS Block 4 Allocated FS Block 2
Allocated FS Block 14 Allocated FS Block 5 Allocated FS Block 163
Allocated FS Block 3 Allocated Commit Block (seq: 295) Unallocated FS
Block Unknown

Категория прикладных данных

PAGE 389

В выходных данных jls виден суперблок, дескриптор и блоки закрепления.
Транзакция 295 начинается в блоке журнала 1 и завершается в блоке 8.
Также приводятся номера блоков файловой системы, которым соответствует
каждый блок журнала. Для извлечения блоков из журнала можно
воспользоваться программой jcat из пакета TSK.

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

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

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

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

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

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

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

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

Известно, что удаленный файл занимал индексный узел 488 650, находящийся
в группе блоков 30. Первый индексный узел группы блоков имеет номер 488
641,

PAGE 390

Глава 14. Ext2 и ЕхгЗ: концепции и анализ

таблица индексных узлов начинается в блоке 943 044, а размер каждого
блока составляет 4 096 байт. Следовательно, интересующий нас индексный
узел хранится в записи 10 таблицы индексных узлов группы и соответствует
первому блоку таблицы.

Мы запускаем jls для журнала и ищем сведения о блоке файловой системы
983 044:

# jls -f linux-ext3 ext3-8.dd 8 […]

2293: Unallocated Descriptor Block (seq: 136723)

2294: Unallocated FS Block 983041

2295: Unallocated FS Block 1

2296: Unallocated FS Block 0

2297: Unallocated FS Block 983044

2298: Unallocated FS Block 983568

2299: Unallocated FS Block 983040

2300: Unallocated Commit Block (seq: 136723)

[…]

Журнал содержит несколько ссылок на блок 983 044; мы проанализируем
различия между этими ссылками. Предыдущие записи относятся к созданию
файла в индексном узле 488 650. В листинге присутствует обновляемая
таблица индексных узлов, суперблок, дескрипторы групп, родительский
каталог и битовая карта блоков. Мы извлекаем таблицу индексных узлов из
блока журнала 2297 и используем dd для перехода к десятому индексному
узлу в таблице:

# jcat -f linux-ext3 ext3-8.dd 8 2297 | dd bs=128 skip=9 count=l | xxd

0000000: a481 0000 041f 0000 8880 3741 3780 3741 ………7A7.7A

0000016: 3780 3741 0000 0000 0000 0100 1000 0000 7.7A…………

0000032: 0000 0000 0000 0000 1102 OfOO 1202 OfOO …………….

0000048: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

[…]

Это те данные, которые когда-то содержались в индексном узле 488 650;
размер указан в байтах 4-7 и составляет 7940 байт (0xlf04). Байты 40-43
и 44-47 содержат два прямых указателя на блоки. Мы видим, что файлу
выделены блоки 883 569 и 983 570. При просмотре содержимого этих блоков
обнаруживается список паролей различных систем, взломанных
злоумышленником.

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

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

Итак, мы рассмотрели отдельные компоненты файлов и каталогов. Давайте
объединим все эти сведения в практических примерах. Сначала мы создадим,
а затем удалим файл /dirl/filel.dat. Размер файла составляет 6 ООО байт,
а размер блока в файловой системе Ext3 равен 1024 байтам.

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

PAGE 391

Пример создания файла

На высоком уровне процесс создания файла /сИг!/АLel.dat сводится к
поиску каталога сИг1, созданию записи каталога, выделению индексного
узла и последующему выделению блоков для содержимого файла. Точный
порядок выделения структур данных зависит от ОС; описанная далее
процедура может отличаться от той, что используется в вашей конкретной
системе.

1. Создание файла начинается с чтения 1024-байтовой структуры данных
суперблока, которая находится в файловой системе со смещением 1024
байта. Из суперблока мы узнаем, что размеры блока и фрагмента равны 1024
байтам. Каждая группа блоков состоит из 8192 блоков и 2016 индексных
узлов. Зарезервированные блоки перед началом первой группы блоков
отсутствуют.

2. На следующем этапе читается таблица дескрипторов групп, хранящаяся в
блоках 2 и 3 файловой системы. Из таблицы берется информация о строении
каждой группы блоков.

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

4. Из блока 6 читается таблица индексных узлов, в которой обрабатывается
вторая запись. Индексный узел 2 показывает, что структуры записей
каталогов для корневого каталога находятся в блоке 258.

5. Мы читаем содержимое корневого каталога из блока 258 и обрабатываем
его как список записей каталогов. В первых двух записях хранится
информация о записях «.» и «..». Последовательно перемещаясь вперед по
указанным длинам записей (удаленные файлы нас не интересуют), мы в
конечном счете приходим к записи, в которой указано имя сИг1. В записи
указан номер индексного узла 5033. А-время корневого каталога
обновляется временем открытия каталога.

6. Местонахождение индексного узла 5033 определяется делением числа на
количество индексных узлов в группе. Так мы определяем, что узел
находится в группе блоков 2. Используя запись дескриптора для группы 2,
мы определяем, что его таблица индексных узлов начинается в блоке 16
390.

7. Из блока 16 390 читается таблица индексных узлов, в которой
обрабатывается запись 1001 — относительным номером индексного узла 5
033. Содержимое индексного узла показывает, что содержимое сИг!
находится в блоке 18 431.

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

PAGE 392

Глава 14. Ехг.2 и Ехг.3: концепции и анализ

9. Для создаваемого файла необходимо выделить индексный узел, причем
этот узел должен принадлежать группе своего родительского каталога, то
есть группе блоков 2. Битовая карта индексных узлов для группы 2
отыскивается в блоке 16 386 по дескриптору группы. Методом поиска
первого доступного узла мы определяем, что индексный узел 5 110
свободен. Соответствующий бит в битовой карте устанавливается равным 1,
счетчик свободных индексных узлов в таблице дескрипторов уменьшается,
как и счетчик свободных индексных узлов в суперблоке. Адрес индексного
узла заносится в запись каталога filel.dat. Изменения битовой карты,
дескриптора группы и суперблока регистрируются в журнале.

Суперблок

Блок 1

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

о

Блоки 2-3

Группа блоков 0

Таблица индексных узлов

Корневой каталог

Блок: 258

Блоки 6-257

Содержимое ^ журнала

Длина Имя Индексный узел

12

2

16 сіігі 23 2 109

12 СІІГІ 5 033

Блоки 258

Группа блоков 2

5 033

5110

Таблица индексных узлов

Содержимое сНИ

Блок: 18 431

Блок: 20 002..

Блоки 16 390-16 641

Длина Имя Индексный узел

12

2

16 12.jpg 5 086

16 їііеі .сіаі 5 110

16 14.jpg 5 088

Блоки 18 431

Битовая карта блоков

…1…

Битовая карта индексных узлов

…1..

Содержимое Ше1 .сМ

Блок 16 385

Блок 16 386

Блоки 20 002-20 003, 20 114-20 117

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

10. На следующем этапе заполняется содержимое индексного узла 5110: для
этого мы находим его в таблице индексных узлов группы 2 и инициализируем
основные параметры индексного узла. Временные штампы инициализируются

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

PAGE 393

текущим временем, а счетчик ссылок задается равным 1. Изменения таблицы
индексных узлов регистрируются в журнале.

11. Для хранения содержимого файла требуется выделить шесть блоков. Мы
переходим к обработке битовой карты блоков, расположенной в блоке 16
385. По алгоритму поиска первого доступного блока в группе находятся
блоки 20 002-20 003 и 20 114-20 117. Биты этих блоков в карте
устанавливаются, а их адреса включаются в прямые указатели, хранящиеся в
узле 5110. Счетчики свободных блоков в дескрипторе групп и суперблоке
также обновляются. М-и С-времена индексного узла обновляются в
соответствии с внесенными изменениями. Изменения индексного узла,
дескриптора группы, суперблока и битовой карты регистрируются в журнале.

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

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

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

1. Удаление файла начинается с чтения 1024-байтовой структуры данных
суперблока, которая находится в файловой системе со смещением 1024
байта. Из суперблока мы узнаем, что размеры блока и фрагмента равны 1024
байтам. Каждая группа блоков состоит из 8192 блоков и 2016 индексных
узлов. Зарезервированные блоки перед началом первой группы блоков
отсутствуют.

2. На следующем этапе читается таблица дескрипторов групп, хранящаяся в
блоках 2 и 3 файловой системы. Из таблицы берется информация о строении
каждой группы блоков.

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

4. Из блока 6 читается таблица индексных узлов, в которой обрабатывается
вторая запись. Индексный узел 2 показывает, что структуры записей
каталогов для корневого каталога находятся в блоке 258.

5. Мы читаем содержимое корневого каталога из блока 258 и обрабатываем
его как список записей каталогов. В первых двух записях хранится
информация о записях «.» и «..». Последовательно перемещаясь вперед по
указанным длинам записей (удаленные файлы нас не интересуют), мы в
конечном счете приходим к записи, в которой указано имя сИг1. В записи
указан номер индексного узла 5033. А-время корневого каталога
обновляется временем открытия каталога.

6. Местонахождение индексного узла 5033 определяется делением числа на
количество индексных узлов в группе. Так мы определяем, что узел
находится

PAGE 394

Глава 14. Ехг.2 и Ехг.3: концепции и анализ

в группе блоков 2. Используя запись дескриптора для группы 2, мы
определяем, что его таблица индексных узлов начинается в блоке 16 390.

Из блока 16 390 читается таблица индексных узлов, в которой
обрабатывается запись 1001 — относительным номером индексного узла 5
033. Содержимое индексного узла показывает, что содержимое сИг1
находится в блоке 18 431.

Мы читаем содержимое сИг1 из блока 18 431 и обрабатываем его как список
записей каталогов. Нас интересует запись файла filel.dat. Мы находим эту
запись и узнаем, что ей выделен индексный узел 5110. Чтобы освободить
запись каталога, ее длина прибавляется к длине предыдущей записи
каталога, относящейся к файлу 12.jpg. В результате операций обновляется
М-, А- и С-время. Изменения регистрируются в журнале.

Суперблок

Блок 1

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

о

Блоки 2-3

Группа блоков О

Таблица индексных узлов

Корневой каталог

Блок: 258

Блоки 6-257

Содержимое ^ журнала

Группа блоков 2

Таблица индексных узлов

5 033

5 110

Блок: 18 431

Блок: 20 002..

Блоки 16 390-16 641 \

Длина Имя Индексный узел

12

2

16 сііг123 2 109

12 СІІГІ 5 033

Блоки 258

Содержимое СІІГІ

Длина Имя Индексный узел

12

2

32 I2.jpg 5 086

16 file1.dat 5 110

16 14.jpg 5 088

Блоки 18 431

Битовая карта блоков

Битовая карта индексных узлов

…о…

^ Содержимое file1.dat

…о..

Блок 16 385

Блок 16 386

Блоки 20 002-20 003, 20 114-20 117

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

9. В результате удаления имени файла счетчик ссылок в индексном узле
5110 таблицы индексных узлов группы 2 уменьшается на 1. Значение
счетчика

Разное

395

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

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

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

Разное

Этот раздел посвящен восстановлению удаленных файлов в ExtX и проверке
целостности файловой системы. Обе темы выходят за рамки какой-либо
конкретной категории данных.

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

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

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

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

PAGE 396

Глава 14. Ехг.2 и ЕхгЗ: концепции и анализ

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

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

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

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

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

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

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

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

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

397

Итоги

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

Возможно, самые большие проблемы с ExtX обусловлены эволюцией этих
систем. Система FAT существовала в нескольких версиях, NTFS претерпевает
изменения в каждой новой версии Windows, но у ExtX существует несколько
«экспериментальных» разновидностей, устанавливаемых или активизируемых
пользователем. В этой главе технология ExtX была представлена на момент
написания книги. Она может быть в любой момент дополнена новыми
возможностями, но это не означает, что эти возможности будут
поддерживаться любой отдельно взятой копией ExtX. Чтобы определить
состав поддерживаемых возможностей, необходимо проанализировать
конфигурацию ядра и системы.

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

• Card, Rcmy, Theodore Ts’o, and Stephen Tweedie. «Design and
Implementation of the Second Extended Filesystem». In Proceeding of the
First Dutch International Symposium on Linux, ed. Frank B. Brokken et
al, Amsterdam, December 1994. http:/ HYPERLINK
“file:///www.mit.edu/tytso/www/linux/ext2intro.html”
/www.mit.edu/tytso/www/linux/ext2intro.html .

• Carrier, Brian, «EXT3FS Keyword Search Test #1». Digital Forensic Tool
Testing, November 2003. HYPERLINK “http://dftt.sourceforge.net”
http://dftt.sourceforge.net .

• Dubeau, Louis-Dominique. «Analysis of the Ext2fs Structures The
Operating System Resource Center, 1994. HYPERLINK
“http://www.nondot.org/sabre/os/files/FileSystem/ext2fs/”
http://www.nondot.org/sabre/os/files/FileSystem/ext2fs/ .

• Red Hat, Inc. Ext3 User Mailing List, n.d. HYPERLINK
“https://listman.redhat.com/mailman/listinfo/”
https://listman.redhat.com/mailman/listinfo/ ext3-users/.

• Heavner, Scott D. Linux Disk Editor, n.d. HYPERLINK
“http://lde.sourceforge.net/” http://lde.sourceforge.net/ .

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

• Gleditsch, Arne Georg, and Per Kristjan Gjermshus. Linux Source Code,
n.d. http:/ HYPERLINK “file:///lxr.linux.no/source/”
/lxr.linux.no/source/ .

• grugq. «Defeating Forensic Analysis on Unix». Phrack, Issue 15, July
28,2002. http:/ / HYPERLINK “http://www.phrack.org/show.php?p=59&a=6”
www.phrack.org/show.php?p=59&a=6 .

• Honeynet Project. «The Forensic Challenges January 15, 2001.
HYPERLINK “http://www.honey-” http://www.honey- HYPERLINK
“http://net.org/challenge/index.html” net.org/challenge/index.html .

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

PAGE 398

[7iaBa 14. Ext2 m Ext3: KOHuenuMM m aHa/iM3

• Philips, Daniel. «A Directory Index for Ext2». Proceeding of the
Usenix Fifth Annual Linux Showcase and Conference, 2001.

• Poirier, Dave. «Second Extended File System: Internal Layout». 2002.
HYPERLINK “http://” http:// HYPERLINK
“http://www.nongnu.org/ext2-doc/” www.nongnu.org/ext2-doc/ .

• Ts’o, Theodore. «E2fsprogs». Sourceforge, n.d. HYPERLINK
“http://e2fsprogs.sourceforge.net/” http://e2fsprogs.sourceforge.net/ .

• Ts’o, Theodore, and Stephen Tweedie. «Planned Extensions to the Linux
Ext2/ Ext3 Filesystem». Proceeding of the 2002 Usenix Technical
Conference FREENIX Track, 2002.

• Tweedie, Stephen. «EXT, Journaling Filesystem». Sourceforge, July 20,
2000. http:/ HYPERLINK
“file:///olstrans.sourceforge.net/release/0LS2000-ext3/0LS2000-ext3.htmL
” /olstrans.sourceforge.net/release/0LS2000-ext3/0LS2000-ext3.htmL

Структуры данных ЕхК2 и Ех13

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

Суперблок

В Ех1Х основные данные категории файловой системы хранятся в суперблоке.
Суперблок хранится со смещением 1024 байта от начала файловой системы и
занимает 1024 байта. Его поля перечислены в табл. 15.1.

Таблица 15.1. Структура данных суперблока Ехг^(

Диапазон Описание Необходимость

0-3 Количество индексных узлов в файловой системе Да

4-7 Количество блоков в файловой системе Да

8-11 Количество блоков, резервируемых для предотвращения переполнения
файловой системы Нет

12-15 Количество свободных блоков Нет

16-19 Количество свободных индексных узлов Нет

20-23 Блок, с которого начинается группа блоков 0 Да

24-27 Размер блока (в формате количества разрядов для сдвига величины
1024 влево) Да

28-31 Размер фрагмента (в формате количества разрядов для сдвига
величины 1024 влево) Да

32-35 Количество блоков в каждой группе Да

36-39 Количество фрагментов в каждой группе Да

40-43 Количество индексных узлов в каждой группе Да

44-47 Последнее время монтирования Нет

48-51 Последнее время записи Нет

52-53 Текущее количество монтирований Нет

54-55 Максимальное количество монтирований Нет

56-57 Сигнатура (0хеГ53) Нет

58-59 Состояние файловой системы (см. табл. 15.2) Нет

продолжение &

PAGE 400

Глава 15. Структуры данных Ехі2 и ЕхіЗ

Таблица 15.1 {продолжение)

Диапазон Описание Необходимость

60-61 Метод обработки ошибок (см. табл. 15.3) Нет

62-63 Дополнительная версия Нет

64-67 Время последней проверки целостности Нет

68-71 Интервал между принудительными проверками целостности Нет

72-75 ОС, создавшая файловую систему (см. табл. 15.4) Нет

76-79 Основная версия (см. табл. 15.5) Да

80-81 иго, которому разрешено использовать зарезервированные блоки Нет

82-83 СГО, которому разрешено использовать зарезервированные блоки Нет

84-87 Первый незарезервированный индексный узел в файловой системе Нет

88-89 Размер структуры индексного узла Да

90-91 Группа блоков, в которую входит данный суперблок (для резервных
копий) Нет

92-95 Флаги совместимых функций (см. табл. 15.6) Нет

96-99 Флаги несовместимых функций (см. табл. 15.7) Да

100-103 Флаги совместимых функций только для чтения (см. табл. 15.8) Нет

104-119 Идентификатор файловой системы Нет

120-135 Имя тома Нет

136-199 Путь последнего монтирования Нет

200-203 Битовая карта использования алгоритма Нет

204-204 Количество блоков, предварительно выделяемых файлам Нет

205-205 Количество блоков, предварительно выделяемых каталогам Нет

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

208-223 Идентификатор журнала Нет

224-227 Индексный узел журнала Нет

228-231 Журнальное устройство Нет

232-235 Начало списка зависших индексных узлов Нет

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

Байты 58-59 содержат флаги состояния системы. Допустимые значения флагов
приведены в табл. 15.2.

Таблица 15.2. Флаги состояния файловой системы в суперблоке

Диапазон Описание Необходимость

0x0001 Проверенная файловая система Нет

0x0002 Файловая система содержит ошибки Нет

0x0004 Обнаружены зависшие узлы Нет

Метод обработки ошибок в байтах 60-61 определяет, как должна поступать
ОС при обнаружении ошибки файловой системы. Эти значения задаются в
момент

Суперблок

401

создания файловой системы. Поле содержит одно из трех значений,
приведенных в табл. 15.3.

Таблица 15.3. Значения поля метода обработки ошибок в суперблоке

Диапазон Описание Необходимость

1 Продолжение Нет

2 Перемонтирование файловой Нет

системы как доступной

только для чтения

3 Паника Нет

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

Таблица 15.4. Значения поля создателя в суперблоке

Диапазон Описание Необходимость

0 Linux Нет

1 GNU Hurd Нет

2 Masix Нет

3 FreeBSD Нет

4 Lites Нет

Для поля основной версии (байты 76-79) определены значения,
перечисленные в табл. 15.5.

Таблица 15.5. Значения поля основной версии в суперблоке

Диапазон Описание Необходимость

0 Исходная версия Да

1 «Динамическая» версия Да

Если в поле не выставлен признак динамической версии, то содержимое
суперблока, начиная с байта 84, может быть неточным. Слово
«динамический» в данном случае означает, что индексные узлы могут
обладать динамическим размером и его точное значение задается в байтах
88-89 суперблока. Текущая версия ядра Linux не поддерживает динамические
индексные узлы, но использует динамическую версию для установки полей
совместимых/несовместимых функций.

Концепция функций — совместимых, несовместимых и совместимых только для
чтения — обсуждалась в главе 14. В суперблоке для каждого типа функций
существует отдельное поле. Следует отметить, что некоторые флаги были
определены, но никогда не использовались в коде Linux. Следовательно, не
все они будут встречаться в стандартной системе Linux. В табл. 15.6
перечислены флаги совместимых функций, в табл. 15.7 — флаги
несовместимых функций, а в табл. 15.8 — флаги функций, совместимых
только для чтения.

PAGE 402

Глава 15. Структуры данных Ext2 и ExtЗ

Таблица 15.6. Флаги поля совместимых функций в суперблоке

Флаг_Описание_Необходимость

0x0001 Для каталогов используется предварительное Нет

выделение блоков с целью сокращения фрагментации

0x0002 Индексные узлы серверов АРБ существуют Нет

0x0004 Файловая система содержит журнал (Ех13) Нет

0x0008 Индексные узлы обладают расширенными атрибутами Нет

0x0010 Допускается изменение размеров файловой системы Нет

для больших разделов

0x0020 Каталоги используют хешированные индексы Нет

Таблица 15.7. Флаги поля несовместимых функций в суперблоке

Флаг Описание Необходимость

0x0001 Сжатие (пока не поддерживается) Да

0x0002 Записи каталогов содержат поле типа файла Да

0x00034 Файловая система нуждается в восстановлении Нет

0x0008 Файловая система использует журнальное устройство Нет

Таблица 15.8. Флаги поля совместимых функций только для чтения в
суперблоке

Флаг Описание Необходимость

0x0001 Разреженные суперблоки и таблицы дескрипторов Нет

групп

0x0002 Файловая система содержит большой файл Нет

0x0004 Каталоги используют В-деревья (не реализовано) Нет

После знакомства со структурами данных и флагами можно рассмотреть
реальный пример суперблока Ех13. Мы воспользуемся программой с1с1 для
извлечения 1024 байт, начиная со смещения 1024: # dd HYPERLINK
“http://if-ext3.dc” if-ext3.dc ! Ь5-1024 5ктр=1 соип1=1 | ххс!

0000000: с053 1сЮ0 ff9d ЗаОО 4сее 0200 4708 ОЬОО .Б….:Л…6…

0000016: 6745 кЮО 0000 0000 0200 0000 0200 0000 дЕ…………..

0000032: 0080 0000 0080 0000 a03f 0000 с9Гс1 1141 ………?…..А

0000048: c9fd 1141 3601 2500 53еГ 0100 0100 0000 …Аб.Х.Б…….

0000064: с!а9с1 е83е 004е ес100 0000 0000 0100 0000 …>.Н……….

0000080: 0000 0000 ОЬОО 0000 8000 0000 0400 0000 …………….

0000096: 0600 0000 0300 0000 077а 06а5 1795 486е ………г….Нп

0000112: 9485 есс4 486Г 63е4 0000 0000 0000 0000 ….Нос………

0000128: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

[…]

0000224: 0800 0000 0000 0000 0000 0000 0000 0000 …………….

[…]

0001008: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

Из листинга видно, что файловая система содержит 1 921 984 (0х001с153с0)
индексных узла (байты 0-3) и 3 841 535 (ОхООЗаЭс^Г) блоков (байты 4-7).
Байты 20-23 показывают, что группа блоков 0 начинается с байта 0. Байты
24-27 и 28-31

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

403

содержат величину поразрядного сдвига числа 1024 (0x0400) для вычисления
размеров блока и фрагмента соответственно. Оба значения равны 2; это
означает, что размеры блока и фрагмента равны 4096 (0x1000) байт. Байты
32-35 показывают, что каждая группа состоит из 32 768 (0x8000) блоков, а
байты 40-43 — что на группу приходится 16 288 (0x3fa0) индексных узлов.
Располагая этими сведениями, мы знаем общий размер файловой системы,
начальные адреса каждой группы блоков и количество индексных узлов в
одной группе.

Байты 76-79 показывают, что используется динамическая версия Ext, так
что байты со смещением 84 должны содержать действительную информацию. Из
байтов 88-91 можно определить, что размер каждого индексного узла равен
128 (0x80) байтам. Байты 92-95 содержат флаги совместимых функций; в
этом поле установлен флаг журнала (0x0004), следовательно, мы имеем дело
с файловой системой Ext3. В поле флагов несовместимых функций (байты
96-99) содержится значение 0x0006; оно означает, что при следующей
загрузке должно выполняться восстановление (0x004) и файловая система
содержит специальные записи каталогов (0x0003). Байты 100-103 содержат
флаги функций, совместимых только для чтения; значение 0x003 указывает
на то, что в системе присутствуют большие файлы (0x0002) и не каждая
группа блоков содержит резервную копию суперблока (0x0001). Байты
224-227 показывают, что журнал находится в индексном узле 8.

Суперблок содержит много других параметров, которые нами отдельно не
рассматривались. Смысл этих параметров будет обсуждаться в
соответствующих разделах; их можно увидеть в выходных данных программы
fsstat, приведенных в главе 14.

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

Таблица дескрипторов групп представляет собой список структур данных,
называемых дескрипторами групп; этот список хранится в блоке файловой
системы, следующем непосредственно за суперблоком. В таблице
присутствует запись для каждой группы блоков в системе, и каждая запись
содержит информацию о некоторой группе. Таблица состоит из 32-байтовых
записей, представленных в табл. 15.9.

Таблица 15.9. Структура данных записи в таблице дескрипторов групп

Диапазон Описание Необходимость

0-3 Начальный адрес битовой карты блоков Да

4-7 Начальный адрес битовой карты индексных узлов Да

8-11 Начальный адрес таблицы индексных узлов Да

12-13 Количество свободных блоков в группе Нет

14-15 Количество свободных индексных узлов в группе Нет

16-17 Количество каталогов в группе Нет

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

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

PAGE 404

Глава 15. Структуры данных Ext2 и Ext3

занимают 4096 байт, суперблок находится в блоке 0, следовательно,
таблица дескрипторов групп находится в блоке 1. С другой стороны, при
1024-байтовых блоках суперблок находится в блоке 1, а таблица
дескрипторов групп начинается в блоке 2. Для извлечения содержимого
таблицы используется программа dcat:

# dcat -f linux-ext3 ext3.dd 1 | xxd

0000000: 0200 0000 0300 0000 0400 0000 d610 7b3f …………..{?

0000016: OaOO 0000 0000 0000 0000 0000 0000 0000 …………….

0000032: 0280 0000 0380 0000 0480 0000 0000 8e3f ……………?

0000048: 0100 0000 0000 0000 0000 0000 0000 0000 …………….

[…]

В листинге присутствуют данные двух дескрипторов групп. Байты 0-3
показывают, что битовая карта блоков находится в блоке 2, а байты 4-7 —
что битовая карта индексных узлов находится в блоке 3. Согласно байтам
8-11, таблица индексных узлов начинается в блоке 4. Группа в данном
образе состоит из 32 768 блоков; это означает, что для хранения битовой
карте блоков требуется 4096 байт, то есть один блок. Группа содержит 16
288 индексных узлов, поэтому для карты битовой карты индексных узлов
потребуется 2036 байт. Таблица индексных узлов содержит 16 288 записей
по 128 байт каждая, итого 2 084 864 байта. При 4096-байтовом размере
блока таблица индексных узлов будет занимать 509 блоков с 4-го блока по
512-й.

Запись таблицы группы 1 начинается с байта 32. Из байтов 32-35 видно,
что битовая карта блоков находится в блоке 32 770 (0x8002). Это вполне
логично, потому что мы знаем, что группа 1 начинается в блоке 32 768, а
в первых двух блоках хранятся резервные копии суперблока и таблицы
дескрипторов групп. Если группа блоков не содержит резервных копий этих
структур, в первом блоке группы находится битовая карта блоков.

Битовая карта блоков

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

Как и остальные битовые карты, встречавшиеся в книге, битовая карта
блоков разделена на блоки. Младший бит соответствует блоку, следующему
после блока, представленного старшим байтом предыдущего байта. Иначе
говоря, байты перебираются слева направо, но внутри каждого байта
перебор бит осуществляется справа налево.

При анализе содержимого дескриптора группы в тестовом образе мы видим,
что битовая карта блоков группы 0 начинается с блока 2. Для извлечения
содержимого этого блока используется программа dcat (или dd):

# dcat -f linux-ext3 ext3.dd 2 | xxd

0000000: ffff ffff ffff ffff ffff ffff ffff ffff …………….

[…]

0000168: ffOl fcff ffff Offe ffff ffff 03fe ffff …………….

Индексные узлы

405

Строка, состоящая из одних «f», показывает, что группа блоков 0
начинается с длинной серии выделенных блоков. В байте 1169 мы видим
значение 0x01. Байт 1169 соответствует блокам 9352-9359. Значение 0x01
показывает, что блок 9352 выделен, а блоки 9353-9359 свободны.

Индексные узлы

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

Размер базовой структуры данных индексного блока составляет 128 байт. В
«динамических» версиях файловой системы (см. описание суперблока)
индексные узлы могут иметь динамический размер, заданный в суперблоке. В
текущей версии ядра Linux возможность увеличения индексных узлов не
поддерживается, но первые 128 байт состоят из тех же полей, что и
стандартные узлы [Ts’o and Tweedie, 2002]. Поля базовых индексных узлов
перечислены в табл. 15.10.

Таблица 15.10. Структура данных индексного узла

Диапазон Описание Необходимость

0-1 Режим доступа к файлу (тип и разрешения) — см. табл. 15.11, 15.12 и
15.13 Да

2-3 Младшие 16 бит идентификатора пользователя Нет

4-7 Младшие 32 бита размера в байтах Да

8-11 Время обращения Нет

12-15 Время изменения Нет

16-19 Время модификации Нет

20-23 Время удаления Нет

24-25 Младшие 16 бит идентификатора группы Нет

26-27 Счетчик ссылок Нет

28-31 Количество секторов Нет

32-35 Флаги (см. табл. 15.14) Нет

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

40-87 12 прямых указателей на блоки Да

88-91 1 косвенный указатель первого уровня Да

92-95 1 косвенный указатель второго уровня Да

96-99 1 косвенный указатель третьего уровня Да

100-103 Номер поколения (NFS) Нет

104-107 Блок расширенных атрибутов (ACL файлов) Нет

108-111 Старшие 32 бита размера / ACL каталогов Да / Нет

112-115 Адрес блока для фрагмента Нет

116-116 Индекс фрагмента в блоке Нет

продолясепие &

PAGE 406

Глава 15. Структуры данных Ext2 и Ext3

Таблица 15.10 {продолжение)

Диапазон

Описание

Необходимость

117- 117

118- 119 120-121 122-123 124-127

Размер фрагмента Не используется

Старшие 16 бит идентификатора пользователя Старшие 16 бит идентификатора
группы Не используется

Нет Нет Нет Нет Нет

Как упоминалось при описании архитектуры, размер изначально был
32-разрядным, но позднее был преобразован в 64-разрядное значение за
счет использования поля ACL каталогов в байтах 108-111. Если в системе
присутствуют файлы с 64-разрядным значением, в суперблоке должен быть
установлен флаг соответствующей функции, совместимой в режиме только для
чтения.

16-разрядное поле режима делится на три части. В младших 9 битах
содержатся флаги разрешений, каждый бит соответствует одному разрешению.
При определении разрешений используется формат
«пользователь/группа/прочие». Идентификаторы пользователя и группы
указаны в индексном узле, а все остальные относятся к категории
«прочих». Каждой категории могут быть предоставлены разрешения чтения,
записи или выполнения. Флаги разрешений приведены в табл. 15.11.

Таблица 15.11. Флаги разрешений в битах 0-8 поля режима

Флаг разрешения Описание

0x001 Прочие — разрешено выполнение

0x002 Прочие -— разрешена запись

0x004 Прочие — разрешено чтение

0x008 Группа -— разрешено выполнение

0x010 Группа -— разрешена запись

0x020 Группа — разрешено чтение

0x040 Пользователь — разрешено выполнение

0x080 Пользователь — разрешена запись

0x100 Пользователь — разрешено чтение

Следующие три бита предназначены для исполняемых файлов и каталогов. При
установке хотя бы одного из них изменяется поведение исполняемого файла
при запуске, или же файлы в каталогах наделяются особыми свойствами. Эти
флаги перечислены в табл. 15.12.

Таблица 15.12. Флаги битов 9-11 поля режима

Флаг Описание

0x200 Бит устойчивости

0x400 SGID (Set Group ID)

0x800_SUID (Set User ID)__

За описанием этих флагов обращайтесь к разделу «Категория метаданных»
главы 14. Наконец, биты 12-15 определяют тип файла, к которому относится

Индексные узлы

407

данный индексный узел. Тип задается отдельным значением, а не набором
флагов. Допустимые значения перечислены в табл. 15.13.

Таблица 15.13. Флаги типа для битов 12-15 поля режима

Флаг Описание

0x1000 FIFO

0x2000 Символьное устройство

0x4000 Каталог

0x6000 Блочное устройство

0x8000 Обычный файл

ОхАООО Символическая ссылка

ОхСООО Сокет UNIX

Четыре временных штампа хранятся в виде количества секунд, прошедших с 1
января 1970 г. в формате 11ТС. Схема перестанет работать в январе 2038
года, потому что значение представляется всего 32 битами. Поле флагов
определяет атрибуты, установленные для файла. Как было сказано в
предыдущем разделе, некоторые флаги поддерживаются не всеми ОС.
Значения, перечисленные в табл. 15.14, либо описаны в электронной
документации, либо используются в текущей версии кода ядра.

Таблица 15.14. Флаги в поле флагов индексного узла

Флаг Описание

0x00000001 Надежное удаление (не используется)

0x00000002 Сохранение копии данных при удалении (не используется)

0x00000004 Сжатие файла (не используется)

0x00000008 Синхронные обновления — новые данные немедленно записываются
на диск

0x00000010 Неизменяемый файл — модификация содержимого невозможна

0x00000020 Разрешено только присоединение данных

0x00000040 Файл не включается в результаты команды dump

0x00000080 А-время не обновляется

0x00001000 Каталог с хеш-индексированием

0x00002000 В Ext3 ведется журнал файловой системы

Рассмотрим индексную запись 16 из предыдущего образа. Прежде всего
необходимо определить группу, частью которой она является. Мы знаем, что
каждая группа содержит 16 288 индексных узлов, следовательно, нам нужна
группа 0. Начальный адрес таблицы индексных узлов задается в дескрипторе
группы. Ранее мы видели, что таблица начинается в блоке 4, а каждый блок
состоит из 4096 байт. Чтобы извлечь данные, мы сначала перейдем к
таблице индексных узлов, вызывая dd с размером блока 4096, а затем
перейдем к узлу 16, вызывая dd с размером блока 128. Нумерация индексных
узлов начинается с 1, поэтому величину смещения нужно уменьшить на 1:

# dd if=ext3.dd bs=4096 skip=4 | dd bs=128 skip=15 count=l | xxd

0000000: a481 f401 0040 9c00 6d09 2a3f f607 2a3f …[email protected].*?..*?

0000016: 8107 2a3f 0000 0000 f401 0100 404e 0000 ..*?……..@N. .

PAGE 408

Глава 15. Структуры данных Ext2 и Ext3

0000032: 0000 0000 0000 0000 2с38 0000 2d38 0000 ………8..-8

0000048: 2е38 0000 2f38 0000 3038 0000 3138 0000 .8../8. .08. .18.

0000064: 3238 0000 3338 0000 3438 0000 3538 0000 28..38. .48. .58.

0000080: 3638 0000 3738 0000 3838 0000 393с 0000 68..78. .88. .9<. ................ utc. dcat linux-ext3 ext3.dd xxd>8..?8..@8..
0000032: 4138 0000 4238 0000 4338 0000 4438 0000 A8..B8..C8..D8.. […]

Информация о состоянии выделения индексных узлов хранится в битовой
карте индексных узлов, принадлежащей той же группе, что и индексный
узел. Адрес блока битовой карты индексных узлов хранится в дескрипторе
группы:

# dcat -f linux-ext3 ext3.dd 3 | xxd

0000000: fff7 fcff If00 0000 00c8 0000 0000 0000 …………….

Чтобы определить нужный байт, мы вычитаем 1 (с учетом первого индексного
узла группы) и делим результат на 8: (16 – 1) / 8 = 1 остаток 7 Бит
индексного узла 16 является старшим битом байта 1 (0xf7); он равен 1.
Это означает, что соответствующий индексный узел выделен.

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

# istat -f linux-ext3 ext3.dd 16 inode: 16

Allocated Group: 0

Generation Id: 199922874 uid / gid: 500 / 500 mode: -rw-r–r–size:
10240000 num of links: 1

Расширенные атрибуты

409

Inode Times:

Accessed: Fri Aug 1 06:32:13 2003

File Modified: Fri Aug 1 06:24:01 2003

Inode Modified: Fri Aug 1 06:25:58 2003

Direct Blocks:

14380 14381 14382 14383 14384 14385 14386 14387 14388 14389 14390 14391
14393 14394 14395 14396 […]

16880 16881 16882 16883

Indirect Blocks:

14392 15417 15418 16443

Расширенные атрибуты

Файл или каталог может обладать расширенными атрибутами, которые
представляют собой пары «имя-значение». Если файл или каталог обладает
расширенными атрибутами, то в его индексном узле будет указан адрес, по
которому эти атрибуты хранятся.

Блок расширенных атрибутов состоит из трех секций. Первые 32 байта
образуют заголовок; за ним следует вторая секция, содержащая список
записей имен. Третья секция начинается с конца блока и следует по
направлению к началу. В ней хранятся значения атрибутов, причем их
порядок может не совпадать с порядком следования записей имен. Структура
блока расширенных атрибутов показана на рис. 15.1.

Заголовок Имя 1 Имя 2 Имя 3

Имя 4 Имя 5

і t

Значение 2 Значение 4

Значение 2 Значение 1 Значение 3

Рис. 15.1. В блоке расширенных атрибутов имена перечисляются в начале, а
значения — в конце. Новые записи создаются по направлению к середине
блока

Заголовок расширенных атрибутов начинается с байта 0 блока, а его длина
равна 32 байтам. Поля заголовка перечислены в табл. 15.15.

Таблица 15.15. Структура данных заголовка расширенных атрибутов

Диапазон Описание Необходимость

0-3 Сигнатура (0хЕА020000) Нет

4-7 Счетчик ссылок Нет

8-11 Количество блоков Да

12-15 Хеш-код Нет

16-31 Зарезервировано Нет

PAGE 410

Глава 15. Структуры данных Ext2 и Ext3

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

После заголовка начинаются записи имен. Структура каждой записи описана
в табл. 15.16.

Таблица 15.16. Структура данных записи имен блока расширенных атрибутов

Диапазон Описание Необходимость

0-0 Длина имени Да

1-1 Тип атрибута (см. табл. 15.17) Да

2-3 Смещение значения Да

4-7 Блок, содержащий значение атрибута Да

8-11 Размер значения Да

12-15 Хеш-код значения Нет

16+ Имя в кодировке ASCII Да

Смещение задается в байтах внутри заданного блока. В текущих версиях
Linux набор расширенных атрибутов может храниться только в одном блоке,
а поле блока в записи не заполняется. Поле размера содержит количество
байт в значении. Длина имени определяет длину записи, а следующая запись
начинается с ближайшей 4-байтовой границы. Поле типа записи может
содержать одно из шести значений, приведенных в табл. 15.17.

Таблица 15.17. Значения поля типа в записях имен расширенных атрибутов

Значение Описание

1 Атрибут пользовательского пространства

2 POSIX ACL

3 POSIX ACL по умолчанию (только для каталогов)

4 Атрибут доверенного пространства

5 LUSTRE (в настоящее время не используется в Linux)

6 Атрибут пространства безопасности

Если атрибут относится к пользовательскому или доверенному пространству,
а также пространству безопасности, в конце блока хранится простое
значение, соответствующее данному имени. Если в поле типа указан один из
типов POSIX ACL, значение обладает собственным набором структур данных.

«Значение» атрибута POSIX ACL начинается с заголовка, за которым следует
список записей. Структура данных заголовка содержит единственное поле,
представленное в табл. 15.18. Структура данных записей ACL приведена в
табл. 15.19.

Таблица 15.18. Структура данных заголовка POSIX ACL

Диапазон Описание Необходимость

0-3 Версия (1) Да

Расширенные атрибуты

411

Таблица 15.19. Структура данных записей POSIX ACL

Диапазон Описание Необходимость

0-1 Тип (см. табл. 15.20) Да

2-3 Разрешения (см. табл. 15.21) Да

4-7 Идентификатор пользователя/группы Да

(не включается для некоторых типов)

Поле типа в записи ACL определяет тип разрешений, для которого
предназначена данная запись. Определены значения, перечисленные в табл.
15.20.

Таблица 15.20. Допустимые значения поля типа в записях POSIX ACL
Значение Описание

0x001 Пользователь — указывается в индексном узле

0x004 Группа -— указывается в индексном узле

0x20 Прочие —• все остальные пользователи

0x10 Маска прав

0x02 Пользователь -— указывается в атрибуте

0x08 Группа — указывается в атрибуте

Первые три типа относятся к владельцу, группе и «прочим» пользователям,
обычно используемым в индексных узлах ExtX. Другими словами, информация
в этих записях дублирует информацию, находящуюся в индексном узле.
Размер записи, относящейся к одному из этих типов, равен всего 4 байтам,
потому что такие записи не используют поле идентификаторов в байтах 4-7.
Для других типов должен быть задан идентификатор пользователя или
группы, к которым относятся разрешения.

Поле разрешений содержит флаги, перечисленные в табл. 15.21.

Таблица 15.21. Флаги поля разрешений в записях РОБ1Х АС1_

Флаг разрешений Описание

0x001 Выполнение

0x002 Запись

0x004 Чтение

Рассмотрим пример блока расширенных атрибутов:

# dcat -f linux-ext3 ext3-2.dd 1238

0000 02ea 0100 0000 0100 0000 7447 05e8 …………tG. .

0000 0000 0000 0000 0000 0000 0000 0000 …………….

0601 c003 0000 0000 1900 0000 a8e9 5147 …………..QG

736f 7572 6365 0000 0002 dc03 0000 0000 source……….

2400 0000 2500 adOl 0000 0000 0000 0000 %…%………..

0000000 0000016 0000032 0000048 0000064

[…]

0000944 0000960 0000976 0000992 0001008

0000 0000 0000 0000 0000 0000 0000 0000 …………….

7777 772e 6469 6769 7461 6c2d 6576 6964 HYPERLINK
“http://www.digital-evid” www.digital-evid

656e 6365 2e6f 7267 0000 0000 0100 0000 HYPERLINK “http://ence.org”
ence.org …….

0100 0600 0200 0400 4a00 0000 0200 0600 ……..]…….

f401 0000 0400 0400 1000 0600 2000 0400 ……………

PAGE 412

Глава 15. Структуры данных Ext2 и Ext3

Первые 4 байта содержат сигнатуру, в байтах 4-7 находится счетчик ссылок
со значением 1, а в байтах 8-11 — количество блоков 1. Первая запись
начинается с байта 32; мы видим, что длина имени в ней равна 6. Запись
относится к типу 1 (атрибут пользовательского пространства), а байты 2-3
показывают, что значение хранится со смещением 960 (ОхОЗсО). Байты 40-43
показывают, что размер значения равен 25 байтам, а байт 48 является
первым байтом имени атрибута «source». Имя заканчивается в байте 53.
Записи выравниваются по границе 4 байт, поэтому за следующим атрибутом
необходимо перейти к байту 56. Значение первого атрибута хранится в
байтах 960-94 и представляет собой строку HYPERLINK
“http://%c2%abwww.digital-evidence.org%c2%bb” «www.digital-evidence.org»
.

Блок также содержит второй атрибут для записи ACL. Он начинается в байте
988 и продолжается до байта 1023. Заголовок хранится в байтах 988-991, а
первая запись находится в байтах 992-993. Запись относится к типу 1, то
есть определяет разрешения для идентификатора пользователя, указанного в
индексном узле. Разрешения задаются в байтах 994-995; мы видим, что
владелец обладает разрешениями на чтение и запись. Вторая запись
начинается с байта 996 и относится к типу 2. Она предоставляет
разрешения на чтение пользователю с идентификатором 74 (0x4а). При
желании читатель может расшифровать остальные разрешения самостоятельно,
а я приведу результат выполнения программы istat для файла:

# istat -f linux-ext3 ext3-2.dd 70 С.]

Extended Attributes (Block: 1238) user.source= HYPERLINK
“http://www.digital” www.digital HYPERLINK “http://-evidence.org”
-evidence.org POSIX Access Control List Entries:

uid: 0: Read. Write

uid: 74: Read

uid: 500: Read. Write

gid: 0: Read

mask: Read. Write

other: Read […]

Запись каталога

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

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

Таблица 15.22. Структура данных исходной версии записи каталога

Диапазон Описание Необходимость

0-3 Значение индексного узла Да

4-5 Длина записи Да

Запись каталога

413

Диапазон Описание Необходимость

6-7 8+ Длина имени

Имя в кодировке ASCII Да Да

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

Вторая версия записи каталога более эффективно использует поле длины
имени. Максимальное количество символов в имени файла равно 255, поэтому
для его хранения достаточно одного байта. Во второй версии записи
каталога второй байт используется для хранения типа файла (который также
хранится в индексном узле). Поля второй версии записи каталога
представлены в табл. 15.23.

Таблица 15.23. Структура данных второй версии записи каталога

Диапазон Описание Необходимость

0-3 Значение индексного узла Да

4-5 Длина записи Да

6-6 Длина имени Да

7-7 Тип файла (см. табл. 15.24) Нет

8+ Имя в кодировке ASCII Да

Значение типа не является необходимым. Его допустимые значения
перечислены в табл. 15.24.

Таблица 15.24. Допустимые значения поля типа файла в записи каталога

Флаг разрешений Описание

0 Неизвестный тип

1 Обычный файл

2 Каталог

3 Символьное устройство

4 Блочное устройство

5 FIFO

6 Сокет UNIX

7 Символическая ссылка

Для просмотра низкоуровневого содержимого каталога можно воспользоваться
командой icat. В тестовом образе используются записи каталогов новой
версии, а индексный узел 69 457 соответствует каталогу:

# icat -f linux-ext3 ext3.dd 69457 | xxd

0000000: 510f 0100 OcOO 0102 2e00 0000 OOdO 0000 Q……………

0000016: OcOO 0202 2e2e 0000 520f 0100 2800 ObOl ……..R…(…

0000032: 6162 6364 6566 672e 7478 7400 530f 0100 abcdefg.txt.S…
0000048: 1400 OcOl 6669 6c65 2074 776f 2e64 6174 ….file two.dat
0000064: 540f 0100 1000 0702 7375 6264 6972 3100 T…….subdirl.

PAGE 414

Глава 15. Структуры данных Ext2 и Ext3

0000080: 550f 0100 ЬООЗ 0801 5253 5455 5657 5859 U…….RSTUVWXY

0000096: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

[…]

Байты 0-3 показывают, что первая запись соответствует индексному узлу 64
457 (0x01 Of51), а байты 4-5 — что длина записи каталога равна 12 байтам
(0x0с). По содержимому байта 6 видно, что длина имени равна всего 1
байту, а по содержимому байта 7 — что запись представляет каталог
(0x02). Имя, заданное в байте 8, представляет собой строку «.». Эта
запись каталога представляет текущий каталог. Для проверки можно
сравнить индексный узел в записи со значением, полученным при выводе
содержимого каталога программой icat; мы видим, что в обоих случаях оно
равно 64 457.

Чтобы найти вторую запись, следует прибавить длину первой записи к ее
начальному смещению; это означает, что вторая запись начинается в байте
12. Согласно содержимому байтов 16-17, длина этой записи также равна 12
байтам, и она представляет родительский каталог «..».

Чтобы найти третью запись, мы прибавляем длину второй записи к ее
начальному смещению и получаем смещение 24. Байты 28-29 показывают, что
длина записи равна 40 байтам (0x28). Байт 30 показывает, что длина имени
равна 11 (ОхОЬ). Имя (байты 32-47) представляет собой строку
abcdefg.txt.

При переходе от начала записи в байте 24 к следующей записи мы
оказываемся у байта 64. Так как предыдущая запись заканчивается в байте
42, между ними остаются 20 неиспользуемых байт. В этом пространстве
хранится имя удаленного файла two.dat; до удаления эта запись начиналась
с байта 42.

Если хотите, проанализируйте остальные записи самостоятельно. Далее
приводится результат выполнения программы fis для того же каталога:

# fis -f linux-ext3 -a ext3.dd 69457 d/d 69457: d/d 53248:

г/г 69458: abcdefg.txt

г/г * 69459: file two.dat

d/d 69460: subdirl

г/г 69461: RSTUVWXY

Символическая ссылка

Символические ссылки представляют собой специальные файлы,
ассоциированные с другим каталогом или файлом. «Содержимым» файла
является целевой объект ссылки, поэтому для определения символических
ссылок не нужно создавать новые структуры данных. Если путь к целевому
файлу или каталогу занимает менее 60 символов, он хранится в 60 байтах
индексного узла, используемых для хранения 12 прямых и 3 косвенных
указателей на блоки. Если длина пути превышает 60 байт, для его хранения
выделяется отдельный блок. Размер файла соответствует длине пути к
целевому объекту.

Для просмотра символической ссылки можно воспользоваться программой
icat. Программа icat выводит содержимое файла; при этом она отображает
полный путь, потому что символическая ссылка обрабатывается как обычный
файл.

Хеш-деревья

415

# fis -f linux-ext3 ext3-3.dd […]

1/1 26: filel.txt

# icat -f linux-ext3 ext3-3.dd 26

/dirl/dir2/di гЗ/di r4/di r5/di гб/di r7/di r8/di r9/di
rlO/dirll/dirl2/dirl3/dirl4/di П5/ filel.txt

В индексном узле указан размер 90. Согласно выходным данным fis, узел
относится к типу «1», что означает «link» (то есть «ссылка»).

Хеш-деревья

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

Блоки, соответствующие узлам следующего уровня, задаются при помощи
структур данных, называемых дескрипторами узлов. Перед дескрипторами
узлов размещается заголовок, который начинается за записью каталога
«..». Поля заголовка дескриптора узла перечислены в табл. 15.25.

Таблица 15.25. Структура данных заголовка хеш-дерева

Диапазон Описание Необходимость

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

4-4 Версия Да

5-5 Длина структуры Да

6-6 Уровни узлов Нет

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

За заголовком следует список дескрипторов узлов, идентифицирующих
хеш-коды каждого блока. В табл. 15.26 описана структура данных
дескриптора в списке.

Таблица 15.26. Структура данных дескриптора узла хеш-дерева

Диапазон Описание Необход и м ость

0-3 Минимальный хеш-код в узле Да

4-7 Адрес блока Да

Каждая запись содержит минимальный хеш-код и блок каталога узла.
Дескриптору первого узла минимальный хеш-код не нужен, потому что он
должен быть равен 0. По этой причине 4 байта используются для другой
цели — в них хранится текущее количество дескрипторов узлов и
максимальное количество дескрипторов в блоке. Таким образом, первый
дескриптор узла содержит поля, перечисленные в табл. 15.27.

PAGE 416

Глава 15. Структуры данных Ех\2 и ExtЗ

Таблица 15.27. Структура данных первого дескриптора узла хеш-дерева

Диапазон

Описание

Необходимость

0-1 2-3 4-7

Максимальное количество дескрипторов узлов Текущее количество
дескрипторов узлов Адрес блока первого узла

Нет

Да

Да

Оставшаяся часть блока за дескриптором последнего узла обычно содержит
данные от ранее существовавших записей каталогов.

Рассмотрим содержимое первого блока большого каталога, индексированного
с применением хеш-дерева:

# ісаг -1 Ііпих-ехгЗ HYPERLINK “http://ext3-3.dc” ext3-3.dc ! 16

0000000: 1000 0000 0с00 0100 2е00 0000 0200 0000 …………….

0000016: ГШ 0200 2е2е 0000 0000 0000 0208 0000 …………….

0000032: 7с00 0400 0100 0000 3295 6541 0400 0000 |…….2.еА….

0000048: 88с15 та92 0200 0000 86е7 50Ье 0300 0000 |………Р…..

0000064: 3738 3930 2е31 3233 3400 0000 1200 0000 7890.1234…….

В этих выходных данных байты 0-9 соответствуют записи каталога «.», а
байты 12-23 — записи «..». Обратите внимание на то, что поле длины
записи «..» в байтах 16-17 равно 1012 байтам (ОхОЗЇА). Оно указывает на
конец 1024-байтового блока.

Заголовок начинается в байте 24, первые 4 байта не используются. Байт 28
показывает, что используется хеш версии 2, а байт 29 — что структура
занимает 8 байт. Дескриптор первого узла хранится в байтах 32-39. Байты
32-33 показывают, что блок может содержать до 124 (0x7с) дескрипторов,
но из байтов 34-35 видно, что используются только 4. Согласно байтам
36-39, первый узел хранится в блоке 1 каталога.

Второй дескриптор узла начинается в байте 40. Мы видим, что этот узел
содержит файлы с хеш-кодами имени, большими 0x41659532, а имена
размещаются в блоке 4 каталога. Чтобы определить верхнюю границу
хеш-кодов этого узла, мы обращаемся к записи следующего узла, которая
начинается в байте 48, и видим, что ее хеш-код равен 0х92ґас1588. Запись
четвертого узла начинается в байте 63.

В журнале регистрируются обновления метаданных, что позволяет ускорить
восстановление системы после сбоев. В журнале ExtЗ задействованы четыре
структуры данных. Первая — суперблок журнала — находится в первом блоке.
Остальные структуры данных предназначены для блока дескрипторов,
закрепления и отмены. Каждая структура данных обладает сигнатурой, на
основании которой обычные блоки журнала отличаются от административных
блоков. Данные записываются в журнал с обратным порядком байтов; в этом
они отличаются от других структур данных ExtX.

Все четыре структуры данных начинаются с однотипного заголовка,
описанного в табл. 15.28.

Структуры данных журнала

Структуры данных журнала

PAGE 417

Таблица 15.28. Структура данных стандартного заголовка структур данных
журнала

Диапазон Описание Необходимость

0-3 Сигнатура (0хС03В3998) Да

4-7 Тип блока (см. табл. 15.29) Да

8-11 Порядковый номер Да

Тип блока является признаком, по которому различаются четыре структуры
данных. Его значения перечислены в табл. 15.29.

Таблица 15.29. Значения поля типа в заголовках журнала

Значение Описание

1 Блок дескрипторов

2 Блок закрепления

3 Суперблок, версия 1

4 Суперблок, версия 2

5 Блок отмены

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

Таблица 15.30. Структуры данных суперблока журнала версии 1 и 2

Диапазон Описание Необходимость

0-11 Стандартный заголовок (см. табл. 15.28) Да

12-15 Размер журнального блока Да

16-19 Количество блоков в журнале Да

20-23 Блок, с которого начинается фактическое Да

содержимое журнала

24-27 Порядковый номер первой транзакции Да

28-31 Блок первой транзакции Да

32-35 Номер ошибки Нет

В суперблоке версии 1 используются только первые 36 байт. В суперблоке
версии 2 также используются дополнительные поля, перечисленные в табл.
15.31.

Таблица 15.31. Дополнительные поля суперблока журнала версии 2

Диапазон Описание Необходимость

36-39 Совместимые функции Нет

40-43 Несовместимые функции Нет

44-47 Функции, совместимые только для чтения Нет

48-63 иию журнала Нет

продолжение &

PAGE 418

Глава 15. Структуры данных Ext2 и ExtЗ

Таблица 15.31 {продолжение)

Диапазон Описание Необходимость

64-67 Количество файловых систем, исполь- Нет

зующих журнал

68-71 Местонахождение копии суперблока Нет

72-75 Максимальное количество блоков жур- Нет

нала на транзакцию

76-79 Максимальное количество системных Нет

блоков на транзакцию

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

256-1023 16-байтовые идентификаторы файловых Нет

систем, использующих журнал

На момент написания книги была доступна только возможность отмены. Она
относится к категории несовместимых функций и представляется флагом
0x00000001.

Блок дескрипторов содержит стандартную структуру данных заголовка (см.
табл. 15.28), которая занимает байты 0-11. Начиная с байта 12, следуют
записи дескрипторов, поля которых описаны в табл. 15.32.

Таблица 15.32. Структуры данных записей блоков дескрипторов журнала

Диапазон Описание Необходимость

0-3 Блок файловой системы Да

4-7 Флаги (см. табл. 15.33) Да

8-23 иию (не существует при установленном Нет

флаге 5АМЕ_ииЮ)

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

Таблица 15.33. Значения флагов в поле дескриптора записи

Флаг Описание

0x01 Специальная обработка блока журнала

0x02 Запись содержит тот же код ШЮ, что и предыдущая (БАМЕ_ииЮ)

0x04 Блок удален транзакцией (в настоящее время не используется)

0x08 Последняя запись в блоке дескрипторов

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

Блок закрепления содержит только стандартный заголовок с типом блока и
порядковым номером закрепляемой транзакции.

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

Структуры данных журнала

PAGE 419

Таблица 15.34. Структура блока отмены в журнале

Диапазон

Описание

Необходимость

0-11

12-15

16-РАЗМЕР

Стандартный заголовок (см. табл. 15.28) Размер данных в байтах Список
4-байтовых адресов блоков файловой системы

Да Да Да

Отмена применяется ко всем транзакциям, порядковый номер которых меньше
либо равен порядковому номеру записи отмены.

Рассмотрим пример журнала из файловой системы. Для просмотра его
содержимого можно запустить программу ка! для индексного узла 8:

# псаг -т Илих-ехгЗ /6еу/ЫЬ2 8 | ххс!

0000000: сОЗЬ 3998 0000 0004 0000 0000 0000 0400 .;9………….

0000016: 0000 0400 0000 0001 0000 0126 0000 0000 ………..

0000032: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

0000048: а34с 4Ье5 с222 460Ь Ь76т с145Ь 518Ь 083с .1.К.. Т. .о.[0.. . ntfs-lO.dls

Полученный файл не структурирован, потому что он просто содержит
случайные блоки данных из файловой системы. Если при поиске в этом файле
будут обнаружены улики, программа dcalc поможет найти их источник. Dcalc
вычисляет адрес исходного блока данных по адресу блока из
неструктурированных данных. Например, если файловая система состоит из
4096-байтовых кластеров и в 123-м кластере неструктурированного файла
были обнаружены улики, достаточно запустить dcalc с параметром -и и
номером 123:

# dcalc -f ntfs -u 123 ntfs-10.dd 15945

Программа dstat позволяет проверить состояние выделения конкретной
единицы данных. Кроме того, dstat выводит информацию о группах цилиндров
и блоках в файловых системах UFS и Ext2/3:

# dstat -f linux-ext3 ext3-5.dd 23456

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

К категории метаданных относятся данные, описывающие файлы: адреса
блоков данных, выделенных файлу, размер файла и временные штампы. Состав
данных этой категории зависит от типа файловой системы. В пакете TSK к
этой категории относятся 4 программы, имена которых начинаются с
префикса i.

Для получения подробной информации о конкретной записи метаданных можно
воспользоваться программой istat. В ее результатах указываются размеры,
временные штампы и разрешения; кроме того, будут приведены адреса всех
выделенных единиц данных. Для образов NTFS istat выводит все атрибуты
файла. Примеры встречаются в главах 9, 12, 14 и 16.

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

PAGE 472

Приложение. The Sleuth Kit и Autopsy

поиске записей удаленных файлов, если запись имени была выделена другому
файлу.

# ils -f ntfs -е ntfslO.dd

ОI a 10101108979528711089795287110897952871100555111247552001010
1|а|0|0|1089795287|1089795287|1089795287|100555|1|4096|0|0 […]

255|а|256|0|998568000|1100132856|1089795731|100777|1|15360|0|0
256|f|256|0|1100132871|1100132871|1100132871|100777|1|256|0|0

Выходные данные ils форматируются с расчетом на автоматизированную
обработку; они часто используются с программой mactime для построения
временных диаграмм. После обнаружения блока данных с интересными уликами
можно провести поиск всех записей метаданных, запустив программу ifind с
параметром -d. Если же потребуется найти запись метаданных; на которую
ссылается некоторое имя файла, можно запустить программу ifind с флагом
-п. Так, в следующем примере выясняется, что кластер NTFS 3456 был
выделен атрибуту $DATA записи MFT с номером 18080:

# ifind -f ntfs -d 3456 ntfslO.dd 18080-128-3

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

# icat -f ntfs ntfslO.dd 18080

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

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

Программа fis перечисляет имена файлов в заданном каталоге. Она получает
адрес метаданных каталога в качестве аргумента и выводит списки как
выделенных, так и свободных имен. С ключом -г программа выполняет
рекурсивную обработку подкаталогов, а с ключом -I проводит поиск в
метаданных и выводит временные штампы с именами файлов. Соответствующие
примеры встречались во всех предыдущих главах. Например, в следующем
образе Ext3 индексный узел 69457 представляет каталог, содержащий
удаленный файл two.dat:

# fis -f linux-ext3 -a ext3.dd 69457 г/г 69458: acbdefg.txt

г/г * 69459: file two.dat d/d 69460: subdirl г/г 69461: RSTUVWXY

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

# ffind -f linux-ext3 ext3.dd 69458 /dirl/abcdefg.txt

Программы для работы с диском

PAGE 473

Категория прикладных данных

К категории прикладных относятся данные, включаемые в файловую систему
для повышения эффективности. В TSK на уровне прикладных данных работают
всего две программы; обе предназначены для работы с журналом в Ext3. В
журнале регистрируются предстоящие обновления метаданных; такая
информация ускоряет восстановление системы после сбоя. Журналы
обсуждались в главах 8 и 14.

Программа jIs выводит содержимое журнала и показывает, какие блоки
файловой системы хранятся в блоках журнала. Содержимое отдельного блока
журнала просматривается программой jcat. Пример:

# jls -f linux-ext3 ext3-6.dd JBlk Description

0: Superblock (seq: 0)

1: Unallocated Descriptor Block (seq: 41012)

2: Unallocated FS Block 98313

3: Unallocated FS Block 1376258

[…]

Если вас заинтересовала запись некоторого блока файловой системы
(например, 98 313), просмотрите содержимое блока журнала 2 командой
jcat:

# jcat -f linux-ext3 ext3-6.dd 2

Прочие

Некоторые программы TSK объединяют данные из разных категорий для
получения вывода, отсортированного в другом порядке. Первая программа,
mactime, получает временные данные от fis и ils и строит по ним
временные диаграммы файловых операций. Каждая строка вывода
соответствует обращению к файлу или его изменению (см. главу 8). Далее
приводится пример временной диаграммы (данные отформатированы по ширине
страницы):

Wed Aug 11 2004 19:31:58 34528 .a. /system32/ntio804.sys

35392 .a. /system32/ntio412.sys

[…]

Wed Aug 11 2004 19:33:27 2048 mac HYPERLINK
“file:///bootstat.dat” /bootstat.dat

1024 mac /system32/config/default.LOG

1024 mac /system32/config/software.L0G

Wed Aug 11 2004 19:33:28 262144 ma. /system32/config/SECURITY

262144 ma. /system32/config/default

Программы поиска

Последнюю из основных категорий программ TSK составляют программы
поиска. В версии 2.00 их круг будет расширен. Из текущей версии к этой
категории относится программа sigfind, предназначенная для поиска
двоичных сигнатур. В частности, она использовалась в ряде сценариев
части III книги.

Пол Беккер (Paul Bakker) работал над включением в TSK и Autopsy
индексированного поиска; эта возможность войдет в версию 2.00 (
HYPERLINK “http://www.brainspark.nl/” http://www.brainspark.nl/ ).
Процесс индексирования строит для образа дерево, ускоряющее поиск
конкретных строк. Более подробное описание можно найти в бюллетене «The
Sleuth Kit Informer, Issue 16» [Bakker, 2004]

PAGE 474

Приложение. The Sleuth Kit и Autopsy

Autopsy

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

Autopsy работает на базе HTML. Фактически это веб-сервер, который умеет
запускать программы из пакета TSK и обрабатывать их вывод. Autopsy
ничего не знает о файловых системах и дисках, это область TSK. Autopsy
может использоваться как при «живом», так и при «мертвом» анализе
систем.

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

При «живом» анализе Autopsy и TSK записываются на компакт-диск. Диск
размещается в системе UNIX, на которой, как предполагается, произошел
индци-дент; после этого вы можете анализировать содержимое файловой
системы, подключаясь к Autopsy с портативного или настольного
компьютера. Применение Autopsy и TSK при «живом» анализе обладает рядом
преимуществ — в частности, они показывают файлы, скрываемые большинством
руткитов (rootkits) и не изменяют А-время файлов и каталогов при
просмотре их содержимого. Как и во всех разновидностях «живого» анализа,
процесс зависит от данных, полученных от ОС, однако последняя может и
солгать, если она была модифицирована злоумышленником.

Режимы анализа

Autopsy поддерживает несколько режимов анализа, соответствующих
структуре пакета TSK. В режиме анализа файлов (File Analysis) эксперт
просматривает списки файлов и каталогов, а также содержимое отдельных
файлов. В режиме метаданных (Metadata) отображаются все метаданные,
связанные с конкретной записью, и все блоки данных, выделенные файлам.
Режим блоков данных (Data Unit) позволяет просмотреть содержимое любого
блока данных файловой системы (как в шестнадцатеричном редакторе), а в
режиме поиска по ключевым словам (Keyword Search) возможен поиск по
ASCII-кодам и строкам Unicode. В последнем режиме поиск осуществляется
по логическим томам, а не по логическим файлам. За дополнительной
информацией о типах поиска обращайтесь к главе 8.

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

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

475

где была обнаружена улика. Наконец, подсистема отслеживания событий
позволяет создавать заметки на основании временных штампов, полученных
при исследовании улик, с последующей сортировкой данных. Например, можно
создать заметки для времени создания файлов улик и оповещений системы
IDS (Intrusion Detection System). Отсортированные заметки принесут
пользу в фазе реконструкции событий.

Примерный вид окна Autopsy в режиме анализа файлов показан на рис. ПЛ.

f^^AUfS»v !e: MS Wiiutow* JP8 32~Mt Intel Ш86 GUI DIJL

String Contents Of File: 2 : \ /systemSZ/inetcpi . cpl

(This proqrara cannot be run in DOS mode.

. text

*.rdata

§.data

. rare

‘4 .reloc

K.ERNEL32.CJI1

USЈR32.diI

ADVAPX32.dll

COHCTL32.dil

Рис. П.1. Вид окна Autopsy в режиме анализа файлов

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

• Bakker, Paul. «Search Tools, Indexed Searching in Forensic Images».
Sleuth Kit Informer’#16, September 2004. HYPERLINK
“http://www.sleuthkit.org/informer/sleuthkit-informer-”
http://www.sleuthkit.org/informer/sleuthkit-informer- 16.html#search.

Алфавитный указатель

Символы

SAttrDef, файл, 257, 341 $ATTRIBUTE_LIST, атрибут, 257, 289 SBadClus,
файл, 254, 282 SBITMAP, атрибут, 253, 334 SBitmap, файл, 282, 342 SBoot,
файл, 254 SDATA, атрибут, 257 $ЕА, атрибут, 257

$EA_INFORMATION, атрибут, 257 SExtend, файл, 254 $FILE_NAME, атрибут,
257 $INDEX_ALLOCATION,

атрибут, 257, 303 $INDEX_ROOT, атрибут, 257, 303 SLogFile, файл, 254
$LOGGED_UTILITY_STREAM,

атрибут, 257 SMFT, файл, 253 SMftMirr, файл, 254, 274 SOBJECTJD,
атрибут, 299 SObjId, файл, 344 SQuota, файл, 306, 345 SReparse, файл,
302 $REPARSE_POINT, атрибут, 257 SSecure, файл, 254, 291
$SECURITY_DESCRIPTOR,

атрибут, 257, 291 SSTANDARDJNFORMATION,

атрибут, 257 $SYMBOLIC_LINK, атрибут, 257 SUpcase, файл, 254 SUsrJrnl,
файл, 348 SVolume, файл, 254, 276, 343 SVOLUMEJNFORMATION,

атрибут, 257 $VOLUME_NAME, атрибут, 257 $VOLUME_VERSION, атрибут, 257

А

ADS (альтернативные потоки

данных), 258, 289 ASCII, 42 ATA, диски, 48 АТА-3, безопасность, 53 AT
API, интерфейс, 53 Autopsy, 36, 474

В

В-деревья, 265 BIOS, 47, 65

ВРВ (BIOS Parameter Block), 200 BSD, 118

BXDR, программа, 68 С

CD-R, 114 CFTT,64, 66 CHS, адреса, 52

D

D-время, 367

DCO (Device Configuration Overlay), 68 dd, программа, 75 DEFRAG,
программа, 220 DEVICE_CONFIGURATION_IDENTIFY,

команда, 56 DFTT, сайт, 221 diskstat, программа, 68 DRIVEID, программа,
68

E

EnCase,35, 149 EOF, маркеры (FAT), 213 ExtX, 352, 399 ACL, 370

блоки, 352, 362, 399 суперблок, 399

Алфавитный указатель

PAGE 477

F

FAT

FSINFO, структура данных, 200 загрузочный сектор, 232 категория имен
файлов, 222 категория метаданных, 211 категория содержимого, 207
проверка целостности, 232

FAT12,200, 240

FAT16,200, 240

FAT32, 200, 240

FEK (File Encryption Key), 263

FIFO, 367

FireWire, 146

FreeBSD разделы, 120

FSINFO, структура данных, 203

H

HPA (Host Protected Area), 68 hpa, программа, 68

I

IDS (Intrusion Detection System), 64 istat, программа

FAT, 216

NTFS, 271

L

LBA (Logical Block Address), 50 LCN (Logical Cluster Number), 257 LFN
(Long File Name), 223

M-N

MFT (Master File Table), 251 NIST(National Institute of Standards

& Technology), 64, 66 NTFS, 198, 235, 250, 273, 317

MFT, 259

анализ, 270

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

системы, 273, 317 категория имен файлов, 300 категория метаданных, 285
файлы метаданных, 339 NTFSInfo, программа, 270

О

OpenBSD, 117, 143

R

RAID, 143

оборудование, 143

уровни, 143 READ_NATIVE_MAX_ADDRESS,

команда, 55

S

SCA (Single Connector Attachment), 61 SCSI, 48, 58

SECURITYJJNLOCK, команда, 54 SGID, 368

sigfind, программа, 205, 221 SMART, технология, 53 SUID, 368

T

TSK, 35, 165, 469 diskstat, программа, 68 sigfind, программа, 205, 279

U

UFS,352, 399

блоки, 422

фрагменты, 422 USN (Update Sequence Number), 310

V-W

VCN (Virtual Cluster Number), 257, 290 Windows

DEFRAG, программа, 220

RAID, 148

A

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

FAT, 208, 224, 302

NTFS, 283 альтернативные потоки

данных (ADS), 258, 289 анализ

ExtX, 358

FAT, 209

NTFS, 279

Solaris, 137

UFS, 429

живой, 27

мертвый, 27

томов, 82 асимметричное шифрование, 263

PAGE 478

Алфавитный указатель

атрибуты SATTRIBUTEJLIST, 257, 289 SBITMAP, 253, 334 $DATA, 257, 288
$ЕА, 257

$EA_INFORMATION, 257 $FILE_NAME, 257 $INDEX_ALLOCATION, 257, 303
$INDEX_ROOT, 257, 303 $LOGGED_UTILITY_STREAM, 257 $OBJECT_ID, 302
$REPARSE_POINT, 257 $SECURITY_DESCRIPTOR, 257, 291
$STANDARD_INFORMATION, 257 SSYMBOLICJLINK, 257 $VOLUME_INFORMATION, 257
$VOLUME_NAME, 257 $VOLUME_VERSION, 257

Б

базовые записи MFT, 259 блокировщики записи

аппаратные, 68

программные, 70

В

восстановление файлов FAT, 224 NTFS,314

геометрия (жесткого диска), 48

д

данные

вспомогательные, 34

необходимые, 34

копирование, 63

скрытые, 64

снятие, 63 двоичные числа, 38 дисковые квоты (NTFS), 306 дорожки, 49

Ж

жесткие диски

АТА, интерфейс, 51

DCO,56

НРА, 55

жесткие диски (продолжение) SCSI, 58

адреса секторов, 52

геометрия, 48 жесткие диски, 48 жесткие ссылки, 301 живое снятие данных,
66 журнал файловой системы

NTFS, 306

загрузочные диски, 46 загрузочный сектор

FAT, 200

NTFS, 275 загрузчик, 356 записи каталогов

FAT, 198, 212, 235 защита данных, 68

К

каталоги

UNIX, 376

атрибут, 212

хеш-деревья, 379 категория имен файлов

FAT, 222

NTFS, 300 категория метаданных

FAT, 211

NTFS, 285 категория содержимого

FAT, 207 кластеры

FAT, 207

NTFS, 280 кодировка, 42 контроллеры, 51 корневой каталог

FAT, 200

NTFS, 298 криптографические хеш-коды, 79 криптография (NTFS), 262

М

машинный код, 47 мертвое снятие данных, 66 монтирование, 35

Алфавитный указатель

PAGE 479

П

переходы, 302

проверка целостности данных, 232 процессор, центральный, 46 прямой
доступ к диску, 57

Р

разделы

Apple, 109

BSD, 117, 143

DOS, 93

EFI, 129

GPT, 138

VTOC, 131

восстановление, 90

создание, 82 разреженные атрибуты, 260 редактор. См. AppBrowser руткиты,
66

С

секторы

адресация, 52, 83

жесткие диски, 49 символические ссылки, 301 симметричное шифрование, 263
снятие данных, 63

dd, программа, 75

живое, 66

мертвое, 66

сетевое, 73 суперблок

ExtX, 354, 399

UFS1.448

UFS2,453

Т

тома RAID, 144 логические, 151

тома {продолжение)

определение, 83

сборка, 82 точка монтирования, 302

У

улики поиск, 29 цифровые, 26

Ф

файлы

$Аг.сЛ)ег, 254, 341

$BadClus, 254, 282

$Вктар, 282

$Воог. 254

$Ехг.егк1, 254

$1хFрПе, 254

$МРТ, 253

$МЙМпт, 254, 274

$F)ио1а, 306

$Reparse, 302

$5есиге,254, 291

Зирсаэе, 254

$изг1гп1, 348

$Уо1шпе,254, 276 физические адреса, 52 фрагментация, 170, 433

X

хеш-деревья, 379 хеш-коды, 28 хеш-коды, 74

ц

цепочки кластеров, 213 цилиндры, 49

Ш

шифрование атрибутов, 262

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

Заведующий редакцией А. Кривцов

Ведущий редактор А. Пасечник

Литературный редактор А. Пасечник

Технический редактор Л. Родионов и

Художник Л. Адуевска; Корректоры
Н. Рощина, И. Тимофеева

Верстка Л. Родионова

Подписано в печать 26.09.06. Формат 70×100/16. Усл. п. л. 38,7. Тираж
2000. Заказ 698 ООО «Питер Пресс», 198206, Санкт-Петербург, Петергофское
шоссе, д. 73, лит. А29.. Налоговая льгота — общероссийский классификатор
продукции ОК 005-93, том 2; 95 3005 — литература учебная.

Отпечатано с готовых диапозитивов в ОАО «Техническая книга» 190005,
Санкт-Петербург, Измайловский пр., 29

криминалистический анализ

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

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

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

Тема: Операционные системы

Уровень пользователя: опытный/эксперт

Е^пптйР

?

TT

Addison-Wesley

Заказ книг:

197198, Санкт-Петербург, а/я 619 тел.: (812) 703-73-74, HYPERLINK
“mailto:[email protected][email protected]

61093, Харьков-93, а/я 9130 тел.: (057) 712-27-05, HYPERLINK
“mailto:[email protected][email protected]

HYPERLINK “http://www.piter.com” www.piter.com — вся информация о
книгах и веб-магазин

ISBN 5-469-01311-1

9″785469″01 31 1 2*

9785469013112

Нашли опечатку? Выделите и нажмите CTRL+Enter

Похожие документы
Обсуждение

Ответить

Курсовые, Дипломы, Рефераты на заказ в кратчайшие сроки
Заказать реферат!
UkrReferat.com. Всі права захищені. 2000-2020