СЕРИЯ

Brian Carrier
File System
Forensic
Analysis
TT
Addison-Wesley
Upper Saddle River, NJ • Boston • Indianapolis • San Francisco
New York • Toronto • Montreal • London • Munich • Paris • Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico • CityMunich

Брайан Кэрриэ
КРИМИНАЛИСТИЧЕСКИЙ
АНАЛИЗ
ФАЙЛОВЫХ
СИСТЕМ
С^ППТЕР*
Москва - Санкт-Петербург - Нижний Новгород - Воронеж
Новосибирск - Ростов-на-Дону - Екатеринбург - Самара
Киев - Харьков - Минск
2007

ББК 32.973.23-018-07
УДК 004.056.57
К90
Кэрриэ Б.
К90 Криминалистический анализ файловых систем. — СПб.: Питер, 2007. —
480 с: ил.
ISBN 5-469-01311-1
Какая структура служит хранилищем всех данных, имеющихся на вашем ПК? Очевидно,
файловая система. При этом четкого понимания ее устройства нет даже у некоторых IT-
специалистов. Развернутые технические описания файловых систем встречаются крайне редко, а
популярная литература по этой теме просто отсутствует. Специалист в области информационной
безопасности Брайан Кэрриэ написал долгожданную книгу, которая необходима всем, кто хочет
понять, как работают файловые системы и как обеспечить сохранность данных.
ББК 32.973.23-018-07
УДК 004.056.57
Права на издание получены по соглашению с Addison-Wesley Longman
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было
форме без письменного разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как
надежные Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не
может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за
возможные ошибки, связанные с использованием книги.
© 2005 Pearson Education, Inc
ISBN 0-321-26817-2 (англ ) © Перевод на русский язык, ООО «Питер Пресс», 2007
ISBN 5-469-01311-1 © Издание на русском языке, оформление, ООО «Питер Пресс», 2007

Краткое содержание
Предисловие 19
Введение 21
Благодарности, 24
Часть I. Основы 25
Глава 1. Основы цифровых расследований 26
Глава 2. Основные принципы работы компьютеров 38
Глава 3. Снятие данных с жесткого диска 63
Часть II. Анализ томов 81
Глава 4- Анализ томов 82
Глава 5. Разделы на персональных компьютерах 93
Глава 6. Разделы в серверных системах 117
Глава 7. Многодисковые тома 143
Часть III. Анализ файловых систем 163
Глава 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
Приложение. The Sleuth Kit и Autopsy 469
Алфавитный указатель 476

Содержание
Предисловие 19
От издательства 20
Введение 21
Структура книги 22
Ресурсы 23
Благодарности 24
Часть I. Основы 25
Глава 1- Основы цифровых расследований 26
Цифровые расследования и улики 26
Процесс анализа места цифрового преступления 27
Фаза сохранения системы 28
Фаза поиска улик 29
Фаза реконструкции событий 29
Общие рекомендации 30
Анализ данных 31
Типы анализа 31
Необходимые и вспомогательные данные 34
Инструментарий эксперта 35
EnCase (Guidance Software) 35
Forensic Toolkit (Access Data) 36
ProDiscover (Technology Pathways) 36
SMART (ASR Data) 36
The Sleuth Kit/Autopsy 36
Итоги 37
Библиография 37
Глава 2. Основные принципы работы компьютеров 38
Организация данных 38
Двоичная, десятичная и шестнадцатеричная запись 38
Размеры данных 41
Строковые данные и кодировка символов 42

Структуры данных 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
Область HPA 67
DCO 68
Аппаратная блокировка записи 68
Программная блокировка записи 70
Запись снятых данных 71
Выбор приемника 71
Формат файла образа 72
Сжатие файла образа 73
Сетевое снятие данных 73
Хеширование и целостность данных 74
Практический пример с использованием dd 75
Источник 75
HPA 76
Приемник 77
Обработка ошибок 78
Криптографическое хеширование 79
Итоги 80
Библиография 80

Часть П. Анализ томов 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
Итоги 113
Съемные носители 114
Библиография 115
Глава 6. Разделы в серверных системах 117
Разделы BSD 117
Общий обзор 117
Структуры данных 121
Факторы анализа 127
Итоги 128
Сегменты Sun Solaris 129
Общий обзор 129
Структуры данных Sparc 130

Структуры данных 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
Методы надежного удаления 175
Категория метаданных 176
Общая информация 176
Методы анализа 182
Категория имен файлов 187
Общие сведения 187

Методы анализа 190
Методы надежного удаления 192
Категория прикладных данных 192
Журналы файловой системы 193
Методы поиска на прикладном уровне 193
Восстановление файлов на прикладном уровне 194
Сортировка файлов по типу 195
Конкретные файловые системы 195
Итоги 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

Глава 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
Стандартные типы атрибутов 257
Другие концепции атрибутов , 259
Базовые записи MFT , 259
Сжатые атрибуты 260
Шифрование атрибутов 262
Индексы , 265
В-деревья 265
Атрибуты индексов NTFS 268
Программы анализа 270
Итоги 271
Библиография 271
Глава 12. NTFS: анализ 273
Категория данных файловой системы 273
Файл $MFT 273
Файл$МРТМ1гг 274
Файл $Boot 275
Файл $Volume 276
Oaiui$AttrDef 277
Тестовый образ 277
Методы анализа 278
Факторы анализа 278
Сценарий анализа 279

Категория данных содержимого 281
Кластеры 281
Файл $Bitmap 282
Файл $BadClus 282
Алгоритмы выделения 283
Структура файловой системы 283
Методы анализа 284
Факторы анализа 285
Сценарий анализа 285
Категория метаданных 285
Атрибут $STANDARD_INFORMATION 286
Атрибут $FILEJMAME 287
Атрибут $DATA 288
Атрибут $ATTRIBUTE_LIST 289
Атрибут $SECUFU7Y_DESCRIPTOR 291
Файл $Secure 291
Тестовый образ 292
Алгоритмы выделения 293
Методы анализа 294
Факторы анализа 296
Сценарий анализа 298
Категория имен файлов 300
Индексы каталогов 300
Корневой каталог 301
Ссылки на файлы и каталоги 301
Идентификаторы объектов 302
Алгоритмы выделения 302
Методы анализа 303
Факторы анализа 303
Сценарий анализа 304
Категория прикладных данных 306
Дисковые квоты 306
Журналы файловых систем 306
Журнал изменений 309
Общая картина 310
Создание файла 311
Пример удаления файла 312
Разное 314
Восстановление файлов 314
Проверка целостности данных 314

Итоги 315
Библиография 316
Глава 13- Структуры данных NTFS 317
Базовые концепции 317
Маркеры 317
Записи MFT (файловые записи) 318
Заголовок атрибута 320
Стандартные атрибуты файлов 324
Атрибут $STANDARD_INFORMATION 324
Атрибут $FILE_NAME 326
Атрибут $DATA 328
Атрибут $ATTRIBUTE_LIST 328
Атрибут $OBJECT_ID 330
Атрибут $REPARSE_POINT 330
Атрибуты и структуры данных индексов 331
Атрибут $INDEX_ROOT 331
Атрибут $INDEX_ALLOCATION 332
Атрибут $ВГГМАР 334
Структура данных заголовка индексного узла 334
Структура данных обобщенного индексного элемента 335
Структура данных индексного элемента каталога 336
Файлы метаданных файловой системы 339
Файл $MFT 339
Файл $Boot 339
Файл $AttrDef 341
Файл $Bitmap 342
Файл $Volume 343
Файл$ОЬ]1с1 344
Файл $Quota 345
Файл $LogFile 347
Файл $UsrJrnl 348
Итоги 351
Библиография 351
Глава 14. Ext2 и Ext3: концепции и анализ 352
Введение 352
Категория данных файловой системы 354
Общие сведения 354
Методы анализа 358
Факторы анализа 358
Сценарий анализа 359

Категория содержимого 362
Общие сведения 362
Алгоритмы выделения 363
Методы анализа 364
Факторы анализа 364
Сценарий анализа 365
Категория метаданных 365
Общие сведения 366
Алгоритмы выделения 371
Выделение индексных узлов 371
Методы анализа 373
Факторы анализа 374
Сценарий анализа 375
Категория данных имен файлов 376
Общие сведения 376
Алгоритмы выделения 380
Методы анализа 381
Факторы анализа 382
Сценарии анализа 383
Категория прикладных данных 387
Журналы файловой системы 387
Сценарий анализа 389
Общая картина 390
Пример создания файла 391
Пример удаления файла 393
Разное 395
Восстановление файлов 395
Проверка целостности данных 396
Итоги 397
Библиография 397
Глава 15- Структуры данных Ext2 и Ext3 399
Суперблок 399
Таблица дескрипторов групп 403
Битовая карта блоков 404
Индексные узлы 405
Расширенные атрибуты 409
Запись каталога 412
Символическая ссылка 414
Хеш-деревья 415
Структуры данных журнала 416

Итоги 421
Библиография 421
Глава 16. UFS1 и UFS2: концепции и анализ 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. Структуры данных UFS1 и UFS2 448
Суперблок UFS1 448
Суперблок UFS2 453
Сводка групп цилиндров 456
Дескриптор группы UFS1 457
Дескриптор группы UFS2 459
Битовые карты блоков и фрагментов 460

Индексные узлы UFS1 461
Индексные узлы UFS2 464
Расширенные атрибуты UFS2 465
Записи каталогов 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 колледжей и университетов ведут разработку научных программ в области
цифровой экспертизы, и каждый месяц их ряды пополняются.
Я имел удовольствие работать со многими органами правопорядка, учебными
учреждениями, колледжами и университетами в области разработки программ
цифровой экспертизы. Один из первых вопросов, который мне обычно задава-
задавали, — не могу ли я порекомендовать хороший учебник для их курсов. На эту тему
было написано немало книг. Одни ориентировались на отдельные аспекты рас-
расследования — такие, как методы реагирования или криминологическая экспер-
экспертиза. Другие представляли собой учебники по использованию конкретных про-
программных пакетов. Было трудно найти книгу, которая закладывала бы надежную
техническую и системную основу в области цифровой экспертизы... Так было до
настоящего времени.
В этой книге изложены основополагающие принципы анализа файловых сис-
систем. Ее материал основателен, полон и хорошо организован. Брайан Кэрриер сделал
то, что необходимо было сделать в этой области. Книга дает читателю хорошее
понимание как структур данных в разных файловых системах, так и принципов
их работы. Кэрриер написал свою книгу так, что читатель сможет использовать
то, что он знает об одной файловой системе, при изучении другой системы. Эта
книга бесценна и как учебник, и как справочник; она должна стоять на полке каж-
каждого практикующего специалиста и преподавателя в области цифровой экспер-
экспертизы. Кроме того, она содержит доступную информацию для читателей, которые
пожелают самостоятельно разобраться в таких темах, как восстановление данных.

Когда мне предложили написать это предисловие, я с радостью принял пред-
предложение! Мы с Брайаном Кэрриером знакомы уже много лет. На меня всегда про-
производило впечатление замечательное сочетание его выдающейся технической ква-
квалификации и умения понятно объяснять не только то, что знает он, но и, что еще
важнее, то, что необходимо знать читателю. Работа Брайана над Autopsy и The
Sleuth Kit (TSK) доказала его компетентность — его имя известно любому специ-
специалисту в области компьютерной экспертизы. Мне выпала честь работать с Брай-
ном в его текущей должности в Университете Пердью (Purdue), где он помогает
сделать академическому сообществу то, что однажды сделал для коммерческого
сектора: установить высокие стандарты.
Итак, я без малейших колебаний рекомендую вам эту книгу. Она поможет вам
заложить прочную основу знаний в области цифровых носителей информации.
Марк М. Поллитт (Mark M. Pollitt).
Президент Digital Evidence Professional Services, Inc.
Бывший директор программы ФБР Regional Computer Forensic Laboratory
Program.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу электронной поч-
почты: comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства — http://www.piter.com — вы найдете подробную ин-
информацию о наших книгах.

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

компьютерной экспертизы. Правительственные и коммерческие лаборатории про-
проводят теоретические исследования в этой области, уделяя внимание как будущим,
так и текущим проблемам. Также появились специализированные бюллетени, в ко-
которых публикуются методики анализа и расследования. Все эти новые исследо-
исследования требуют основательной подготовки, выходящей за рамки конкретного про-
программного пакета или методики.
В этой книге я постараюсь изложить базовые концепции и теорию файловых
систем и томов, а затем применить их в контексте расследования. Для каждой
файловой системы рассматриваются методы анализа и факторы, которые должен
учитывать эксперт. Описанные сценарии закрепят навыки применения теории
на практике. Также в книге приводятся структуры данных, задействованные
в томах и файловых системах, а ручной разбор низкоуровневых образов поможет
понять, где хранятся те или иные данные. Если формальные описания структур
данных вас не интересуют, соответствующие главы можно пропустить. В книге
используются только некоммерческие программы, поэтому вы можете бесплатно
загрузить их и воспроизвести результаты в своей системе.
Структура книги
Книга делится на три части. В первой части приводится основная теория, а основ-
основной технический материал содержится во второй и третьей частях. Книга органи-
организована таким образом, чтобы изучение шло от нижних уровней абстракции к вер-
верхним. Мы начнем с общего знакомства с жесткими дисками, а затем разберемся,
как дисковое пространство организуется в разделы. После знакомства с раздела-
разделами речь пойдет о содержимом разделов, которое обычно представляет собой фай-
файловые системы.
Часть 1, «Основы», начинается с главы 1, «Основы цифровых расследований»;
в ней я излагаю свой подход к цифровым расследованиям. Будут представлены
различные фазы расследования и рекомендации, чтобы вы знали, где использу-
используются методики, описанные в книге. Впрочем, книга не требует, чтобы вы исполь-
использовали этот же подход в своей работе. Главы 2 и 3 содержат теорию и примеры
снятия данных с жесткого диска для их последующего анализа в частях 2 и 3.
Часть 2, «Анализ томов», посвящена анализу структур данных, обеспечиваю-
обеспечивающих разбиение и объединение дискового пространства в томах. В главе 4, «Ана-
«Анализ томов», приводится общий обзор методов анализа томов, а в главе 5, «Разде-
«Разделы на персональном компьютере», рассматриваются распространенные схемы
разделов DOS и Apple. Глава 6, «Разделы в серверных системах», посвящена раз-
разделам в системах BSD, Sun Solaris и Itanium. В главе 7, «Многодисковые тома»,
говорится о RAID и объединении томов.
Часть 3, «Анализ файловых систем», посвящена анализу тех структур данных
томов, которые непосредственно связаны с сохранением и загрузкой данных. В гла-
главе 8, «Анализ файловых систем», представлена общая теория анализа файловых
систем и определяется терминология для остальных глав части 3. Каждой файло-
файловой системе посвящаются как минимум две главы: в первой излагаются общие

концепции и методы расследования, а во второй приводятся структуры данных
и результаты ручного анализа дисковых образов. Вы можете сами решить, как чи-
читать эти две главы: параллельно, последовательно или вообще пропустить главу
с описаниями структур данных.
Файловые системы сильно различаются по архитектуре, поэтому при их опи-
описании используется обобщенная модель файловой системы с классификацией дан-
данных на пять категорий: данные файловой системы, содержимое, метаданные, дан-
данные имен файлов и прикладные данные. Эта обобщенная модель применяется при
описании всех файловых систем и упрощает их сравнительный анализ.
В главах 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) описаны в приложении к книге. Дополнительную документацию
можно загрузить по адресу: http://www.sleuthkit.org.
URL-адреса и ссылки на другие программы приводятся по мере надобности.
Дополнительные ресурсы, ссылки и исправления размещаются на сайте книги:
http://www.digitaL-evidence.org/fsfa/.

Благодарности
Мне хотелось бы поблагодарить многих людей, помогавших мне в области циф-
цифровой экспертизы. Прежде всего я должен упомянуть тех, кто оказывал мне об-
общее содействие в течение многих лет: это Эоган Кейси (Eoghan Casey), Дэйв Дит-
Дитрих (Dave Dittrich), Дэн Фармер (Dan Farmer), Дэн Гир (Dan Geer), Дэн Калил
(Dan Kalil), Уоррен Круз (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

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

Возьмем сервер, подвергшийся внешнему вторжению. Расследование начинается
с определения ответа на вопрос: когда это произошло и кто это сделал. В процессе
расследования обнаруживаются данные, которые были созданы событиями, свя-
связанными с инцидентом. Эксперт восстанавливает на сервере удаленные записи
журнала, находит программы, задействованные в атаке, и многочисленные уяз-
уязвимости, существующие на сервере. По этим и другим данными строится гипоте-
гипотеза относительно того, какая уязвимость была использована нападающим, и что он
делал потом. Позднее эксперт анализирует конфигурацию брандмауэра (firewall)
и журнала. По результатам анализа он определяет, что некоторые сценарии, сфор-
сформулированные в гипотезах, невозможны, потому что сетевой трафик соответству-
соответствующего типа не существовал, а в журнале не нашлось обязательных записей. Та-
Таким образом обнаруживаются улики, опровергающие одну или несколько гипотез.
В этой книге я использую термин «улика» в следственном контексте. Улики
имеют как юридическое, так и следственное применение. Приведенное ранее опре-
определение относилось к следственному применению улик; далеко не всегда найден-
найденные улики могут быть предъявлены в суде. Поскольку требования к юридичес-
юридической допустимости улик зависят от страны или штата, а я не обладаю юридической
подготовкой, я сосредоточу внимание на общей концепции улик, а вы можете вне-
внести поправки с учетом местного законодательства. В действительности никаких
юридических требований, относящихся именно к файловым системам, не суще-
существует, поэтому необходимую информацию можно почерпнуть из общей литера-
литературы по цифровому расследованию.
Процесс анализа места цифрового преступления
Не существует единого подхода к проведению расследований. Если спросить пя-
пятерых людей, как найти человека, который допил остатки кофе из кофейника, ве-
вероятно, вы получите пять разных ответов. Один предложит снять с кофейника
отпечатки пальцев, другой — поискать видеозаписи на камерах системы безопас-
безопасности, третий — проверить, у кого самая горячая чашка. Если нам удастся найти
нужного человека, не нарушив никаких законов, не так уж важно, какой процесс
при этом использовался, хотя некоторые способы эффективнее других.
Подход, который я использую в цифровых расследованиях, основан на процессе
анализа места физического преступления [Carrier and Spafford, 2003]. В данном слу-
случае мы имеем место цифрового преступления, к которому относится цифровое ок-
окружение, создаваемое программами и оборудованием. Процесс состоит из трех ос-
основных фаз: консервации системы, поиска улик и реконструкции событий. Эти фазы
не обязаны следовать одна за другой, а общая схема процесса показана на рис. 1.1.
Рис. 1.1. Три основные фазы анализа места цифрового преступления
Этот процесс применяется при проведении расследования как в живых, так
и в мертвых системах. Живой анализ происходит при поиске улик с использовани-
использованием операционной системы или других ресурсов анализируемого компьютера. Мер-
Мертвый анализ происходит тогда, когда вы запускаете доверенное приложение в до-

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

Фаза поиска улик
Позаботившись о сохранении данных, можно перейти к поиску в них улик. Вспом-
Вспомните: мы ищем данные, которые поддерживают или опровергают гипотезы о про-
произошедшем инциденте. Процесс обычно начинается с изучения стандартных мест,
зависящих от типа инцидента (если он известен). Например, если речь идет о при-
привычках по работе с браузером, следует просмотреть содержимое кэша браузера,
файл истории и закладки. Если же расследуется взлом системы Linux, стоит по-
поискать следы руткитов или новые учетные записи пользователей. С ходом рас-
расследования эксперт строит гипотезы и ищет улики, которые подтверждали бы или
опровергали их. Важно, чтобы эксперт искал и опровергающие улики, не ограни-
ограничиваясь подтверждающими.
Теория процесса поиска проста. Сначала следует определить общие характе-
характеристики искомого объекта, а затем провести поиск этого объекта в наборе дан-
данных. Например, если потребуется найти все файлы с расширением JPG, следует
просмотреть все имена файлов и выделить среди них те, которые заканчиваются
символами «JPG». Два ключевых шага — это определение того, что нужно найти,
и тех мест, где должен проводиться поиск.
Часть 2, «Анализ томов», и часть 3, «Анализ файловых систем», посвящены
поиску улик в томах и файловых системах. В сущности, главы анализа файловых
систем организованы таким образом, чтобы читатель мог сосредоточиться на кон-
конкретной категории данных, содержащей улики. В конце главы приводится сводка
популярных аналитических программ; все они позволяют просматривать, искать
и сортировать данные в подозрительных системах с целью поиска улик.
Методы поиска
Большинство улик находится в файловой системе и в файлах. Стандартная мето-
методика поиска заключается в поиске файлов по именам или шаблонам. Также часто
требуется найти файл по ключевым словам, присутствующим в их содержимом.
Возможен и вариант поиска файлов по временным данным — таким, как время
последнего обращения или записи.
Иногда поиск известных файлов проводится сравнением хеш-кодов содержимо-
содержимого файлов, вычисленных по алгоритму MD5 или SHA-1, с базой данных хеш-ко-
хеш-кодов — такой, KaKNational Software Reference Library (NSRL— http://www.nsrLnist.gov).
Базы данных хеш-кодов часто применяются при поиске заведомо хороших или
заведомо вредоносных файлов. Другой распространенный метод поиска основан
на сигнатурах, присутствующих в содержимом. По сигнатурам часто удается най-
найти все файлы заданного типа даже в том случае, если они были переименованы.
При анализе сетевого трафика возможен поиск всех пакетов, отправленных
с некоторого исходного адреса, или всех пакетов, адресованных конкретному пор-
порту. Иногда требуется найти все пакеты с заданным ключевым словом.
Фаза реконструкции событий
В последней фазе расследования на базе найденных улик определяются события,
происходившие в системе. В соответствии с нашим определением расследования
мы пытаемся найти ответы на вопросы о цифровых событиях в системе. Допустим,
в фазе поиска улик были обнаружены файлы, нарушающие корпоративную

политику или закон, но факт их обнаружения не дает никакой информации о со-
событиях. Выясняется, что один из файлов появился в результате определенного
события — загрузки по сети; также следует попытаться определить, какое прило-
приложение загрузило его. Был ли это веб-браузер или какая-то вредоносная програм-
программа? Известен ряд случаев использования вредоносных программ для защиты
при обнаружении незаконных материалов или других цифровых улик [George,
2004; Brenner, Carrier, and Henninger, 2004]. Иногда после фазы реконструкции
цифровых событий удается связать эти цифровые события с физическими.
Для реконструкции событий эксперт должен хорошо знать приложения и ОС,
установленные на компьютере, чтобы строить гипотезы на основании их воз-
возможностей. Например, цифровые события в Windows 95 отличаются от событий
Windows XP, а разные версии браузера Mozilla порождают разные события. Та-
Такой тип анализа выходит за рамки книги, но некоторые общие рекомендации мож-
можно найти в [Casey, 2004].
Общие рекомендации
Не стоит полагать, будто все расследования проводятся по одной схеме, — иногда
приходится изобретать новые процедуры. Возможно, книга покажется кому-то
излишне академичной, потому что она не ограничивается возможностями, реали-
реализованными в существующих инструментах. Некоторые методы еще не были реа-
реализованы, поэтому для поиска улик вам придется импровизировать. Приведу свой
набор общих правил, которые, как хочется верить, упростят вашу работу при раз-
разработке новых процедур.
Первое правило — сохранение исследуемой системы. Эксперт должен исклю-
исключить любые модификации данных, которые могут послужить уликами. Крайне
неприятно оказаться в суде, когда другая сторона убеждает присяжных, что вы по
неосторожности стерли улики. Решению этой задачи была посвящена первая ста-
стадия процесса расследования. Приведу несколько примеров ее реализации:
• Скопируйте важные данные, поместите оригинал в надежное место и анализи-
анализируйте копию, чтобы в случае модификации данных можно было восстановить
оригинал.
• Вычислите хеш-коды MD5 или SHA важных данных. Позднее они помогут
доказать, что данные не изменились.
• Воспользуйтесь устройством блокировки записи во время любых действий,
способных привести к записи в анализируемые данные.
• Сведите к минимуму количество файлов, создаваемых во время живого ана-
анализа, — они могут стереть улики в свободном пространстве.
• Будьте осторожны при открытии файлов во время живого анализа, поскольку
это может привести к модификации данных (таких, как время последнего об-
обращения).
Второе правило — изоляция среды анализа как от анализируемых данных, так
и от внешнего мира. Изоляция от подозрительных данных необходима, потому
что вы не знаете, что они могут сделать. Исполняемый файл из анализируемой
системы может удалить все файлы на вашем компьютере или попытаться уста-
установить связь с удаленной системой. Открытие HTML-файла в браузере может

привести к запуску сценариев и загрузке файлов с удаленного сервера. Оба вари-
варианта потенциально опасны, и от них необходимо защититься. Изоляция от подо-
подозрительных данных реализуется их просмотром в приложениях с ограниченной
функциональностью или виртуальных средах, легко воссоздаваемых в случае
уничтожения — таких, как VMWare (http://www.vmware.com).
Изоляция от внешнего мира необходима для того, чтобы предотвратить всякое
вмешательство извне и нежелательную пересылку данных. Например, как говори-
говорилось в предыдущем абзаце, даже простая загрузка HTML-страницы может приве-
привести к попытке подключения к удаленному серверу. Изоляция от внешнего мира
обычно реализуется подключением к лабораторной сети, не имеющей внешнего
выхода, или фильтрацией сетевого трафика на брандмауэре.
Следует отметить, что живой анализ затрудняет изоляцию. Система не изолиро-
изолирована от анализируемых данных по определению, потому что для анализа этих дан-
данных применяется ее же ОС, которая может содержать посторонний код. Каждое
действие выполняется с участием анализируемых данных. Кроме того, изоляция
от внешнего мира тоже усложняется, потому что для нее необходимо отключить
систему от сети, а живой анализ обычно выполняется во время активности системы.
Третье правило — проверка данных по другим независимым источникам. Тем
самым снижается риск использования ложных данных. Например, как будет по-
показано позднее, в большинстве систем временные штампы файлов легко изме-
изменить. Таким образом, если в вашем расследовании время играет важную роль, по-
постарайтесь найти записи в журналах, сетевой трафик или другие события, которые
подтверждали бы время выполнения операций с файлами.
Последнее правило — документирование всех действий. Это поможет вам оп-
определить, какой поиск еще не проводился и какие результаты были получены ра-
ранее. При проведении живого анализа или применении методов, которые могут
привести к модификации данных, очень важно документировать все происходя-
происходящее; позднее вы сможете описать, какие изменения были внесены в систему из-за
ваших действий.
Анализ данных
В предыдущем разделе я говорил, что основной задачей эксперта является поиск
цифровых улик. Это довольно общее заявление, потому что улики могут найтись
почти в любом месте. В этом разделе я намерен сузить область поиска цифровых
улик и выделить ряд положений, которые будут подробно обсуждаться позднее
в книге. Также мы обсудим, каким данным можно доверять больше других.
Типы анализа
При анализе цифровых данных эксперт ищет объекты, спроектированные чело-
человеком. Кроме того, при проектировании систем хранения данных большинства
цифровых устройств разработчики стремились добиться гибкости и масштаби-
масштабируемости, вследствие чего такие системы имеют многоуровневую структуру. Я вос-
воспользуюсь этой многоуровневой структурой для определения различных типов
анализа [Carrier, 2003a].

Если начать с нижних уровней архитектуры, мы обнаруживаем на них две не-
независимые области анализа. Первая базируется на устройствах хранения инфор-
информации, а вторая — на устройствах обмена данными. В этой книге основное внима-
внимание уделяется анализу устройств хранения информации, а еще точнее — устройств
долгосрочного хранения информации (таких, как жесткие диски). Анализ ком-
коммуникационных систем (таких, как сети IP) в книге не рассматривается, но вы
можете найти необходимую информацию в других источниках [Bejtlich, 2005;
Casey, 2004; Mandia et al., 2003].
Различные области анализа представлены на рис. 1.2. На нижнем уровне вы-
выполняется анализ физических носителей информации: жестких дисков, карт па-
памяти и дисков CD-ROM. Анализ в этой области может быть сопряжен с чтением
низкоуровневых данных с магнитной поверхности и другими методами, для ко-
которых необходима чистая комната. В книге я буду предполагать, что в вашем рас-
распоряжении имеется надежный метод чтения данных с физического носителя, а на
устройство хранения информации уже записан поток из нулей и единиц.
Рис. 1.2. Иерархия уровней анализа, основанная на архитектуре цифровых данных.
Блоки, выделенные жирными линиями, рассматриваются в книге
В дальнейшем мы будем рассматривать анализ двоичного потока информации
на физическом носителе. Структура микросхем памяти обычно определяется на
уровне процессов и выходит за рамки книги. Наше внимание будет сосредоточе-
сосредоточено на постоянных носителях — таких, как жесткие диски и карты памяти.
Как правило, устройства долгосрочного хранения информации организуются
в виде томов. Том представляет собой совокупность ячеек носителя информации,
доступных для чтения и записи со стороны приложений. Анализ томов будет под-
подробно рассматриваться в части 2 книги, а сейчас я упомяну о двух важнейших
концепциях этого уровня. Первая — это разделы (один том разбивается на не-
несколько томов меньшего объема), а вторая — сборка (объединение нескольких
томов в один большой том, на котором в дальнейшем могут создаваться разделы).
Примерами данных этой категории служат таблицы разделов DOS, разделы Apple
и массивы RAID. Некоторые носители (скажем, дискеты) не содержат данных на
этом уровне, а весь диск представляет собой один том. Анализ данных на уровне
томов позволяет определить, где находится файловая система и другие данные
и где может храниться скрытая информация.

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

Необходимые и вспомогательные данные
Все данные в описанной схеме в той или иной степени структурированы, но не
вся структура необходима для выполнения основных функций уровня. Напри-
Например, целью уровня файловой системы является организация пустых томов для
хранения данных и их последующей выборки. Файловая система связывает имя
файла с содержимым. Следовательно, данные об имени файла и его местонахож-
местонахождении на диске являются обязательными. Так, на рис. 1.4 изображен файл с име-
именем mirade.txt и содержимым, хранящимся по адресу 345. Если имя файла или
адрес содержимого окажутся неверными или будут отсутствовать, прочитать со-
содержимое файла не удастся. Например, если в поле адреса будет храниться значе-
значение 344, то при попытке чтения будет получено постороннее содержимое.
Рис. 1.4. Чтобы система могла найти и прочитать этот файл, его имя, размер и местонахождение
содержимого должны быть точно заданы. С другой стороны, точное
значение времени последнего обращения не обязательно
На рис. 1.4 также показано, что для файла хранится время последнего обраще-
обращения. Однако этот атрибут не является необходимым для выполнения основной
функции файловой системы: даже если он будет изменен, пропадет или будет за-
задан неверно, это никак не повлияет на процесс чтения и записи содержимого.
В книге я ввожу концепцию необходимых и вспомогательных данных, пото-
потому что обязательным данным можно доверять, но о вспомогательных данных
этого сказать нельзя. Мы можем быть уверены в правильности адреса содержи-
содержимого файла, потому что в противном случае пользователь, работавший с систе-
системой, не мог бы прочитать его данные. Время последнего обращения может быть
правильным, но может и не быть. Допустим, ОС не обновила его после послед-
последнего обращения, пользователь изменил время по своему усмотрению, или внут-
внутренние часы ОС были смещены на 3 часа, и для файла было сохранено непра-
неправильное время.
Обратите внимание: то, что мы доверяем числовому значению адреса содер-
содержимого, не означает, что мы доверяем фактическому содержимому по этому ад-
адресу. Скажем, адрес в удаленном файле может быть точным, но блок данных, на
который он ссылается, может оказаться выделенным заново, а содержимое по это-
этому адресу может относиться к другому файлу. Вспомогательные данные обычно
бывают правильными, но, если они заложены в основу гипотезы об инциденте,
постарайтесь найти дополнительные источники данных для их поддержки. В ча-
частях 2 и 3 книги я буду указывать, какие данные являются необходимыми, а ка-
какие — нет.

Инструментарий эксперта
Существует множество программ, используемых аналитиками при анализе циф-
цифровых систем. Функции большинства программ такого рода в основном сосредо-
сосредоточены в фазах сохранения и поиска. В примерах, приводимых в книге, будет ис-
использоваться пакет TSK (The Sleuth Kit). Я разрабатываю этот пакет и опишу его
позднее в этом разделе. TSK распространяется бесплатно; это означает, что лю-
любой читатель может воспроизвести приведенные примеры без каких-либо допол-
дополнительных затрат.
Я не собираюсь превращать книгу в руководство по TSK, и не каждому читате-
читателю потребуются бесплатные программы на платформе UNIX. По этой причине
я привожу список самых распространенных программ анализа. Они позволят
решить большинство задач, упоминавшихся в этой главе. Краткие описания не
содержат полного списка возможностей программ и основываются на информа-
информации, размещенной на сайтах. Я лично не проверял и не пытался использовать все
их возможности, однако каждое описание было проверено разработчиками соот-
соответствующей программы.
Если вас интересует более обширный список программ, обратитесь на сайт
Кристин Сидсма (Christine Siedsma) Electronic Evidence Information (http://
www.e-evidence.info) или на сайт Якко Тунниссена (Jacco Tunnissen) Computer
Forensics, Cybercrime and Steganography (http://www.forensics.nl). Я также веду
список программ анализа с открытыми исходными кодами — как коммерчес-
коммерческих, так и некоммерческих (http://www.opensourceforensics.org). В книге приво-
приводятся теоретические обоснования того, как программы используются при ана-
анализе файловой системы, но мне кажется, что программы с открытым кодом также
пригодятся в расследовании: эксперт или доверенная сторона может прочитать
исходный код и проверить, как в программе реализована теория. Это позволит
экспертам дать более обоснованные показания относительно цифровых улик
[Carrier, 2003b].
EnCase (Guidance Software)
Несмотря на отсутствие официальных цифр, считается, что EnCase (http://www.en-
case.com) является самой распространенной программой компьютерных расследо-
расследований. EnCase работает на платформе Windows и позволяет снимать и анализи-
анализировать данные с применением локальной или сетевой версии. EnCase анализирует
различные форматы файловых систем, включая FAT, NTFS, HFS, UFS, Ext2/3,
Reiser, JFS, CD-ROM и DVD. Кроме того, EnCase поддерживает динамические
диски Microsoft Windows и AIX LVM.
EnCase выводит списки файлов и каталогов, восстанавливает удаленные фай-
файлы, проводит поиск по ключевым словам, просматривает всю графику, составляет
временные диаграммы файловых операций и идентифицирует файлы по базам
данных хеш-кодов. В пакете также реализован собственный сценарный язык EnScript,
который позволяет автоматизировать многие задачи. Дополнительные модули
обеспечивают расшифровку шифрованных файлов NTFS и монтирование анали-
анализируемых данных как локального диска.

Forensic Toolkit (Access Data)
Пакет FTK (Torensic Toolkit) работает на платформе Windows. К его функциям
относятся снятие данных и анализ дисков, файловых систем и прикладных дан-
данных (http://www.accessdata.com). FTK поддерживает файловые системы FAT, NTFS
и Ext2/3, но пакет более всего известен своими возможностями поиска и поддер-
поддержкой анализа прикладного уровня. FTK строит отсортированный индекс слов
в файловой системе, существенно ускоряющий поиск. Кроме того, FTK содержит
множество программ просмотра различных файловых форматов и поддерживает
разные форматы электронной почты.
FTK позволяет просматривать файлы и каталоги файловой системы, восста-
восстанавливать удаленные файлы, проводить поиск по ключевым словам и различным
характеристикам файлов, просматривать все графические файлы и идентифици-
идентифицировать известные файлы по базам данных хеш-кодов. Компания AccessData так-
также предлагает программы дешифрования файлов и восстановления паролей.
ProDiscover (Technology Pathways)
ProDiscover (http://www.techpathways.com) работает на платформе Windows. Эта
программа снятия данных и анализа существует как в локальной, так и в сетевой
версиях. ProDiscover умеет анализировать файловые системы FAT, NTFS, Ext2/
3 и UFS, а также динамические диски Windows. В области поиска реализованы
основные функции составления списков файлов и каталогов, восстановления уда-
удаленных файлов, поиска по ключевым словам и идентификации файлов по базам
данных хеш-кодов. Возможен вариант приобретения лицензии ProDiscover с ис-
исходными кодами, чтобы аналитик мог проверить принципы работы программы.
SMART (ASR Data)
SMART (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 (http://www.sl.euth-
kit.org). Инструментарий файловой системы TSK создавался на базе пакета ТСТ
(The Coroner's Tookit), авторами которого были Дэн Фармер (Dan Farmer) и Вит-
це Венема (Wietse Venema). TSK и Autopsy анализируют файловые системы
FAT, NTFS, Ext2/3 и UFS, выводят списки файлов и каталогов, восстанавливают

удаленные файлы, строят временные диаграммы файловых операций, выполня-
выполняют поиск по ключевым словам и работают с базами данных хеш-кодов.
Итоги
Не существует единственно верного подхода к проведению расследования. В этой
главе я кратко охарактеризовал тот подход, который я использую в своей работе.
Он состоит всего из трех фаз и базируется на процедуре анализа места физичес-
физического преступления. Также были представлены основные типы расследования
и приведена сводка существующих пакетов.
В следующих двух главах рассматриваются основные принципы работы ком-
компьютеров и способы снятия данных в фазе сохранения.
Библиография
• 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 Cyber-
Cybercrime Cases». Santa Clara Computer and High Technology Law Journal, 21A), 2004.
• Carrier, Brian. «Defining Digital Forensic Examination and Analysis Tools Using
Abstraction Layers». InternationalJournal ofDigital Evidence, Winter 2003a. http:/
/www.ijde.org.
• Carrier, Brian. «Open Source Digital Forensic Tools: The Legal Argument». Fall
2003b. http://www.digital-evidence.org.
• Carrier, Brian, and Eugene H. Spafford. «Getting Physical with the Digital Investi-
Investigation Process». International Journal of Digital Evidence, Fall 2003. http://
www.ijde.org.
• Casey, Eoghan. Digital Evidence and Computer Clime. 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, 1B), 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. Emeryville: McGraw Hill/Osborne, 2003.
• Scheier, Bruce. Applied Cryptography. 2nd ed. New York: Wiley Publishing, 1995.

Основные принципы
работы компьютеров
Данная глава посвящена низкоуровневым основам работы компьютеров. О том,
как организуется хранение данных, достаточно подробно рассказано в следую-
следующих главах, а здесь приводится вводный курс для читателей, не обладающих опы-
опытом программирования и познаниями в архитектуре операционных систем. Глава
начинается с обсуждения данных и способов их хранения на диске. В частности,
будут рассмотрены двоичное и шестнадцатеричное представление, а также пря-
прямой и обратный порядок байтов. Затем мы перейдем к процессу начальной заг-
загрузки системы и системному коду, необходимому для запуска компьютера. В конце
главы речь пойдет о жестких дисках, их геометрии, командах АТА, защищенных
областях и технологии SCSI.
Организация данных
Устройства, анализом которых мы собираемся заниматься, предназначены для
хранения цифровых данных, поэтому в этом разделе будут рассмотрены основ-
основные концепции хранения данных: двоичная и шестнадцатеричная запись, разме-
размеры данных, порядок байтов и структуры данных. Без хорошего понимания этих
концепций невозможно понять, как организуется хранение данных. Даже если
ранее вы уже занимались программированием, этот материал напомнит уже изве-
известные факты.
Двоичная, десятичная и шестнадцатеричная запись
Начнем с систем счисления. Люди привыкли работать с десятичными числами,
но компьютеры работают с двоичными данными, состоящими из нулей и единиц.
Каждая двоичная цифра (ноль или единица) называется битом; группа из 8 битов
называется байтом. Двоичные числа аналогичны десятичным, если не считать того,
что в десятичных числах используются 10 разных цифр (от 0 до 9), а в двоич-
двоичных — только две.
Прежде чем подробно заниматься двоичными числами, необходимо понять,
что такое десятичное число. Десятичное число представляет собой серию симво-
символов (цифр), при этом каждая цифра обладает некоторым значением. Для крайней
правой цифры это значение равно 1, для цифры слева от нее — 10 и т. д. Каждая
цифра обладает весовым значением, в 10 раз превышающим значение предыду-
предыдущего разряда: для второй цифры справа это значение равно 10, для третьей — 100,
для четвертой — 1000 и т. д. Для примера возьмем десятичное число 35 812. Чтобы

получить его, следует умножить цифру в каждом разряде на значение этого раз-
разряда и сложить произведения (рис. 2.1). Поскольку в данном случае десятичная
запись числа преобразуется в его десятичное значение, результат вполне законо-
закономерен. Аналогичная процедура применяется и для вычисления десятичного зна-
значения чисел, записанных в других системах счисления.
Рис. 2.1. Значение каждой цифры в десятичном числе
Крайняя правая цифра называется младшей, а крайняя левая — старшей. Так,
для числа 35 812 цифра 3 является старшей, а цифра 2 — младшей.
Теперь перейдем к двоичным числам. В каждом разряде двоичного числа на-
находится только одна из двух цифр @ и 1); при этом каждый разряд обладает деся-
десятичным значением, вдвое превышающим значение предыдущего разряда. Таким
образом, крайний правый разряд соответствует десятичному значению 1, второй
разряд справа — десятичному значению 2, третий — 4 и четвертый — 8 и т. д. Что-
Чтобы вычислить десятичное представление двоичного числа, следует просуммиро-
просуммировать весовые значения столбцов, умноженные на находящиеся в них цифры. На
рис. 2.2 показано, как двоичное число 1001 0011 переводится в десятичную систе-
систему. Из результата видно, что его десятичное значение равно 147.
В табл. 2.1 приведены десятичные значения первых 16 двоичных чисел. В ней
также указаны их шестнадцатеричные эквиваленты, о которых речь пойдет далее.
Рис. 2.2. Преобразование двоичного числа в десятичное значение
Таблица 2.1. Преобразования между двоичной, десятичной
и шестнадцатеричной системами
Двоичная запись Десятичная запись Шестнадцатеричная запись
0000 00 0
0001 01 1
0010 02 2
ООП 03 3
0100 04 4
0101 05 5

Таблица 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, за
которыми следуют буквы от А до F). В табл. 2.1 показано соответствие между
шестнадцатеричными цифрами и десятичными числами. Шестнадцатеричная за-
запись удобна прежде всего тем, что она легко преобразуется в двоичную (и наобо-
наоборот), и часто применяется при работе с низкоуровневыми данными. Я буду снаб-
снабжать шестнадцатеричные числа префиксом Ох, чтобы отличить их от десятичных.
Необходимость в преобразовании шестнадцатеричных чисел в десятичную за-
запись возникает довольно редко, но я все же покажу, как это делается. Десятич-
Десятичные весовые коэффициенты разрядов шестнадцатеричного числа увеличивают-
увеличиваются в 16 раз. Таким образом, десятичное значение первого (крайнего правого)
разряда равно 1, второго — 16, третьего — 256 и т. д. Чтобы выполнить преобразо-
преобразование, мы просто умножаем весовые коэффициенты разрядов на соответствую-
соответствующие цифры и суммируем результаты. На рис. 2.3 показан результат преобразова-
преобразования шестнадцатеричного числа 0х8ВЕ4 в десятичную систему.
Рис. 2.3. Преобразование шестнадцатеричного числа в десятичную систему
Остается рассмотреть преобразования между шестнадцатеричной и двоичной
записью. Такие преобразования выполняются гораздо проще и сводятся к простой
подстановке. Чтобы получить двоичное представление имеющегося шестнадца-
шестнадцатеричного числа, достаточно обратиться к табл. 2.1 и заменить каждую шестнад-
цатеричную цифру эквивалентной последовательностью из 4 битов. И наоборот,
при преобразовании двоичного числа в шестнадцатеричное следует разделить чис-
число на группы по 4 бита и заменить каждую «четверку» эквивалентной шестнадца-
шестнадцатеричной цифрой. Вот и все! Преобразование двоичного числа в шестнадцате-
шестнадцатеричное и наоборот показано на рис. 2.4.
Иногда требуется определить максимальное значение, которое может быть
представлено некоторым количеством разрядов. Для этого нужно возвести коли-

чество допустимых цифр в степень, равную числу разрядов, и вычесть 1 (чтобы
учесть нулевое значение). Например, для двоичных чисел мы возводим 2 в сте-
степень, равную количеству битов, и вычитаем 1. Следовательно, наибольшее десятич-
десятичное число, которое может быть представлено 32-разрядной двоичной последова-
последовательностью:
232 - 1 = 4 294 967 295
К счастью, в большинстве системных редакторов имеется встроенный кальку-
калькулятор с возможностью преобразования между двоичной, десятичной и шестнадца-
теричной записью, поэтому запоминать все эти методы вам не придется. В книге
дисковые данные приводятся в шестнадцатеричной записи; важнейшие значения
будут приводиться как в шестнадцатеричной, так и в десятичной записи.
Рис. 2.4. Преобразование между двоичной и шестнадцатеричной записью осуществляется
простой заменой по табл. 2.1
Размеры данных
Для сохранения цифровых данных на носителе информации выделяется область
соответствующего размера. Представьте анкету, в которой символы вашего име-
имени и адреса вводятся в отдельных квадратиках: поля имени и адреса выделяются
для хранения вводимых символов. Аналогичным образом при работе с цифровы-
цифровыми данными участок диска или памяти выделяется для хранения байтов с конк-
конкретными значениями.
В общем случае байт представляет собой наименьшую область памяти, выде-
выделяемую для хранения данных. Байт позволяет представить до 256 возможных зна-
значений, поэтому для хранения больших чисел байты приходится группировать. Как
правило, на практике используются группы размером 2, 4 и 8 байт. Конкретный
способ хранения многобайтовых данных зависит от компьютера. На одних ком-
компьютерах применяется обратный порядок байтов (big-endian), при котором в пер-
первом байте на носителе хранится старший (наиболее значимый) байт хранимого
числа, а на других — прямой порядок байтов (little-endian), при котором в первом
байте хранится младший (наименее значимый) байт. Напомню, что старшим на-
называется байт с наибольшим весовым коэффициентом (крайний левый байт),
а младшим — байт с наименьшим весовым коэффициентом (крайний правый
байт).
На рис. 2.5 изображено 4-байтовое значение с прямым и обратным порядком
байтов. Для его хранения выделяется 4-байтовый блок, начинающийся с байта 80
и заканчивающийся байтом 83. При анализе содержимого диска и файловой сис-
системы необходимо учитывать порядок байтов исходной системы, в противном слу-
случае вычисленное значение окажется неверным.

В системах на базе IA32 (например, Intel Pentium) и их 64-разрядных аналогах
используется прямой порядок байтов, поэтому, если мы хотим, чтобы старший
байт оказался в крайней левой позиции, байты необходимо «переставить». На Sun
SPARC и Motorola PowerPC (например, на компьютерах Apple) применяется об-
обратный порядок байтов.
Рис. 2.5. 4-байтовое значение с прямым и обратным порядком байтов
Строковые данные и кодировка символов
В предыдущем разделе рассказывалось о том, как на компьютерах хранятся чис-
числовые данные, но мы также должны подумать о хранении строковых данных, то
есть отдельных символов и целых предложений. На практике для хранения сим-
символьных данных чаще всего применяется кодировка ASCII или Unicode. Коди-
Кодировка ASCII проще, поэтому начнем с нее. В ASCII каждый символ английского
языка обозначается числовым кодом. Например, букве А соответствует код 0x41,
а символу & — код 0x26. Наибольшее определенное значение равно 0х7Е; таким
образом, любой символ базового набора представляется одним байтом. Многие
коды соответствуют управляющим символам и не имеют печатного представле-
представления — например, звуковой сигнал 0x07. В табл. 2.2 приведены соответствия меж-
между шестнадцатеричными числами и символами ASCII. Более подробная таблица
ASCII-кодов приводится по адресу: http://www.asciitable.com/.
Таблица 2.2. Шестнадцатеричные коды символов в ASCII
OO-NULL 1—DLE 20-SPC 30-0 40-@ 50-Р 60-* 70—р
01-SOH 11-DCI 21-! 31-1 41-А 51-Q 61-a 71-q
02-STX 12-DC2 22-" 32-2 42-В 52-R 62-Ь 72-г
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-E 55-U 65-е 75-и
Об-АСК 16-SYN 2б-& Зб-б 46-F 56-У 66-f 76-v
07-BEL 17-ETB 27-' 37-7 47-G 57-W 67-g 77-w
08-BS 18-CAN 28-( 38-8 48-H 58-X 68-h 78-x ~~
09-TAB 19-EM 29-) 39-9 49-1 59-Y 69-i 79-y
OA-LF 1A-SUB 2A-* 3A-: 4A-J 5A-Z 6A-j 7/^z

QB-BT 1B-ESC 2B-+ 3B-; 4B-K 5B-[ 6B-k 7B-{
OC-FF 1C-FS 2C-, 3O< 4C-L 5C-\ 6C-I 7C-|
QD-CR 1D-GS 2D-- 3D-= 4D-M 5D-] 6D-m 7D-}
QE-SO 1E-RS 2E-. 3E-> 4E-N 5E-A 6E-n 7E-~
QF-SI 1F-US 2F-/ 3F-? 4F-0 5F-_ 6F-0 7F-
Чтобы сохранить предложение или слово в кодировке ASCII, необходимо вы-
выделить под него область памяти, размер которой в байтах соответствует количе-
количеству символов в слове. В каждом байте хранится код одного символа. Порядок
байтов в этом случае роли не играет, потому что каждый символ представлен
отдельным 1-байтовым кодом. Таким образом, первый символ слова или пред-
предложения всегда находится на первом месте. Последовательность байтов в слове
или предложении называется строкой (string). Строки часто завершаются нуль-
символом (NULL), соответствующим коду 0x00. На рис. 2.6 показан пример стро-
строки, хранящейся в кодировке ASCII. Строка состоит из 10 символов и заверша-
завершается нуль-символом, поэтому для ее хранения выделяется 11 байт, начиная
с байта 64.
Рис. 2.6. ASCII-строка, хранящаяся в памяти, начиная с адреса 64
Кодировка ASCII проста и удобна, если ваши потребности ограничиваются
английским алфавитом. Однако для пользователей из других стран мира ее явно
недостаточно, поскольку ASCII не позволяет представлять символы национальных
алфавитов. Для решения этой проблемы была создана кодировка Unicode, в кото-
которой числовой код символа занимает более 1 байта (за подробностями обращай-
обращайтесь на сайт www.unicode.org). Версия 4.0 стандарта Unicode поддерживает более
96 000 символов, при этом для представления одного символа необходимы 4 бай-
байта (вместо 1 байта в ASCII).
Существует три варианта хранения символов Unicode. В первом варианте —
UTF-32 — каждый символ представляется 4 байтами, но при этом большая часть
памяти будет расходоваться неэффективно. Во втором варианте, UTF-16, часто
используемые символы хранятся в 2-байтовых кодах, а более редкие — в 4-байто-
4-байтовых, поэтому в среднем текст занимает меньший объем, чем в UTF-32. Третий
вариант называется UTF-8, и один символ в нем представляется 1, 2 или 4 байта-
байтами. При этом наиболее часто используемые символы кодируются всего 1 байтом.
Переменная длина кода в UTF-8 и UTF-16 несколько усложняет обработку
данных. На практике чаще используется UTF-8, поскольку в этой кодировке мень-
меньше места расходуется напрасно, a ASCII является ее подмножеством. Если строка
UTF-8 состоит только из ASCII-символов, каждый символ в ней кодируется 1 бай-
байтом, а по своему содержимому такая строка совпадает с эквивалентной ASCII-
строкой.

Структуры данных
Прежде чем переходить к особенностям хранения данных в конкретных файловых
системах, необходимо познакомиться с общими принципами организации дан-
данных. Вернемся к предыдущему примеру, в котором проводилась аналогия между
цифровыми данными и квадратиками на бумажной анкете. Когда вы заполняете
анкету, надпись перед полем указывает, что данное поле предназначено для ввода
имени или адреса. Как правило, компьютеры не снабжают данные файловых сис-
систем подобными метками. Вместо этого они просто знают, что в первых 32 байтах
записи хранится (к примеру) имя, а в следующих 32 байтах — название улицы.
Способ размещения данных в памяти определяется структурами данных. Струк-
Структура данных напоминает шаблон или карту. Она делится на поля, при этом каждое
поле обладает определенным размером и именем (хотя эта служебная информа-
информация не хранится вместе с данными). Например, структура данных может опреде-
определить, что первое поле называется number и имеет длину в 2 байта. В программе это
поле будет использоваться для хранения номера дома в адресе. Сразу же за полем
number следует поле street, длина которого равна 30 байтам. Соответствующая
структура данных показана в табл. 2.3.
Таблица 2.3. Простая структура данных для хранения номера дома и названия улицы
Диапазон байтов Описание
0-1 Номер дома B байта)
2-31 Название улицы в кодировке ASCII C0 байт)
Когда данные требуется записать на носитель информации, область памяти
для каждого компонента записи определяется по соответствующей структуре дан-
данных. Например, если требуется сохранить адрес 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. Символами «.» обозначается отсутствие

печатных ASCII-символов в данной позиции. Вспомните, что каждый 16-разряд-
16-разрядный символ представляет 5 бита, поэтому на один байт требуется 2 шестнадцате-
ричных символа.
Просматривая раскладку структуры данных, мы видим, что каждый адрес зани-
занимает 32 байта, поэтому первый адрес хранится в байтах 0-31. Байты 0-1 предназна-
предназначены для хранения 2-байтового номера дома, а байты 2-31 — для названия улицы.
В байтах 0-1 отображается значение 0x0100. Данные взяты из системы Intel, ис-
использующей прямой порядок байтов, поэтому 0x01 и 0x00 необходимо поменять
местами — получаем 0x0001. Преобразование к десятичному виду дает число 1.
Второе поле структуры данных занимает байты 2-31. Содержащаяся в нем
ASCII-строка не зависит от порядка байтов в системе, поэтому переставлять дан-
данные не придется. Мы можем либо преобразовать каждый байт в ASCII-эквива-
ASCII-эквивалент, либо схитрить и сразу заглянуть в нужные столбцы, чтобы найти в них на-
название «Main St.». Именно это значение было записано ранее. Из приведенного
вывода следует, что другая структура данных начинается с байта 32 и продолжа-
продолжается до байта 63. Попробуйте самостоятельно обработать ее для практики (она
соответствует адресу «25 South St.»).
Разумеется, в структурах данных файловых систем хранится совершенно иная
информация, но базовые принципы остаются прежними. Например, в первом
секторе файловой системы обычно хранится большая структура данных с десят-
десятками полей; читая ее, мы знаем, что размер файловой системы хранится в байтах
32-35. Во многих файловых системах задействовано несколько больших струк-
структур данных, используемых в разных местах.
Флаги
Прежде чем переходить к реальным структурам данных, я хотел бы обсудить еще
один тип данных — флаги. Некоторые данные всего лишь показывают, выполняет-
выполняется или не выполняется некоторое условие: скажем, является ли раздел загрузоч-
загрузочным или нет. Значения таких данных представляются одной двоичной цифрой
A или 0). Конечно, для этой информации можно выделить целый байт, в котором
сохраняется значение 0 или 1. Однако такой способ крайне неэффективен: из 8 вы-
выделенных битов реально используется всего один. Более эффективный способ
основан на упаковке нескольких двоичных условий в одно значение, каждый бит
которого соответствует некоторому признаку или условию. Такие биты часто на-
называются флагами (flags). Чтобы получить значение флага, необходимо преобра-
преобразовать число в двоичную форму и проанализировать нужный бит. Если бит ра-
равен 1, значит, флаг установлен.
Давайте рассмотрим практический пример и преобразуем структуру данных
с почтовым адресом в нечто более сложное. Исходная структура содержала два
поля данных: для номера дома и названия улицы. В новой версии в нее добавля-
добавляется необязательное 16-байтовое название города, следующее за названием ули-
улицы. Так как имя города не является обязательным, необходимо добавить флаг,
указывающий на его наличие или отсутствие. Флаг хранится в байте 31; если за-
запись содержит название города, бит 0 устанавливается (то есть 0000 0001). Если
название города присутствует, структура данных содержит 48 байт вместо 32.
Новая структура данных приведена в табл. 2.4.

Таблица 2.4. Структура данных со значением флага
Диапазон байтов Описание
0-1 Номер дома B байта)
2-30 Название улицы в кодировке ASCII B9 байт)
31-31 Флаги
32-47 Название города в кодировке ASCII A6 байт) — если флаг установлен
Пример данных, записанных на диск с использованием этой структуры:
00000000: 0100 4d61 69бе 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. Сам по
себе процессор не приносит особой пользы, потому что он умеет только выпол-
выполнять полученные команды. В этом отношении он напоминает калькулятор. Как

известно, калькулятор отлично справляется с вычислениями, но при этом за ним
должен сидеть человек и вводить числа.
Процессор получает команды из памяти. Команды процессора представляют
собой машинный код, неудобный и плохо воспринимаемый человеком. Как пра-
правило, машинный код находится на два уровня ниже языков программирования
С и Perl, хорошо знакомых многим программистам. Промежуточное место зани-
занимает язык ассемблера, понятный для человека, но не слишком удобный.
Я кратко опишу структуру машинного кода, чтобы вы знали, с чем имеете дело,
обнаружив его на диске. Каждая команда машинного кода состоит из нескольких
байтов. Первая пара байтов определяет тип команды, называемый кодом опера-
операции (opcode). Например, значение 3 может обозначать операцию сложения. За
кодом операции следуют аргументы команды — скажем, аргументы команды сло-
сложения определяют два суммируемых числа.
Для данной книги более подробного описания не потребуется, но я приведу
простейший пример. Одна из машинных команд заносит числа в регистры про-
процессора. Регистрами называются ячейки, в которых процессор хранит обрабаты-
обрабатываемые данные. Ассемблерная команда MOV АН,00 заносит значение 0 в регистр
АН. Эквивалентная команда машинного кода в шестнадцатеричном виде имеет
0хВ400, где В4 — код операции MOV АН, а 00 — шестнадцатеричное число, помеща-
помещаемое в регистр. Некоторые утилиты автоматически транслируют машинный код
на ассемблер, но во многих случаях неочевидно, имеете ли вы дело с машинным
кодом или какими-то произвольными данными.
Местонахождение загрузочного кода
Итак, центральный процессор является «сердцем» компьютера, и для работы ему
необходимо передавать команды. Следовательно, для запуска компьютера некое
устройство должно поставлять процессору команды, называемые загрузочным
кодом. В большинстве систем этот процесс состоит из двух этапов: на первом эта-
этапе происходит инициализация оборудования, а на втором запускается опера-
операционная система или иное программное обеспечение. Мы кратко познакомимся
с загрузочным кодом, потому что во всех томах и файловых системах имеется спе-
специальная область для хранения загрузочного кода, причем она зачастую не ис-
используется.
При включении питания компьютер способен только прочитать команды из
специальной области памяти, как правило — из постоянной (ПЗУ). Код ПЗУ за-
заставляет систему провести проверку и настройку оборудования. После завершения
настройки процессор переходит к поиску устройства, которое может содержать
дополнительный загрузочный код. Если такое устройство найдено, то управле-
управление передается его загрузочному коду, а последний пытается найти и загрузить
операционную систему. Процесс загрузки после обнаружения загрузочного дис-
диска зависит от конкретной платформы, и более подробно рассматривается в следу-
следующих главах.
А пока для примера мы в общих чертах рассмотрим процесс загрузки системы
Microsoft Windows. При включении питания процессор читает команды из BIOS
(Basic Input/Output System) и ищет жесткие диски, дисководы CD-ROM и дру-
другие устройства, поддержка которых настроена в BIOS. После идентификации

оборудования BIOS анализирует флоппи-диски, жесткие диски и дисководы CD-
ROM в некотором заданном порядке и обращается к первому сектору за загру-
загрузочным кодом. Код первого сектора загрузочного диска заставляет процессор об-
обработать таблицу разделов и найти загрузочный раздел, в котором находится
операционная система Windows. В первом секторе раздела размещается допол-
дополнительный загрузочный код, обеспечивающий поиск и загрузку операционной
системы. На рис. 2.7 изображено взаимодействие различных компонентов в про-
процессе загрузки.
Рис. 2.7. Взаимодействие компонентов загрузочного кода в системах IA32
Если загрузочный код на диске отсутствует, BIOS не находит загрузочное ус-
устройство и выдает сообщение об ошибке. Если загрузочный код на диске не мо-
может найти загрузочный код в одном из своих разделов, он также выдает сообще-
сообщение об ошибке. Все эти компоненты загрузочного кода будут описаны в следующих
главах.
Технологии жестких дисков
В этом разделе рассматриваются основные концепции жестких дисков и различ-
различные темы, представляющие интерес с аналитической точки зрения: методы дос-
доступа, блокировка записи и возможные места хранения скрытых данных. В первом
подразделе содержится краткий обзор принципов работы диска, а два следующих
подраздела посвящены дискам AT A/IDE и SCSI соответственно.
Геометрия и внутреннее устройство жесткого диска
Начнем с внутреннего строения всех современных жестких дисков. Эта инфор-
информация полезна для понимания общих принципов хранения данных, поскольку ста-
старые файловые системы и схемы формирования разделов используют параметры
геометрии диска и другие внутренние данные, скрытые в современных дисках.

Таким образом, знание геометрии диска поможет лучше понять смысл некоторых
данных в файловой системе. Конечно, я привожу этот материал не для того, что-
чтобы вы могли самостоятельно ремонтировать жесткие диски. Моя задача — дать
концептуальное понимание их внутреннего устройства.
Жесткий диск состоит из одной или нескольких круглых пластин, располо-
расположенных друг над другом и вращающихся одновременно. На рис. 2.8 показано, как
выглядит жесткий диск изнутри. Верхняя и нижняя поверхности каждой пласти-
пластины покрыты магнитным материалом. Непосредственно после изготовления дис-
диска пластины однородны и пусты.
Рис. 2.8. Внутреннее устройство диска АТА: справа находятся пластины, а слева — рычаг
с магнитной головкой, осуществляющей чтение и запись
Внутри корпуса находится подвижный рычаг. На нем крепятся головки чте-
чтения и записи данных, находящиеся у верхней и нижней поверхностей каждой пла-
пластины. В любой момент времени только одна головка может выполнять чтение
или запись данных.
Пустые пластины размечаются операцией низкоуровневого форматирования,
создающей структуры данных дорожек и секторов. Каждая дорожка (track) пред-
представляет собой замкнутое «кольцо», проходящее по поверхности пластины. Ад-
Адреса, присваиваемые дорожкам жесткого диска, увеличиваются по направлению
от края к центру. Например, если на каждой пластине размещается по 10 000 до-
дорожек, то внешней дорожке каждой пластины присваивается адрес 0, а внутрен-
внутренней дорожке (возле центра круга) — адрес 9 999. Так как все пластины имеют
одинаковое строение, а находящимся на них дорожкам присваиваются одинако-
одинаковые адреса, совокупность всех дорожек с заданным адресом на всех пластинах
называется цилиндром. Так, цилиндр 0 состоит из дорожек 0 от нижней до верх-
верхней пластины жесткого диска. Головкам чтения/записи также присваиваются ад-
адреса, что позволяет однозначно определить, на какой пластине и с какой стороны
должна быть выполнена операция чтения или записи.
Дорожки делятся на секторы — наименьшие самостоятельно адресуемые блоки
жесткого диска, размер которых обычно составляет 512 байт. Каждому сектору
дорожки присваивается адрес, начиная с 1. Таким образом, к конкретному сектору

можно обратиться по адресу цилиндра (С), определяющему дорожку, адресу го-
головки (Н), определяющему пластину и ее поверхность, и адресу сектора (S). Схе-
Схема обращения продемонстрирована на рис. 2.9.
Рис. 2.9. Геометрия отдельной пластины с адресами дорожек (цилиндров) и секторов;
цифры не имеют даже отдаленного отношения к реальности
Как будет показано в разделе «Типы адресации секторов», схема CHS уже не
является основной схемой адресации. Вместо нее используется адресация LBA
(Logical Block Address), при которой всем секторам присваиваются последователь-
последовательные адреса. Адрес LBA никак не связан с физическим расположением сектора.
Поврежденные секторы не могут использоваться для хранения пользователь-
пользовательских данных. Раньше операционная система должна была знать о наличии по-
поврежденных секторов и не выделять их для хранения файлов. Пользователь так-
также мог вручную указать диску, какие секторы необходимо игнорировать из-за
наличия повреждений. Многие файловые системы до сих пор предоставляют воз-
возможность пометки поврежденных секторов. Впрочем, в наше время это обычно
излишне, поскольку современные диски сами выявляют плохие секторы и ото-
отображают их адреса на работоспособные секторы в другом месте диска. Пользова-
Пользователь даже не подозревает о происходящем.
Предыдущее описание геометрии диска излишне упрощено: в действительности
диски упорядочивают секторы для обеспечения оптимального быстродействия.
Это означает, что к секторам и дорожкам может применяться сдвиг, соответству-
соответствующий времени поиска и скорости диска. Впрочем, для большинства аналитиков
упрощенного описания достаточно; мало кто имеет доступ к технологически чис-
чистым помещениям и оборудованию для поиска секторов на диске.
Интерфейс ATA/IDE
Интерфейс ATA (AT Attachment) является самым распространенным интерфей-
интерфейсом жестких дисков. Диски, использующие этот интерфейс, часто называются
дисками IDE, но сокращение IDE означает «Integrated Disk Electronics» и обо-
обозначает жесткий диск со встроенной логической схемой (чего не было в старых

дисках). Интерфейс, используемый дисками «IDE», называется АТА. В этом раз-
разделе приводятся некоторые важные детали спецификации АТА, чтобы позднее
мы могли обсудить такие технологии, как аппаратная блокировка записи и защи-
защищенные области.
Спецификации АТА разрабатывались техническим комитетом Т13 (http://
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), хотя ни один из дисков не управляет работой другого. Диски

ATA настраиваются на выполнение роли ведущего или ведомого при помощи фи-
физической перемычки на диске. Некоторые диски также поддерживают режим Cable
Select, в котором роль ведущего или ведомого назначается в зависимости от того,
к какому разъему плоского кабеля подключен диск. На большинстве бытовых ком-
компьютеров используются два канала и поддержка до четырех дисков AT А.
Типы адресации секторов
Для выполнения операций чтения и записи данных на диск необходима схема
адресации секторов. Как будет показано далее, одному сектору назначаются раз-
разные адреса при каждом его использовании разделом, файловой системой или фай-
файлом. В этом разделе речь пойдет о физических адресах, то есть адресах секторов по
отношению к началу физического носителя информации.
Существует два разных метода физической адресации. На старых жестких дис-
дисках используются геометрические параметры и уже упоминавшаяся схема CHS.
Упрощенный пример организации адресов цилиндров и головок показан на рис. 2.9.
Схема адресации CHS проста и удобна, но ее возможности оказались слишком
ограниченными, поэтому в наши дни она встречается редко. В исходной специ-
спецификации AT А задействован 16-разрядный номер цилиндра, 4-разрядный номер
головки и 8-разрядный номер сектора, однако в старых версиях BIOS использо-
использовался 10-разрядный номер цилиндра, 8-разрядный номер головки и 6-разрядный
номер сектора. Следовательно, для взаимодействия с жестким диском через BIOS
должен использоваться минимальный размер каждого параметра, вследствие чего
максимальный объем диска ограничивается 504 Мбайт.
Чтобы обойти это ограничение, были разработаны новые версии BIOS, транс-
транслировавшие «свои» диапазоны адресов в диапазоны адресов, соответствующие
спецификации AT А. Например, если приложение запрашивало данные из цилин-
цилиндра 8, головки 4 и сектора 32, система BIOS транслировала его и запрашивала
с диска цилиндр 26, головку 2, сектор 32. Для успешной работы трансляции сис-
система BIOS сообщала параметры геометрии диска, отличающиеся от фактических.
Процесс трансляции не работает для дисков объемом более 8,1 Гбайт.
Сейчас BIOS с трансляцией адресов встречаются относительно редко, однако
если аналитик все же столкнется с такой системой, у него возникнут проблемы.
Если извлечь диск из исходной системы и подключить его к тестовому компьюте-
компьютеру, может оказаться, что трансляция не поддерживается или работает иначе. К тому
же некоторые методы анализа выполнить не удастся из-за возврата неверных сек-
секторов. Для решения проблемы аналитик должен использовать исходную систему
или найти аналогичную систему, выполняющую ту же трансляцию. Информа-
Информацию о том, используется ли в системе трансляция адресов, можно найти в описа-
описании версии BIOS на сайте производителя или в справочном описании BIOS.
Ограничение в 8,1 Гбайт, присущее трансляции, необходимо было преодолеть,
поэтому от схемы адресации CHS пришлось отказаться. Стандартной стала схема
адресации LBA (Logical Block Addresses), в которой каждый сектор обозначается
одним числом, начиная с 0. Схема LBA поддерживается с момента выхода первой
официальной спецификации AT А. В схеме LBA приложение не обязано ничего
знать о геометрии диска; достаточно одного числа. Поддержка адресации CHS
была исключена из спецификации АТА в версии АТА-6.

К сожалению, некоторые файловые системы и другие структуры данных про-
продолжают работать со старыми адресами 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 - ((B * 16) + 3) * 63) + 4 - 1
Стандарты интерфейсов
В области жестких дисков встречаются многочисленные названия интерфей-
интерфейсов, способные запутать потребителя. Некоторые термины означают одно и то
же; просто комитет стандартизации выбрал один термин, а компания, выпус-
выпустившая жесткий диск, — другой. Описания неофициальных терминов вроде
«Enhanced IDE» или «Ultra ATA» приводятся на странице PC Guide «Unofficial
IDE/ATA Standards and Marketing Programs» (http://www.pcguide.com/ref/hdd/if/
ide/unstd.htm). Как правило, каждый новый стандарт обеспечивает более быст-
быстрый метод чтения или записи данных либо снимает ограничения предыдущего
стандарта.
Учтите, что спецификации АТА относятся только к жестким диска. Съемные
носители информации (такие, как CD-ROM и ZIP-диски) должны использо-
использовать особую спецификацию ATAPI (AT Attachment Packet Interface). Устрой-
Устройства AT API обычно подключаются к тем же кабелям и контроллерам, но для их
работы необходимы специальные драйверы.
Краткий перечень спецификаций, представляющих интерес для нашей темы:
• АТА-1: опубликована в 1994 году. Спецификация включает поддержку CHS
и 28-разрядных адресов LBA [T13 1994].
• АТА-3: спецификация опубликована в 1997 году, в нее были включены средства
контроля надежности pi безопасности. В частности, в АТА-3 была представле-
представлена технология SMART (Self-Monitoring Analysis and Reporting Technology),
которая пытается повысить надежность работы диска посредством отслежи-
отслеживания нескольких его частей. В этой спецификации также появились пароли
[Т13 1997].
• ATA/ATAPI-4: спецификация для съемных носителей AT API была интегри-
интегрирована в спецификацию АТА в версии АТА-4, опубликованной в 1998 году.
В ней появился 80-проводный кабель для снижения помех. В АТА-4 также до-
добавилась поддержка HPA, о которой речь пойдет далее [Т13 1998].

• ATA/ATAPI-6: в обновленной спецификации, опубликованной в 2002 году,
добавилась 48-разрядная адресация LBA, исчезла поддержка адресации CHS
и добавилась поддержка DCO [T13 2002].
• ATA/ATAPI-7: на момент написания книги спецификация оставалась в пред-
предварительной версии. В нее вошла поддержка Serial ATA (см. далее).
Команды диска
В этом разделе приводится обзор взаимодействия контроллера с жестким дис-
диском, который поможет вам лучше понять аппаратную блокировку записи и защи-
защищенные области. Материал не относится к устройствам ATAPI (скажем, диско-
дисководам CD-ROM).
Контроллер передает команды жесткому диску по плоскому кабелю. Команда
может быть принята обоими дисками, подключенными к кабелю, но одна из час-
частей команды указывает, для какого диска она предназначена: ведущего или ведо-
ведомого. Взаимодействие контроллера с жестким диском основано на записи данных
в регистры (небольшие ячейки памяти). После того как все необходимые данные
будут загружены в регистры, контроллер осуществит запись в регистр команд,
и жесткий диск выполнит команду (как при щелчке на кнопке Submit после за-
заполнения HTML-формы). Теоретически диск ничего не должен делать до момен-
момента записи в регистр команд.
Допустим, контроллер хочет прочитать сектор с диска. Для этого он должен
записать адрес сектора или количество читаемых секторов в соответствующие ре-
регистры. После того как необходимые данные будут записаны в регистры, контрол-
контроллер инициирует операцию чтения посредством записи в регистр команд.
Пароли жестких дисков
В спецификации АТА-3 появились новые средства защиты данных, в том числе
возможность назначения пароля в BIOS или прикладных программах. Если па-
парольная защита реализована, жесткому диску назначаются два пароля: пользова-
пользовательский и главный. Главный пароль нужен для того, чтобы администратор мог
получить доступ к компьютеру в случае утраты пользовательского пароля. При
использовании паролей диск может работать в двух режимах: повышенной и мак-
максимальной безопасности. В режиме повышенной безопасности блокировка с дис-
диска снимается как пользовательским, так и главным паролем. В режиме максималь-
максимальной безопасности пользовательский пароль может снять блокировку с диска, но
снятие блокировки главным паролем становится возможным только после стира-
стирания всего содержимого диска. После нескольких неудачных попыток ввода паро-
пароля диск «зависает», и систему приходится перезагружать.
Перед выполнением многих команд АТА должна быть выполнена команда
SECURITY_UNLOCK с правильным паролем. После ввода правильного пароля диск
работает обычным образом вплоть до отключения питания.
Выполнение некоторых команд АТА разрешено и с заблокированным жест-
жестким диском, поэтому при подключении к компьютеру диск может выглядеть впол-
вполне нормально. Однако при попытке прочитать данные с заблокированного диска
либо выдается сообщение об ошибке, либо запрашивается пароль. В Интернете
можно найти несколько бесплатных программ, которые сообщают, заблокирован

ли диск, и позволяют снять блокировку с вводом пароля. Для примера назову две
такие программы, atapwd и hdunlock К Пароль задается в BIOS или в специальном
приложении. Некоторые компании, специализирующиеся на восстановлении дан-
данных, умеют обходить пароль для открытия диска.
Область HPA
Защищенной областью HPA (Host Protected Area) называется специальная область
диска, предназначенная для сохранения данных и невидимая для постороннего
наблюдателя. Размер этой области задается командами АТА. Для большинства
дисков по умолчанию он равен 0.
Поддержка HPA появилась в АТА-4. Она предназначалась для того, чтобы про-
производитель компьютера мог сохранить данные, которые не терялись бы при фор-
форматировании жесткого диска пользователем и стирании его содержимого. HPA
находится в конце диска, а обращение к ее содержимому возможно лишь в ре-
результате изменения конфигурации жесткого диска.
Рассмотрим процесс резервирования HPA более подробно, на уровне команд
АТА. Некоторые из используемых команд существуют в двух версиях в зависимос-
зависимости от размера диска, но я буду приводить только одну версию. Первые две команды
возвращают максимальный номер адресуемого сектора; если возвращаемые значе-
значения различаются, значит, на диске существует область HPA. Команда READ_N ATIVE_
MAX_ADDRESS возвращает максимальный физический адрес, а команда IDENTIFY_DEVICE
возвращает количество секторов, доступных для пользователя. Следовательно,
при наличии HPA READ_NATIVE_MAX_ADDRESS вернет фактический конец диска,
тогда как IDENTIFY_DEVICE вернет конец пользовательской области (и начало
HPA). Обратите внимание: как будет показано в следующем разделе, команда
READ_NATIVE_MAX_ADDRESS не всегда возвращает последний физический адрес диска.
При создании HPA команда SET_MAX_ADDRESS задает максимальный адрес, до-
доступный для пользователя. Если потребуется отказаться от использования HPA,
команда SET_MAX_ADDRESS выполняется заново с фактическим максимальным раз-
размером диска, возвращаемым командой READ_NATIVE_MAX_ADDRESS.
Например, если объем диска составляет 20 Гбайт, READ_NATIVE_MAX_ADDRESS
возвращает количество секторов для 20 Гбайт (скажем, 41 943 040). Чтобы со-
создать защищенную область HPA объемом 1 Гбайт, следует выполнить команду
SET_MAX_ADDRESS с адресом 39 845 888. Любые попытки чтения или записи в послед-
последние 2 097 152 сектора A Гбайт) приводят к ошибке, а команда IDENTIFY_DEVICE воз-
возвращает максимальный адрес 39 845 888 (рис. 2.12). Чтобы снять защиту с HPA, сле-
следует снова выполнить команду SET_MAX_ADDRESS с полным количеством секторов.
Среди параметров команды SET_MAX_ADDRESS присутствует «бит устойчивос-
устойчивости». Если он установлен, то HPA продолжает существовать после сброса жестко-
жесткого диска или отключения питания. В спецификации АТА также присутствуют ко-
команды блокировки, которые запрещают модификацию максимального адреса до
следующего сброса. Это позволяет BIOS прочитать или записать данные в защи-
защищенную область при включении питания, задать размер защищенной области так,
1 Эти программы чаще всего встречаются на веб-сайтах, посвященных модификации игровых приста-
приставок — например, http//www.xbox-scene.com/tools/tools.php?page=harddrive.

чтобы данные оставались невидимыми для пользователя, и заблокировать область
для предотвращения ее изменений. При этом даже может использоваться пароль
(отличный от пароля для доступа к диску).
Рис. 2.12. Диск объемом 20 Гбайт с 1-гигабайтной защищенной областью HPA
Подведем итог: жесткий диск может содержать защищенную область HPA
с системными файлами или скрытой информацией (а возможно, и тем и другим).
Присутствие защищенной области выявляется сравнением результатов двух ко-
команд АТА. Для удаления защищенной области следует сбросить ограничение мак-
максимального пользовательского адреса жесткого диска, но бит устойчивости по-
позволяет внести временные изменения.
DCO
Помимо HPA для скрытия данных также может применяться механизм DCO
(Device Configuration Overlay), поддержка которого была добавлена в АТА-6. DCO
ограничивает доступ к некоторым функциям жесткого диска. В каждой специфи-
спецификации АТА указываются дополнительные возможности, реализация которых жест-
жестким диском не является обязательной. Для определения набора возможностей, фак-
фактически поддерживаемых жестким диском, используется команда IDENTIFY_DEVICE.
Под воздействием DCO команда IDENTIFY_DEVICE сообщает о том, что некоторые
поддерживаемые возможности якобы не поддерживаются, и выдает размер диска
меньше фактического.
Рассмотрим некоторые команды DCO. Команда DEVICE_CONFIGURATION_IDENTIFY
возвращает информацию о возможностях диска и его размере. Следовательно, для
обнаружения вмешательства DCO следует сравнить вывод команд DEVICЕ_СОN FI-
GURATION.IDENTIFY и IDENTIFY.DEVICE. Напомню, что команда READ_NATIVE_MAX_AD-
DRESS возвращает полный размер диска (вместе с HPA). Сравнив результат
READ_NATIVE_MAX_ADDRESS с результатом DEVICE_CONFIGURATION_IDENTIFY, можно
обнаружить присутствие секторов, скрытых DCO.
Допустим, имеется 20-гигабайтный жесткий диск, в котором механизм DCO
установил максимальный адрес 19 Гбайт. Команды READ_NATIVE_MAX_ADDRESS
и IDENTIFY_DEVICE указывают, что размер диска равен только 19 Гбайт. Если на
диске также создается HPA размером 1 Гбайт, команда IDENTIFY_DEVICE покажет,
что размер диска составляет всего 18 Гбайт (рис. 2.13).
Для создания или изменения скрытой области DCO применяется команда
DEVICE_CONFIGURATION_SET, а для ее удаления - команда DEVICE_CONFIGURATION_RE-
SET. В отличие от HPA, не существует возможности внести изменения только на
время текущего сеанса. Все изменения DCO являются устойчивыми, сохраняют-
сохраняются при сбросе и отключении питания.

Рис. 2.13. DCO создает скрытые секторы в конце диска
(помимо секторов, скрытых HPA)
Serial ATA
У устройств АТА имеются свои недостатки. Их кабели слишком велики, недоста-
недостаточно гибки, а разъемы часто оказываются совсем не там, где они нужны. Кроме
того, перемычки «ведущий/ведомый» усложняют конфигурацию жестких дисков.
Кабели и скорость передачи данных стали некоторыми причинами для разработ-
разработки интерфейса Serial ATA, включенного в спецификацию АТА-7.
Интерфейс называется «последовательным» (Serial), потому что в любой мо-
момент времени между контроллером и диском передается только один бит инфор-
информации — в отличие от 16 битов исходного интерфейса «параллельного АТА».
Разъемы Serial ATA примерно в четыре раза меньше разъемов параллельного АТА
и содержат только семь контактов. Каждое устройство Serial ATA подключается
к контроллеру напрямую, подключение «гирляндой» не поддерживается.
Интерфейс Serial ATA проектировался таким образом, чтобы после установки
нового контроллера компьютер не отличал новое устройство Serial ATA от исход-
исходных (параллельных) устройств АТА. Более того, регистры контроллера Serial ATA
создают у компьютера «иллюзию», будто он взаимодействует с параллельным дис-
диском АТА. С точки зрения компьютера каждый диск, подключенный к контролле-
контроллеру Serial ATA, работает как ведущий (master) диск на отдельном канале.
BIOS и прямой доступ
Итак, вы в общих чертах представляете, как работают жесткие диски АТА и как
осуществляется управление ими. Теперь необходимо разобраться, как с ними вза-
взаимодействуют программы, потому что это тоже может вызвать проблемы при об-
обращении к содержимому диска. Взаимодействие программ с диском может осу-
осуществляться на двух уровнях: напрямую через контроллер диска или через BIOS.
Прямой доступ к контроллеру
В предыдущем разделе было показано, что жесткий диск подключается к контрол-
контроллеру, передающему команды диску по плоскому кабелю. В одном из вариантов
чтения/записи данных программа «общается» напрямую с контроллером, кото-
который затем взаимодействует с жестким диском.
Чтобы взаимодействие было организовано подобным образом, программа дол-
должна знать способ адресации контроллера и уметь отдавать ему команды. В част-
частности, программе должен быть известен код команды для операции чтения

и режим идентификации читаемых секторов, а также способ получения у жест-
жесткого диска дополнительной информации (такой, как тип и размер).
Доступ к контроллеру через 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 Inter-
Interface), различных типов устройств и отличий от AT А. Жесткие диски SCSI не по-
получили столь широкого распространения, как жесткие диски АТА для «бытовых»
PC, но именно они применяются на большинстве серверов.
Как и в случае с АТА, существует целый ряд спецификаций SCSI, опублико-
опубликованных техническим комитетом Т10 при INCITS (http://www.tlO.org). Три основ-
основные спецификации SCSI — SCSI-1, SCSI-2 и SCSI-3 — включают несколько специ-
спецификаций более низкого уровня, но их подробное описание выходит за рамки книги.

SCSI и ATA
Между SCSI и ATA существует множество различий как на высоком, так и на
низком уровне. К наиболее очевидным различиям верхнего уровня относятся мно-
многочисленные типы разъемов. В АТА поддерживаются разъемы только с 40 и 44 кон-
контактами, но в SCSI набор форм и типов разъемов гораздо более разнообразен.
Кабели SCSI могут иметь гораздо большую длину, чем кабели АТА, и к одному
кабелю может подключаться более двух устройств. Каждому устройству, подклю-
подключенному к кабелю SCSI, присваивается уникальный числовой идентификатор, ко-
который задается при помощи перемычек на диске или специальной программы.
На многих дисках SCSI также присутствует перемычка, которая разрешает дос-
доступ к диску только для чтения; по своим функциям она напоминает блокировщик
записи АТА — внешнее устройство, блокирующее команды записи (см. главу 3).
Первое низкоуровневое различие между АТА и SCSI состоит в том, что в тех-
технологии SCSI нет контроллера. Интерфейс АТА проектировался в расчете на еди-
единый контроллер, управляющий работой одного или двух жестких дисков. Интер-
Интерфейс SCSI проектировался как шина для взаимодействия различных устройств,
круг которых не ограничивается жесткими дисками. В конфигурации SCSI плата,
подключаемая к компьютеру, не является контроллером, поскольку все устрой-
устройства на кабеле SCSI равноправны и могут обращаться с запросами друг к другу.
По аналогии с АТА, стандартный интерфейс SCSI работает в параллельном
режиме, а пересылка данных осуществляется 8- или 16-разрядными пакетами. Как
и в АТА, существует последовательная версия спецификации.
Типы SCSI
Различия в версиях SCSI сводятся к количеству одновременно пересылаемых
битов, скорости передачи (частоте сигналов в кабеле) и типам используемых сиг-
сигналов. Более старые разновидности существовали в двух версиях, нормальной
и расширенной; в нормальной версии одновременно передавалось 8 битов, а в рас-
расширенной — 16 битов. Например, устройства Ultra SCSI использовали 8-разряд-
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
Ultra2SCSI 40 40 80
Ultra3SCSI 80 — 160
Ultral60SCSI 80 — 160
Ultra320SCSI 160 — 320

В рамках каждого типа существуют различные способы представления дан-
данных при пересылке. Наиболее очевидным является несимметричное представле-
представление: при пересылке 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, Ultral6O SCSI, Ultra320 SCSI
Ни в коем случае не путайте типы сигналов! Подключение устройств SE к ус-
устройствам HVD и некоторым устройствам LVD приведет к их повреждению. Не-
Некоторые диски LVD являются SE-совместимыми pi могут использоваться в среде
SE без повреждения, но только на тех скоростях, на которых работают устройства
SE. На устройствах SCSI присутствует условное обозначение используемого типа
сигнала (рис. 2.14).
Рис. 2.14. Условные обозначения типа сигнала на устройствах SCSI: (A) — устройства SE,
(В) — устройства LVD, (С) — SE- и LVD-совместимые устройства, (D) — устройства HVD
Типы разъемов
Существует много разновидностей разъемов SCSI, но на практике часто встреча-
встречаются лишь некоторые из них. Как правило, диски с 8-разрядной шиной использу-
используют 50-контактные разъемы, а диски с 16-разрядной шиной — 68-контактные. В на-
настоящее время наибольшее распространение получили 68-контактные адаптеры
высокой плотности, существующие в двух модификациях: нормальные и очень

высокой плотности. Нормальные разъемы получили наибольшее распространение
(рис. 2.15). 68-контактный адаптер используется для сигналов LVD и SE, но фи-
физические кабели для разных типов сигналов различаются. Внимательно проверь-
проверьте пометку на кабеле, чтобы избежать возможных проблем.
Рис. 2.15. Диск SCSI с 68-разрядным разъемом
Одну из разновидностей 68-контактных разъемов высокой плотности пред-
представляют разъемы SCA (Single Connector Attachment). Они предназначены для
объединения проводов питания с проводами данных в одном разъеме, что упро-
упрощает замену дисков на сервере. Разъем состоит из 80 контактов, среди которых
присутствуют контакты для подачи питания и настройки конфигурации диска.
На рис. 2.16 показано, как выглядит такой разъем.
Существует множество адаптеров для разных разъемов SCSI; предполагается,
что устройства SCSI обладают обратной совместимостью. Тем не менее работают
не все адаптеры и конфигурации устройств (а даже если они работают, то на ско-
скорости самого медленного из устройств). Помните, что устройства HVD не долж-
должны комбинироваться с устройствами LVD и SE без соответствующих адаптеров,
а сочетания устройств LVD и SE возможны только в том случае, если устройства
LVD способны работать в режиме SE.
Ограничения размера
Ограничения размеров, действующие для дисков АТА, не распространяются на
диски SCSI, потому что в спецификации SCSI всегда использовались 32- и 64-
разрядные адреса LBA. Тем не менее максимальный размер диска, поддерживае-
поддерживаемый BIOS (при использовании INT 13h) или файловой системой, может быть
меньше того, что поддерживается спецификацией SCSI. Данное обстоятельство
может стать ограничивающим фактором.
При работе с диском через BIOS контроллер SCSI преобразует адреса CHS
в адреса LBA. Разные контроллеры используют разные способы отображения, но
во многих случаях способ выбирается на основании геометрии, описываемой в таб-
таблице разделов. Может оказаться, что в рабочей системе аналитика установлен кон-
контроллер с другой схемой отображения адресов, поэтому обращение к диску долж-
должно осуществляться методом прямого доступа, а не через BIOS.

Итоги
В этой главе рассматривались основные принципы организации и хранения дан-
данных. Материал играет важную роль в книге, потому что мы будем рассматривать
структуры данных и методы хранения информации в разных файловых системах.
Дополнительная информация о структурах данных приводится в книгах, посвя-
посвященных языку С. Кроме того, в этой главе представлены основные технологии
жестких дисков; этот материал тоже важен, потому что именно жесткие диски
чаще всего становятся объектом анализа и экспертизы. Дополнительные све-
сведения о технологии жестких дисков можно найти на сайте PC Guide (http://
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. http://www.tl3.org/project/d0791r4c-ATA-l.pdf.
• T13. «Information Technology — AT Attachment with Packet Interface - 6 (ATA/
ATAPI-6». 1410D Revision 3b, February 26, 2002. 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. 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. http://www.tl3.org/project/d2008r7b-ATA--
3.pdf.

Снятие данных
с жесткого диска
Основная часть материала так или иначе связана со снятием данных, находящих-
находящихся на носителе информации — а именно, на жестком диске. Анализ также может
проводиться в «живых» системах, но чаще данные копируются для проведения
стороннего анализа. Как правило, снятие данных происходит в фазе сохранения
системы и является одной из важнейших составляющих цифровой экспертизы.
Ведь если данные не будут скопированы в другую систему, они могут быть слу-
случайно утрачены, и тогда они перестанут быть уликами. Более того, если копиро-
копирование произведено некорректно, данные тоже утрачивают свою юридическую силу.
В этой главе приводится теория снятия данных, а также рассматривается конк-
конкретный пример с применением утилиты Linux dd.
Введение
Как было показано в главе 1, первой фазой цифрового анализа является сохране-
сохранение цифрового «места преступления». Обычно для сохранения системы создают-
создаются полные копии жестких дисков, которые затем доставляются в лабораторию для
проведения стороннего анализа. Эту фазу можно сравнить с процессом создания
точной копии здания, в котором было совершено реальное преступление, чтобы
следователи могли спокойно заняться поиском улик в лаборатории.
Общая процедура снятия данных
В самой общей и интуитивно понятной процедуре снятия данных один байт с ис-
исходного носителя информации (источника) копируется в приемное устройство,
после чего эта процедура многократно повторяется. Происходит примерно так,
как если бы вы при копировании документа вручную читали отдельную букву,
знак препинания или пробел из оригинала и записывали его в копию. Такой спо-
способ работает, но большинство читателей вряд ли будут им пользоваться — ведь
они могут запоминать целые слова, а копировать документ по одному или несколь-
нескольким словам гораздо эффективнее, чем по отдельным знакам. Компьютеры дей-
действуют по тому же принципу, и копирование данных из анализируемых систем
производится блоками размером от 512 до многих тысяч байтов.
Размер одного передаваемого блока обычно кратен 512 байтам, то есть разме-
размеру сектора на большинстве дисков. Если при чтении данных с анализируемого
диска происходит ошибка, большинство программ снятия данных записывает
в приемник нули.

Уровни снятия данных
В общей теории неразрушающего снятия данных сохраняется каждый байт, кото-
который может использоваться в качестве улики. Как было показано в главе 1, интер-
интерпретация данных может осуществляться на разных уровнях: например, на уровне
дисков, томов, файлов и приложений. На каждом уровне абстракции теряется
некоторая часть данных. Таким образом, снятие данных должно осуществляться
на самом низком уровне, на котором будут находиться улики. В большинстве слу-
случаев аналитик снимает содержимое каждого сектора диска; именно этот способ
будет рассматриваться в этой главе. Обратите внимание: сохраняя только содер-
содержимое секторов с данными, мы теряем информацию, которая может понадобить-
понадобиться специалистам по восстановлению данных.
Чтобы показать, почему снятие данных обычно производится на уровне диска,
рассмотрим пару примеров. Допустим, диск был клонирован на уровне тома, с соз-
созданием копии каждого сектора в каждом разделе. Такая копия позволит восста-
восстановить удаленные файлы в каждом разделе, но анализ секторов, не принадлежа-
принадлежащих ни одному из разделов, будет невозможен. Как будет показано в главе 5, на
диске с разделами DOS не используются секторы с 1 по 62, и в них могут нахо-
находиться скрытые данные. При проведении снятия на уровне тома эти скрытые дан-
данные будут потеряны.
Теперь предположим, что мы воспользовались утилитой архивации и скопи-
скопировали только существующие файлы. В этом случае станет невозможным восста-
восстановление удаленных файлов, могут стать недоступными все временные данные,
а также служебная информация, скрытая в разделах и структурах данных файло-
файловой системы. Иногда никаких других данных, кроме архива, не имеется, и анали-
аналитик должен извлечь из него максимум пользы. Скажем, в корпоративной среде
сервер перестал работать, потому что все его диски были записаны нулями, а за-
затем компьютер был перезагружен. Последний архив системы может содержать
информацию о том, кто имел доступ к системе или каким образом злоумышлен-
злоумышленник проник в нее.
В некоторых системах наше правило относительно снятия данных на минималь-
минимальном уровне, на котором мы рассчитываем найти улики, означает, что достаточно
скопировать только файлы. Допустим, вы расследуете попытку взлома сети с дей-
действующей системой обнаружения вторжений (IDS, Intrusion Detection System),
у которой имеется журнал с информацией об атаке. Если вы считаете, что данные
IDS не подвергались посторонним изменениям, то все улики существуют на фай-
файловом уровне; можно просто скопировать необходимые журналы и предпринять
необходимые шаги по их сохранению. Если есть подозрение, что данные IDS были
изменены, то информацию следует копировать на дисковом уровне для проведе-
проведения анализа всех данных.
Тесты программ снятия данных
Клонирование является критической составляющей процесса расследования,
и Национальный институт стандартов и технологий (NIST, National Institute of
Standards and Technology) провел сравнительное тестирование распространен-
распространенных программ клонирования. В рамках проекта CFTT (Computer Forensic Tool

Testing) в NIST был разработан набор требований и тестов для утилит создания
образов дисков. Результаты и спецификации приведены на веб-сайте (http://
wwwxftt.nist.gov/diskjmaging.htm).
Чтение исходных данных
В соответствии с общей теорией клонирования, описанной в предыдущем разде-
разделе, процесс состоит из двух основных частей. Сначала данные необходимо прочи-
прочитать из источника, а затем записать их в приемник. Поскольку в книге основное
внимание уделяется анализу томов и данных файловых систем, мы рассмотрим
процесс клонирования на уровне диска (поскольку именно на этом уровне хра-
хранится большинство структур данных томов). В этом разделе будут рассмотрены
вопросы, связанные с чтением диска, а в следующем речь пойдет о записи. Пред-
Предполагается, что в качестве источника используется типичная система IA32 (на-
(например, x86/i386). Мы рассмотрим различные способы обращения к данным, об-
обработку ошибок и снижение риска записи данных на исследуемый диск.
Прямой доступ или BIOS?
Как показано в главе 2, существует два способа обращения к данным на диске.
В первом способе операционная система или программа клонирования обраща-
обращается к жесткому диску напрямую; для этого программа должна обладать полной
информацией о конфигурации оборудования. Во втором способе операционная
система или программа клонирования обращается к жесткому диску через про-
прослойку BIOS (Basic Input/Output System), которой известны все подробности кон-
конфигурации. На первый взгляд особых различий не видно, и работать через BIOS
вроде бы удобнее, потому что BIOS берет на себя все аппаратные тонкости. К со-
сожалению, когда речь идет о расследовании, дело обстоит несколько сложнее.
При обращении через BIOS возникает опасность того, что BIOS вернет невер-
неверную информацию о диске. Если BIOS считает, что размер диска составляет 8 Гбайт,
тогда как фактический размер равен 12 Гбайт, функции INT 13h предоставят дос-
доступ только к первым 8 Гбайт дискового пространства. Следовательно, при клони-
клонировании диска последние 4 Гбайт не будут скопированы. Суть происходящего
продемонстрирована на рис. 3.1, где два приложения пытаются определить раз-
размер диска разными способами.
Рис. 3.1. Два приложения пытаются определить размер диска. Из-за неверной конфигурации
BIOS сообщает, что размер 12-гигабайтного диска составляет всего 8 Гбайт
Возможны различные варианты этого сценария. Первый — когда BIOS настра-
настраивается на конкретную геометрию жесткого диска, отличную от фактической.

В другом варианте программа клонирования использует устаревший метод полу-
получения размера диска. Приложение может запросить у 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]. Руткиты скрывают некоторые файлы в каталогах или работающие процес-
процессы. Чаще всего нападающий скрывает файлы, установленные им после взлома
системы. Также он может модифицировать операционную систему так, чтобы
в процессе она автоматически подменяла данные в некоторых секторах диска.

Полученный образ диска может не иметь отношения к происшествию из-за про-
произошедшей подмены. По возможности избегайте живого клонирования, чтобы
обеспечить надежный сбор всех улик.
Аналитики обычно загружают исследуемую систему с заведомо надежной дис-
дискеты DOS или компакт-диска Linux, конфигурация которого не предусматривает
монтирования дисков или модификации каких-либо данных. С технической точ-
точки зрения злоумышленник может изменить оборудование так, чтобы оно возвра-
возвращало ложные данные даже в надежной операционной системе, но этот вариант
гораздо менее вероятен, чем модификация операционной системы.
Обработка ошибок
В процессе чтения данных с диска программа клонирования должна обрабатывать
возникающие ошибки. Причины могут быть различными: как отказ всего диска,
так и сбои в ограниченном количестве секторов. При повреждении части секторов
клонирование возможно — но при условии, что программа обработает все ошибки.
Общепринятый способ обработки поврежденных секторов заключается в со-
сохранении адреса и записи нулей на место данных, которые не удалось прочитать.
Запись нулей сохраняет правильное местонахождение остальных данных. Если
бы поврежденные секторы просто игнорировались, то полученная копия оказа-
оказалась бы слишком маленькой, а многие аналитические программы не смогли бы
с ней работать. На рис. 3.2 показана последовательность клонируемых секторов.
Три сектора содержат ошибки, и прочитать их не удалось, поэтому в копию на их
место записываются нули.
Область HPA
При снятии данных с дисков АТА следует обращать внимание на защищенную
область HPA диска, поскольку в ней могут храниться скрытые данные. Если про-
программа снятия данных не пытается обнаружить HPA, эти данные не будут клони-
клонированы. За дополнительной информацией о HPA обращайтесь к главе 2.
Программа обнаруживает присутствие HPA, сравнивая результаты выполне-
выполнения двух команд АТА. Команда READ_NATIVE_MAX_ADDRESS возвращает общее ко-
количество секторов на диске, а команда IDENTIFY_DEVICE — количество секторов,
доступных для пользователя. Если область HPA существует, эти два числа будут
различаться.
Если у вас нет программы, которая выполняла бы необходимые команды АТА,
вероятно, вам придется сравнить количество секторов, скопированных в процессе
снятия данных, с количеством секторов, указанным на наклейке на диске. Многие
современные программы снятия данных обнаруживают присутствие HPA. Также

существуют специализированные утилиты, такие как BXDR (http://www.sanderson-
forensics.co.uk/BXDR.htm) Пола Сэндерсона (Paul Sanderson), diskstatH3 пакета The
Sleuth Kit, DRIVEID компании МуКеу Technology (http://www.mykeytechnology.com)
и hpa Дэна Mapeca (Dan Mares) (http://www.dmares.com/maresware/gk.htmSHPA).
Если на диске будет обнаружена область HPA и вы захотите получить дос-
доступ к скрытым данным, придется изменить конфигурацию диска. Чтобы уда-
удалить HPA, следует задать максимальный сектор, адресуемый пользователем,
равным максимальному сектору на диске. При этом можно использовать бит
устойчивости, чтобы изменения в конфигурации были утрачены при следующем
отключении питания жесткого диска. Выполнению команды могут помешать не-
некоторые аппаратные блокировщики записи, о которых речь пойдет далее.
Процесс удаления HPA сопряжен с изменением конфигурации диска. Суще-
Существует крайне малая вероятность того, что в контроллере диска или программе
снятия данных неверно реализован механизм изменения HPA, и попытка снятия
защиты приведет к потере данных. Следовательно, перед удалением HPA стоит
создать полный образ диска. Если в процессе удаления будут нанесены какие-
либо повреждения, у пользователя останутся исходные данные для анализа. При-
Пример диска с HPA будет рассмотрен далее в этой главе. Факт снятия HPA обяза-
обязательно должен быть отражен в ваших заметках.
DCO
При снятии данных с современных дисков АТА также следует проверить нали-
наличие области DCO (Device Configuration Overlay), из-за которой размер диска ка-
кажется меньше фактического. Область DCO в целом похожа на HPA, причем обе
области могут существовать на диске одновременно (тема DCO также обсужда-
обсуждалась в главе 2).
Присутствие DCO обнаруживается сравнением результатов двух команд АТА.
Команда READ_NATIVE_MAX_ADDRESS возвращает максимальный сектор диска, дос-
доступный для обычных команд АТА, а команда DEVICE_CONFIGURATION_IDENTIFY -
физическое количество секторов. Если результаты двух команд различаются, зна-
значит, на диске существует защищенная область DCO и ее необходимо удалить для
снятия всей информации.
Чтобы удалить область DCO, необходимо изменить конфигурацию диска ко-
командой DEVICEj:ONFIGURATION_SET или DEVICE_CONFIGURATION_RESET. Оба измене-
изменения имеют постоянный характер и не пропадают при сбросе, как это возможно
при создании областей HPA. В настоящее время лишь немногие программы спо-
способны обнаруживать и удалять DCO. Например, программа Image MASSter Solo
2 от ICS (http://www.icforensic.com) копирует секторы, скрытые в DCO. Как и в слу-
случае с HPA, самое безопасное решение заключается в полном копировании диска
с областью DCO, ее удалении и создании второй копии. Не забудьте документи-
документировать факт удаления DCO. Кроме того, проверьте, не запрещено ли удаление
DCO аппаратным блокировщиком записи.
Аппаратная блокировка записи
Одна из рекомендаций из области цифровой экспертизы, приведенных в гла-
главе 1, гласила, что исходные данные должны подвергаться как можно меньшим

изменениям. Существует множество методов снятия информации, не связан-
связанных с модификацией исходных данных, но ошибки все же случаются. Более того,
некоторые методы могут изменять исходные данные, чего нам хотелось бы из-
избежать.
Аппаратный блокировщик записи представляет собой устройство, подключен-
подключенное между компьютером и носителем информации. Такое устройство отслеживает
передаваемые команды и не позволяет компьютеру записывать данные на уст-
устройство хранения информации. Блокировщики поддерживают разные интерфей-
интерфейсы пересылки данных, в том числе ATA, SCSI, Fire Wire (IEEE 1394), USB или
Serial ATA. Они особенно важны в операционных системах, способных смонти-
смонтировать исходный диск (например, Microsoft Windows).
При обсуждении команд АТА в главе 2 говорилось о том, что диск выполняет
какие-либо действия лишь после записи в его регистр команд. Таким образом,
теоретически простейший аппаратный блокировщик записи АТА просто не дает
контроллеру записать в регистр команд никакие значения, которые могли бы при-
привести к записи информации или ее стиранию с диска. Тем не менее такое устрой-
устройство может разрешить контроллеру запись данных в другие регистры. Можно ска-
сказать, что блокировщик записи разрешает зарядить ружье, но не дает возможности
спустить курок. На рис. 3.3 показано, что команды чтения передаются диску, а ко-
команды записи — нет.
Рис. 3.3. Запрос на чтение сектора 5 передается через блокировщик записи,
но команда записи в тот же сектор блокируется на пути к диску
Устройство No Write компании MyKeyTechnologies обладает более сложной
конструкцией и выполняет функции посредника с поддержкой состояния между
контроллером и жестким диском [MyKeyTechnology, 2003]. Данные и команды
передаются жесткому диску только для заведомо безопасных команд. Аргументы
команд не записываются в регистры, если устройство NoWrite не знает, к какой
команде они относятся. Пересылка данных несколько замедляется, но зато сни-
снижается опасность записи потенциально опасных команд. Если продолжить пре-
предыдущую аналогию, такой процесс проверяет каждый патрон и разрешает заря-
заряжать ружье только холостыми.
Я уже упоминал об аппаратных блокировщиках записи в разделах, посвященных
HPA и DCO, и сейчас хочу снова вернуться к этой теме. Для удаления областей

HPA и DCO диску необходимо передать соответствующие команды. Так как вы-
выполнение этих команд приводит к изменению устройства, они должны быть оста-
остановлены аппаратным блокировщиком записи. Устройство No Write делает исклю-
исключение для команды SET_MAX и разрешает выполнять ее при сброшенном бите
устойчивости, чтобы изменения не носили постоянного характера. Все остальные
команды SET_MAX и DEVICE_CONFIGURATION блокируются. Некоторыеблокировщи-
ки записи разрешают прохождение этих команд, а другие их блокируют. На мо-
момент написания книги документация с перечислением блокируемых команд по-
почти не встречалась.
Аппаратные блокировщики записи, как и все остальные аналитические ин-
инструменты, должны проходить тщательное тестирование, и группа CFTT при
NIST опубликовала спецификацию аппаратных блокировщиков записи (http://
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 разработала требования и провела тестирование про-
программных блокировщиков записи. Подробности можно найти на сайте: http://
www.cftt.nost.gov/software_write_block.htm.

Рис. 3.4. Таблица прерываний BIOS до и после установки программного
блокировщика, предотвращающего запись на диск
Запись снятых данных
После того как информация будет прочитана с исходного диска, ее нужно куда-то
записать. В этом разделе речь пойдет о том, где сохранять данные, и о различных
форматах сохранения.
Выбор приемника
Сохраняемые данные записываются непосредственно на диск или в файл. Мы
рассмотрим оба варианта.
До появления специализированных программ эксперту приходилось лишь
загружать анализируемую систему либо монтировать диски в своей системе. Сня-
Снятие информации производилось простым копированием данных на другой диск.
Иначе говоря, сектор 0 исходного диска был идентичней сектору 0 приемного
диска. Полученный диск обычно назывался дубликатом или клоном. Если при-
приемный диск был больше исходного, при таком способе снятия данных возни-
возникали проблемы, потому что было трудно определить, где именно на диске

заканчиваются скопированные данные. Как правило, перед прямым снятием дан-
данных приемный диск рекомендовалось заполнить нулями, чтобы посторонние
данные (возможно, оставшиеся от предыдущих исследований) не смешивались
сданными из анализируемой системы. Вторая потенциальная проблема со сня-
снятием данных на диск заключается в том, что некоторые операционные системы
(например, Microsoft Windows) пытаются монтировать все диски. Копия мон-
монтируется в системе, из которой снимаются данные, что может привести к из-
изменению ее содержимого. Кроме того, трудности могли возникнуть и из-за раз-
различий в геометриях исходного и приемного дисков, потому что некоторые
структуры данных описывают местонахождение данных с использованием па-
параметров геометрии диска.
В настоящее время самым распространенным способом является сохранение
данных в файле на жестком диске или на диске CD-ROM. При выводе в файл
границы данных сразу видны, а операционная система не пытается автоматичес-
автоматически монтировать диск. Такой файл часто называется образом (image). Многие про-
программы позволяют разбивать файлы образов на меньшие фрагменты, помещаю-
помещающиеся на один диск CD-ROM или DVD. Некоторые эксперты стирают диски, на
которых хранятся файлы образов, — стирание гарантирует, что данные не содер-
содержат посторонних включений от прошлых случаев.
Формат файла образа
Сохранив данные в файле, можно выбрать формат образа. Физический образ (raw
image) содержит только данные с исходного диска, что упрощает сравнение обра-
образа с исходными данными. Внедренный образ (embedded image) содержит данные
с исходного устройства и дополнительную служебную информацию: хеш-коды,
пометки даты pi времени. Некоторые программы создают физический образ и со-
сохраняют служебную информацию в отдельном файле. Напомню, что хеш-коды
(CRC, MD5 и SHA-1) используются для проверки целостности данных. Приме-
Примеры форматов образов показаны на рис. 3.5.
Рис. 3.5. Примеры образов: (А) — физический образ, (В) — внедренный образ, в котором
метаданные чередуются с физическими данными, (С) — комбинированный образ: данные
хранятся в физическом формате, а метаданные находятся в отдельном файле
В текущих реализациях многие программы клонирования используют за-
закрытые форматы внедренных образов. Примерами могут послужить программы

EnCase1 (Guidance Software) и SafeBack (NTI). Формат образов других про-
программ документирован — как, скажем, формат ProDiscover (Technology Path-
Pathway) [Technology Pathways, 2003]. Как правило, аналитические программы им-
импортируют физические образы, поэтому этот формат обеспечивает наибольшую
гибкость. Программы SMART (ASR Data) и dcfldd/dccidd снимают данные в фи-
физическом формате и создают внешний файл с дополнительной информацией.
Сжатие файла образа
Записываемые в файл данные можно сжать, чтобы они занимали меньше места.
Механизм сжатия основан на более эффективном хранении повторяющихся дан-
данных. Например, если данные содержат блок из 10 000 единиц, то после сжатия
этот блок может представляться несколькими сотнями бит вместо 10 000. Если
данные имеют полностью произвольный характер, повторений будет немного и эф-
эффективность сжатия снижается. Попытка сжатия уже сжатых данных тоже мало-
малоэффективна. Например, графика в формате JPEG уже хранится в сжатом виде,
и ее размер практически не изменится в результате повторного сжатия.
Аналитические программы, используемые для работы со сжатыми образами,
должны поддерживать соответствующий тип сжатия. Большинство общих схем
сжатия требует полной распаковки файла перед его использованием. Примерами
служат утилиты Winzip для Windows и gzip для UNIX. Специальные алгоритмы
сжатия позволяют выполнять распаковку небольшой части сжатого файла; обычно
именно такие алгоритмы применяются в программах снятия данных, чтобы избе-
избежать необходимости полной распаковки всего образа.
Преимущество сжатия состоит в том, что снятая с носителя информация со-
сохраняется в файле образа, имеющем меньший размер, хотя реальная экономия
зависит от характера данных. Впрочем, наряду с преимуществами имеется ряд
недостатков:
• Возможно, ваш выбор будет ограничен аналитическими программами, поддер-
поддерживающими данный формат.
• Снятие данных часто занимает больше времени, потому что программа долж-
должна «на ходу» сжимать обрабатываемые данные.
• Необходимость распаковки изображения при чтении данных замедляет про-
процесс анализа.
Сетевое снятие данных
Файл образа также может создаваться на удаленном компьютере. В этом случае
данные читаются с исходного диска, передаются на приемный хост по сети и за-
записываются в файл. Этот метод снятия данных особенно удобен в ситуациях, ког-
когда вы не можете получить доступ к анализируемому диску или у вас под рукой
пет необходимого адаптера или интерфейса. Многие современные программы
поддерживают сетевой режим как при мертвом, так и при живом снятии данных.
1 Спецификация формата, используемого программой Expert Witness (предшественником EnCase),
находится по адресу: http://www.asrdata.com/SMART/whitepaper.html.

Некоторые программы обеспечивают шифрование для сохранения конфиденци-
конфиденциальности данных в процессе пересылки. Здесь также может пригодиться сжатие
для уменьшения объема данных, передаваемых по медленной сети.
Хеширование и целостность данных
В главе 1 среди основополагающих концепций цифровой экспертизы называ-
называлось хеширование анализируемых данных для последующей проверки их цело-
целостности. Некоторые программы снятия данных вычисляют хеш-коды в процес-
процессе копирования данных, в других случаях приходится использовать отдельную
утилиту. Хеш-коды сохраняются либо во внедренном образе, либо во внешнем
файле, прилагаемом к физическому образу. Внедрение хеш-кодов в образ не
обеспечивает какой-либо дополнительной безопасности или проверки целост-
целостности данных.
Важно понимать, какая же функция отводится хешированию. Хеш-код, хра-
хранящийся в изображении, вовсе не гарантирует, что данные не подвергались по-
посторонним модификациям. В конце концов, если злоумышленник изменил образ,
он мог пересчитать хеш-коды, даже если они внедрены в формат образа. Напи-
Написать соответствующую программу довольно легко. Для проверки целостности
файла образа по хеш-коду потребуется криптографическая цифровая подпись
и доверенный источник. Такое решение сопряжено с основательными непроиз-
непроизводительными затратами; следовательно, гораздо проще сохранить хеш-код на но-
ноутбуке. Если кто-то захочет изменить изображение и пересчитать хеш-код, ему
придется получить доступ к вашему ноутбуку.
Хотя хеширование играет важную роль при будущих проверках целостности
образа, оно также может использоваться для демонстрации точности процесса
снятия данных и отсутствия модификаций исходных данных. Если вычислить
хеш-код диска перед снятием данных и сравнить полученное значение с хеш-
кодом физического образа, можно показать, что физический образ содержит те
же данные, что и исходный диск. В идеальном случае исходный хеш-код должен
вычисляться другой программой независимо от инструментария клонирования,
чтобы одни и те же ошибки не проявлялись в контрольных данных и в получен-
полученном образе.
Учтите, что в процессе хеширования читаются только данные, доступные
для программы. Если из-за аппаратных или программных проблем часть со-
содержимого диска окажется недоступной, хеш-код диска может совпасть с хеш-
кодом файла образа несмотря на то, что файл образа не представляет всего со-
содержимого диска. Например, если программа может прочитать только первые
8 Гбайт 12-гигабайтного диска, она вычислит хеш-код для первых 8 Гбайт, ско-
скопирует первые 8 Гбайт данных и вычислит хеш-код для 8-гигабайтного файла
образа.
Также следует подумать о периодичности вычисления хеш-кодов. Хеширо-
Хеширование чаще всего применяется для выявления изменений в блоках данных. Если
хеш-код показывает, что содержимое блока изменилось, значит, этот блок ис-
использоваться не может. Вычисление хеш-кодов для блоков меньшего размера
снижает последствия от нарушений целостности данных. Если какой-либо блок
данных не проходит проверку целостности, он исключается из дальнейшей

обработки, но остальные части образа вполне могут быть пригодными для ис-
использования.
Практический пример с использованием dd
Чтобы продемонстрировать процесс снятия данных, я опишу методику снятия
данных утилитой dd. Программа dd считается одной из самых простых и гибких
программ снятия данных, но она работает в режиме командной строки, а ее осво-
освоение несколько усложняется богатыми возможностями настройки, dd существует
во многих версиях UNIX, а также в версии для Windows1. В данном примере бу-
будет рассматриваться Linux-версия.
Фактически программа dd копирует блок данных из одного файла и записыва-
записывает его в другой файл. Она не интересуется типом копируемых данных и ничего не
знает о файловых системах и дисках — копируются только файлы.
dd читает данные по блокам; размер блока по умолчанию равен 512 байтам.
Данные читаются из входного источника, заданного флагом if=. Если флаг if= не
указан, программа получает данные из стандартного ввода, которым обычно яв-
является клавиатура. Данные записываются в выходной файл, заданный флагом of=.
При отсутствии параметра данные записываются в стандартный вывод, чаще
всего на экран. В следующем примере файл filel.dat копируется в файл file2.dat
512-байтовыми блоками:
# dd if-filel.dat of-fi1e2.dat bs=512
2+0 records in
2+0 records out
Две последние строки показывают, что два полных блока были прочитаны из
файла fUel.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) находится по адресу: http://users.erols com/gmgarner/
forensics/, а версия UnxUtils — по адресу: http://unxutils.sourceforge net.

создаются но для ссылки на диск можно использовать синтаксис \\.\ — напри-
например, \\.\PhysicalDriveO.
Размер блока по умолчанию составляет 512 байт, но параметр bs= позволя-
позволяет задать произвольное значение. За одну операцию может копироваться как
1 байт, так и 1 гигабайт. Подходит любое значение, но некоторые обеспечивают
более высокое быстродействие по сравнению с остальными. Диски обычно чи-
читают данные блоками по 512 байт, но легко могут читать и больше. Слишком
малые размеры блока неэффективны, потому что они требуют более частых
обращений к диску и приводят к лишним потерям времени в процессе копиро-
копирования. Если же выбранное значение окажется слишком большим, то время бу-
будет тратиться на заполнение буфера dd перед выполнением операции копиро-
копирования. Эксперименты показали, что оптимальные значения лежат в интервале
от 2 до 8 Кбайт.
Linux работает с диском напрямую и не нуждается в услугах BIOS, поэтому
мы не рискуем получить у BIOS неверную информацию о размерах диска. Отсю-
Отсюда также следует, что в Linux невозможна программная блокировка записи, но
при желании вы можете воспользоваться аппаратным устройством.
HPA
Как упоминалось ранее, dd работает только с файлами и ничего не знает о АТА
HPA. В этом разделе будут рассмотрены некоторые способы обнаружения АТА
HPA в Linux.
В сценарии данного примера используется 57-гигабайтный диск, содержащий
120 103 200 секторов. Я поместил в сектор 15 000 строку «here i am»:
# dd itWdef/hdb bs=512 skip=15000 count-1 | xxd
1+0 records in
1+0 records out
00000000: 6865 7265 2069 2061 6d0a 0000 0000 0000 here i am
Затем в последних 120 091 200 секторах была создана область HPA. Другими
словами, на диске остались только 12 000 секторов, доступных для ОС и прило-
приложений. В этом легко убедиться, так как строка в секторе 15 000 стала недоступ-
недоступной:
# dd ifVdef/hdb bs=512 skip-15000 count=l | xxd
0+0 records in
0+0 records out
Записи не были скопированы, потому что программа не смогла прочитать дан-
данные. Возможны различные варианты обнаружения HPA в Linux. Новые версии
Linux выводят сообщения в журнале dmesg. Учтите, что размер журнала ограни-
ограничен, поэтому при выводе большого количества предупреждений или сообщений
об ошибках часть информации будет потеряна. Для нашего диска результат выг-
выглядит так:
# dmesg | less
[REMOVED]
hdb: Host Protected Area detected.
current capacity is 12000 sectors F MB)
native capacity is 120103200 sectors F1492 MB)

Впрочем, это сообщение выводится не во всех версиях Windows. Другой спо-
способ обнаружения HPA основан на использовании программы hdparm, входящей
в поставку Linux. Программа выводит информацию о жестком диске, и для полу-
получения общего количества секторов необходимо указывать флаг -I. Полученное
значение сравнивается со значением, записанным на диск или найденным на сай-
сайте фирмы-производителя. По выходным данным hdparm также можно судить о том,
поддерживает ли диск HPA (у старых дисков поддержка HPA отсутствует).
# 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 (http://
www.win.tue.nl/~aeb/linux/setmax.с). Мы запускаем setmax и задаем максимальное
количество секторов на диске, то есть 120 103 200 для данного примера. Утилита
изменяет конфигурацию жесткого диска, поэтому при работе с ней необходима
крайняя осторожность (в частности, следует тщательно документировать все вы-
выполняемые действия). Также учтите, что программа не поддерживает временное
изменение максимального адреса, так что вносимые изменения являются посто-
постоянными. Если вы намерены использовать подобную программу, сначала протес-
протестируйте ее на других дисках и только потом переходите к диску, который может
содержать ценную информацию:
# setmax --max 120103200 /dev/hdb
После сброса ограничений максимального адреса программа dd может ис-
использоваться для снятия информации со всего диска. Запишите размер HPA;
это позволит вам вернуть диск в исходное состояние, с которого начинался ана-
анализ данных.
Приемник
Выходные данные dd направляются либо в новый файл, либо на другое устрой-
устройство хранения информации. Например, следующие два примера выполняются

в среде 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
(http://www.atstake.com/research/tools/) или cryptcat (http://sf.net/projects/cryptcat).
В примере для netcat на доверенном сервере с IP-адресом 10.0.0.1 выполняется
следующая команда для открытия сетевого порта 7000 и сохранения входящих
данных в файле:
# пс -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)
(http://www.garloff.de/kurt/linux/ddrescue), похожа на исходную версию dd, но ре-
режим обработки ошибок включен в ней по умолчанию. Обнаружив ошибку, про-
программа переходит на меньший размер блока и заполняет нулями блоки, кото-
которые не удалось прочитать. Программа dd_rescue также умеет копировать данные

от конца диска к началу — автор утверждает, что это может быть полезно при на-
наличии поврежденных секторов.
Криптографическое хеширование
Как правило, для выполнения криптографического хеширования файла при
использовании dd приходится пользоваться услугами другой программы (такой,
как md5sum). Криптографический хеш-код образа вычисляется для последующей
проверки его целостности. Джессе Корнблум (Jesse Kornblum) и Рейд Литцов
(Reid Leatzow) из Центра киберпреступности Министерства обороны США
создали версию dd с хешированием копируемых данных. В настоящее время
существует две версии этой утилиты. Исходная версия dcfldd (http://source-
forge.net/projects/biatchux) вычисляет только хеш-коды по алгоритму MD5.
Новая версия dccidd (http://www.dc3.gov; также можно отправить сообщение
электронной почты по адресу: dcci@dc3.gov) умеет параллельно вычислять хеш-
коды 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: 97O653da48fO47f3511196c8a23Of64c
1048576 - 2097152: b6d81b360a5672d80c27430f39153e2c
103809024 - 104857600: b6d81b360a5672d80c27430f39153e2c
104857600 - 105906176: 94al71ec3908687fdlf456087576715b
Total: 28dd34393f36958f8fc822ae39800f37c3
Строка начинается с диапазона байтов, для которого вычисляется хеш-код,
и завершается значением хеш-кода. Последнее значение представляет собой хеш-
код всего образа. Файл журнала dccidd имеет несколько иную структуру: в него
включается хеш SHA-1, а поле диапазона дополняется нулями. Приведу фраг-
фрагмент файла с окном хеширования, равным 512 байтам (хеши SHA-1 и MD5 обыч-
обычно выводятся в одной строке):
000000 - 000511: 5dbdl21cad07429edl76f7fac6al33d6
09cae0d9f2a387bb3436al5aa514bl6f9378efbf
000512 - 001023: 91cf74d0ee95d4b60197e4c0ca710be4
0f71d8729ad39ae094e235ab31a9855b2a5a5900

001024 - 001535: 8a0al0f43b2bcd9el385628f7e3a8693
641b9b828e41cd391f93b5f3bfaf2dlb7b393da0
Упоминавшаяся ранее Windows-версия dd Джорджа Гарнера также содержит
встроенную поддержку MD5. При передаче ключа -md5sum программа Гарнера
хеширует файл по алгоритму MD5. Результат хеширования сохраняется в файле
при помощи ключа -md5out
Итоги
В современных цифровых расследованиях большинство улик находится именно
на жестких дисках. Вероятно, ситуация сохранится в течение многих лет (по
крайней мере до тех пор, пока содержимое всех жестких дисков не будет шифро-
шифроваться). Снятие данных играет важную роль в процессе расследования: если оно
выполняется некорректно, вы можете лишиться данных для расследования. В этой
главе была представлена общая теория клонирования данных и рассмотрен прак-
практический пример использования dd. Программа относительно проста, но она ра-
работает в режиме командной строки, а обилие параметров может создать путаницу.
Библиография
• МуКеу Technology, Inc. «Technical White Paper: No Write Design Notes.» 2003.
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. https://
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. https://www.ncjrs.org/pdffilesl/nij/20032.pdf.

ЧАСТЬ II
Анализ томов
Глава 4. Анализ томов 82
Глава 5. Разделы на персональных компьютерах 93
Глава 6. Разделы в серверных системах 117
Глава 7. Многодисковые тома 143

Анализ томов
Настоящая глава открывает вторую часть книги, посвященную анализу томов.
Процесс анализа томов включает просмотр структур данных, задействованных
в определениях разделов, и сборку байтов на носителях информации для форми-
формирования томов. Тома (volumes) используются для хранения файловых систем
и других структурированных данных, которые будут описаны в третьей части кни-
книги, «Анализ файловых систем». В этой главе основные концепции анализа томов
рассматриваются с абстрактных позиций: изложенные в ней принципы примени-
применимы ко всем типам томов. Следующие три главы будут посвящены конкретным
типам разделов и систем формирования томов.
Введение
Цифровые носители информации особым образом структурируются для обеспе-
обеспечения эффективной выборки данных. Пользователи чаще всего сталкиваются
с системой томов при установке Microsoft Windows и созданием разделов на жес-
жестком диске. Процесс установки руководит действиями пользователя при созда-
создании разделов (основного и логических), и в конечном итоге на компьютере появ-
появляется список «дисков» или «томов» для хранения данных. Аналогичный процесс
происходит и при установке операционной системы UNIX. В наше время при хра-
хранении больших объемов информации все чаще применяются программы управ-
управления томами, благодаря которым несколько дисков интерпретируются как один
большой диск.
Во время цифрового следствия чаще всего снимается полный образ диска, ко-
который затем импортируется в аналитическую программу. Многие инструменты
цифровой экспертизы автоматически разбивают образ диска на разделы, но иног-
иногда у них возникают проблемы. Концепции, представленные в этой части книги,
помогут эксперту во всех подробностях понять, что делает программа и почему
при повреждении диска возникают те или иные проблемы (например, если раз-
раздел на диске был удален или модифицирован подозреваемым либо программа про-
просто не может найти раздел). Материал этой части также пригодится при анализе
содержимого секторов, не принадлежащих ни одному разделу.
Настоящая глава также содержит теоретические обоснования, краткий об-
обзор программных инструментов и разновидностей методов анализа. В следую-
следующих двух главах более подробно рассматриваются некоторые схемы разделов,
включая разделы DOS, Apple Partitions, разделы BSD и сегменты (slices) SUN.

Последняя глава посвящена распределенным дисковым томам, таким как RAID
и disk spanning.
Общие положения
Концепция тома
Многотомные системы основаны на двух основных концепциях. Первая — это
объединение нескольких томов в единое целое, а вторая — разбиение томов на
независимые разделы. Термины «раздел» (partition) и «том» (volume) часто ис-
используются как синонимы, но я буду различать эти понятия.
Томом называется совокупность адресуемых секторов, которые могут исполь-
использоваться операционной системой (ОС) или приложением для хранения данных.
Секторы тома не обязаны храниться в смежных блоках физического носителя,
хотя при использовании томов может возникнуть такое впечатление. Примером
тома, хранящегося в смежных секторах, служит жесткий диск. Том также может
представлять собой результат объединения и слияния томов меньшего размера.
Общая теория разделов
Одной из важнейших концепций систем с использованием томов является созда-
создание разделов. Разделом называется совокупность смежных секторов на диске. По
определению раздел также является томом, поэтому эти термины часто путают. Я
буду называть том, которому принадлежит раздел, родительским томом этого раз-
раздела. Разделы используются во многих ситуациях, в том числе:
• в некоторых файловых системах максимальный размер меньше размера жест-
жесткого диска;
• на многих портативных компьютерах создается специальный раздел для хра-
хранения содержимого памяти при переходе компьютера в спящий режим;
• в системах UNIX разные каталоги хранятся в разных разделах, чтобы свести
к минимуму последствия от возможной порчи файловой системы;
• в системах на базе IA-32 с несколькими операционными системами (напри-
(например, Microsoft Windows и Linux) для каждой операционной системы может
потребоваться свой раздел.
Рассмотрим систему Microsoft Windows с одним жестким диском. Том жест-
жесткого диска делится на три тома меньшего размера, в каждом из которых имеется
своя файловая система. Windows присваивает этим томам имена С, D и Е (рис. 4.1).
Каждая операционная система и аппаратная платформа обычно использует
свой метод создания разделов. Некоторые варианты реализации описаны в гла-
главах 5 и 6, но сейчас мы познакомимся с основными компонентами. Типичная си-
система разделов содержит одну или несколько таблиц, при этом каждая запись таб-
таблицы описывает один раздел. В данных записи обычно указывается начальный
сектор раздела, конечный сектор раздела (или длина) и тип раздела. На рис. 4.2
показан пример таблицы с тремя разделами.

Рис. 4.2. Таблица с информацией о начале, конце и типе каждого раздела
Система разделов предназначена для логической организации структуры тома;
следовательно, действительно необходимы только данные о начале и конце каж-
каждого раздела. Если эти данные будут повреждены или пропадут, система разделов
не сможет выполнять свои функции. Все остальные поля (например, тип и описа-
описание) несущественны и могут содержать ложную информацию.
Как правило, первый и последний секторы раздела не содержат никаких при-
признаков, по которым их можно было бы идентифицировать как граничные секто-
секторы. Ведь границы земельных участков тоже обычно не помечаются на местности.
Для определения точного положения границ необходим инспектор и документа-
документация (аналог структур данных разделов). Если структуры данных разделов отсут-
отсутствуют, границы иногда удается восстановить, если вы знаете, какая информация
хранится в разделе. Можно провести аналогию с восстановлением границ участ-
участков по особенностям местности.
Помните, что система разделов зависит от операционной системы и не имеет
отношения к типу интерфейса жесткого диска. Таким образом, система Windows
использует одну систему разделов как для дисков с интерфейсом АТА, так и для
дисков SCSI.
Использование томов в UNIX
Системы UNIX работают с томами не так, как Windows. Этот раздел предназна-
предназначен для пользователей, незнакомых с UNIX; в нем приводится краткий обзор ис-
использования томов в UNIX. За дополнительной информацией следует обратить-
обратиться к системному администратору UNIX.

В UNIX пользователь работает не с «дисками» С:, D: и т. д., а с набором ката-
каталогов, иерархия которых начинается с корневого каталога/. Подкаталоги/являют-
Подкаталоги/являются либо подкаталогами той лее файловой системы, либо точками монтирования
для новых файловых систем и томов. Например, дисководу CD-ROM в Windows
может быть присвоено обозначение Е:, но в Linux он может монтироваться под
именем /mnt/cdrom. В результате простое переключение между каталогами может
приводить к переходу с диска на диск, причем пользователь в большинстве слу-
случаев даже и не подозревает об этом. На рис. 4.3 показано, как организован доступ
к жестким дискам и компакт-дискам в Windows и UNIX.
Рис. 4.3. Точки монтирования двух томов и диска CD-ROM (A) — Microsoft Windows,
и (В) — в типичной системе UNIX
Чтобы свести к минимуму последствия от повреждения дисков, а также по-
повысить эффективность, UNIX обычно разбивает разделы каждого диска на не-
несколько томов. В томе корневого каталога (/) хранится основная информация;
отдельный том может существовать для домашних каталогов пользователей (/
home/), а приложения могут находиться в отдельном томе (/usr/). Однако все
системы уникальны, и в них могут использоваться совершенно различные схе-
схемы формирования и монтирования томов. В некоторых системах используется
один большой том для корневого каталога, а сегментирование системы отсут-
отсутствует.
Общая теория объединения томов
В крупных системах используются средства объединения томов, благодаря кото-
которым несколько дисков выглядят как один. В частности, это может делаться для
введения избыточности на случай сбоя диска. Если данные записываются на не-
несколько дисков, то в случае сбоя одного из дисков будет существовать резервная
копия. Другая возможная причина — простота добавления новых носителей. В ре-
результате объединения создается один большой том, пространство памяти которо-
которого включает пространства всех составляющих томов. Добавление новых дисков
в объединенный том не влияет на существующие данные. Эта методика будет рас-
рассматриваться в главе 7.
Рассмотрим простой пример. На рис. 4.4 изображены два тома жестких дис-
дисков, которые в сумме содержат три раздела. Разделу 1 присваивается имя тома С:,
а разделы 2 и 3 обслуживаются специальным устройством. Устройство формирует

из них один большой том, разбитый на два раздела, которым присвоены имена
томов. Учтите, что в данном случае устройство не повышает надежности хране-
хранения данных, а лишь увеличивает размер тома.
Рис. 4.4. Два раздела объединяются в один том с последующим разбиением
Адресация секторов
В главе 2 обсуждались методы адресации секторов. В самом распространенном
методе используются адреса LBA, которые представляют собой последователь-
последовательные числа, начиная с 0 (первый сектор диска). Этот адрес называется физическим
адресом сек гора.
Том представляет собой совокупность секторов, и каждому сектору необходи-
необходимо присвоить адрес. Абсолютным логическим адресом называется адрес сектора
относительно начала тома. Поскольку диск по определению является томом, фи-
физический адрес может рассматриваться как абсолютный логический адрес для дис-
дискового тома. Начало и конец раздела обычно задаются с использованием абсо-
абсолютных логических адресов.
Когда речь заходит о содержимом разделов, появляется еще один уровень ло-
логической адресации томов. Эти адреса задаются по отношению к началу раздела,
а не к началу диска или родительского тома и называются относительными логи-
логическими адресами. Если сектор не принадлежит ни одному разделу, он не имеет
относительного логического адреса. На рис. 4.5 показан пример с двумя раздела-
разделами и нераспределенным пространством между ними. Первый раздел начинается
с сектора 0, поэтому абсолютные логические адреса разделов в нем совпадают с от-
относительными логическими адресами. Второй раздел начинается с физического
сектора 864, поэтому абсолютные логические адреса в нем на 864 сектора больше
соответствующих относительных.

Рис. 4.5. Относительные логические адреса отсчитываются
от начала раздела, а абсолютные — от начала диска
Основы анализа
Задача анализа томов возникает достаточно часто, хотя это и не всегда очевидно.
Во многих случаях эксперт снимает информацию со всего жесткого диска и им-
импортирует образ в аналитическую программу для просмотра содержимого файло-
файловой системы. Чтобы определить, где начинается и заканчивается файловая систе-
система, программа должна проанализировать таблицы разделов.
У анализа структуры разделов томов имеется еще одно важное применение:
некоторые секторы, не принадлежащие ни одному разделу, могут содержать дан-
данные из предыдущей файловой системы или другую информацию, которую
подозреваемый пытается скрыть. Иногда система разделов может оказаться
поврежденной или стертой, и тогда средства автоматизированного анализа рабо-
работать не будут.
Методы анализа
Базовый принцип анализа томов прост: мы хотим найти таблицы разделов, обра-
обработать их и узнать структуру диска. Затем полученные данные передаются про-
программе анализа файловой системы, которой необходимо знать смещение разде-
разделов, или выводятся на печать, чтобы пользователь мог выбрать данные для анализа.
В некоторых случаях данные, находящиеся в разделах или в пространстве между
разделами, приходится извлекать из родительского тома (см. далее). Для анализа
данных в разделах необходимо решить, к какому типу они относятся. Чаще всего
это данные файловых систем, которые будут рассматриваться в третьей части
книги.
Чтобы проанализировать компоненты системы томов, необходимо найти и об-
обработать структуры данных с информацией об объединяемых томах и о том, как
именно это делается. Как будет показано в главе 7, существует много способов
объединения томов. Мы займемся поиском данных, не используемых в процессе
объединения и содержащих информацию от предыдущей установки или скры-
скрытую.

Проверка целостности
При анализе систем томов бывает полезно проверить каждый раздел по отношению
к другим разделам. Возможно, результат выявит другие возможные местоположе-
местоположения улик, не принадлежащих ни одному разделу. Системы разделов чаще всего не
требуют, чтобы записи хранились в отсортированном порядке, поэтому перед про-
проведением проверки вы или ваша аналитическая программа можете отсортировать
их по адресу начального или конечного сектора.
Проверки первого типа находят последний раздел и сравнивают его конечную
границу с концом родительского тома. В идеальном случае последний раздел за-
завершается в последнем секторе тома. На рис. 4.6 (А) изображена ситуация, при
которой последний раздел заканчивается перед концом тома, и на томе могут ос-
оставаться секторы со скрытыми или удаленными данными.
Проверки второго типа сравнивают начальный и конечный секторы смежных
разделов; возможны четыре варианта. В первом варианте (рис. 4.6 (В)) между дву-
двумя разделами находятся секторы, не входящие ни в один из них. Секторы, не при-
принадлежащие к разделам, могут содержать скрытую информацию, поэтому их обя-
обязательно необходимо проанализировать. Второй вариант (рис. 4.6 (С)) встречается
практически во всех системах; второ.й раздел здесь начинается сразу же после пер-
первого.
Рис. 4.6. Пять вариантов взаимного расположения разделов.
Первые три варианта допустимы, последние два — нет
Третий вариант (рис. 4.6 (D)), при котором второй раздел начинается раньше
завершения первого, в общем случае недопустим. Секторы двух разделов пере-
перекрываются, что, как правило, свидетельствует о повреждении таблицы разделов.
Чтобы определить, какие разделы допустимы (и есть ли они вообще), необходи-
необходимо проанализировать данные в каждом разделе. Четвертый вариант показан на
рис. 4.6 (Е); как правило, он тоже недопустим. Второй раздел находится внутри
первого, и для определения ошибки необходимо проанализировать содержимое
обоих разделов.

Получение содержимого разделов
Некоторые программы в качестве входных данных должны получать образы разде-
разделов. А может быть, вам потребуется извлечь данные из разделов (или промежуточно-
промежуточного пространства) в отдельный файл. В этом разделе будет показано, как произво-
производится выборка данных, а описанные методы работают во всех системах разделов.
Если структура разделов известна, выборка данных становится несложным делом.
Вы уже знаете, как это сделать при помощи программы dd, ранее описанной в главе 3.
Программа dd работает в режиме командной строки, а при вызове ей передает-
передается ряд аргументов. Для получения данных из разделов потребуются следующие
параметры:
• if — образ, из которого читаются данные;
• of — выходной файл для сохранения данных;
• bs — размер читаемого блока E12 байт по умолчанию);
• 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 @xA6)
05: 00:01 0004209030 0006265349 0002056320 NTFS @x07)
Утилита mm Ls упорядочивает содержимое таблицы разделов по начальному сек-
сектору и выделяет секторы, не принадлежащие ни одному разделу. Первые две стро-
строки @0 и 01) описывают основную таблицу разделов и неиспользуемое простран-
пространство между таблицей разделов и первым разделом. Из листинга видно, что строка
02 определяет раздел с файловой системой FAT32, строка 04 относится к разделу
OpenBSD, а строка 05 — к разделу с файловой системой NTFS. Строка 03 обозна-
обозначает нераспределенное дисковое пространство. Графическое представление этих
данных показано на рис. 4.7.
Чтобы извлечь разделы файловых систем из образа диска, следует отметить
начальный сектор и размер каждого раздела и передать их dd:
# dd if-diskl.dd of-partl.dd bs=512 skip=63 count=1028097
# dd if-diskl.dd of=part2.dd bs=512 skip=2570400 count=1638630
# dd if=diskl.dd of=part3.dd bs=512 skip=4209030 count=2056320

Рис. 4.7. Структура образа диска из примера
Эти команды берут входные данные из файла diskl.dd и сохраняют вывод в фай-
файлах с именами parti.dd, part2.dd и part3.dd. Во всех случаях размеры копируемых
блоков составляют 512 байт. Перед извлечением первого раздела dd пропускает
64 блока, а затем копирует следующие 1 028 097 блоков. В выходных данных mm ls
мы видели, что раздел начинается с сектора 63, поэтому вроде бы пропускать нужно
только 62 блока. Однако следует вспомнить, что адресация секторов начинается
с 0, поэтому мы пропускаем 63. Расширение .dd указывает на то, что файлы содер-
содержат физические образы, созданные программой dd или ее аналогом.
Некоторые программы выводят только начальный и конечный секторы каж-
каждого раздела, а размер разделов приходится вычислять самостоятельно. Для это-
этого следует вычесть начальный сектор из конечного и прибавить 1 (вычитание оп-
определяет расстояние между двумя числами, но в нашем случае последнее число
необходимо включить в результат). Например, в предыдущем примере размер пер-
первого раздела составит
1028159 - 63 + 1 - 1028097
Чтобы понять, для чего нужно прибавлять 1, рассмотрим простой пример: раз-
раздел начинается с сектора 2 и заканчивается в секторе 4. Его размер равен 3 секто-
секторам:
4-2+1 = 3
Программа dd также может использоваться для выборки данных, находящих-
находящихся между разделами. Например, из выходных данных mm ls мы знаем, что секторы
с 1 028 160 по 2 570 399 не используются. Их содержимое извлекается командой
# dd if«diskl.dd of-unallocl.dd bs=512 skip=1028160 count=1542240
Другие низкоуровневые программы (такие, как шестнадцатеричные редакто-
редакторы) также предоставляют возможность сохранения последовательных секторов
в файлах.
Восстановление удаленных разделов
Желая помешать цифровой экспертизе, злоумышленники часто заново разбива-
разбивают диск на разделы или стирают информацию о существующих разделах. Похожая,
но более безобидная проблема возникает при восстановлении системы с повреж-
поврежденными структурами разделов. В таких ситуациях анализ заметно усложняется.
К счастью, существует несколько программ, упрощающих восстановление разде-
разделов. В этом разделе будет рассказано, как работают эти программы.
Средства восстановления разделов исходят из предположения, что в каждом
разделе находилась файловая система. Многие файловые системы начинаются со
структуры данных с постоянной сигнатурой. Например, файловая система FAT

содержит значения 0x55 и ОхАА в байтах 510 и 511 первого сектора. Программа
восстановления ищет сигнатуры и определяет по ним возможное начало раздела.
При обнаружении сигнатуры часто выполняются дополнительные проверки
с диапазонами значений, допустимых для некоторых полей структуры данных.
Например, одно из полей файловой системы FAT определяет количество секто-
секторов в кластере; значение поля представляет собой степень 2 (например, 1, 2, 4, 8,
16, 32, 64 или 128). Любое другое значение свидетельствует о том, что сектор не
является частью загрузочного сектора файловой системы FAT, хотя он и закан-
заканчивается сигнатурой 0х55АА.
Механизм поиска зависит от конкретной программы. Одни программы про-
просматривают каждый сектор и сравнивают его содержимое с известными сигнату-
сигнатурами. Другие анализируют данные только на границах цилиндров, потому что
разделы чаще всего создаются именно там. Третьи по данным служебных струк-
структур определяют размер файловой системы и переходят к ее концу, где продолжа-
продолжают поиск других известных структур данных.
Например, в системе Linux для восстановления разделов применяется програм-
программа 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(DOS FAT). size(800mb), offset(Omb)
type: 006@x06)(Primary 'big' DOS (>32MB))
size: 800mb #sA638566) sF3-1638628)
chs: @/l/l)-A01/254/62)d @/1/1)-A01/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@x06)(Primary 'big1 DOS (>32MB))
size: 917mb #sA679604) sA638630-3518233)
chs: A02/0/1)-B18/254/62)d A02/0/1)-B18/254/62)г
hex: 00 00 01 66 06 FE 3E DA E6 00 19 00 34 AE 1С 00
Possible partitiondinux ext2). sizeE02mb). offsetA874mb)
type: 131@x83)(Linux ext2 filesystem))
size: 502mb #sA028160) sC839535-4867694)
chs: B39/0/1)-C02/254/63)d B39/0/1)-C02/254/63)r
hex: 00 00 01 EF 83 FE 7F 2E 2F 96 ЗА 00 40 ВО OF 00
Из результатов видно, что на диске, по всей вероятности, существовало два
раздела FAT и один раздел Ext2. Поле в конце строки size: показывает местона-
местонахождение раздела в секторах. Если бы флаг -v не был задан, то эта информация не

выводилась бы. Другая аналогичная утилита — TestDisk Кристофа Гренье (Christophe
Grenier) (http://www.cgsecurity.org/testdisk.html). Помните, что автоматизирован-
автоматизированное восстановление работает только при простейшем удалении или повреждении
таблицы разделов.
Итоги
Все носители информации большого объема содержат некоторую разновидность
системы томов, которая анализируется при каждом расследовании (даже если это
не очевидно). Системы томов предназначены для логической организации носи-
носителей, а системы разделов описывают начало и конец каждого раздела. В этой
главе был приведен общий обзор технологии, а в следующей главе мы подробно
рассмотрим несколько систем создания разделов и томов.

Разделы
на персональных
компьютерах
В предыдущей главе был приведен общий обзор анализа томов и показано, поче-
почему он так важен. Теперь от абстрактного обсуждения томов мы перейдем к под-
подробностям систем разделов, используемых на персональных компьютерах. В этой
главе будут рассматриваться разделы DOS, разделы Apple и съемные носители.
Для каждой системы будут описаны основные принципы работы и структуры дан-
данных. Если вас не интересуют подробности структур данных, эти описания можно
пропустить. В главе также перечислены некоторые особые обстоятельства, кото-
которые необходимо учитывать при анализе разделов в этих системах. Следующая
глава будет посвящена системам формирования разделов на серверах.
Разделы в DOS
Наибольшее распространение получила система разделов DOS. Разделы DOS в те-
течение многих лет использовались на платформе Intel IA32 (то есть i386/x86), од-
однако официальная спецификация до сих пор отсутствует. Существует много до-
документов (опубликованных как Microsoft, так и сторонними источниками), но
стандартного описания нет.
Более того, нет не только стандартного описания, но pi стандартного названия.
Компания Microsoft называет диски с подобным типом системы разделов диска-
дисками MBR (Master Boot Record) — в отличие от дисков GPT(GUID Partition Table),
используемых в системах EFI (Extensible Firmware Interface) и 64-разрядных сис-
системах на базе Intel Itanuim (IA64), о которых речь пойдет в следующей главе
[Microsoft, 2004a]. Начиная с Windows 2000, компания Microsoft также ввела раз-
различия между базовыми и динамическими дисками. Базовым может быть диск MBR
или GPT, при этом разделы диска независимы и автонохмны. Динамические дис-
диски, рассматриваемые в главе 7, могут быть дисками MBR или GPT, а их разделы
могут объединяться в один раздел большего размера. Базовые диски традицион-
традиционно ассоциируются с разделами DOS, а диски GPT еще не получили широкого рас-
распространения. Таким образом, если пользоваться современной терминологией,
в этой главе будут рассматриваться базовые диски MBR. Тем не менее в книге
для краткости будет использоваться термин «разделы DOS».
Разделы DOS применяются в Microsoft DOS, Microsoft Windows, Linux и в сис-
системах FreeBSD и OpenBSD на платформе IA32. Эта система получила наибольшее
распространение, но она же оказалась наиболее сложной. Дело в том, что система
проектировалась в 1980-х годах для малых систем, а потом постепенно адаптиро-
адаптировалась для больших современных систем. Фактически в ней задействованы два

разных метода определения разделов. Далее приводится общая характеристика
системы и ее основных структур данных, представлены программы сбора инфор-
информации о разделах на диске, а также некоторые соображения, которые должны учи-
учитываться при анализе.
Общий обзор
Здесь будут представлены основные концепции разделов 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, что-
чтобы раздел не отображался при повторной загрузке системы.
Каждая запись также содержит флаг, который указывает, является ли раздел
«загрузочным». По этому флагу определяется местонахождение операционной

системы при загрузке компьютера. Используя четыре записи в MBR, можно опи-
описать простую структуру диска, содержащего не более четырех разделов. На рис. 5.1
показан пример диска с двумя разделами и MBR в первом секторе.
Рис. 5.1. Простой диск DOS с двумя разделами и MBR
Концепция расширенного раздела
MBR позволяет описать до четырех разделов. Тем не менее во многих системах
этого количества недостаточно. Допустим, имеется 12-гигабайтный диск, кото-
который пользователь хочет разделить на шесть 2-гигабайтных разделов, потому что
он использует несколько операционных систем. Описать шесть разделов при по-
помощи четырех записей невозможно.
Именно тот способ, который был выбран для решения этой проблемы, делает
разделы DOS такими сложными. Общий принцип состоит в следующем: в MBR
создается одна, две или три записи для обычных разделов, а затем формируется
«расширенный раздел», заполняющий все оставшееся место на диске. Прежде чем
двигаться дальше, стоит разобраться с некоторыми терминами. Первичным разде-
разделом файловой системы называется раздел, представленный записью в MBR и со-
содержащий файловую систему или другие структурированные данные. Первичным
расширенным разделом называется раздел, представленный записью в MBR и со-
содержащий вторичные разделы. На рис. 5.2 изображены три первичных раздела
файловой системы с одним первичным расширенным разделом.
Рис. 5.2. Диск DOS с тремя первичными разделами файловой системы
и одним первичным расширенным разделом
Чтобы понять, как устроен первичный расширенный раздел, придется забыть
практически все, о чем говорилось до настоящего момента. В MBR мы видели
централизованную таблицу с описанием нескольких разделов; теперь мы видим
связанный список разделов. Перед каждым разделом файловой системы хранит-
хранится служебная информация, описывающая этот раздел и местонахождение следу-
следующего раздела. Все разделы должны находиться в основном расширенном разде-
разделе, вот почему ему необходимо выделить максимум доступного пространства.

Вторичный раздел файловой системы, также называемый в Windows логическим
разделом, находится в границах основного расширенного раздела и содержит фай-
файловую систему или другие структурированные данные. Вторичный расширенный
раздел содержит таблицу разделов и дополнительный раздел файловой системы.
Каждый вторичный расширенный раздел представляет собой «обертку» для вто-
вторичного раздела файловой системы; он описывает местонахождение вторичного
раздела файловой системы и следующего вторичного расширенного раздела.
На рис. 5.3 показано, как работает система вторичных разделов. Вторичный
расширенный раздел 1 содержит таблицу разделов, в которой хранится информа-
информация о вторичном разделе файловой системы 1 и вторичном расширенном разделе.
Вторичный расширенный раздел 2 содержит таблицу разделов с информацией о
вторичном разделе файловой системы 2. Но в общем случае он также может со-
содержать ссылку на следующий вторичный расширенный раздел, и так далее, пока
не будет распределено все свободное дисковое пространство.
Рис. 5.3. Основной принцип и общая структура вторичных разделов
(расширенных и файловых систем)
Общая картина
Давайте объединим два метода определения разделов. Если в системе использу-
используется от одного до четырех разделов, то для их создания достаточно MBR и расши-
расширенные разделы не потребуются. Если количество разделов больше 4, в MBR со-
создается до трех первичных разделов файловой системы, а оставшееся место на
диске выделяется под первичный расширенный раздел.
В первичном расширенном разделе информация о разделах хранится в форма-
формате связанного списка. Для оптимизации схемы со связанным списком, описанной
ранее, можно отказаться от изначального создания вторичного расширенного раз-
раздела и поместить таблицу разделов в начало первичного расширенного раздела.
В этом случае таблица будет описывать одну вторичную файловую систему и один
вторичный расширенный раздел.

Рассмотрим пример. Имеется 12-гигабайтный диск, который требуется раз-
разбить на шесть 2-гигабайтных разделов. Первые три 2-гигабайтных раздела созда-
создаются в первых трех записях MBR, а оставшиеся 6 Гбайт выделяются под первич-
первичный расширенный раздел, включающий дисковое пространство от 6 до 12 Гбайт.
Остается определить еще три раздела в формате связанного списка. Мы ис-
используем таблицу разделов в первом секторе первичного расширенного раздела,
создаем вторичный раздел файловой системы в диапазоне от 6 Гбайт до 8 Гбайт
и создаем вторичный расширенный раздел в диапазоне от 8 Гбайт до 10 Гбайт.
Таблица разделов находится во вторичном расширенном разделе и содержит за-
записи вторичного раздела файловой системы в диапазоне от 8 Гбайт до 10 Гбайт и
вторичного расширенного раздела в диапазоне от 10 Гбайт до 12 Гбайт. Таблица
разделов находится в последнем вторичном расширенном разделе и содержит за-
запись последнего раздела файловой системы в диапазоне от 10 до 12 Гбайт. Схема
показана на рис. 5.4.
Рис. 5.4. Структура диска с шестью разделами файловой системы
Как утверждается в большинстве документов, расширенная таблица разделов
должна содержать не более одной записи для раздела вторичной файловой систе-
системы и одной записи для вторичного расширенного раздела. На практике многие
операционные системы не будут выдавать ошибку при использовании более двух
записей. В июле 2003 г. я опубликовал 160-мегабайтный образ диска [Carrier, 2003]

с шестью 25-мегабайтными разделами DOS в списке CFTT Yahoo! Groups (http:/
/groups.yahoo.com/group/cftt/). Образ содержал первичный расширенный раздел
с двумя записями вторичных разделов файловых систем и одной записью вто-
вторичного расширенного раздела. Одни системные программы правильно обраба-
обрабатывали запись третьего раздела, другие игнорировали его или вместо 25-мегабай-
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.

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 Сигнатура @хАА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, а диск разбит на

два раздела, то у раздела с операционной системой (например, C:\windows) будет
установлен флаг загрузочного раздела. С другой стороны, если загрузочный код
предлагает пользователю выбрать раздел для загрузки системы, флаг может ока-
оказаться лишним. Впрочем, некоторые загрузочные программы устанавливают его
после того, как пользователь выберет соответствующий раздел для загрузки.
Начальный и конечный адреса CHS состоят из головки (8 бит), сектора F бит)
и цилиндра A0 бит). Теоретически для каждого раздела должен быть задан только
один из двух адресов (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 FAT16, 32 Мбайт-2 Гбайт, CHS
0x07 NTFS
OxOb FAT32, CHS
ОхОс FAT32, LBA
ОхОе FAT16, 32 Мбайт-2 Гбайт, LBA
OxOf Расширенный раздел Microsoft, LBA
0x11 Скрытый раздел FAT12, CHS
0x14 Скрытый раздел FAT16, 16-32 Мбайт, CHS
0x16 Скрытый раздел FAT16, 32 Мбайт-2 Гбайт, CHS
Oxlb Скрытый раздел FAT32, CHS
Oxlc Скрытый раздел FAT32, LBA
Oxle Скрытый раздел FAT16, 32 Мбайт-2 Гбайт, LBA
0x42 Microsoft MBR, динамический диск
0x82 Solaris x86
0x82 Раздел подкачки Linux
0x84 Данные спящего режима
0x85 Расширенный раздел Linux
0x86 Набор томов NTFS
0x87 Набор томов NTFS
ОхаО Спящий режим
Oxal Спящий режим
0ха5 FreeBSD
Охаб OpenBSD

Тип Описание
0ха8 Mac OSX
0ха9 NetBSD
Oxab Mac OSX
0xb7 BSDI
0xb8 Раздел подкачки BSDI
Oxee Диск EFI GPT
Oxef Системный раздел EFI
Oxfb Файловая система Vmware
Oxfc Раздел подкачки Vmware
Обратите внимание, сколько разных типов разделов существует для файло-
файловых систем Microsoft в диапазоне от 0x01 до OxOf. Это объясняется тем, что опера-
операционные системы Microsoft используют тип раздела для определения способа
чтения и записи данных в раздел. Как говорилось в главе 2, Windows может ис-
использовать как традиционные, так и расширенные обработчики прерывания BIOS
INT13h. Расширенные обработчики INT 13h необходимы для работы с дисками
объемом более 8,1 Гбайт и применения адресации LBA (вместо CHS). Следова-
Следовательно, типы FAT16 0x04 и ОхОЕ одинаковы, но во втором случае ОС будет ис-
использовать расширенные обработчики при работе с BIOS. Аналогично, типы
ОхОВ и ОхОС представляют обычную и расширенную версии FAT32, а типы 0x05
и OxOF — обычную и расширенную версии расширенных разделов [Microsoft,
2004b]. «Скрытые» версии этих типов разделов содержат 1 вместо 0 в верхнем
полубайте, а для их создания применяются различные системные программы.
Чтобы продемонстрировать работу с MBR и таблицами разделов, мы извле-
извлечем информацию из реальной системы и разберем ее вручную. В качестве приме-
примера будем использовать компьютер с альтернативной загрузкой Windows и Linux,
на жестком диске которого находятся восемь разделов файловых систем.
Первый пример взят из первого сектора диска. Данные выводятся утилитой
xxd в Linux, но для получения информации также можно было воспользоваться
шестнадцатеричным редактором для Windows или UNIX. В Linux командная стро-
строка выглядела так:
# dd if=disk3.dd bs=512 skip=O count=l | xxd
В левом столбце выводится десятичное смещение в байтах, средние восемь стол-
столбцов содержат данные в шестнадцатеричном формате, а последний столбец — те
же данные в кодировке ASCII. Данные взяты из системы на базе IA32 с прямым
порядком байтов, при котором младшие (менее значащие) байты располагаются
по меньшим адресам, поэтому байты в средних столбцах переставляются. Содер-
Содержимое MBR выглядит так:
# dd if=disk3.dd bs=512 skip=O count=l | xxd
0000000: eb48 9010 8edO 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 <
0000416: 0075 f4c3 0000 0000 0000 0000 0000 0000 .u
0000432: 0000 0000 0000 0000 0000 0000 0000 0001
0000448: 0100 07fe 3f7f 3f00 0000 4160 If00 8000 ....?.?...A\ ...
0000464: 0180 83fe 3f8c 8060 lfOO cd2f 0300 0000 ....?..\ ../....

0000480: 018d 83fe 3fcc 4d90 2200 40b0 OfOO 0000 ....?.M.\@
0000496: Olcd 05fe ffff 8d40 3200 79eb 9604 55aa @2.y...U.
Первые 446 байтов содержат загрузочный код. В последних двух байтах секто-
сектора присутствует сигнатура 0хАА55 (хотя и в переставленном виде из-за порядка
байтов, используемого на данной платформе). Таблица разделов выделена жир-
жирным шрифтом и начинается со значения 0x0001 со смещением 446. Каждая стро-
строка выходных данных занимает 16 байт; каждая запись таблицы тоже занимает
16 байт. Таким образом, вторая запись начинается строкой ниже первой записи
с числа 0x8000. В табл. 5.4 приведены четыре записи таблицы разделов в описан-
описанной ранее структуре. Значения приводятся в шестнадцатеричной записи, а деся-
десятичные эквиваленты заключены в круглые скобки.
Таблица 5.4. Содержимое первичной таблицы разделов в образе диска
№ Флаг Тип Начальный сектор Размер
1 0x00 0x07 0x0000003f F3) 0x001f6041 B 056 257)
2 0x80 0x83 0x001f6080 B 056 320) 0x00032fcd B08 845)
3 0x00 0x83 0x0022904d B 265 165) 0x000fb040 A 028 160)
4 0x00 0x05 0x0032408d C 293 325) 0x0496eb79 G6 999 545)
По табл. 5.4 и типам разделов, перечисленным в табл. 5.3, можно предполо-
предположить, какие данные находятся в каждом разделе. Первый раздел должен содер-
содержать файловую систему NTFS (тип 0x07), второй и третий — файловые системы
Linux @x83), а четвертый — расширенный раздел @x05). Для второй записи ус-
установлен флаг загрузочного раздела. Присутствие расширенного раздела абсолют-
абсолютно логично, потому что ранее упоминалось о том, что на диске находятся 8 разде-
разделов. Структура диска для данной таблицы разделов показана на рис. 5.5.
Рис. 5.5. Структура диска после обработки первой таблицы
разделов данного примера (без соблюдения масштаба)
Структуры данных расширенного раздела
Ранее уже говорилось о том, что первый сектор расширенного раздела имеет ту
же структуру, что и MBR, но в расширенных разделах он используется для пост-
построения связанного списка. Записи таблицы разделов устроены несколько иначе,
потому что отсчет начальных адресов секторов ведется не от начала диска. Более
того, начальный сектор вторичного раздела файловой системы также отсчитыва-
ется не от начального сектора вторичного расширенного раздела.

Начальный адрес в записи вторичной файловой системы задается по отноше-
отношению к текущей таблице разделов — и это вполне логично, потому что вторичные
расширенные разделы служат «обертками» для разделов файловых систем. С дру-
другой стороны, начальный адрес вторичного расширенного раздела задается отно-
относительно первичного расширенного раздела.
Разберем пример, показанный на рис. 5.6. Первичный расширенный раздел на-
начинается с сектора 1000 и занимает 11 000 секторов. Его таблица разделов содержит
две записи. Первая запись описывает файловую систему FAT с начальным сектором
63, который в сумме с сектором текущей таблицы разделов дает 1063. Вторая запись
предназначена для расширенного раздела и начинается с сектора 4 000. В сумме с на-
начальным сектором первичного расширенного раздела A000) это дает сектор 5000.
Рис. 5.6. Диск с тремя вторичными расширенными разделами. Обратите внимание:
начальный сектор вторичных расширенных разделов задается по отношению
к началу первичного расширенного раздела в секторе 1000
Перейдем ко вторичному расширенному разделу (в секторе 5000). Первая за-
запись таблицы разделов описывает файловую систему NTFS с начальным секто-
сектором 63, который в сумме с адресом текущей таблицы разделов дает сектор 5063.
Вторая запись описывает расширенный раздел с начальным сектором 6500, кото-
который в сумме с сектором первичного расширенного раздела дает сектор 7500.

Давайте разберем еще один цикл, чтобы все окончательно прояснилось. Сле-
Следующий расширенный раздел начинается с сектора 7500. Первая запись файло-
файловой системы EXT3FS начинается с сектора 63, который в сумме с 7500 дает 7563.
Вторая запись описывает вторичный расширенный раздел, а ее начальное значе-
значение 9000 в сумме с 1000 дает сектор 10 000.
Вернемся к практическому примеру, в котором мы разбирали вручную табли-
таблицу разделов. Далее приводится содержимое первого сектора первичного расши-
расширенного раздела, находящегося в секторе 3 293 325:
# del if=disk3.dd bs=512 skip=O count=l | xxd
[...]
0000432: 0000 0000 0000 0000 0000 0000 0000 0001
0000448: Olcd 83fe 7fcb 3f00 0000 0082 ЗеОО 0000 ? >
0000464: 41cc 05fe bfOb 3f82 ЗеОО 40Ь0 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 OxOOOOOO3f F3) 0x001f6041 B 056 257)
6 0x00 0x05 0x003e823f D 096 575) 0x000fb040 A 028 160)
Запись 5 помечена типом файловой системы Linux @x83); таким образом,
раздел является вторичным разделом файловой системы, а его начальный сек-
сектор задается по отношению к началу текущего расширенного раздела (сектор
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.

Рис. 5.7. Структура диска после обработки второй таблицы разделов (без соблюдения масштаба)
Таблица 5.6. Содержимое первой вторичной расширенной таблицы разделов
в образе диска
№ Флаг Тип Начальный сектор Размер
7 0x00 0x82 0x0000003f F3) OxOOOfbOOl (I 028 097)
8 0x00 0x05 0x004e327f E 124 735) 0x000fb040 A 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-про-
Windows-программами (в том числе системами экспертного анализа и шестнадцатеричными
редакторами).
Команда fdisk входит в поставку Linux и отличается от одноименной програм-
программы, поставляемой с системой Windows. Fdisk может работать с устройством Linux
или файлом образа, сгенерированным программой dd. При запуске с флагом -L

программа выводит список разделов вместо перехода в интерактивный режим
с возможностью редактирования разделов. Флаг -и означает, что информация дол-
должна выводиться в секторах (вместо цилиндров). Для диска с разделами 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
Рис. 5.8. Структура диска после обработки третьей таблицы разделов (без соблюдения масштаба)
Обратите внимание на некоторые обстоятельства. В выходных данных указан
только первичный расширенный раздел (disk3.dd4). Вторичный расширенный раз-
раздел, в котором находится раздел подкачки Linux, обнаружен, но информация о нем
не выводится. Такой подход приемлем в большинстве случаев, потому что для
анализа абсолютно необходимы только первичный и вторичный разделы файло-
файловых систем, но все же следует помнить, что в результатах отображаются не все
записи таблицы разделов.

Выходные данные программы 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 @x07)
03: 00:01 0002056320 0002265164 0000208845 Linux @x83)
04: 00:02 0002265165 0003293324 0001028160 Linux @x83)
05: 00:03 0003293325 0080292869 0076999545 DOS Extended @x05)
06: 0003293325 0003293325 0000000001 Table #1
07: 0003293326 0003293387 0000000062 Unallocated
08: 01:00 0003293388 0007389899 0004096512 Linux @x83)
09: 01:01 0007389900 0008418059 0001028160 DOS Extended @x05)
10: 0007389900 0007389900 0000000001 Table #2
11: 0007389901 0007389962 0000000062 Unallocated
12: 02:00 0007389963 0008418059 0001028097 Linux swap @x82)
13: 02:01 0008418060 0009446219 0001028160 DOS Extended @x05)
14: 0008418060 0008418060 0000000001 Table #3
15: 0008418061 0008418122 0000000062 Unallocated
16: 03:00 0008418123 0009446219 0001028097 Linux @x83)
17: 03:01 0009446220 0017639369 0008193150 DOS Extended @x05)
18: 0009446220 0009446220 0000000001 Table #4
19: 0009446221 0009446282 0000000062 Unallocated
20: 04:00 0009446283 0017639369 0008193087 NTFS @x07)
21: 04:01 0017639370 0048371714 0030732345 DOS Extended @x05)
22: 0017639370 0017639370 0000000001 Table #5
23: 0017639371 0017639432 0000000062 Unallocated
24: 05:00 0017639433 0048271714 0030732282 Linux @x83)
Строки с пометкой Unallocated обозначают пространство между разделами,
а также между концом таблицы разделов и началом первого раздела. В выходных
данных mmls указан как конечный адрес, так и результат, что упрощает их исполь-
использование для извлечения содержимого разделов программой dd.
Результаты mmls сортируются по начальному сектору раздела, поэтому пер-
первый столбец содержит только порядковый номер строки и не имеет отношения
к положению записи в таблице разделов. Во втором столбце выводится таблица
разделов и положение записи в ней. Первое число определяет таблицу @ — пер-
первичная таблица, 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 (OxOB)
03: 0001028160 0002570399 0001542240 Unallocated
04: 00:03 0002570400 0004209029 0001638630 OpenBSD @xA6)
05: 00:01 0004209030 0006265349 0002056320 NTFS @x07)

Из листинга видно, что раздел NTFS находится в позиции перед разделом
OpenBSD, но раздел NTFS начинается после раздела OpenBSD. Также можно за-
заметить, что запись с пометкой 00:02 отсутствует, а 1 542 240 секторов между FAT
и OpenBSD также помечены как нераспределенные.
Факторы анализа
В этом разделе упоминаются некоторые обстоятельства, которые необходимо учи-
учитывать при анализе диска с разделами DOS. Для таблицы разделов и загрузочно-
загрузочного кода обычно хватает одного сектора, но, как правило, для MBR и расширенных
разделов выделяются 63 сектора, потому что разделы должны начинаться на гра-
границе цилиндра. Следовательно, раздел 0 расширенного раздела или MBR содер-
содержит код и таблицу разделов, а секторы 1-62 могут оставаться неиспользуемыми.
В неиспользуемых секторах может храниться дополнительный загрузочный код,
но также в них могут находиться данные от предыдущей установки, нули или скры-
скрытые данные. Windows XP не стирает данные в неиспользуемых секторах при со-
создании разделов на диске.
Разделы в большинстве случаев начинаются с сектора 63, и этим обстоятель-
обстоятельством можно воспользоваться для восстановления содержимого первого раздела,
так как при отсутствии таблицы разделов средства, упоминавшиеся в главе 4, ра-
работать не будут. Попробуйте извлечь данные, начиная с сектора 63. В этом случае
в выборку будут включены другие разделы из образа, но возможно, вам удастся
определить фактический размер раздела по данным файловой систехмы. Извлече-
Извлечение раздела программой dd осуществляется так:
# dd if=disk.dd bs=512 skip=63 of=part.dd
Теоретически расширенные разделы должны содержать только две записи: для
раздела вторичной файловой системы и вторичного расширенного раздела. Боль-
Большинство программ создания разделов следуют этим правилам, но существует воз-
возможность создать третий раздел вручную. Microsoft Windows XP и Red Hat 8.0
отобразили «лишний» раздел, когда расширенный раздел содержал более двух
записей, однако ни та, ни другая ОС не позволили создать такую конфигурацию.
Протестируйте свои аналитические программы и убедитесь в том, что в подобных
«неправильных» конфигурациях они выводят информацию обо всех разделах.
Значение в поле типа раздела учитывается не всегда. Windows использует поле
для идентификации разделов для монтирования, но в таких операционных систе-
системах, как Linux, пользователь получает доступ ко всем разделам. Таким образом,
пользователь может поместить файловую систему FAT в раздел, предназначен-
предназначенный (в соответствии с типом) для хранения данных спящего режима. Эта файло-
файловая система не будет монтироваться в Windows — только в Linux.
Некоторые версии Windows создают в MBR только один первичный раздел,
а все остальные разделы создают как расширенные. Другими словами, они не со-
создают три первичных раздела, прежде чем переходить к созданию расширенных
разделов.
Если часть таблицы разделов будет повреждена, возможно, придется таблицы
расширенных разделов искать на диске. Поиск следует производить по сигнатуре
0хАА55 в двух последних байтах секторах. Обратите внимание: в файловых
системах NTFS и FAT присутствуют в той же позиции первого сектора. Чтобы

отличить таблицу разделов от загрузочного сектора файловой системы, придется
проанализировать прочее содержимое сектора. Если сектор окажется загрузоч-
загрузочным сектором файловой системы, возможно, таблица разделов находится на 63
сектора раньше него.
Итоги
В современной компьютерной аналитике чаще всего приходится иметь дело с раз-
разделами DOS. К сожалению, схема разделов DOS также оказывается самой слож-
сложной, потому что при ее исходном проектировании не учитывались масштабы со-
современных систем. К счастью, существуют системные программы для получения
информации о структуре диска, используемом и неиспользуемом пространстве.
Многие системы UNIX, работающие на IA32-совместимых платформах, исполь-
используют разделы DOS в сочетании с собственными системами разделов. Следова-
Следовательно, каждый эксперт обязан хорошо разбираться в разделах DOS.
Разделы Apple
Компьютеры с операционной системой Apple Macintosh встречаются реже, чем
компьютеры с Microsoft Windows, однако их популярность возросла с выходом
Mac OS X, операционной системы на базе UNIX. Разделы, о которых пойдет речь,
применяются на последних портативных и настольных компьютерах Apple с сис-
системой OS X, более старых системах с Macintosh 9 и даже портативных устрой-
устройствах iPod, предназначенных для воспроизведения аудио в формате МРЗ. Карты
разделов также могут использоваться в файлах образов дисков, используемых
в Macintosh при пересылке файлов. Файлы образов дисков напоминают zip-фай-
zip-файлы в Windows или tar-файлы в UNIX. Их содержимое хранится в виде файловой
системы, которая может находиться в разделе.
Архитектура системы разделов в Apple является удачным компромиссом меж-
между сложностью разделов DOS и ограниченным количеством разделов в BSD. Раз-
Раздел DOS может описывать произвольное количество разделов, а структуры дан-
данных хранятся в смежных секторах диска. Далее приводится общий обзор разделов
Apple, подробно описываются их структуры данных и способы получения под-
подробной информации.
Общий обзор
Разделы Apple описываются специальной структурой данных — картой разделов
(partition map), находящейся в начале диска. Обработка этой структуры реализо-
реализована на уровне «прошивок» (встроенного кода), поэтому карта не содержит за-
загрузочный код, как в схеме разделов DOS. Каждая запись карты разделов опреде-
определяет начальный сектор раздела, размер, тип и имя тома. Структура данных также
содержит информацию о данных, хранящихся в разделе, — в частности, местона-
местонахождение области данных и загрузочного кода.

Первая запись обычно определяет максимальный размер карты разделов. На
компьютерах Apple создаются разделы для хранения драйверов оборудования,
поэтому главный диск системы Apple содержит множество разделов с драйвера-
драйверами и другим содержимым, не имеющим прямого отношения к файловой системе.
На рис. 5.9 показан пример структуры диска Apple с тремя разделами файловой
системы и одним разделом, в котором хранится карта разделов.
Рис. 5.9. Диск Apple с одним разделом, содержащим карту разделов,
и тремя разделами файловых систем
Как будет показано далее, в системах BSD используется другая структура раз-
разделов, называемая разметкой диска. Несмотря на то что Mac OS X базируется на
ядре BSD, в этой системе используется карта разделов Apple, а не разметки диска.
Структуры данных
От знакомства с базовыми концепциями разделов Apple можно переходить к рас-
рассмотрению структур данных. Как и в случае с другими структурами данных в книге,
если этот материал не представляет для вас интереса, его можно пропустить. Здесь
также приводятся выходные данные некоторых аналитических программ на при-
примере образа диска.
Запись карты разделов
Карта разделов Apple содержит несколько 512-байтовых структур данных, каждая
из которых представляет один раздел. Карта разделов начинается со второго секто-
сектора диска и продолжается до тех пор, пока не будут описаны все разделы. Структуры
данных разделов хранятся в смежных секторах, и в каждой записи присутствует
общее количество разделов. Структура записи карты разделов показана в табл. 5.7.
Таблица 5,7- Структура данных записей разделов Apple
Диапазон байтов Описание Необходимость
0-1 Сигнатура @x504D) Нет
2-3 Зарезервировано Нет
4-7 Общее количество разделов Да
8-11 Начальный сектор раздела Да
12-15 Размер раздела в секторах Да
16-47 Имя раздела в кодировке ASCII Нет

Диапазон байтов Описание Необходимость
48-79 Тип раздела в кодировке ASCII Нет
80-83 Начальный сектор области данных в разделе Нет
84-87 Размер области данных в секторах Нет
88-91 Состояние раздела (см. табл. 5.8) Нет
92-95 Начальный сектор загрузочного кода Нет
96-99 Размер загрузочного кода в секторах Нет
100-103 Адрес кода загрузчика Нет
104-107 Зарезервировано Нет
108-111 Точка входа в загрузочный код Нет
112-115 Зарезервировано Нет
116-119 Контрольная сумма загрузочного кода Нет
120-135 Тип процессора Нет
136-511 Зарезервировано Нет
Тип раздела задается в кодировке 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 skip=l | xxd
0000000: 504d 0000 0000 000a 0000 0001 0000 003f PM ?

0000016: 4170 706с 6500 0000 0000 0000 0000 0000 Apple
0000032: 0000 0000 0000 0000 0000 0000 0000 0000
0000048: 4170 706с 655f 7061 7274 6974 696f 6e5f Apple_partition_
0000064: 6d61 7000 0000 0000 0000 0000 0000 0000 map
0000080: 0000 0000 0000 003f 0000 0000 0000 0000 ?
0000096: 0000 0000 0000 0000 0000 0000 0000 0000
На компьютерах Apple используются процессоры Motorola PowerPC, поэтому
данные на них хранятся с обратным порядком байтов. В результате отпадает не-
необходимость в перестановке байтов, как в разделах DOS. В байтах 0-1 видна сиг-
сигнатура 0x504d, а в байтах 4-7 — количество разделов, равное 10 (ОхОООООООа).
Байты 8-11 показывают, что первый сектор диска является начальным сектором
раздела, а размер раздела составляет 63 сектора @x3f). Разделу присвоено имя
«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
Slot Start End Length Description
00: 0000000000 0000000000 0000000001 Unallocated
01: 00 0000000001 0000000063 0000000063 Apple_partition_map
02: 0000000001 0000000010 0000000010 Table
03: 0000000011 0000000063 0000000053 Unallocated
04: 01 0000000064 0000000117 0000000054 Apple_driver43
05: 02 0000000118 0000000191 0000000074 Apple_driver44
06: 03 0000000192 0000000245 0000000054 Apple_driver_ATA
07: 04 0000000246 0000000319 0000000074 Apple_driver_ATA
08: 05 0000000320 0000000519 0000000200 AppleJWDriver
09: 06 0000000520 0000001031 0000000512 Apple_Driver_IOKit
10: 07 0000001032 0000001543 0000000512 Apple_Patches
11: 08 0000001544 0039070059 0039068516 Apple_HFS
12: 09 0039070060 0039070079 0000000020 Applejree
В этих данных строки отсортированы по начальному сектору, а второй стол-
столбец показывает, какая запись карты содержит описание раздела. В данном приме-
примере записи уже хранятся в отсортированном виде. Из строки 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)

1: Apple_partition_map Apple 63 @ 1
2: Apple_Driver43*Macintosh 54 @ 64
3: Apple_Dnver43*Macintosh 74 @ 118
4: Apple_Driver_ATA*Macintosh 54 @ 192
5: Apple_Driver_ATA*Macintosh 74 @ 246
6: Apple_FWDriver Macintosh 200 @ 320
7: Apple_Driver_IOKit Macintosh 512 @ 520
8: Apple_Patches Patch Partition 512 @ 1032
9: Apple_HFS untitled 390668516 @ 1544 ( 18.6G)
10: Applejree 0+@ 39070060
Device block size=512. Number of Blocks=10053
DeviceType=0x0. DeviceId=0x0
Drivers-
1: @ 64 for 23. type-0xl
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 имеет довольно простую структуру, и понять ее несложно.
Структуры данных хранятся в одном месте, а максимальное количество разделов
зависит от того, каким образом производилось исходное разбиение диска. Программа

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 @x06)
Чтобы создать образ карты памяти, достаточно вставить ее в устройство чте-
чтения карт с интерфейсом 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

и создал компакт-диск с тремя сеансами. В системе OS X все три сеанса монтиро-
монтировались как файловые системы. При использовании диска в системе Linux после-
последний сеанс монтировался по умолчанию, но два других сеанса также можно было
смонтировать, указав их в команде mount. Для определения количества сеансов
на диске можно воспользоваться утилитой readcd (http://freshmeat.net/projects/
cdrecord/). Когда тот же диск был открыт в системе Microsoft Windows XP, сис-
система заявила, что он содержит недопустимую информацию, хотя программа
SmartProject ISO Buster (http://www.isobuster.com) увидела все три сеанса. Даже
если многосеансовый диск создавался в Windows, возможны разные варианты
поведения. Таким образом, при анализе CD-R очень важно использовать програм-
программу, позволяющую просмотреть содержимое всех сеансов, а не полагаться на стан-
стандартное поведение той платформы, на которой осуществляется анализ.
Некоторые компакт-диски также содержат разделы, специфические для «род-
«родной» операционной системы. Например, гибридные CD сочетают формат ISO
с форматом Apple — внутри сеанса используется карта разделов Apple и файло-
файловая система HFS+. К таким дискам применимы стандартные методы анализа для
платформы Apple. Например, вот как выглядит результат запуска mmls для гиб-
гибридного диска:
# mmls -t mac cd-slice.dmg
MAC Partition Map
Units are in 512-byte sectors
Slot Start End Length Description
00: 0000000000 0000000000 0000000001 Unallocated
01: 00 0000000001 0000000002 0000000002 Apple_partition_map
02: 0000000001 0000000002 0000000002 Table
03: 0000000003 0000000103 0000000101 Unallocated
04: 01 0000000104 0000762559 0000762456 Apple_HFS
Многие загрузочные компакт-диски тоже содержат систему разделов опреде-
определенной операционной системы. Загрузочные диски Sparc Solaris содержат струк-
структуру Volume Table of Contents в томе ISO, а в начале загрузочных компакт-дисков
Intel может находиться таблица разделов DOS. Эти структуры используются после
загрузки операционной системы с компакт-диска, а код, необходимый для загруз-
загрузки системы, хранится в формате ISO.
Библиография
• Agile Risk Management, «Linux Forensics — Week 1 (Multiple Session CDRs)».
March 19, 2004, http://www.agilerm.net/linuxl.htmL
• Apple, «File Manager Reference». March 1,2004. http://developer.apple.com/documen-
tation/Carbon/Reference/FHe_Manager/index.htmL
• Apple, «Inside Macintosh: Devices». July 3,1996. http://developer.apple.com/documen-
tation/mac/Devices/Devices-2.htmL
• Apple, «The Monster Disk Driver Technote». November 22, 1999. http://devel.o-
per.apple.com/technotes/pdf/tnll89.pdf.

• Brouwer, Andries. «Minimal Partition Table Specification». September 16, 1999.
http://www.win.tue.nl/~aeb/partitions/partition_tables.html.
• Brouwer, Andries. «Partition Types». December 12, 2004. http://www.win.tue.nl/
~aeb/partitions/partition_types.html.
• Carrier, Brian. «Entended Partition Test». Digital Forensics Tool Testing Images,
July 2003. http://dftt.sourceforge.net/testl/index.htmL
• CDRoller. Reading Data CD, n.d. http://www.cdroLler.com/htm/readdata.htmL
• ECMA. «Volume and File Structure of CDROM for Information Interchange».
ISO Spec, September 1998. http://www.ecma-international.org/publications/files/
ECMA-ST/Ecma-119.pdf.
• Landis, Hale. «How it Works: Master Boot Record». May 6, 2002. http://www.ata-
atapi.com/hiwmbr.htm.
• Microsoft. «Basic Disks and Volumes Technical Reference». Windows Server 2003
Technical Reference, 2004. http://www.microsoft.com.
• Microsoft. «Managing GPT Disks in Itamium-based Computers». Windows XP
Professional Resource Kit Documentation, 2004a. http://www.microsoft.com.
• Microsoft. «MS-DOS Partitioning Summary». Microsoft Knowledge Base Article
69912, December 20, 2004b. http://support.microsoft.com/default.aspx?scid=kb;EN-
US;69912.
• Stevens, Curtis, and Stan Merkin. «El Torito: Bootable CD-ROM Format Specifica-
Specification 1.0». January 25,1999. http://www.phoenix.com/resources/specs-cdrom.pdf.

Разделы в серверных
системах
В предыдущей главе было показано, как организовано хранение информации на
персональных компьютерах. Давайте посмотрим, как происходит создание томов
на серверах. В области основных концепций эта глава совершенно не отличается
от предыдущей. Более того, я разделил их только для того, чтобы материал был
представлен по главам среднего размера, и такое разделение было ничем не хуже
других возможных (хотя ничто не мешает использовать разделы DOS и Apple на
серверах). В этой главе мы познакомимся с системами разделов FreeBSD, NetBSD
и OpenBSD; системами разделов Sun Solaris; а также разделами GPT, поддержи-
поддерживаемыми в 64-разрядных системах Intel Itanium.
Разделы BSD
Компьютерным аналитикам все чаще приходится иметь дело с серверными сис-
системами BSD UNIX — такими, как FreeBSD (http://www.freebsd.org), OpenBSD
(http://www.openbsd.org) pi NetBSD (http://www.netbsd.org). Такие системы исполь-
используют собственные схемы формирования разделов, и в этой части будут описаны
соответствующие структуры данных. На практике чаще встречается система Linux,
но она использует только разделы DOS и не имеет собственных структур данных.
Многие системы BSD работают на оборудовании IA32 (то есть x86/i386), а при
их проектировании учитывалась возможность их совместного существования на
одном диске с продуктами Microsoft. Такие системы строятся на базе разделов
DOS, упоминавшихся в предыдущей главе. Системы BSD, работающие на другом
оборудовании, по всей вероятности, не будут использовать разделы DOS, но в
книге они не рассматриваются.
Прежде чем переходить к рассмотрению темы, необходимо понять одно важ-
важное обстоятельство: во время работы операционная система может выбрать раз-
разделы, доступ к которым предоставляется пользователю. Как будет показано, опе-
операционная система FreeBSD использует системы разделов DOS и FreeBSD, тогда
как OpenBSD и NetBSD используют только систему разделов BSD. Для данного
раздела необходимо хотя бы общее понимание разделов DOS.
Общий обзор
Система разделов BSD проще системы разделов DOS, но по своим возможностям
она уступает картам разделов Apple. Необходимые данные хранятся только в од-
одном секторе, который находится в разделе DOS (рис. 6.1). Это было сделано для

того, чтобы на том же диске могла быть установлена система Windows, а пользо-
пользователь мог выбрать загружаемую операционную систему. В таблице разделов DOS
создается запись для разделов FreeBSD, OpenBSD или NetBSD — типы 0ха5, Охаб
и 0ха9 соответственно. Раздел BSD является одним из первичных разделов DOS.
Рис. 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 просты. Получение информации
сводится к чтению одной структуры данных и обработке списка разделов. Впро-

чем, некоторые проблемы могут возникнуть с доступом к разделам. Например,
в системе с альтернативной загрузкой аналитик должен знать, обладал ли пользо-
пользователь доступом к разделу 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 она не нужна.
Рис. 6.2. Диск FreeBSD с именами устройств
FreeBSD, как и прочие разновидности UNIX, связывает с каждым разделом
и сегментом специальный файл устройства. Имя этого файла задается в соответ-
соответствии с номером раздела DOS и номером раздела BSD. Первичному диску АТА
присваивается базовое имя /dev/adO. Для каждого сегмента, также называемого
разделом DOS, к базовому имени прибавляется буква «s» и номер сегмента. На-
Например, первый сегмент обозначается именем /dev/adOsl, а второй — /dev/adOs2.
На любом сегменте с типом раздела FreeBSD система ищет структуру разметки
диска. Разделам в сегменте присваиваются буквенные обозначения на основании
положения их записей в таблице разделов разметки диска. Например, если вто-
второй раздел DOS принадлежит FreeBSD, первому разделу BSD будет присвоено
имя /dev/adOs2a, а второму — /dev/adOs2b. Также иногда для разделов BSD созда-
создается вторая группа имен устройств, не включающая в себя номера сегментов. На-
Например, имя /dev/adOa может использоваться как сокращенное обозначение раз-
раздела /dev/adOs2a (если раздел FreeBSD является вторым разделом DOS).
Некоторые разделы BSD имеют особый смысл. Раздел «а» обычно выполняет
функции корневого, в нем находится загрузочный код. Раздел «Ь» обычно содер-
содержит область подкачки, раздел «с» обычно представляет весь сегмент, а начиная
с «d», разделы могут содержать произвольную информацию. Я говорю «обычно»,

потому что эти разделы создаются большинством системных программ 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.
Рис. 6.3. Диск FreeBSD с именами устройств
Имена файлов устройств в OpenBSD похожи нате, что используются в FreeBSD.
Первичному устройству АТА назначается базовое имя /dev/wdO. Понятие «сег-
«сегментов» отсутствует, а имена разделов BSD обозначаются буквами. Следователь-
Следовательно, первому разделу BSD присваивается имя /dev/wdOa, а второму — /dev/wdOb.
Как и в FreeBSD, первый раздел обычно является корневым, а второй предназ-
предназначается для области подкачки. Третий раздел, /dev/wdOc в нашем примере, явля-
является устройством, представляющим весь диск. Вспомните, что в FreeBSD третий
раздел предназначался только для одного сегмента, или раздела, DOS.
Подведем итог: система OpenBSD предоставляет доступ только к разделам,
описанным в разметке диска OpenBSD. Анализ системы OpenBSD следует сосре-
сосредоточить на разделах, перечисленных в разметке диска.

Загрузочный код
Загрузочный код в системе BSD «окружает» структуру разметки диска, находя-
находящуюся в секторе 1 тома. В секторе 0 тома хранится загрузочный код, выполняе-
выполняемый при обнаружении загрузчиком MBR загрузочного раздела с типом BSD. Если
загрузочный код не помещается в секторе 0, он продолжается в секторе 2 и может
продолжаться до начала данных файловой системы, обычно в секторе 16.
Структуры данных
В этом разделе описываются структуры данных разметки диска BSD и приводит-
приводится пример обработки системных данных в системах FreeBSD и OpenBSD. Также
приводятся примеры результатов некоторых служебных программ.
Разметка диска
Посмотрим, как устроена структура данных, называемая разметкой диска. Если
этот материал вас не интересует, пропустите его и перейдите к примерам анализа
образов дисков. Я начну с общего описания разметки диска BSD, а затем перейду
к подробностям реализации FreeBSD и OpenBSD. В табл. 6.1 перечислены поля
этой структуры данных. Учтите, что некоторые поля могут быть не задействова-
задействованы в определении структуры диска, но при этом необходимы для выполнения
других операций.
Таблица 6.1. Структура данных разметки диска BSD
Диапазон Описание Необходимость
байтов
0-3 Сигнатура @x82564557) Нет
4-5 Тип диска Нет
6-7 Подтип диска Нет
8-23 Имя типа диска Нет
24-39 Имя идентификатора пакета Нет
40-43 Размер сектора в байтах Да
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 Время коммутации головок в микросекундах Нет

Таблица 6.1 {продолжение)
Диапазон Описание Необходимость
байтов
84-87 Время позиционирования дорожек в микросекундах Нет
88-91 Флаги Нет
92-111 Специфическая информация о диске Нет
112-131 Зарезервировано Нет
132-135 Сигнатура @x82564557) Нет
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.

Таблица 6.3, Типы разделов BSD
Тип Описание
0 Не используется
1 Область подкачки
2 Version 6
3 Version 7
4 System V
5 4.1BSD
6 Eighth edition
7 4.2BSD FFS (Fast File System)
8 Файловая система MSDOS D.4LFS)
9 4.4BSD LFS (Log Structured File System)
10 Используется, но имеет неизвестное или неподдерживаемое содержимое
11 OS/2 HPFS
12 CD-ROM (ISO9660)
13 Загрузчик
14 Диск vinum
Самой распространенной файловой системой для FreeBSD и OpenBSD явля-
является 4.2BSD FFS (Fast File System). Для этой системы также создается минимум
один раздел подкачки. Раздел NTFS обычно имеет тип «используется, но имеет
неизвестное содержимое».
Теперь рассмотрим пример системы, в которой установлены как FreeBSD, так
и OpenBSD. Содержимое таблицы разделов DOS выглядит так:
# mmls -t dos bsd-disk.dd
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 0002056319 0002056257 Win95 FAT32 (OxOB)
03: 00:01 0002056320 0008209214 0006152895 OpenBSD @xA6)
04: 00:02 0008209215 0019999727 0011790513 FreeBSD @xA5)
Мы видим, что диск содержит раздел FAT A Гбайт), раздел OpenBSD C Гбайт)
и раздел FreeBSD F Гбайт). В каждом из разделов 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 fO2b 3101 ? +1.
0000064: 0000 0000 0000 0000 lOOe 0100 0000 0000
[... НУЛИ ]

0000128: 0000 0000 5745 5682 Ь65е 1000 0020 0000 ....WEV..A
0000144: 0000 0100 501f 0300 8060 lfOO 0004 0000 ....P.../
0000160: 0708 1000 eO61 0900 dO7f 2200 0004 0000 a...."
0000176: 0108 1000 fO2b 3101 0000 0000 0000 0000 +1
0000192: 0000 0000 501f 0300 bOel 2b00 0004 0000 ....P _
0000208: 0708 1000 8056 0200 0001 2f00 0004 0000 V..../
0000224: 0708 1000 0000 0000 0000 0000 0000 0000
0000240: 0000 0000 3f4b ЗсОО 00f8 4000 0004 0000 ....?K<...@
0000256: 0708 1000 80a0 Of00 8057 3100 0004 0000 Wl
0000272: 0708 1000 4160 lfOO 3f00 0000 0000 0000 ....A\ .?
0000288: 0800 0000 9dae ЬЗОО 3f43 7d00 0000 0000 ?C}
0000304: OaOO 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
[...]
В байтах 0-3 и 132-135 присутствуют сигнатуры 0x825644557. После вто-
второй сигнатуры байты 138-139 показывают, что таблица разделов содержит 16
@x0010) записей. Таблица начинается в следующей строке с байта 148, продол-
продолжается шестнадцатью 16-байтовыми структурами и завершается в позиции 403.
Записи 11-16 не используются pi содержат нули. Оставшаяся часть сектора не
используется структурой разметки диска.
В табл. 6.4 приведены основные данные шестнадцати записей таблицы разде-
разделов. Десятичные эквиваленты заключены в скобки.
Таблица 6.4. Содержимое структуры разметки диска BSD в образе диска
Начало Размер Тип
1 0x001f6080 B 056 320) 0x00031f50 B04 624) 0x07 G)
2 0x00227fd0 B 260 944) 0х000961е0 F14 880) 0x01 A)
3 0x00000000 @) 0x01312bf0 A9 999 728) 0x00 @)
4 0x002belb0 B 875 824) 0x00031f50 B04 624) 0x07 G)
5 0x002f0100C 080 448) 0x00025680 A53 216) 0x07 G)
6 0x00000000 @) 0x00000000 @) 0x00 @)
7 0x0040f800 D 257 792) 0x003c4b3f C 951 423) 0x07 G)
8 0x00315780 C 233 664) 0x000fa080 A 024 128) 0x07 G)
9 OxOOOOOO3f F3) 0x001f6041 B 056 257) 0x08 (8)
10 0x007d433f (8 209 215) 0x00b3ae9d A1 775 645) OxOa A0)
Прежде чем переходить к подробному рассмотрению разделов, необходимо по-
познакомиться со специальными разделами BSD. Первый раздел — корневой — со-
содержит загрузочный код. Второй раздел хранит область подкачки, третий пред-
представляет весь диск, а четвертый и все последующие — произвольные разделы BSD.
Образ, использованный в нашем примере, соответствует этой схеме. Первый
раздел начинается вместе с разделом DOS в секторе 2 056 320. У второго разде-
раздела поле типа равно 1, что соответствует области подкачки. Третий раздел начи-
начинается в секторе 0, а его размер соответствует размеру всего диска. Разделы 4, 5,

7 и 8 относятся к типу 4.2BSD FFS, а их начальные секторы увеличиваются
вплоть до раздела 9. Раздел 9 начинается с сектора 63, а его тип соответствует
файловой системе FAT. Он представляет раздел FAT, описанный в первой за-
записи таблицы разделов DOS, в разметке диска BSD. Раздел 10 обладает неизве-
неизвестным типом. Он представляет раздел FreeBSD, который описан третьей запи-
записью в приведенной ранее таблице разделов DOS. Так как разделу 9 соответствует
буква «i», пользователь может обращаться к разделу FAT через имя /dev/wdOi.
Как говорилось ранее, OpenBSD игнорирует содержимое таблицы разделов DOS
после загрузки.
Таблица 6.5 показывает, какие разделы будут доступны для пользователя в си-
системе OpenBSD.
Таблица 6.5. Файловые системы, доступные в системе OpenBSD
Устройство Описание Точка Начальный Конечный сектор
монтирования сектор
/dev/wdOa 4.2FFS BSD / 2 056 320 2 260 943
/dev/wdOb Подкачка - 2 260 944 2 875 823
/dev/wdOc Весь диск - 0 19 999 727
/dev/wdOd 4.2FFS BSD /tmp/ 2 875 824 3 080 447
/dev/wdOe 4.2FFS BSD /home/ 3 080 448 3 233 663
/dev/wdOg 4.2FFS BSD /var/ 4 257 792 820 921
/dev/wdOh 4.2FFS BSD /usr/ 3 233 664 4 257 791
/dev/wdOi FAT Выбирается 63 2 056 319
пользователем
/dev/wdOj Раздел FreeBSD 8 209 215 19 984 859
Раздел FreeBSD нельзя смонтировать, потому что для этого необходимо сна-
сначала прочитать разметку диска для определения местонахождения файловой си-
системы. Для просмотра тех же данных из разметки диска можно воспользоваться
утилитой mm Ls, указав в командной строке тип bsd. Смещение раздела BSD долж-
должно задаваться с ключом -о, поскольку мы работаем с образом диска.
# mmls -t bsd -о 20563210 bsd-disk.dd
BSD Disk Label
Units are in 512-byte sectors
Slot Start End Length Description
00: 02 0000000000 0019999727 0019999728 Unused @x00)
01: 08 0000000063 0002056319 0002056257 MSDOS @x08)
02: 00 0002056320 0002260943 0000204624 4.2BSD @x07)
03: 01 0002260944 0002875823 0000614880 Swap @x01)
04: 03 0002875824 0003080447 0000204624 4.2BSD @x07)
05: 04 0003080448 0003233663 0000153216 4.2BSD @x07)
06: 07 0003233664 0004257791 0001024128 4.2BSD @x07)
07: 06 0004257792 0008209214 0003951423 4.2BSD @x07)
08: 09 0008209125 0019984859 0011776454 Unknown (OxOA)
Вспомните, что программа mm Ls сортирует выходные данные по начальному
сектору раздела, поэтому раздел FAT находится в начале, хотя он и занимает
восьмую позицию в таблице разделов (позиция указывается в столбце Slot).

Пример образа FreeBSD
Теперь давайте посмотрим, как выглядит раздел BSD в образе из нашего приме-
примера. Раздел начинается с сектора 8 209 215, а разметка диска находится во втором
секторе:
# dd if=bsd-disk.dd skip=8209216 bs=512 count=l | xxd
0000000: 5745 5682 0500 0000 6164 3073 3300 0000 WEV ad0s3...
0000016: 0000 0000 0000 0000 0000 0000 0000 0000
0000032: 0000 0000 0000 0000 0002 0000 3f00 0000 ?...
0000048: 1000 0000 814d 0000 f003 0000 fO2b 3101 M +1.
0000064: 0000 0000 0000 0000 lOOe 0100 0000 0000
[... НУЛИ ]
0000128: 0000 0000 5745 5682 b9ab 0800 0020 0000 ....WEV
0000144: 0000 0000 0000 0800 3f43 7d00 0008 0000 ?C}
0000160: 0708 0880 aO73 1700 3f43 8500 0000 0000 s..?C
0000176: 0100 0000 Ые8 ЬЗОО 3f43 7d00 0000 0000 ?C
0000192: 0000 0000 0000 0800 dfb6 9c00 0008 0000
0000208: 0708 0880 0000 0800 dfb6 9c00 0008 0000
0000224: 0708 0880 1175 8400 dfb6 a400 0008 0000 u
0000240: 0708 886f 0000 0000 0000 0000 0000 0000 ...o
0000256: 0000 0000 0000 0000 0000 0000 0000 0000
0000272: 0000 0000 ebOe 4254 5801 0180 f60f 8007 BTX
0000288: 0020 0000 fa31 c08e dObc 0018 8ec0 8ed8 . ...1
0000304: 666a 0266 9dbf OOle b900 3957 f3ab 5fbe fj.f 9W.._.
0000320: e296 ac98 91e3 ldac 92ad 93ad b608 dleb
0000336: 730b 8905 8875 0288 5505 83cO 048d 7dO8 S....U..U }.
[...]
По содержимому байтов 138-139 видно, что на диске создано восемь разделов.
Записи этих разделов находятся в байтах 148-275, а их расшифровка приводится
в табл. 6.6 (десятичные эквиваленты заключены в скобки).
Таблица 6.6. Содержимое структуры разметки диска BSD в образе диска FreeBSD
Начало Размер Тип
1 0x007d433f (8 209 215) 0x00080000 E24 288) 0x07 G)
2 0x0085433f (8 733 503) Ох001773аО A 536 928) 0x01 A)
3 0x007d433f (8 209 215) ОхООЬЗе8Ы A1 790 513) 0x00 @)
4 0x009cb6df A0 270 431) 0x00080000 E24 288) 0x07 G)
5 0x00a4b6df A0 794 719) 0x00080000 E24 288) 0x07 G)
6 0x00acb6df A1 319 007) 0x00847511 (8 680 721) 0x07 G)
7 0x00000000 @) 0x00000000 @) 0x00 @)
8 0x00000000 @) 0x00000000 @) 0x00 @)
Мы видим, что начальный сектор первого раздела BSD совпадает с началь-
начальным сектором раздела DOS, в котором находится разметка диска, и этот раздел
относится к типу 4.2BSD FFS. Вторая запись определяет область подкачки,
а третья относится только к секторам раздела DOS. Записи 4, 5 и 6 определяют
разделы с файловой системой FFS. В табл. 6.7 перечислены имена устройств
и приведены данные о местонахождении каждого раздела, доступного для поль-
пользователей FreeBSD.

Таблица 6.7. Файловые системы, доступные в системе FreeBSD
Устройство Описание Точка Начальный Конечный
монтирования сектор сектор
/dev/adOsl Раздел DOS FAT Выбирается 63 2 056 319
пользователем
/dev/ad0s2 Раздел DOS OpenBSD ~ 2 056 320 8 209 214
/dev/ad0s3a 4.2FFS BSD / 8 209 215 8 733 502
/dev/ad0s3b Область подкачки - 8 733 503 1027 430
/dev/ad0s3c Весь раздел DOS FreeBSD - 8 209 215 19 999 727
/dev/ad0s3d 4.2FFS BSD /tmp 10 270 431 10 794 718
/dev/ad0s3e 4.2FFS BSD /var 10 794 719 11319 006
/dev/ad0s3f 4.2FFS BSD /usr 11319 007 19 999 727
Для просмотра содержимого разметки диска можно воспользоваться програм-
программой mm Ls из пакета The Sleuth Kit. Результат выглядит так:
# mmls -t bsd -о 82092165 bsd-disk.dd
BSD Disk Label
Units are in 512-byte sectors
Slot Start End Length Description
00: 0000000000 0008209214 0008209215 Unallocated
01: 00 0008209215 0008733502 0000524288 4.2BSD @x07)
02: 02 0008209215 0019999727 0011790513 Unused @x00)
03: 01 0008733503 0010270430 0001536928 Swap @x01)
04: 03 0010270431 0010794718 0000524288 4.2BSD @x07)
05: 04 0010794719 0011319006 0000524288 4.2BSD @x07)
06: 05 0011319007 0019999727 0008680721 4.2BSD @x07)
Обратите внимание: пространство, выделенное под разделы FAT и OpenBSD,
помечено как «нераспределенное», поскольку для него отсутствуют записи в размет-
разметке диска. Для распределения данных по разделам необходима таблица разделов DOS.
Факторы анализа
Каждый раздел BSD в структуре разметки диска содержит поле типа, но в системах
BSD оно играет менее важную роль, чем в Microsoft Windows, так как Windows
по содержимому поля типа определяет, нужно ли присваивать разделу букву диска
или нет. В системах BSD для каждой записи в разметке диска создается устрой-
устройство, поэтому разделы могут монтироваться с любым типом. Следовательно, не-
необходимо убедиться в том, что раздел не содержит известной файловой системы,
даже если тип идентифицирует его как старый формат UNIX, поскольку раздел
может содержать другую распространенную файловую систему (например, FAT).
Максимальный размер разметки диска равен 404 байтам. Для разметок дисков,
содержащих только восемь записей, структура данных занимает всего 276 байт.
Это означает, что оставшаяся часть 512-байтового сектора может использоваться
для хранения скрытых данных (хотя и относительно небольших). Если в резуль-
результате повреждения таблицы разделов DOS определить местонахождение раздела
BSD не удается, проведите поиск сигнатуры 0x82564557. Сигнатура должна на-
находиться в байте 0 и байте 132 структуры разметки диска.

Помните, что в системе FreeBSD пользователь получает доступ как к разде-
разделам DOS, так и к разделам BSD. Таким образом, в ходе экспертизы необходимо
анализировать как разделы DOS, так и разделы BSD. Учтите, что в системе может
отсутствовать поддержка NTFS, чтобы пользователь не мог смонтировать раздел
NTFS (если он существует).
В OpenBSD пользователь имеет доступ только к разделам, перечисленным
в разметке диска. Поскольку OpenBSD игнорирует таблицу разделов DOS, мо-
может быть полезно сравнить содержимое таблицы разделов DOS с разметкой дис-
диска BSD. Проанализируйте разделы BSD и DOS, выявите возможные перекрытия
и промежутки. На рис. 6.4 показаны интересные примеры разделов BSD. Один из
разделов BSD храшггся в разделе DOS с типом NTFS. Если раздел NTFS содер-
содержит файловую систему NTFS, такая ситуация маловероятна, и ее следует проана-
проанализировать подробнее. На рисунке также показан раздел BSD, созданный в про-
пространстве, которое не было выделено разделу DOS. С точки зрения системного
администратора так поступать не рекомендуется, потому что другая программа
может выделить пространство под раздел DOS и уничтожить данные BSD, одна-
однако такая возможность существует.
Рис. 6.4. Диск с двумя разделами BSD в разделе DOS с типом OpenBSD, разделом BSD
в разделе DOS с типом NTFS и разделом BSD, не входящим в раздел DOS
Итоги
Разделы BSD описываются простой структурой данных, называемой разметкой
диска. У эксперта могут возникнуть определенные трудности с идентификацией
всех данных, доступных для пользователя в анализируемой системе. Системы
семейства BSD часто используются на серверах, которые зачастую становятся
объектами криминальных и корпоративных расследований. Если эксперт хоро-
хорошо разбирается в разделах BSD, это повысит качество расследования.

Сегменты Sun Solaris
Операционная система Solaris компании Sun Microsystems используется на боль-
больших серверах и на настольных системах. В ней применяются две разные схемы
формирования разделов, выбор зависит от размера диска и версии Solaris. В Solaris
9 появилась поддержка файловых систем, размер которых превышает 1 Тбайт,
и используются таблицы разделов EFI с 64-разрядным полем адреса [Sum, 2003].
Во всех остальных версиях Solaris используются структуры данных, напоми-
напоминающие уже описанную разметку диска BSD. Более того, главная структура дан-
данных тоже называется разметкой диска, хотя и имеет несколько иное строение.
Впрочем, этому не приходится удивляться, если учесть, что структуры различа-
различаются даже на Solaris для платформ Sparc и 1386. Ситуация дополнительно услож-
усложняется тем, что имена структур данных Solaris совпадают с именами BSD, но из-
изменяется смысл терминов. Например, в Solaris сегментом (slice) называется любой
из разделов этой системы. Для простоты я буду использовать в этом разделе тер-
термин «раздел Solaris», однако следует помнить, что в других книгах чаще встречает-
встречается официальная терминология. Мы начнем с общих характеристик архитектуры
Solaris, затем познакомимся со специфическими особенностями структур данных
Sparc и в завершение займемся спецификой структур данных i386.
Общий обзор
При установке Solaris на диске создается структура разметки диска. Ее точное
местонахождение зависит от аппаратной платформы (см. далее). Максимальное
количество разделов, описываемых разметкой диска, ограничено: для систем Sparc
оно 8, адля1386 — 16.
Описание каждого раздела на диске состоит из начального сектора, размера,
набора флагов и типа. Флаги указывают, доступен ли раздел только для чтения
и не запрещено ли его монтирование (как для областей подкачки). В других сис-
системах разделов, представленных в книге, поле типа использовалось для описания
типа файловой системы, но в Solaris оно обычно описывает точку монтирования
раздела. Например, некоторые типы обозначают разделы home, usr или var, дру-
другие — область подкачки или нераспределенное пространство. Полный список ти-
типов приведен в разделе «Структуры данных».
В Solaris используется хитроумная, но хорошо масштабируемая схема выбора
имен разделов. В среде Solaris блочные устройства находятся в каталоге/dev/dsk,
а неструктурированные устройства (raw devices) — в каталоге /dev/rdsk. В этих
каталогах разделам Solaris (или сегментам) присваиваются имена вида cWtXdYsZ
в системах Sparc и cWdYsZ в системах i386. В этом шаблоне W — номер контрол-
контроллера, X — идентификатор физической шины (SCSI ID), Y — номер диска на шине,
a Z — номер сегмента на диске. Например, если в системе Sparc имеется только
один контроллер, идентификатор SCSI ID диска равен 6, то для обращения к сег-
сегменту 5 следует использовать имя /dev/rdsk/c0t6d0s5.
В Solaris записи разделов в таблице разметки диска обычно создаются на ос-
основании точки монтирования. Это не является обязательным требованием, но
на дисках с операционной системой часто используется схема, представленная
в табл. 6.8.

Таблица 6.8. Типичная структура разметки диска
Запись Описание
0 /root/partition — операционная система и ядр
1 Область подкачки
2 Весь диск, включая разметку и все разделы
3 /export/
4 /export/swap/
5 /opt/
6 /usr/
7 /home/
На дополнительных дисках, включаемых в систему, часто создается всего один
раздел, для которого используется запись 5, 6 или 7.
Структуры данных Sparc
В системах на базе Sparc структура разметки диска создается в первом секторе
диска (сектор 0). Секторы 1-15 содержат загрузочный код системы, а в секторах
16 и далее создаются разделы для хранения файловых систем и областей подкач-
подкачки. В Solaris используется файловая система UFS; как будет показано в главе 16,
эта файловая система начинается с сектора 16. Пример строения диска Sparc по-
показан на рис. 6.5 и в табл. 6.9.
Рис. 6.5. Строение диска Sun Sparc: разметка диска и загрузочный код находятся в первом разделе
Таблица 6.9. Структура данных разметки диска Sun Sparc
Диапазон байтов Описание Необходимость
0-127 Метка в кодировке ASCII Нет
128-261 Sparc VTOC (см. табл. 6.10) Да
262-263 Пропускаемые секторы (модификация) Нет
264-265 Пропускаемые секторы (чтение) Нет
266-419 Зарезервировано Нет
420-421 Скорость диска Нет
422-423 Количество физических цилиндров Нет
424-^425 Коэффициент дублирования цилиндров Нет
426-429 Зарезервировано Нет
430-431 Коэффициент чередования Нет
432-433 Количество цилиндров данных Нет

Диапазон байтов Описание Необходимость
434-435 Количество альтернативных цилиндров Нет
436-437 Количество головок Да
438-439 Количество секторов в дорожке Да
440-443 Зарезервировано Нет
444-^51 Карта диска для раздела 1 (см. табл. 6.13) Да
452-459 Карта диска для раздела 2 (см. табл. 6.13) Да
460-467 Карта диска для раздела 3 (см. табл. 6.13) Да
468-475 Карта диска для раздела 4 (см. табл. 6.13) Да
476-483 Карта диска для раздела 5 (см. табл. 6.13) Да
484-491 Карта диска для раздела 6 (см. табл. 6.13) Да
492-499 Карта диска для раздела 7 (см. табл. 6.13) Да
500-507 Карта диска для раздела 8 (см. табл. 6.13) Да
508-509 Сигнатура (OxDABE) Нет
510-511 Контрольная сумма Нет
В байтах 128-261 находится оглавление тома (VTOC). Эта структура содер-
содержит общее количество разделов (байты 12-13), а также флаги, тип и временной
штамп для каждого раздела. Поля VTOC перечислены в табл. 6.10.
Таблица 6.10. Структура данных VTOC в разметке диска Sun Sparc
Диапазон байтов Описание Необходимость
0-3 Версия @x01) Нет
4-11 Имя тома Нет
12-13 Количество разделов Да
14-15 Тип раздела 1 (см. табл. 6.11) Нет
16-17 Флаги раздела 1 (см. табл. 6.12) Нет
18-19 Тип раздела 2 (см. табл. 6.11) Нет
20-21 Флаги раздела 2 (см. табл. 6.12) Нет
22-23 Тип раздела 3 (см. табл. 6.11) Нет
24-25 Флаги раздела 3 (см. табл. 6.12) Нет
26-27 Тип раздела 4 (см. табл. 6.11) Нет
28-29 Флаги раздела 4 (см. табл. 6.12) Нет
30-31 Тип раздела 5 (см. табл. 6.11) Нет
32-33 Флаги раздела 5 (см. табл. 6.12) Нет
34-35 Тип раздела 6 (см. табл. 6.11) Нет
36-37 Флаги раздела 6 (см. табл. 6.12) Нет
38-39 Тип раздела 7 (см. табл. 6.11) Нет
40-41 Флаги раздела 7 (см. табл. 6.12) Нет
42-43 Тип раздела 8 (см. табл. 6.11) Нет
44-45 Флаги раздела 8 (см. табл. 6.12) Нет
46-57 Загрузочная информация Нет
58-59 Зарезервировано Нет
60-63 Сигнатура @x600DDEEE) Нет
64-101 Зарезервировано Нет
102-105 Временной штамп раздела 1 Нет

Таблица 6.10 {продолжение)
Диапазон байтов Описание Необходимость
106-109 Временной штамп раздела 2 Нет
110-113 Временной штамп раздела 3 Нет
114-117 Временной штамп раздела 4 Нет
118-121 Временной штамп раздела 5 Нет
122-125 Временной штамп раздела 6 Нет
126-129 Временной штамп раздела 7 Нет
130-133 Временной штамп раздела 8 Нет
Поле типа каждого раздела VTOC указывает, для чего используется данный
раздел и где он должен монтироваться. Тем не менее при монтировании файло-
файловых систем операционная система руководствуется специальным конфигураци-
конфигурационным файлом. Таким образом, даже если раздел помечается типом /usr/, это еще
не означает, что он будет смонтирован как/usr/. В отличие от других систем, струк-
структура разметки диска Solaris не задает тип файловой системы для каждого раздела.
Допустимые значения типов разделов перечислены в табл. 6.11.
Таблица 6.11. Типы разделов Sun (для Sparc и i386)
Значение Описание Значение Описание
0 Не задано 6 Раздел /stand/
1 Раздел /boot/ 7 Раздел /var/
2 Раздел / 8 Раздел /home/
3 Раздел подкачки 9 Прочие разделы
4 Раздел /usr/ 10 Раздел cachefs
5 Весь диск
Каждый раздел также обладает полем флагов. Допустимые значения флагов пе-
перечислены в табл. 6.12 (установка хотя бы одного флага для раздела не обязательна).
Таблица 6.12. Значения флагов для разделов Sun (для Sparc и i386)
Значение Описание
1 Раздел не может монтироваться
128 Раздел доступен только для чтения
Вся эта информация полезна, но в контексте нашего обсуждения самой важ-
важной частью разметки диска является местонахождение разделов. Начальный ци-
цилиндр и размер каждого раздела хранятся в структурах карты диска, а не в VTOC.
Карта диска находится в конце структуры разметки диска, а поля ее записей пере-
перечислены в табл. 6.13.
Таблица 6,13, Структура данных карты диска Sun Sparc
Диапазон байтов Описание Необходимость
0-3 Начальный цилиндр Да
4-7 Размер Да

Однако нас интересует начальный сектор, а не цилиндр, поэтому значение при-
придется преобразовать — к счастью, это делается несложно. Вспомните, что цилиндр
X состоит из дорожек X на каждой пластине диска. Чтобы преобразовать адрес
цилиндра в адрес сектора, следует умножить адрес цилиндра на количество сек-
секторов в дорожке и количество головок (оба значения находятся в структуре раз-
разметки диска).
Для примера возьмем диск с 15 головками и 63 секторами на дорожку. Если
адрес начального цилиндра равен 1 112, вычисление дает следующий результат:
63 * 15 * 1112 - 1 050 840
Таким образом, мы должны обратиться к сектору 1 050 840 и проанализиро-
проанализировать данные при помощи программ с поддержкой схемы адресации LBA.
Давайте рассмотрим пример с реальными структурами в шестнадцатеричном
виде. Далее приводится содержимое первого сектора жесткого диска Solaris Sparc:
# dd if=sparc-disk.dd bs=512 count=l | xxd
0000000: 4d61 7874 6f72 2038 3532 3530 4136 2063 Maxtor 85250A6 с
0000016: 796c 2031 3038 3534 2061 6c74 2032 2068 yl 10854 alt 2 h
0000032: 6420 3135 2073 6563 2036 3300 0000 0000 d 15 sec 63
0000048: 0000 0000 0,000 0000 0000 0000 0000 0000
Г... НУЛИ ]
0000128: 0000 0001 0000 0000 0000 0000 0008 0002
0000144: 0000 0003 0001 0005 0000 0000 0000 0000
0000160: 0000 0007 0000 0004 0000 0008 0000 0000
0000176: 0000 0000 0000 0000 0000 0000 600d deee
[... НУЛИ ]
0000416: 0000 0000 1518 2a68 0000 0000 0000 0001 *h
0000432: 2a66 0002 OOOf 003f 0000 0000 0000 0826 *f ? &
0000448: 0020 bO6b 0000 0000 0010 0176 0000 0000 . .k v....
0000464: 009c 8286 0000 0000 0000 0000 0000 0000
0000480: 0000 0000 0000 0609 0007 cdOd 0000 1101
0000496: 005d bdd5 0000 0458 0006 3e61 dabe lffe .]....X..>a....
На платформе Sparc используется обратный порядок байтов, поэтому числа
переставлять не нужно. В первых восьми строках содержится 128-байтовая метка
в кодировке ASCII, описывающая тип жесткого диска. Таблица VTOC начинается
с позиции 128; байты 140-141 показывают, что структура содержит 8 разделов.
В байтах 142-173 перечислены типы B байта) и флаги B байта) для каждого разде-
раздела. Так, тип первого раздела содержится в байтах 142-143, и значение поля равно 2,
что соответствует разделу/. Флаги хранятся в байтах 144-145, значение поля равно
0. Байты 146-147 показывают, что второй раздел относится к типу 3 (область под-
подкачки), а поле флагов в байтах 148-149 равно 1 (раздел не монтируется).
В байтах 436-437 приводится количество головок 15 (OxOf), а в байтах 438-
439 — количество секторов на дорожку 63 @x3f)- Эти данные понадобятся для
преобразования адресов цилиндров.
Карта диска начинается с байта 444; начальный цилиндр и размер задаются 4-
байтовыми числами. У первого раздела начальный цилиндр равен 2 086 @x00000826),
а размер — 2 142 315 @x0020b06b). Вспомните, что разделу назначен тип /. На-
Начальный сектор вычисляется по следующей формуле:
15 * 63 * 2 086 - 1 971 270
Раздел находится в первой позиции таблицы, поэтому он будет считаться «сег-
«сегментом 0» диска, хотя он отдален от начала диска на многие тысячи секторов.

Описание следующего раздела хранится в байтах 452-459, с начальным цилинд-
цилиндром 0 и размером 1 048 950 @x00100176). Это пространство подкачки, соответ-
соответствующее «сегменту 1». Третья запись таблицы разделов, «сегмент 2», обычно
представляет весь диск и находится в байтах 460-467. В нашем примере ее на-
начальный цилиндр равен 0, а размер составляет 10 257 030 секторов.
Существует несколько программ, позволяющих просмотреть содержимое раз-
разметки диска Sparc, но не все они могут использоваться в процессе экспертизы.
Команды Solaris format и prvtoc работают только с устройствами, но не с файлами
образов устройств. С другой стороны, команда Linux fdisk успешно работает с об-
образами дисков Sparc. Также можно запустить программу mm Ls из пакета The Sleuth
Kit с параметром -t sun. Для образа диска из рассматриваемого примера програм-
программа mm Ls выдала следующий результат:
# mmls -t sun sparc-disk.dd
Sun VTOC
Units are in 512-byte sectors
Slot Start End Length Description
00: 01 0000000000 0001048949 0001048950 swap @x03)
01: 02 0000000000 0010257029 0010257030 backup @x05)
02: 07 0001050840 0001460024 0000409185 /home/ @x08)
03: 05 0001460025 0001971269 0000511245 /var/ @x07)
04: 00 0001971270 0004113584 0002142315 / @x02)
05: 06 0004113585 0010257029 0006143445 /usr/ @x04)
Структуры данных i386
Перед установкой Solaris в системе i386 необходимо предварительно создать один
или несколько разделов DOS. В типичной установке создается загрузочный раз-
раздел (тип раздела DOS OxBE) и раздел с файловыми системами (тип раздела 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 i386
Диапазон байтов Описание Необходимость
0-11 Загрузочная информация Нет
12-15 Сигнатура @x600DDEEE) Нет
16-19 Версия Нет

Диапазон байтов Описание Необходимость
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 Сигнатура (OxDABE) Нет
510-511 Контрольная сумма Нет
Рис. 6.6. Диск i386 Sun с тремя разделами DOS. Последний раздел содержит
разметку диска и три раздела Sun
Каждая из 16 записей разделов имеет структуру, показанную в табл. 6.15.

Таблица 6.15- Структура записи раздела в разметке диска Sun 1386
Диапазон байтов Описание Необходимость
0-1 Тип раздела (см. табл. 6.11) Нет
2-3 Флаг (см. табл. 6.12) Нет
4-7 Начальный сектор Да
8-11 Размер в секторах Да
В полях типа и флагов используются те же значения, которые прршодились
ранее для структур данных Sparc. Для идентификации разделов в Solaris на плат-
платформе i386 необходимо проанализировать записи разделов 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 '
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 lOOe 0000 0000 0000 0000 0000 0000
0000496: 0000 lOOe 0000 0000 0000 0000 beda a24a ]
Данные получены в системе i386, в которой используется прямой порядок бай-
байтов. По значению со смещением 30 мы видим, что таблица содержит 16 разделов
@x10). Первая запись раздела начинается со смещением 72 и заканчивается со
смещением 83. Байты 72-73 показывают, что запись имеет тип 0x02, то есть пред-
представляет корневой раздел. Начальный сектор в байтах 76-79 равен 1 052 352
(ОхООЮОЕСО). Байты 80-83 указывают размер раздела; мы видим, что он равен
4 096 512 @х003е8200). В данной разметке используются 10 разделов, описание
последнего находится в байтах 180-191. Все временные штампы равны нулю, а имя
тома состоит из слова DEFAULT и параметров геометрии диска.
Для получения информации о местонахождении загрузочного раздела и раз-
разделов файловых систем из образа диска i386 молено воспользоваться любой про-
программой, работающей с разделами DOS. При запуске mmls для диска Solaris на
платформе i386 был получен следующий результат:
# mmls -t dos i386-disk.dd
DOS Partition Table

Units are in 512-byte sectors
Slot Start End Length Description
00: 0000000000 0000000000 0000000001 Primary Table (#0)
01: 0000000001 0000001007 0000001007 Unallocated
02: 00:00 0000001008 0000021168 0000021168 Solaris 8 Boot (OxBE)
03: 0000022176 0000000320 0000000320 Unallocated
04: 00:01 0000022496 0024180911 0024158416 Linux swap / Solaris x86 @x82)
Напомню, что раздел типа ОхВЕ предназначен для загрузочного кода, файло-
файловая система в нем отсутствует. Файловые системы и структуры разметки диска
хранятся в разделах типа 0x82. Ту же информацию можно получить, запустив ути-
утилиту fdisk в Linux, но fdisk не включает разделы Solaris в разметку диска. Чтобы
просмотреть содержимое файловой системы, либо извлеките раздел, начиная с сек-
сектора 22 496, либо просто вызовите mmls и укажите смещение с параметром -о:
# 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 @x05)
01: 08 0000000000 0000001007 0000001008 boot @x01)
02: 09 0000001008 0000003023 0000002016 alt sector @x09)
03: 01 0000003024 0001052351 0001049328 swap @x03)
04: 00 0001052352 0005148863 0004096512 / @x02)
05: 05 0005148864 0021532895 0016384032 /usr/ @x04)
06: 07 0021532896 0023581151 0002048256 /home/ @x08)
Как говорилось ранее, адреса задаются по отношению к началу раздела DOS,
поэтому при извлечении данных программой dd необходимо увеличивать адреса
всех начальных секторов на 22 496. Эксперименты показали, что при загрузке
Linux с диском Solaris i386, подключенным как один из ведомых (slave) дисков,
Linux создает устройства только для первых восьми разделов Solaris. Для всех
последующих разделов устройства не создаются.
Факторы анализа
При анализе разделов Solaris действуют те же особые соображения, что и при ана-
анализе других систем разделов. Структура разметки диска содержит неиспользуе-
неиспользуемые поля, в которых могут находиться скрытые данные (хотя объем этого скры-
скрытого пространства невелик).
Как и в других системах разделов, поле типа в описании раздела не имеет стро-
строго обязательного смысла. Даже если в структуре разметки диска сказано, что раз-
раздел является разделом /var/ или содержит область подкачки, это еще не значит,
что это действительно так. Как всегда, проведите поиск неиспользуемого простран-
пространства на диске.
Если местонахождение разметки диска неизвестно, попробуйте провести по-
поиск по сигнатурам. Сигнатура 0x600DDEEE находится внутри разметки диска,
а сигнатура OxDABE хранится в байтах 508-509.
Итоги
Системы Solaris часто встречаются в корпоративных сетях и часто становятся
объектом экспертного анализа при попытках взлома и мошенничества. В этой

части книги было показано, как организованы диски Solaris и как вывести или
извлечь соответствующую служебную информацию. Структура разметки диска
относительно проста, а для ее чтения можно воспользоваться программами fdisk и
mmls.
Разделы GPT
Системы с 64-разрядными процессорами Intel Itanium (IA64), в отличие от си-
систем IA32, не имеют BIOS. Вместо этого в них используется интерфейс EFI
(Extensible Firmware Interface). EFI (http://www.inteL.com/technology/efi) работа-
работает не только на платформе Intel, но и на других платформах — например, в систе-
системах Sun Sparc. В EFI применяется система разделов GPT(GXJID Partition Table),
поддерживающая до 128 разделов с 64-разрядной адресацией LBA. На случай сбоя
в системе хранятся резервные копии важных структур данных. На момент напи-
написания книги диски GPT применялись на мощных серверах и практически не встре-
встречались в типичных настольных системах.
Общий обзор
Диск GPT состоит из пяти основных областей (рис. 6.7). Первая — защитная об-
область MBR — начинается в первом секторе диска и содержит таблицу разделов
DOS с единственной записью. Запись представляет раздел типа ОхЕЕ, распрост-
распространяющийся на весь диск. Этот раздел существует для того, чтобы старые компь-
компьютеры распознавали диск как используемый и не пытались форматировать его.
В действительности EFI не использует разделы в традиционном смысле.
Рис. 6.7. Диск GPT состоит из пяти областей
Вторая область диска GPT начинается с сектора 1 и содержит заголовок GPT.
Заголовок определяет размер и местонахождение таблицы разделов, которое фик-
фиксируется при создании диска GPT. В системе Windows количество разделов в таб-
таблице ограничивается 128 [Microsoft, 2004]. Заголовок также содержит контроль-
контрольную сумму заголовка и таблицы разделов, что позволяет обнаруживать ошибки
и посторонние изменения.
Третья область содержит таблицу разделов. Каждая запись таблицы содержит
начальный и конечный адреса, код типа, имя, флаги атрибутов и значение GUID.
128-разрядный код GUID является уникальным для данной системы и задается
при создании таблицы разделов.
Четвертая область диска — область раздела. Она занимает наибольшее диско-
дисковое пространство и содержит секторы, распределяемые по разделам. Начальный
и конечный секторы этой области определяются в заголовке GPT. В последней

области диска хранятся резервные копии заголовка 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-47 Адрес LBA начала области раздела Да
48-55 Адрес LBA конца области раздела Нет
56-71 Код GUID диска Нет
72-79 Адрес LBA начала таблицы разделов Да
80-83 Количество записей в таблице разделов Да
84-87 Размер каждой записи в таблице разделов Да
88-91 Контрольная сумма таблицы разделов (CRC32) Нет
92-конец сектора Зарезервировано Нет
По этим значениям можно полностью определить структуру диска, включая
местонахождени е таблицы разделов, области разделов и резервных копий заго-
заголовка GPT и таблицы разделов.
Заголовок GPT для образа диска выглядит так:
# dd if=gpt-disk.dd bs=512 skip=l count=l | xxd
0000000: 4546 4920 5041 5254 0000 0100 5c00 0000 EFI PART...A...
0000016: 8061 аЗЬО 0000 0000 0100 0000 0000 0000 .a
0000032: lfal 2807 0000 0000 2200 0000 0000 0000 .. ( "
0000048: feaO 2807 0000 0000 7e5e 4dal 1102 5049 ..( -AM...PI
0000064: ab2a 79a6 Зеаб 3859 0200 0000 0000 0000 .*y.>.8Y
0000080: 8000 0000 8000 0000 69a5 7180 0000 0000 i.q
0000096: 0000 0000 0000 0000 0000 0000 0000 0000

Первые 8 байт содержат сигнатуру. Байты 12-15 показывают, что размер заго-
заголовка GPT составляет 96 байт @х5с). Согласно байтам 32-39, резервная копия
заголовка хранится в секторе 120 103 199 @x0728alaf). Обратите внимание: этот
же сектор был указан в качестве последнего сектора защитного раздела DOS. Бай-
Байты 40-47 показывают, что область раздела начинается с сектора 34 @x22) и завер-
завершается в секторе 120 103 166 @x0728a0fe). Из байтов 72-79 мы узнаем, что таб-
таблица разделов начинается с сектора 2, а из байтов 80-83 — что таблица содержит
128 @x80) записей. Байты 84-87 показывают, что размер каждой записи составля-
составляет 128 @x80) байт; это означает, что для хранения таблицы потребуются 32 сектора.
По информации из заголовка GPT можно вычислить начало и конец таблицы раз-
разделов, а также размер каждой записи. В табл. 6.17 перечислены поля записей таблицы.
Таблица 6-17. Структура данных записей таблицы разделов GPT
Диапазон байтов Описание Необходимость
0-15 Код GUID типа раздела Нет
16-31 Уникальный код GUID раздела Нет
32-39 Начальный адрес LBA раздела Да
40-47 Конечный адрес LBA раздела Да
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
GUIP Описание
E3C9E316-05BC-4DB8-817D-f92DF00215AE Зарезервированный раздел Microsoft (MRP)
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 Первичный раздел (базовый диск)
5808C8AA-7E8F-42E0-85D2-E1E90434CFB3 Раздел метаданных LDM (динамический диск)
AF9B60A0-1431-4F62-BC68-3311714A69AD Раздел данных LDM (динамический диск)

В системе 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: 16e3 c9e3 5c0b b84d 817d f92d f002 15ae ... Л..М.}.-....
0000016: 2640 69eb 2f99 1942 afcO d673 7c0b 8ae4 &@i./..B...s|...
0000032: 2200 0000 0000 0000 0080 ЗеОО 0000 0000 " >
0000048: 0000 0000 0000 0000 0000 ffff ffff ffff
0000064: ffff ffff ffff ffff ffff ffff ffff ffff
В верхней строке (байты 0-15) мы видим код GUID типа раздела, а во второй
(байты 16-31) — код GUID самого раздела. Начальный адрес раздела хранится
в байтах 32-39; раздел начинается с сектора 32 @x0022). Конечный адрес раздела
задается байтами 40-47 и равен 4 096 000 @х003Е8000).
Пример выполнения mmls:
# mmls -t gpt gpt-disk.dd
GUID Partition Table
Units are in 512-byte sectors
Slot Start End Length Description
00: 0000000000 0000000000 0000000001 Safety table
01: 0000000001 0000000001 0000000001 GPT Header
02: 0000000002 0000000033 0000000032 Partition Table
03: 00 0000000034 0004096000 0004095967
04: 01 0004096001 0012288000 0008192000
В конце диска находятся резервные копии заголовка GPT и таблицы разделов.
Они следуют в обратном порядке: заголовок GPT хранится в последнем секторе,
а таблица разделов — в предыдущем. В нашем примере резервный заголовок GPT
находится в секторе 120 103 199.
Факторы анализа
На момент написания книги диски GPT встречались крайне редко, и в докумен-
документации большинства системных программ ничего не говорится о поддержке GPT.
Linux позволяет разбить диск GPT на разделы для последующего применения
других программ анализа файловой системы. Пакет The Sleuth Kit тоже поддер-
поддерживает разделы GPT.
Резервная копия таблицы разделов в дисках GPT упрощает восстановле-
восстановление системы в случае повреждения исходной таблицы. Неиспользуемые байты

сектора 0, сектора 1 и всех свободных записей в таблице разделов могут ис-
использоваться для хранения скрытых данных.
Итоги
На момент написания книги разделы GPT довольно редко встречались при про-
проведении расследований и не поддерживались многими средствами экспертного
анализа. Несомненно, в будущем, с переходом многих систем на 64-разрядную
базу, ситуация изменится. Разделы GPT существенно превосходят разделы DOS
по гибкости и простоте.
Библиография
• FreeBSD Documentation Project. «FreeBSD Handbook», 2005. http://www.freebsd.org.
• Holland, Nick, ed. «OpenBSD Installation Guide». January 2005. http://www.open-
bsd.org/faq/faq4.html.
• Intel. Extensible Firmware Interface, Version 1.10, December 1, 2002. http://deve-
loper.intel.com/technology/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. http://www.microsoft.com/resources/documentation/Windows/
XP/all/reskit/en-us/Default.aspTurU/resources/documentation/Windows/XP/aLL/reskit/
en-us/prkd_tro_zkfe.asp.
• Sun. «Solaris 9 System Administration Guide: Basic Administration. Chapter 31».
May 2002. http://docs.sun.com/db/doc/806-4073/6jd67r9fn?a=view.
• Sun. «System Administration Guide. Chapter 32: Managing Disks». April 2003.
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, обеспечивающих разный вы-
выигрыш по надежности и быстродействию. Далее мы рассмотрим шесть уровней

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
используется в системах исключительно по соображениям производительности;
избыточность в нем отсутствует, потому что данные хранятся в единственном эк-
экземпляре.
Рис. 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 данные делятся на байтовые фрагменты и распреде-
распределяются (чередуются) по дискам данных. Диск контроля четности содержит инфор-

мацию, необходимую для восстановления данных в случае сбоя одного из дисков.
Уровень 3 отчасти напоминает уровень 0, но чередуемые данные имеют гораздо
меньший размер (байты вместо блоков), и в массиве имеется выделенный диск
контроля четности. Пример массива с двумя дисками данных и одним диском кон-
контроля четности показан на рис. 7.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
JL 1 0
Оператор XOR удобен тем, что если вам известны два из трех значений, уча-
участвующих в операции, по ним можно определить третье значение. Допустим, име-
имеется три диска данных и один диск контроля четности. Диски данных содержат
числа 1011 0010, 1100 1111 и 1000 0001. Контрольная сумма этих чисел вычисля-
вычисляется следующим образом:
A011 0010 XOR 1100 1111) XOR 1000 0001
@111 1101) XOR 1000 0001
1111 1100
Байт 1111 1100 записывается на диск контроля четности. Если на втором дис-
диске произойдет сбой, хранившийся на нем байт легко восстанавливается:
1111 1100 XOR A011 0010 XOR 1000 0001)
1111 1100 XOR (ООП ООП)
1100 1111
Тома RAID уровня 4 сходны с уровнем 3, но распределение данных в них осу-
осуществляется по блокам, а не по байтам. На уровне 4 используются два и более

диска данных и выделенный диск контроля четности, поэтому его архитектура не
отличается от показанной на рис. 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.
Рис. 7.3. Том RAID уровня 5 с тремя дисками и распределенным контролем четности
Уровень 5 является одной из самых распространенных форм RAID, а для со-
создания массива необходимы как минимум три диска. Существуют и другие уров-
уровни RAID, которые встречаются реже. Они объединяют несколько уровней RAID,
что приводит к дополнительному усложнению анализа.
Аппаратная реализация RAID
Один из способов создания томов RAID основан на использовании специального
оборудования.
Общие сведения
Аппаратные реализации RAID делятся на две основные разновидности: специ-
специальные контроллеры, подключаемые к одной из шин, и устройства, подключае-
подключаемые к обычному контроллеру диска (с интерфейсом ATA, SCSI или FireWire).
В обоих случаях жесткие диски подключаются к специальному устройству, а ком-
компьютер взаимодействует с томом RAID, а не с обычными дисками. На рис. 7.4 пред-
представлены логические связи между дисками, контроллером и томом.
При использовании специального контроллера RAID компьютер проверяет
наличие контроллера во время загрузки. Во многих системах IA32 BIOS контрол-
контроллера RAID выводит сообщения на экране, а пользователь может вызвать экран
настройки контроллера и дисков. Операционной системе понадобятся драйверы
контроллера RAID. Диски, созданные одним контроллером, обычно не могут ис-
использоваться с другими контроллерами. При использовании специального уст-
устройства, подключаемого между обычным контроллером дисков и жесткими дис-
дисками, драйверы не потребуются.

Снятие данных и анализ
Аппаратные реализаций RAID весьма разнообразны, поэтому я приведу лишь неко-
некоторые общие рекомендации. Чтобы проанализировать том RAID, проще всего
снять данные с последнего тома RAID как с обычного автономного диска и восполь-
воспользоваться стандартными средствами анализа файловой системы и разделов. В од-
одном из способов анализируемая система загружается с загрузочного компакт-диска
Linux (или другой системы), содержащего драйверы контроллера RAID. Учтите,
что некоторые тома RAID очень велики, поэтому для хранения образа потребует-
потребуется большое дисковое пространство (а может быть, даже отдельный том RAID).
Загрузочные компакт-диски Linux содержат драйверы разных контроллеров
RAID, так что проверьте свой любимый дистрибутив и составьте список поддер-
поддерживаемых контроллеров. Возможно, вам придется создать собственный диск или
заготовить несколько дисков для разных случаев.
Если вы не располагаете необходимыми драйверами контроллера RAID для
снятия данных «на месте», возможно, диски и контроллер придется взять в лабора-
лабораторию. Информация о строении отдельных дисков RAID практически отсутствует,
поэтому при объединении дисков без контроллера могут возникнуть трудности.
Некоторые секторы диска могут быть не задействованы в томе RAID. В неис-
неиспользуемых секторах могут храниться скрытые данные. Таким образом, снятие
содержимого каждого диска (в дополнение к содержимому тома RAID) является
самым надежным, хотя и не всегда самым простым решением. Если раскладка дан-
данных неизвестна, с идентификацией неиспользуемых секторов диска могут воз-
возникнуть проблемы. Если возможен поиск информации по ключевым словам, про-
проведите поиск не только по тому RAID, но и по отдельным дискам.
Программная реализация RAID
Также возможна реализация томов RAID на программном уровне.
Общие сведения
При программной реализации RAID операционная система объединяет отдель-
отдельные диски при помощи специальных драйверов. В этом сценарии ОС «видит»

отдельные диски, но показывает пользователю только том RAID. Доступ к от-
отдельным дискам обычно осуществляется при помощи неструктурированных уст-
устройств UNIX или объектов устройств в Microsoft Windows. Многие современные
операционные системы обеспечивают поддержку RAID; к их числу относятся
Microsoft Windows NT, 2000 и Windows XP; Apple OS X; Linux; Sun Solaris; HP-
UX и IBM AIX. Программная реализация RAID уступает аппаратной реализации
по эффективности, потому что для вычисления битов четности и распределения
данных приходится задействовать центральный процессор. Логическая схема про-
программной реализации RAID показана на рис. 7.5.
Рис. 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 De-
Device). Диски в массивах RAID системы Linux не требуют специального форматиро-
форматирования и могут содержать обычные разделы DOS. Описание конфигурации хранит-
хранится в локальной системе в конфигурационном файле (по умолчанию /etc/raidtab).
Полученному тому RAID назначается новое устройство, и он может монтироваться
как обычный диск. Драйвер MD поддерживает RAID уровней 0 (чередование),
1 (зеркальное копирование) и 5 (чередование с контролем четности). Также
существует необязательная возможность создания «постоянного суперблока»
с размещением конфигурационной информации на диске, чтобы она могла исполь-
использоваться в других системах, кроме исходной (это упрощает анализ «на стороне»).

Снятие данных и анализ
Задачи снятия данных и анализа при программной реализации RAID решаются
почти так же, как при аппаратной реализации. При текущей технологии простей-
простейший сценарий основан на снятии данных с тома RAID для последующего приме-
применения стандартных средств анализа файловой системы. В отличие от аппаратной
реализации RAID, некоторые программы анализа позволяют объединять содер-
содержимое отдельных дисков.
Возможно, при программной реализации RAID вам не понадобится исходное
программное обеспечение для восстановления тома RAID. Например, в Linux
предусмотрена поддержка диспетчера логических дисков Windows (LDM) с воз-
возможностью правильного объединения дисков Windows. He все версии ядра 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.

Общие замечания по поводу анализа
Анализ системы с томами RAID может оказаться сложной задачей, поскольку
такие системы встречаются не так часто и имеют разные реализации. Опробуя
разные методы снятия данных, будьте очень осторожны и следите за тем, чтобы
это не привело к модификации исходных дисков. Используйте аппаратные бло-
кировщики записи или перемычки «только для чтения» на жестких дисках для
предотвращения изменений. Также может быть полезно создать образы отдель-
отдельных дисков перед созданием образа всего тома RAID. Образы отдельных дисков
могут содержать скрытые данные, не входящие в том RAID. Случаи со скрытыми
данными RAID пока не документированы, но теоретически такая возможность
существует — все зависит от того, какая система является объектом анализа. Так-
Также нельзя исключать, что для создания тома RAID используется не весь диск.
Некоторые системы RAID ограничиваются частью жесткого диска, чтобы диск
было проще заменить в случае сбоя. Например, система может использовать только
40 Гбайт на каждом отдельном диске независимо от его фактической емкости D0
или 80 Гбайт). Неиспользуемая область может содержать данные от предыдуще-
предыдущего образа, но в ней также могут находиться скрытые данные.
Итоги
В этом разделе был приведен обзор технологии RAID. Массивы RAID широко
применяются на высокопроизводительных серверах и получают все большее рас-
распространение среди настольных систем, нуждающихся в повышенном быстродей-
быстродействии или емкости диска. Низкоуровневые подробности не рассматривались, по-
потому что они зависят от реализации, а единого стандарта пока не существует.
Дополнительная информация приводится в разделе «Объединение дисков», по-
поскольку в поддержке управления томами многих систем присутствует интегри-
интегрированная программная реализация RAID.
Ключевым фактором успешной экспертизы является опыт снятия данных
в системах RAID. Самый простой, хотя и не всегда возможный вариант — снятие
всего тома RAID «на месте» и последующий анализ с применением стандартных
средств. У такого подхода есть свои недостатки: для сохранения данных необхо-
необходим диск очень большого размера, а на отдельных дисках могут находиться дан-
данные, не входящие в итоговый том RAID. Следовательно, безопаснее также произ-
произвести снятие данных с отдельных дисков.
Объединение дисков
В результате объединения (disk spanning) несколько отдельных дисков выглядят
как один большой диск. Объединение дисков часто рассматривается вместе
с RAID, поскольку оно поддерживается многими программными решениями RAID,
однако объединение дисков не обеспечивает ни избыточности, ни повышенного
быстродействия. Оно просто формирует носители информации большего объе-
объема, а некоторые версии позволяют добавлять новые диски и динамически увели-
увеличивать размер файловой системы.

В наше время объединение дисков поддерживается многими операционными
системами. Далее будут рассмотрены программные решения в системах Microsoft
Windows и Linux. Другие системы — такие, как Sun Solaris, IBM AIX и Apple
OSX — также содержат собственные технологии объединения дисков, но здесь
они не рассматриваются. Раздел начинается с описания основных концепций
и определения общих понятий, используемых во всех реализациях. Затем мы пе-
перейдем к конкретным системам Windows и Linux. Как и в предыдущем разделе,
посвященном RAID, не надейтесь найти здесь ответы на все вопросы — хотя бы
потому, что не все ответы известны. Я всего лишь объясню, как работает объеди-
объединение дисков; возможно, это поможет вам понять, почему не существует програм-
программы, которая решала бы все ваши задачи.
Общий обзор
Объединение дисков используется примерно по тем же причинам, по которым
мы используем скоросшиватель вместо блокнота на пружинной спирали. Когда
все страницы блокнота будут исписаны, приходится покупать новый блокнот и
носить его вместе со старым. Если же кончатся страницы в скоросшивателе, вы
можете добавить в него новые страницы и даже перенести накопившиеся заметки
в папку большего размера. При использовании объединения дисковое простран-
пространство новых дисков добавляется в конец существующего пространства. На рис. 7.6
показан пример с двумя дисками, каждый из которых содержит 100 блоков дан-
данных. Блоки 0-99 хранятся на диске 1, а блоки 100-199 — на диске 2.
Рис. 7.6. Объединение дисков: 100 блоков хранятся на первом диске и еще 100 — на втором
Программная поддержка объединения дисков формирует логический том. Ло-
Логические тома состоят из нескольких физических дисков или разделов, последо-
последовательно объединяемых друг с другом. Во многих системах также существуют дис-
дисковые группы, то есть группы физических дисков; только диски, входящие в одну
группу, объединяются для создания логического тома. На рис. 7.7 показано, как

связаны между собой эти уровни абстракции. Система содержит три физических
диска, входящих в одну дисковую группу. В результате объединения дисков фор-
формируются два логических тома.
Рис. 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

Ядро читает конфигурационный файл и создает устройство /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 не монтируется!
Если разместить диски в порядке, отличном от исходного, суперблок будет пере-
перезаписан. Это происходит даже без монтирования тома, поэтому примите меры по
сокращению изменений на каждом диске. Кроме того, у меня возникали проблемы

при загрузке, когда в системе, используемой для анализа, был установлен только
один из двух дисков. Счетчик диска увеличивался, но при следующей загрузке
с обоими дисками система 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 и ка-

талоге/etc/Lvmtab.d/. Конфигурационный файл имеет двоичный формат и обнов-
обновляется утилитами LVM, такими как vgimport, vgscan и vgchange. Дисковая струк-
структура находится в начале диска и содержит информацию о диске, о группе томов,
к которой он принадлежит, и о логических томах, входящих в группу. Ни одно из
полей структуры не содержит временных штампов, поэтому структура не обнов-
обновляется при создании логического тома, как это происходит с устройствами MD.
Рис. 7.8. LVM делит физические диски на физические экстенты, отображаемые
на логические экстенты в логическом томе
Снятие данных и анализ
Анализ систем 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 г.

к аналитическому пакету The Sleuth Kit). Пакет Penguin Sleuth Kit доступен по
адресу: 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@x42)
В системах IA64 (Intel Itanium и т. д.) на динамических дисках создаются раз-
разделы GPT для области разделов и базы данных LDM. Для этих разделов предус-
предусмотрены специальные типы.

Рис. 7.9. Строение динамического диска в системе IA32: структуры данных LDM
находятся внутри раздела DOS
Windows поддерживает только одну дисковую группу, в которую автомати-
автоматически включаются все динамические диски. Область разделов динамического
диска разбивается на динамические разделы, а динамические разделы одного или
нескольких дисков группируются для формирования логических томов (рис. 7.10).
Очень важно различать термины, используемые компанией Microsoft для дина-
динамических дисков и разделов DOS. В схеме разделов DOS Microsoft называет ло-
логическими томами разделы, создаваемые внутри расширенных разделов, тогда как
в динамических дисках логическими томами называются все разделы, которые
могут содержать файловую систему или другие данные.
Рис. 7.10. Логический том LDM формируется из динамических разделов,
входящих в дисковую группу
База данных LDM
В базе данных LDM хранятся определения динамических разделов и правила
создания логических томов. Компания Microsoft не опубликовала точного опи-
описания строения базы данных LDM, но Интернет-группы идентифицировали не-
некоторые внутренние структуры данных (одна из групп, Linux NTFS, доступна
по адресу: http://Linux-ntfs.sourceforge.net). Из опубликованных справочных ру-
руководств Microsoft [Solomon and Russinovich, 2000] известно, что база данных
LDM состоит из четырех основных частей. Приватный заголовок сходен с загру-
загрузочным сектором файловой системы. Он описывает уникальные характеристи-
характеристики диска и логического тома. Эта структура содержит уникальный идентифика-
идентификатор диска (GUID) и имя дисковой группы. Windows содержит только одну
дисковую группу, имя которой определяется именем компьютера. Далее следу-
следует оглавление, состоящее из 16 секторов. По данным Соломона и Руссиновича,
оглавление «содержит информацию о строении базы данных», то есть о следую-
следующей части LDM.

Область базы данных содержит описания дисков, разделов, компонентов и то-
томов. Для каждого динамического диска (как DOS, так и GPT) в базе данных со-
создается запись диска. Записи разделов описывают структуру разделов на динами-
динамических дисках. Записи компонентов описывают процесс объединения разделов.
Каждая запись раздела содержит ссылку на используемую ей запись компонента.
Записи компонентов существуют для объединения, чередования и зеркального
копирования. Наконец, записи томов описывают логические тома, то есть резуль-
результат применения компонентов к разделам.
Рассмотрим пример с двумя динамическими дисками. Имеется логический том,
первая часть которого занимает 15 Мбайт на диске 1, вторая — 10 Мбайт на диске
2, а последняя часть — 20 Мбайт на диске 1 (конечно, эти цифры гораздо меньше
тех, которые используются в реальных ситуациях). Структура логического тома
показана на рис. 7.10. Программа Microsoft dmdiag (http://www.microsoft.com/
windows2000/techinfo/reskit/tooLs/existing/dmdiag-o.asp) предназначена для вывода
информации о записях в базе данных. Результат ее работы выглядит так:
Disk: Diskl rid=0.1027 updated=O.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=O.1025 update=O.1028
id: dgid=d4f40362-7794-429a-a6ad-a6dfc0553cee
diskset: id=00000000-0000-0000-0000-000000000000
copies: nconfig=all n"log-all
minors: >= 0
Запись определяет группу дисков и показывает, что имя дисковой группы оп-
определяется именем компьютера (hash).
Subdisk: Diskl-01 rid=0.1109 updated=0.1112
info: disk=0.1027 offset-0 len=30720 hidden=O
assoc: plex=0.1107 (column=0 offset-O)
Subdisk: Diskl-02 rid-0.1121 updated=0.1122
info: disk=0.1027 offset=0 len=40960 hidden=O
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=O.1112
info: disk=0.1063 offset-0 len=20480 hidden=O
assoc: plex=0.1107 (column=0 offset=30720)
Запись определяет раздел для динамического диска Disk2 (ID:0.1063) с иден-
идентификатором 0.1111, смещением 0 секторов и размером 20 480 секторов. Связи

между физическим диском и записями динамических разделов показаны на
рис. 7.11. Направление стрелки означает, что запись динамического раздела со-
содержит указатель на физический диск.
Plex: Volume-01 rid=0.1107 update=O.1124
type: 1ayout=CONCAT
state: state=ACTIVE
assoc: voi=0.1105
Рис. 7.12. Связи между записями базы данных LDM (указатели на другие
объекты обозначены стрелками)
Приведенный фрагмент является записью компонента объединения дисков
(CONCAT), описывающей способ создания логического тома посредством объедине-
объединения динамических разделов. Мы видим идентификатор 0.1107, который встречался

в каждой из записей разделов. Также видно, что он ассоциируется с идентифика-
идентификатором тома 0.1105, описание которого приводится далее.
Volume: Volumel rid=0.1105 update=O.1124 mountname=F:
info: len=92160 guid=e4O794dO-6e3c-4788-af3d-ff49d2ce769d
type: parttype=7 usetype=gen
state: state=ACTIVE
policies: read=SELECT
flags: writeback
База данных завершается последним фрагментом, содержащим запись логи-
логического тома. В записи указана точка монтирования F:\h длина 92 160 секторов.
Тому присвоен идентификатор 0.1105 и имя Volumel. Связи между записями по-
показаны на рис. 7.12. Учтите, что все диски группы содержат одинаковые записи
базы данных.
Итоговая организация логического тома показана на рис. 7.13. Обратите вни-
внимание: последовательность разделов в логическом томе не соблюдается.
Рис. 7.13. Диск LDM с двумя физическими дисками, тремя динамическими
разделами и одним логическим томом
База данных LDM завершается журналом транзакций, то есть протоколом из-
изменений LDM. В случае сбоя питания или отказа оборудования журнал позволя-
позволяет восстановить диск в работоспособном состоянии.
Снятие данных и анализ
Анализ любого логического тома довольно сложен, особенно при программной
реализации, а воссоздание тома в режиме «только для чтения» является отнюдь
не тривиальной задачей. Как упоминалось ранее в разделе, посвященном RAID,
анализ системы проще всего выполняется при снятии данных с логического тома
и применении стандартных средств анализа. Тем не менее в Windows это не все-
всегда возможно, потому что система пытается монтировать диски при загрузке.
Снятие смонтированной файловой системы может привести к порче образа, а мон-
монтирование способно вызвать модификацию данных. Перемещение дисковых групп
LDM между компьютерами также сопряжено с некоторым риском. В Windows
в любой момент времени поддерживается только одна дисковая группа, а дина-
динамические диски добавляются в локальную группу, если она существует [Microsoft,
2003]. Следовательно, если динамические диски из исходной системы импорти-
импортируются в систему анализа, использующую динамические диски, они будут вклю-
включены в локальную группу дисков, а ОС запишет новые данные в базу данных LDM.

Ядро Linux включает поддержку объединения дисков LDM, хотя она и не все-
всегда включается по умолчанию. Если в вашем дистрибутиве объединение дисков
отключено, возможно, вам придется перекомпилировать ядро. Если ядро поддер-
поддерживает LDM, Linux прочитает базу данных и создаст устройства для каждого ди-
динамического раздела каждого динамического диска. Например, если загрузить
Linux с двумя дисками из предыдущего примера, в системе будут созданы устрой-
устройства/dev/hdbl, /dev/hdb2 и /dev/hddl. Затем создается файл /etc/raidtab с описа-
описанием структуры, чтобы драйвер ядра MD мог создать одно устройство. Если/dev/
hdbl содержит первый раздел, /dev/hddl — второй, a/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 разработала про-
программу Idminfo (http://linux-ntfs.sourceforge.net/status.html#ldmtools), которая ана-
анализирует записи базы данных LDM динамического диска Windows и выводит
подробную информацию с ключом —dump. Программа работает с любыми неструк-
неструктурированными устройствами или дисковыми образами массива дисков, потому
что базы данных на всех дисках содержат одинаковые записи. Она выводит такую
же подробную информацию, как и dmdiag.exe, но мы сосредоточимся на информа-
информации о структуре тома из предыдущего примера:
# Idminfo --dump diskl.dd
VOLUME DEFINITIONS:
Volume Size: 0x00016800 D5 MB)
Diskl-01 VolumeOffset: 0x00000000 Offset: 0x00000000 Length: 0x00007800
Diskl-01 VolumeOffset: 0x00007800 Offset: 0x00000000 Length: 0x00005000
Diskl-02 VolumeOffset: 0x0000C800 Offset: 0x00007800 Length: 0x0000A000
Из результатов видно, что том содержит два диска и три раздела. Диск нетруд-
нетрудно воссоздать, потому что он использует объединение без разбиения данных. Ра-
Ранее из результатов выполнения mmis для образа диска мы видели, что область раз-
разделов начинается в секторе 63. Следовательно, к смещениям в выходных данных

Ldminfo необходимо прибавлять 63, потому что смещения задаются относительно
начала области разделов. Чтобы получить данные первого раздела, мы извлекаем
30 720 секторов @x7800) из области разделов первого диска:
# dd if-diskl.dd skip=63 count=30720 > span.dd
Вторая часть дискового массива является первой частью второго диска. Мы
присоединим ее содержимое к данным первого диска. Таким образом, следует из-
извлечь первые 20 480 секторов @x5000) из области разделов второго диска:
# dd if=disk2.dd skip=63 count=20480 » span.dd
Последняя часть массива находится в области разделов первого диска. Она
также будет присоединена к данным, извлеченным со второго диска. Данные начи-
начинаются с сектора 30 720 @x7800) области разделов; следовательно, нам нужен сек-
сектор 30 783 по отношению к началу диска, а его длина составляет 40 960 секторов.
# dd if-diskl.dd skip=30783 count=40960 » span.dd
Полученный образ span.dd обрабатывается как обычный образ файловой сис-
системы. Если доступна поддержка LDM уровня ядра, я рекомендую сначала опро-
опробовать этот путь, прежде чем браться за ручную обработку. Также учтите, что при
разработке многих вспомогательных драйверов сторонних разработчиков и ути-
утилит LDM подробные спецификации Microsoft отсутствовали, поэтому правиль-
правильность их работы не гарантирована.
Библиография
• Lewis, AJ. «The LVM HOWTO». The Linux Documentation Project, 2002-2004.
http://tldp.org/HOWTO/LVM-HOWTO/.
• Microsoft, «Description of Disk Groups in Windows Disk Management». Microsoft
Knowledge Base Article 222189, November 21, 2003. http://support.microsoft.com/
kb/222189.
• Microsoft. Microsoft Windows XP Professional Resource Kit Documentation, 2004.
http://www.microsoft.com/resources/documentation/Windows/XP/aU/reskit/en-us/
prork_overview.asp.
• Ostergaard, Jakob. The Software-RAID HOWTO». The Linux Documentation Pro-
Project, June 3, 2004. http://www.tldp.org/HOWTO/Software-RAID-HOWTO.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. http://www.pc-
guide.com/ref/hdd/perf/raid/index.htm.
• Solomon, David, and Mark Russinovich. Inside Microsoft Windows 2000. 3rd ed.
Redmond: Microsoft Press, 2000.
• Sourceforge.net. «LDM Documentation». Linux NTFS Project, 2002. http://Linux-
ntfs. sourceforge.net/ldm/index.html.

Анализ файловых
систем
Глава 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 000 пациентов и 25 шкафов. Важно лишь
то, что специалист знает, что такое шкаф, умеет открывать его и знает, как прочи-
прочитать или заполнить корешок. Если же он посетит кабинет врача, живущего по пра-
правилам Национальной ассоциации беспорядочного хранения документов, у кото-
которого все истории болезни свалены в углу, вся его подготовка окажется бесполезной,
и специалист не сможет найти необходимую информацию.
Нечто похожее происходит и в файловых системах. В них существуют конк-
конкретные процедуры и структуры данных, используемые для хранения одного файла

на дискете или сотен, а то и тысяч файлов на массивах большой емкости. Каждый
экземпляр файловой системы обладает некоторым размером, но благодаря исполь-
использованию единой базовой структуры данных этот экземпляр может быть обрабо-
обработан любым компьютером, поддерживающим данный тип файловой системы.
Некоторые данные требуют внутреннего структурирования файлов. В этом они
напоминают физические документы, которые также обычно структурируются
в виде разделов и глав. Внутреннее строение файлов зависит от приложений и вы-
выходит за рамки книги. Нас интересуют только методы и правила получения дан-
данных, находящихся внутри файла или же не принадлежащих ни одному файлу.
Категории данных
При рассмотрении различных типов файловых систем полезно иметь эталонную
модель, упрощающую сравнение разных файловых систем (скажем, FAT и Ext3).
Кроме того, наличие эталонной модели упрощает поиск доказательств. В нашей
эталонной модели будут задействованы пять категорий: данные файловой системы,
содержимого, метаданные, данные имен файлов и прикладные данные. Любая
информация файловой системы принадлежит к одной из перечисленных катего-
категорий в зависимости от того, какую роль она играет в файловой системе. Мы будем
использовать эти категории при описании файловых систем, хотя некоторые сис-
системы (а именно, FAT) не так хорошо соответствуют эталону, как другие системы.
Инструментарий The Sleuth Kit (TSK) тоже базируется на тех же категориях.
Категория данных файловой системы включает общую информацию, относя-
относящуюся к файловой системе в целом. Каждая файловая система обладает некой
общей структурой, но ее экземпляры уникальны, поскольку они обладают уни-
уникальным размером и могут оптимизироваться. Данные файловой системы указыва-
указывают, где найти некоторые структуры данных и насколько велики единицы хранения
информации. Их можно сравнить с «географической картой» файловой системы.
К категории данных содержимого относятся данные, составляющие фактичес-
фактическое содержимое файлов (которое, собственно, и является главной причиной для
создания файловых систем). Большая часть данных файловой системы относится
к этой категории, а для их хранения обычно применяются контейнеры стандарт-
стандартного размера. Название контейнеров зависит от файловой системы (например,
кластер или блоку, до описания конкретных файловых систем я буду использо-
использовать общий термин блок данных.
Категория метаданных включает данные с описаниями файлов; иначе говоря,
это данные, описывающие другие данные. В частности, к метаданным относится
информация о местонахождении содержимого файла, его размере, времени и дате
последнего чтения или записи в файл, контроле доступа и т. д. Метаданные не
включают ни фактического содержимого файла, ни его имени. Примерами струк-
структур данных этой категории являются записи каталогов FAT, записи NTFS MFT
(Master File Table), структуры i-узлов UFS и Ext3.
Категория данных имен файлов, или интерфейса с пользователем, содержит
информацию об именах, присвоенных всем файлам. В большинстве файловых
систем эти данные хранятся в каталогах в виде списка имен файлов с соответ-
соответствующими адресами метаданных. Категорию данных имен файлов можно срав-
сравнить с именем хоста в сети. Сетевые устройства взаимодействуют друг с другом

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

но для решения главной задачи — сохранения и выборки файлов — они не нуж-
нужны. В качестве примера вспомогательных данных можно назвать время последне-
последнего обращения и разрешения доступа.
Почему так важно отличать необходимые данные от вспомогательных? Пото-
Потому что необходимым данным мы просто обязаны доверять, тогда как для вспомо-
вспомогательных данных это не обязательно. Например, во всех файловых системах при-
присутствует некоторое значение, которое указывает, где хранится содержимое файла.
Оно относится к необходимым данным; ведь если это значение окажется лож-
ложным, пользователь не сможет прочитать файл. С другой стороны, информация о
времени последнего обращения или идентификаторе пользователя является вспо-
вспомогательной, потому что ее истинность не является абсолютно необходимой. Даже
если время последнего обращения к файлу не будет обновляться, это никак не
повлияет на чтение или запись в файл. Следовательно, мы должны доверять не-
необходимым данным в большей степени, чем вспомогательным, потому что они
жизненно важны для сохранения и чтения файлов.
Некоторые ОС требуют, чтобы некоторые значения обязательно задавались,
но это не означает, что эти данные являются необходимыми. К примеру, очень
строгая (и вымышленная) ОС может отказаться монтировать файловые системы
с файлами, время последнего обращения к которым относится к будущему. Дру-
Другая ОС не обратит внимания на проблемы с временем, смонтирует файловую си-
систему и сохранит в ней данные. Microsoft Windows требует, чтобы все файловые
системы FAT начинались с некоторого блока данных, хотя последний использу-
используется только в том случае, если файловая система является загрузочной. С другой
стороны, в Linux подобные требования отсутствуют.
Если рассматривать происходящее с этой точки зрения, становится очевидно,
что аналитик должен хорошо знать не только тип файловой системы, но и ОС,
записывающую данные в файловую систему. Если мы говорим о восстановлении
файлов, недостаточно узнать, как восстановить удаленный файл в файловой сис-
системе FAT, — задайтесь вопросом, как восстановить файл, удаленный Windows 98
в файловой системе FAT. Система FAT реализована во многих операционных си-
системах, и каждая из них может использовать свою методику удаления файлов.
Например, большинство ОС ограничиваются минимальным набором действий,
необходимых для удаления файла, но другие системы могут уничтожать все дан-
данные, ассоциированные с файлом. В обоих случаях конечным результатом будет
действительная файловая система FAT.
В этой книге основное внимание уделяется необходимым данным. Там, где воз-
возможно, я буду описывать информацию прикладного уровня, не являющуюся аб-
абсолютно необходимой для функционирования файловой системы. Тем не менее
очень важно, чтобы аналитик изучал и тестировал прикладные аспекты поведе-
поведения файловой системы в контексте конкретного инцидента.
Методы анализа и категории данных
В оставшейся части настоящей главы и книги пять категорий данных будут ис-
использоваться для описания методов анализа. В главе 1 было показано, что при
поиске улик аналитик определяет свойства, которыми они должны обладать, и их

вероятное местонахождение. На основании вероятного местонахождения опре-
определяется категория данных и методы анализа, которые должны быть задейство-
задействованы при поиске. Например, при поиске файлов с расширением JPG основное
внимание будет сосредоточено на методах анализа категории имен файлов. С дру-
другой стороны, при поиске файла, содержащего заранее заданное значение, будут
использованы методы анализа метаданных, поскольку адреса блоков данных от-
относятся именно к этой категории.
Во многих инструментах экспертного анализа объединяются методы анализа,
относящиеся к разным категориям, поэтому некоторые описания в книге могут
показаться искусственными. При описании методов анализа я постараюсь выде-
выделить все действия, происходящие «за кулисами», и показать, где могут произойти
сбои. Описания методов не привязаны к конкретным программам анализа. Во мно-
многих случаях для демонстрации я использую программы из пакета TSK; за допол-
дополнительной информацией обращайтесь к приложению.
Категория данных файловой системы
К категории файловой системы относятся общие данные, описывающие ее строе-
строение и местонахождение других важных данных. Чаще всего большая часть этих
данных размещается в стандартных структурах в начальных секторах файловой
системы (по аналогии с картой, висящей в вестибюле здания).
Анализ данных, относящихся к категории файловой системы, обязателен для всех
типов анализа файловых систем, потому что на этом этапе определяется местона-
местонахождение структур данных других категорий. Если какие-либо из этих данных бу-
будут повреждены или утрачены, это усложнит дополнительный анализ, потому что
вам придется искать резервные копии или догадываться, где находились значения.
Помимо общей структурной информации, в ходе анализа данных категории файло-
файловой системы также может быть получена информация о версии файловой системы;
приложении, создавшем файловую систему; дате создания и метке файловой систе-
системы. Лишь небольшая часть данных этой категории может быть просмотрена или
изменена типичным пользователем без использования шестнадцатеричного редак-
редактора. Нередко информация, не относящаяся к местонахождению структур данных,
считается несущественной, а ее значение может не соответствовать действительности.
Методы анализа
Данные этой категории обычно представляют собой одиночные самостоятельные
значения. С ними трудно сделать что-либо более содержательное, чем вывести их
для сведения аналитика или использовать в работе программы. Структурная ин-
информация может быть полезной при ручном восстановлении данных. Если вы
пытаетесь определить, на каком компьютере была создана файловая система, при-
пригодится идентификатор тома или номер версии. Структуры данных этой катего-
категории часто содержат неиспользуемые значения и свободные блоки, которые могут
использоваться для хранения небольших объемов скрытых данных. К проверке
целостности данных в этой категории можно отнести сравнение размера файло-
файловой системы с размером тома, в котором она находится. Если том имеет больший

размер, секторы после файловой системы называются резервным пространством
тома и могут использоваться для хранения скрытых данных.
В пакет TSK входит утилита fsstat, выводящая данные из категории файловой
системы. Объем выводимой информации зависит от типа файловой системы; при-
примеры будут приведены в следующих главах.
Категория данных содержимого
К категории содержимого относятся адреса ячеек носителя информации, ассоци-
ассоциированных с файлами и каталогами и предназначенных для сохранения инфор-
информации. Данные этой категории обычно делятся на группы равного размера; я буду
называть эти группы блоками данных, хотя в каждой файловой системе исполь-
используется свой термин (например, кластер или блок). Блок данных может находить-
находиться в одном из двух состояний: выделенном или свободном. Как правило, суще-
существует некоторая структура данных, в которой хранится информация о состоянии
каждого блока данных.
При создании нового или расширении существующего файла ОС ищет сво-
свободный блок данных и выделяет его файлу. Различные стратегии поиска будут
рассмотрены далее, в разделе «Стратегии выделения». Когда файл удаляется, вы-
выделенные ему блоки данных переводятся в свободное состояние и могут выде-
выделяться новым файлам. Большинство ОС не стирает содержимое блоков данных
при их переводе в свободное состояние, хотя некоторые ОС и программы «надеж-
«надежного удаления» предоставляют такую возможность.
Анализ данных содержимого проводится с целью восстановления удаленных
данных и проведения низкоуровневого поиска. Объем данных содержимого от-
относительно велик, поэтому анализ обычно проводится в автоматизированном ре-
режиме. Например, если эксперт может проанализировать содержимое 512-байто-
512-байтового сектора за 5 секунд, то при 12-часовом рабочем дне на анализ 40-гигабайтного
диска ему потребуется 388 дней.
Общие сведения
В этом разделе рассматриваются механизмы адресации блоков данных, способы
их выделения и обработки поврежденных блоков данных файловой системой.
Логические адреса файловой системы
Сектор может обладать несколькими адресами для разных уровней абстракции.
При обсуждении методов снятия данных мы видели, что каждому сектору назнача-
назначается физический адрес, отсчитываемый от начала носителя информации. В томах
секторам назначаются логические адреса томов, отсчитываемые от начала тома.
В файловых системах используются логические адреса томов, но наряду с ними
секторам назначаются логические адреса файловой системы] это связано с груп-
группировкой смежных секторов для формирования блоков данных. В большинстве
файловых систем каждому сектору тома назначается логический адрес файловой
системы. В качестве примера системы, в которой секторам не назначаются логи-
логические адреса файловой системы, молено привести систему FAT.

На рис. 8.2 показан том с 17 секторами и их логическими адресами. Внизу при-
приведены логические адреса файловой системы. Вымышленная файловая система
создает блоки данных, каждый из которых состоит из двух секторов, причем при-
присваивание адресов начинается с сектора 4. Эта очень маленькая файловая систе-
система завершается в секторе 15, а сектор 16 образует резервное пространство тома.
Рис. 8.2. Пример тома, в котором файловая система назначает адреса
группам из двух секторов, а некоторые секторы
исключаются из логической адресации
Стратегии выделения
В операционных системах используются разные стратегии выделения блоков
данных. Чаще всего ОС выделяет смежные блоки данных, но это не всегда воз-
возможно. Файл, который не состоит только из смежных блоков данных, называется
фрагментированным.
В стратегии первого доступного блока поиск начинается с первого блока дан-
данных в файловой системе. После того как первый блок будет выделен и потребует-
потребуется выделить второй блок, поиск снова начинается от начала файловой системы.
Данная стратегия часто приводит к появлению фрагментированных файлов, по-
потому что память под файл выделяется не как единое целое, а по частям. Пред-
Представьте себе театр, в котором стратегия выделения первого доступного блока ис-
используется для бронирования мест. Если группа из четырех зрителей захочет
купить билеты, кассир последовательно переберет свободные места, начиная с пер-
первого ряда. Возможно, всей четверке достанутся соседние места; а может быть, двое
будут сидеть в первом ряду, а еще двое — в последнем. Если же во время поиска
кто-то из зрителей вернет билет в кассу, третий может оказаться ближе к первому
ряду, чем первые двое. В примере на рис. 8.3 при использовании этой стратегии
следующим будет выделен блок данных 1. В операционных системах, использую-
использующих стратегию выделения первого доступного блока, удаленные данные в начале
файловой системы перезаписываются быстрее, чем при использовании других
алгоритмов. Следовательно, попытка восстановления удаленного содержимого
в конце файловой системы с большей вероятностью увенчается успехом.
Рис. 8.3. Пример выделения 8 блоков данных

В похожей стратегии поиска следующего доступного блока поиск начинается
не с начала, а с последнего выделенного блока данных. Например, после выделения
блока данных 3 на рис. 8.3 поиск начнется с блока 4, а не с 0. В нашем примере
с театром поиск продолжится не с первого ряда, а с последнего забронированного
места. Даже если во время поиска будет возвращен билет на первый ряд, он не
будет продан до того, как поиск достигнет последнего места. Такой алгоритм лучше
сбалансирован для восстановления данных, потому что блоки данных в начале фай-
файловой системы выделяются заново лишь после выделения всех блоков до ее конца.
Стратегия оптимальной подгонки ищет смежные блоки данных, объем кото-
которых позволит сохранить заданное количество данных. Такой способ хорошо ра-
работает, если количество блоков известно заранее, но при увеличении размера файла
новые блоки данных, скорее всего, будут выделены в другом месте, и файл все
равно фрагментируется. Если алгоритм не может найти смежный блок нужного
размера, он может использовать стратегию поиска первого или следующего дос-
доступного блока. Обычно именно такой алгоритм применяется при бронировании
мест в театре. Кассир перебирает пустые места, пока не найдет достаточно сосед-
соседних мест для вей группы. Скажем, если бы в примере на рис. 8.3 потребовалось
выделить два блока данных, то файл попал бы в блоки данных 4 и 5 и не был бы
разбит между блоками 1 и 4.
Каждая ОС выбирает стратегию выделения блоков данных по своему усмот-
усмотрению. В спецификациях некоторых файловых систем указано, какая стратегия
должна в них использоваться, однако обеспечить выполнение этого требования
невозможно. Проверьте реализацию файловой системы, прежде чем считать, что
она использует указанную стратегию.
Кроме проверки стратегии выделения на уровне операционной системы также
следует учитывать специфику приложения, записывающего данные. Например,
при обновлении существующих файлов некоторые приложения открывают ис-
исходный файл, обновляют его и сохраняют новые данные поверх исходных. Дру-
Другое приложение может создать копию исходного файла, обновить ее и переимено-
переименовать копию так, чтобы она перезаписала оригинал. В этом случае файл сохраняется
в новых блоках данных. Не путайте поведение приложения со стратегией выделе-
выделения, потому что ОС не заставляла приложение выделять новые блоки данных.
Поврежденные блоки данных
Во многих файловых системах предусмотрена возможность пометки поврежден-
поврежденных блоков данных. Когда-то это было необходимо, потому что старые жесткие
диски не умели обрабатывать ошибки. Операционной системе приходилось самой
выявлять поврежденные блоки данных и помечать их, чтобы они не выделялись
файлам. Современные жесткие диски обнаруживают поврежденные секторы
и подбирают им замену из числа свободных секторов, поэтому эта функциональ-
функциональность файловой системы стала излишней.
Механизм пометки поврежденных блоков данных (если он поддерживается)
позволяет легко скрывать данные. Как правило, программы проверки целостнос-
целостности диска не проверяют, действительно ли поврежден блок данных, который поме-
помечен как поврежденный. Таким образом, пользователь может вручную включить
блок данных в список поврежденных и разместить в нем свою информацию. Мно-
Многие программы снятия данных выводят список реально поврежденных секторов,

чтобы его можно было сравнить со списком помеченных секторов и выявить сек-
секторы, вручную включенные в список для хранения скрытой информации.
Методы анализа
От рассмотрения основных концепций данных содержимого мы переходим к спо-
способам их анализа. В этом разделе представлены различные методы анализа, ис-
используемые при поиске улик.
Просмотр блоков данных
Метод просмотра блоков данных применяется в тех случаях, когда эксперту изве-
известен адрес возможного местонахождения улик — например, выделенный опреде-
определенному файлу или имеющий особое значение. Скажем, во многих системах FAT32
сектор 3 не используется файловой системой и заполняется нулями, однако в нем
могут храниться скрытые данные. Просмотр содержимого сектора 3 покажет, при-
присутствуют ли в нем данные, отличные от нуля.
Принцип проведения такого рода анализа очень прост. Эксперт вводит логи-
логический адрес файловой системы, а программа вычисляет смещение в байтах или
адрес сектора для указанного блока данных. Затем программа переходит к ука-
указанной позиции и читает данные. Для примера рассмотрим файловую систему,
в которой блок данных 0 хранится со смещением 0, а размер каждого блока дан-
данных равен 2 048 байт. Смещение блока данных 10 составит 20 480 байт (рис. 8.4).
Рис. 8.4. Просмотр содержимого блоков данных 10
Данная функция выполняется многими программами, в том числе шестнадца-
теричными редакторами и средствами анализа. В частности, программа dcat из
пакета TSK позволяет просмотреть конкретный блок данных в низкоуровневом
или шестнадцатеричном формате.
Поиск в логической файловой системе
В предыдущем примере мы знали, где могут находиться улики, но не знали, какие
именно. На этот раз ситуация обратная: мы знаем содержимое улик, но не знаем,

где они находятся. При поиске в логической файловой системе каждый блок дан-
данных проверяется на присутствие некоторой фразы или значения. На рис. 8.5 каж-
каждый блок данных проверяется на присутствие строки «forensics».
Рис. 8.5. При поиске в логической файловой системе каждый блок данных
проверяется на присутствие заранее известного значения
Традиционно эта методика поиска называлась «физическим поиском», пото-
потому что в ней используется физический порядок секторов; на мой взгляд, этот тер-
термин верен только для отдельных дисков, но не для систем с объединением дисков
и массивов RAID. В таких системах порядок следования секторов не соответству-
соответствует их физическому порядку, и лучше использовать более точный термин.
К сожалению, файлы не всегда занимают смежные блоки данных, и во фраг-
ментированном файле искомое значение может оказаться разбитым на две не-
несмежных блока. В этом случае при поиске в логической файловой системе оно
обнаружено не будет. Как будет показано далее, задача решается поиском в логи-
логических файлах. Многие программы анализа позволяют выполнять поиск как по
логическим томам, так и по логическим файлам. Чтобы определить, какой режим
поиска используется вашей программой, попробуйте провести поиск по ключе-
ключевым словам в тестовых образах, размещенных на моем сайте DFTT (Digital Forensic
Tool Testing) [Carrier, 2004].
Если вернуться к аналогии из раздела «Стратегии выделения», можно сказать,
что мы пытаемся найти в театре конкретную семью. Процедура поиска в логичес-
логической файловой системе начинается с первого ряда, и проверяется каждая группа
из четырех людей, занимающих соседние места. Если семье достались несмежные
места, поиск завершится неудачей. Поиск также можно повторить для отдельно-
отдельного человека, но это может привести к ложным совпадениям из-за людей с похо-
похожей внешностью.
Состояние выделения блоков данных
Еще одна ситуация: точное местонахождение улик неизвестно, но мы знаем, что
они находятся в свободном (невыделенном) пространстве. Некоторые программы
позволяют извлечь содержимое всех свободных блоков данных файловой системы
в отдельный файл, другие проводят анализ только в пределах свободных областей.
Результат извлечения всех свободных блоков будет представлять собой низко-
низкоуровневые данные, лишенные какой-либо структуры файловой системы, поэтому
такие данные не могут обрабатываться в средствах анализа файловой системы.
На рис. 8.6 изображена битовая карта первых 12 блоков данных. В этой струк-
структуре каждый блок данных представлен одним битом. Если бит равен 1, значит,
блок данных выделен, а если 0 — свободен. Если потребуется извлечь содержи-
содержимое всех свободных блоков данных, мы извлечем блоки 2, 6, 7 и 11.

Рис. 8.6. Чтобы извлечь содержимое свободных блоков данных, мы просматриваем битовую
карту выделения и извлекаем блоки с заданным значением
Функция извлечения содержимого свободного пространства файловой систе-
системы поддерживается многими программами цифровой экспертизы, хотя опреде-
определения «свободного пространства» могут быть разными. Я заметил, что некоторые
программы считают свободными любые данные, не принадлежащие файлам, вклю-
включая данные категории файловой системы и метаданные. С другой стороны, неко-
некоторые программы восстанавливают удаленные файлы и считают их блоки дан-
данных выделенными, хотя с технической точки зрения эти блоки свободны. А вы
знаете, как ваша программа интерпретирует свободные данные?
В пакете TSK программа dls извлекает свободные данные в файл. Обнаружив
интересные данные, вы захотите узнать, в каком блоке данных файловой системы
они находились; для этой цели можно воспользоваться программой dcalc. TSK счита-
считает свободными блоки данных в категории содержимого, у которых состояние выде-
выделения помечено как свободное. Если некоторые блоки данных используются фай-
файловой системой и не имеют состояния выделения, они считаются выделенными.
Порядок выделения блоков данных
Ранее я уже упоминал некоторые стратегии, используемые ОС при выделении
блоков данных. В общем случае выбор стратегия зависит от ОС и является объек-
объектом анализа прикладного уровня. Например, Windows ME и Windows 2000 могут
использовать разные стратегии выделения блоков данных для системы FAT, но
при этом каждая из систем создает действительную файловую систему FAT.
Если относительный порядок выделения двух и более блоков данных важен,
можно попробовать определить его моделированием процедуры выделения ОС.
Это очень трудная задача, потому что сначала необходимо определить страте-
стратегию, используемую ОС, а затем исследовать все возможные сценарии, которые
могли привести к данному состоянию блоков данных. Такой метод анализа ис-
используется при реконструкции событий, которая выполняется уже после того,
как блоки будут идентифицированы как улики. Он связан с информацией при-
прикладного уровня, но его подробное рассмотрение выходит за рамки настоящей
книги.
Проверка целостности данных
Проверка целостности данных играет важную роль при анализе всех категорий
данных. Она позволяет определить, находится ли файловая система в подозри-
подозрительном состоянии. Одна из проверок целостности данных в категории содержимо-
содержимого использует информацию из категории метаданных и проверяет, что на каждый

выделенный блок данных указывает ровно одна запись метаданных. Это делается
для того, чтобы пользователь не мог вручную изменить состояние выделения бло-
блоков данных, не указав для них имени. Выделенные блоки данных, не имеющие
ассоциированной структуры метаданных, называются зависшими блоками данных.
На рис. 8.7 блоки данных 2 и 8 являются выделенными. Блок данных 2 не имеет
ассоциированной записи метаданных, поэтому он является зависшим. На блок
данных 8 ссылаются сразу две записи метаданных, что недопустимо в большин-
большинстве файловых систем.
Рис. 8.7. Проверка целостности убеждается в том, что на каждый блок данных
ссылается одна и только одна запись метаданных
В ходе другой проверки целостности данных анализируются все блоки данных,
помеченные как поврежденные. Если у вас имеется образ жесткого диска с повреж-
поврежденными секторами, многие программы снятия данных заполняют поврежденные
секторы нулями. Следовательно, любой блок данных, входящий в список повреж-
поврежденных, должен содержать нули (при условии, что программа снятия данных за-
заменяет поврежденные данные нулями). Ненулевые данные заслуживают присталь-
пристального внимания, потому что это могут быть данные, скрытые от пользователей.
Методы надежного удаления
Итак, мы разобрались с тем, как выполняется анализ данных этой категории.
Теперь давайте посмотрим, как пользователь может усложнить вашу задачу. Мно-
Многие программы надежного удаления информации, работающие в категории дан-
данных содержимого, заполняют нулями или случайными значениями все неисполь-
неиспользуемые или выделяемые файлу блоки данных.
Надежное удаление получает все более широкое распространение и становит-
становится стандартной функцией в некоторых операционных системах. Средства надеж-
надежного удаления, интегрированные в ОС, наиболее эффективны. Работа сторонних
приложений часто зависит от определенных аспектов поведения ОС, что может
повлиять на их эффективность. Скажем, много лет назад существовала програм-
программа для Linux, которая заполняла нули в блоки данных перед их освобождением,
однако ОС откладывала запись. Позднее ОС замечала, что блок данных свободен,
и вообще не записывала нули на диск. Кроме того, многие программы предпола-
предполагают, что при записи данных в существующий файл ОС будет использовать те же
блоки данных. Однако ОС также может выделить новые блоки данных, и в этом
случае содержимое файла останется на диске.
Подтвердить применение программ надежного удаления в этой категории
нелегко. Разумеется, если все свободные блоки данных содержат нули или слу-
случайные данные, логично предположить, что это работа программы надежного

удаления. Если программа записывает случайные данные или копирует содержи-
содержимое других блоков данных, без доказательств применения программы на приклад-
прикладном уровне обнаружить ее применение практически невозможно. Конечно, если
в системе найдется программа надежного удаления, вы можете определить, ис-
использовалась ли она, и проверить время последнего обращения. Если повезет, вам
также удастся найти временные копии файла.
Категория метаданных
Категория метаданных объединяет все данные с описаниями других данных. На-
Например, к ней принадлежит время последнего обращения и адреса блоков дан-
данных, выделенных файлу. Лишь немногие программы выделяют анализ метадан-
метаданных как отдельную операцию; чаще он объединяется с анализом категории имени
файла. Однако в книге я буду различать их, чтобы показать, откуда поступают
данные и почему некоторые удаленные файлы невозможно восстановить.
Многие структуры метаданных хранятся в таблицах фиксированной или ди-
динамической длины; каждой записи таблицы назначается адрес. При удалении
файла его запись метаданных переводится в свободное состояние, и ОС может
стереть часть содержащейся в ней информации.
Анализ в категории метаданных проводится с целью получения дополнитель-
дополнительной информации о конкретном файле или поиске файла, удовлетворяющего не-
некоторому критерию. Обычно в этой категории присутствует больше вспомогатель-
вспомогательных данных, чем в других категориях. Например, время последнего обращения
или записи может оказаться неточным, или ОС может не соблюдать права досту-
доступа к файлу; следовательно, эксперт не может сделать вывод относительно того,
имел ли пользователь доступ к файлу для чтения. Для поддержки заключений,
касающихся вспомогательных данных этой категории, необходимы дополнитель-
дополнительные доказательства.
Общая информация
Данный раздел посвящен основным концепциям категории метаданных. В част-
частности, мы рассмотрим новую схему адресации, резервное пространство, восста-
восстановление удаленных файлов, сжатие и шифрование.
Логическая адресация файлов
Ранее я упоминал о логических адресах файловой системы, назначаемых блокам
данных. Блок данных, выделенный файлу, также обладает логическим адресом
файла, который отсчитывается от начала файла, которому выделен данный блок.
Например, если файлу выделены два блока данных, то первому блоку назначает-
назначается логический адрес файла 0, а второму — логический адрес файла 1. Для форми-
формирования уникального логического адреса файла необходимо задействовать имя
или адрес метаданных файла. Пример показан на рис. 8.8, дополняющем преды-
предыдущий пример. На рисунке изображены два файла с пятью выделенными блока-
блоками данных. Обратите внимание: логический адрес файловой системы 1 не выде-
выделен файлу, поэтому он не имеет логического адреса файла.

Рис. 8.8. Проверка целостности убеждается в том, что на каждый блок данных
ссылается одна и только одна запись метаданных
Резервное пространство
Резервное пространство (slack space) — один из модных терминов цифровой
экспертизы, который наверняка приходилось слышать читателю. Резервное про-
пространство возникает в ситуации, когда размер файла не кратен размеру блока дан-
данных. Система обязана выделить файлу полный блок данных, даже если реально
задействована будет лишь малая его часть; неиспользуемые байты в последнем
блоке данных называются резервным пространством. Например, если размер фай-
файла составляет 100 байт, система должна выделить ему полный блок данных раз-
размером 2048 байт, а последние 1948 байт попадают в резервное пространство.
Почему резервное пространство представляет интерес для эксперта? Потому что
компьютеры «ленивы». Некоторые из них не стирают содержимое неиспользуемых
байтов, и резервное пространство содержит данные, оставшиеся от предыдущих
файлов или содержимого памяти. Вследствие архитектуры, используемой в боль-
большинстве компьютеров, в резервном пространстве имеется две интересные области.
Первая находится между концом файла и концом сектора, в котором этот файл
заканчивается. Вторая состоит из секторов, не содержащих данных файлов. На-
Наличие этих двух областей объясняется тем, что жесткие диски имеют блочную струк-
структуру, а запись в них может осуществляться только фрагментами, кратными 512 байт
(размер сектора). В предыдущем примере ОС не может записать на диск только
100 байт, она должна записать все 512 байт. По этой причине 100 байт приходится
дополнять 412 байтами данных. Представьте, что вы покупаете товар в магазине,
в котором имеются коробки только одного размера; чем меньше товар, тем больше
упаковочного материала придется положить в коробку, чтобы она была полной.
Первая область резервного пространства интересна тем, что способ заполне-
заполнения неиспользуемой части сектора определяется операционной системой. Наи-
Наиболее очевидный метод заключается в заполнении сектора нулями, что и проис-
происходит в большинстве ОС. Некоторые старые ОС (а именно, DOS и ранние версии
Windows) заполняли остаток сектора данными из памяти. Эта область резервно-
резервного пространства называлась резервом RAM [NTI, 2004], а теперь она обычно за-
заполняется нулями. Резервное пространство с содержимым памяти может содер-
содержать пароли и другие данные, не предназначенные для записи на диск.

Вторая область резервного пространства складывается из секторов, оставших-
оставшихся неиспользованными в блоке данных. Одни ОС стирают содержимое таких сек-
секторов, другие игнорируют их. Во втором случае секторы будут содержать данные
того файла, которому ранее принадлежал данный сектор.
Рассмотрим файловую систему NTFS с 2048-байтовым кластером и 512-бай-
512-байтовым сектором. Файл состоит из 612 байт, поэтому он использует весь первый
сектор и 100 байт второго сектора в кластере. Оставшиеся 412 байт второго секто-
сектора заполняются данными по усмотрению ОС. Третий и четвертый секторы ОС
может заполнить нулями, а может и оставить в них данные из удаленного файла.
Это показано на рис. 8.9: серым цветом помечено содержимое файла, а белым —
резервное пространство.
Рис. 8.9. Резервное пространство 612-байтового файла с 2048-байтовым кластером
При описании резервного пространства часто приводится аналогия с видео-
видеомагнитофоном [Kruse, 2003]. Представьте, что вы ночью записываете 60-минут-
60-минутный эпизод нового сериала. Вы смотрите записанную программу и перематывае-
перематываете ленту в начало. Позднее на ленту записывается 30-минутная программа. После
записи лента «выделяется» под 30-минутную программу, однако в конце остают-
остаются еще 30 минут от предыдущей передачи.
Все файловые системы содержат резервное пространство, потому что диско-
дисковое пространство выделяется многобайтовыми фрагментами, а не отдельными бай-
байтами. Резервное пространство представляет интерес для аналитика не из-за фай-
файловой системы, а из-за ОС и тех данных, которые она записывает. Важно заметить,
что резервное пространство относится к выделенным данным. Оно может содер-
содержать остатки ранее удаленного файла, но его память выделена некоторому файлу.
Если извлечь содержимое свободных блоков данных файловой системы, в него не
войдет содержимое резервного пространства.
Восстановление файлов по метаданным
В некоторых ситуациях улики приходится искать в удаленных файлах. Существует
два основных способа восстановления удаленных файлов: на уровне метаданных
и на прикладном уровне. Методы анализа прикладного уровня рассматриваются
в конце главы, а сейчас мы обсудим восстановление на уровне метаданных. Вос-
Восстановление по метаданным работает только в том случае, если метаданные
удаленного файла еще существуют. Если метаданные были стерты или их струк-
структура была выделена новому файлу, придется использовать методы прикладного
уровня.
После того как структура метаданных файла будет найдена, восстановление
проходит просто. Фактически оно не отличается от чтения содержимого суще-
существующего файла. В примере на рис. 8.10 (А) в записи метаданных удаленного
файла остались адреса блоков данных, что позволяет легко прочитать его содержи-
содержимое. На рис. 8.10 (В) показан пример, в котором ОС стерла адреса после удаления

файла. Практические методы восстановления будут рассмотрены далее, в главах
с описаниями конкретных файловых систем.
Рис. 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 (С)).

Рис. 8.11. Последовательность состояний при выделении и освобождении блоков данных:
в состоянии (С) неясно, к какой записи метаданных относятся данные в блоке 1000
Этот пример показывает, что, даже если свободная структура метаданных по-
прежнему содержит адрес блока данных, очень трудно определить, относится ли
содержимое блока к этому файлу или другому, созданному после освобождения
структуры метаданных. Чтобы проверить правильность восстановления, можно
попытаться открыть файл в том приложении, в котором (по вашим предположе-
предположениям) он был создан. Если новый файл занял один из блоков удаленного файла
и записал в него свои данные, скорее всего, внутренняя структура файла будет
повреждена и открыть его не удастся.
Многие программы предоставляют функции восстановления файлов. К сожа-
сожалению, информация о процедурах, используемых для восстановления при отсут-
отсутствии метаданных, практически не публикуется, поэтому вы должны протестиро-
протестировать и сравнить программы из своего инструментария. В этом вам помогут тестовые
образы на сайте DF1\'l (Digital Forensic Tool Testing).
Сжатые и разреженные файлы
Некоторые файловые системы позволяют хранить данные в сжатом формате, что-
чтобы они занимали меньше места на диске. Сжатие файлов может происходить как
минимум на трех уровнях. На самом высоком уровне данные сжимаются в файло-
файловом формате. В качестве примера можно привести файлы JPEG: данные графичес-
графического изображения хранятся в сжатом виде, а заголовок файла — нет. На следующем
уровне внешняя программа сжимает все содержимое файла и создает новый файл1.
Перед использованием сжатый файл необходимо распаковать в другой файл.
1 Примеры внешних программ сжатия файлов — WinZip (www.winzip.com) и gzip (http://www.gnu.org/
software/gzip/gzip.html).

Последний и самый низкий уровень сжатия — сжатие данных на уровне фай-
файловой системы. В этом случае приложение, записывающее данные, не знает, что
файл будет храниться в сжатом виде. В файловых системах используются два стан-
стандартных метода сжатия. Наиболее очевидное решение — применение к блокам
данных стандартных алгоритмов сжатия, используемых для файлов. Во втором
методе файловая система не выделяет физический блок данных, который должен
быть заполнен одними нулями. Файлы, в которых пропускаются блоки данных,
заполненные одними нулями, называются разреженными файлами] пример пока-
показан на рис. 8.12. Существует несколько способов реализации разреженных фай-
файлов. Например, UFS (Unix File System) записывает 0 в поле, в котором обычно
хранится адрес блока. Ни одному файлу не может быть выделен блок 0; ОС знает,
что ноль означает блок, заполненный одними нулями.
Сжатые файлы затрудняют процесс анализа, потому что программа анализа
должна поддерживать тот же алгоритм сжатия. Кроме того, некоторые формы по-
поиска по ключевым словам и восстановления файлов теряют эффективность, по-
потому что они просматривают сжатые данные вместо исходных.
Рис. 8.12. Файл хранится в сжатом формате: блоки данных, заполненные
одними нулями, не записываются на диск
Шифрование файлов
Содержимое файла может храниться в зашифрованном виде для защиты от по-
постороннего доступа. Шифрование может выполняться приложением, создавшим
файл, внешним приложением, которое читает незашифрованный файл и создает
зашифрованный файл1, или операционной системой при создании файла. Перед
тем как записывать файл на диск, ОС шифрует его и сохраняет текст шифра в бло-
блоках данных. Информация, не относящаяся к содержимому файла (например, имя
файла и время последнего обращения), обычно не шифруется. Приложение, за-
записывающее данные, не знает, что данные хранятся в зашифрованном виде. Дру-
Другой способ шифрования содержимого файлов заключается в шифровании целого
тома2. В этом случае шифруются все данные файловой системы, не только содер-
содержимое файлов. Как правило, том с операционной системой не шифруется.
Шифрование данных создает проблемы при анализе, поскольку многие файлы
оказываются недоступными, если эксперту неизвестен ключ шифрования или
пароль. Еще хуже, если неизвестен способ шифрования. Существуют програм-
программы для подбора ключей и паролей простым перебором («атака методом грубой
силы»), но если алгоритм неизвестен, они тоже оказываются неэффективными.
Если зашифрованы только отдельные файлы и каталоги, иногда удается найти
1 Распространенные примеры — PGP (www.pgp.com) и GPG (www.gpg.org).
2 Примеры — PGP Disk (www.pgp.com), шифрованные дисковые образы Macintosh (www.apple.com)
и зашифрованные образы Linux AES.

копии незашифрованных данных во временных файлах или свободных блоках
[Casey, 2002; Wolfe, 2004].
Методы анализа
Перейдем к анализу в категории метаданных. Метаданные могут использоваться
для просмотра содержимого файлов, поиска значений и обнаружения удаленных
файлов.
Поиск метаданных
Во многих случаях анализ метаданных выполняется потому, что мы нашли имя
файла, ссылающееся на конкретную структуру метаданных, и хотим получить до-
дополнительную информацию о файле. Таким образом, нужно найти запись мета-
метаданных и обработать ее. Например, при просмотре содержимого каталога мы об-
обнаружили файл badstuff.txt и теперь хотим узнать его содержимое и дату создания.
Многие программы автоматически выполняют такого рода поиск при составле-
составлении списков имен файлов в каталогах и позволяют отсортировать результаты по
значениям метаданных.
Конкретная процедура поиска зависит от файловой системы, так как метадан-
метаданные могут храниться в разных местах. В TSK для вывода структур метаданных
используется программа istat. На рис. 8.13 изображена файловая система со струк-
структурами метаданных, обнаруженными в блоке 371. Программа читает блок данных
и выводит содержимое двух записей метаданных. Одна запись представляет уда-
удаленный файл, а другая — существующий каталог.
Рис. 8.13. Процесс просмотра содержимого записи метаданных
Просмотр логических файлов
После обнаружения метаданных можно просмотреть содержимое файла; для это-
этого следует прочитать блоки данных, выделенные файлу. Обычно это делается при
поиске улик в содержимом файла. Допустим, мы определили адрес блока данных
файла badstuff.txt и теперь хотим ознакомиться с его содержимым.
Этот процесс работает как в категории метаданных, так и в категории данных
содержимого. На рис. 8.14 перечислены блоки данных, связанные с записями
метаданных 1 и 2. Многие графические программы объединяют эту процедуру

с перечислением имен файлов. Если выбрать файл, программа переходит к поис-
поиску блоков данных, указанных в метаданных файла.
В процессе поиска необходимо помнить о резервном пространстве, потому что
последний блок данных может использоваться файлом лишь частично. Чтобы оп-
определить используемую часть последнего блока, вычислите остаток от деления
размера файла на размер каждого блока данных.
В пакете TSK для просмотра содержимого блоков данных, выделенных струк-
структуре метаданных, используется программа icat. При запуске с ключом -s выводит-
выводится информация о резервном пространстве, а с ключом -г программа пытается вос-
восстанавливать удаленные файлы.
Рис. 8.14. Объединение информации из метаданных и блоков данных
позволяет просмотреть содержимое файла
Поиск в логических файлах
Предыдущие методы подразумевают, что вам известен конкретный файл и вы
хотите просмотреть его содержимое. Нередко возникает обратная задача — найти
файл на основании его содержимого (например, найти все файлы, содержащие
слово «forensics»). В таких ситуациях применяется поиск в логических файлах.
Он основан на тех же принципах, что и просмотр логических файлов, но вместо
просмотра содержимого в файле ищется конкретное значение.
Своим названием этот метод сильно напоминает поиск в логической файло-
файловой системе. Действительно, эти методы очень похожи, только в данном случае
поиск в блоках данных производится в порядке их использования файлами, а не
в порядке их следования в томе. На рис. 8.15 изображены две записи метаданных
и выделенные им блоки данных. В данном случае поиск осуществляется в блоках
2, 3, 4 и 6 как в едином наборе. Преимущество такого вида поиска перед поиском
в логической файловой системе состоит в том, что он находит данные, фрагмен-
тированные по блокам данных или секторам. Допустим, мы ищем слово «forensics»,
которое начинается в блоке данных 4 и заканчивается в блоке 6. При поиске в ло-
логической файловой системе оно найдено не будет, потому что оно не содержится
в смежных блоках данных. Разновидностью этого вида поиска является поиск
файла с известным хеш-кодом MD5 или SHA-1.

Не забывайте, что логические адреса файлов присваиваются только выделен-
выделенным блокам данных. Это означает, что для поиска того же значения в свободных
блоках данных следует провести поиск в логическом томе. Например, поиск в ло-
логических файлах на рис. 8.15 не затронет блоки 0 и 1, поэтому необходимо прове-
провести второй поиск, который включал бы блоки 0, 1, 7, 9, 10, 11 и т. д.
Рис. 8.15. Лри поиске в логическом файле просматриваются блоки данных,
выделенные записи метаданных
Обязательно выясните, включает ли ваша программа анализа резервное про-
пространство файла при поиске в логическом файле; одни программы это делают,
другие — нет. Для этой цели можно воспользоваться поиском по ключевым сло-
словам в тестовых образах на сайте DFTT.
Анализ свободных метаданных
Если поиск проводится в содержимом удаленных файлов, не ограничивайтесь
именами удаленных файлов из содержимого каталога. Примеры будут приведе-
приведены в разделе «Категория данных имен файлов», а пока достаточно сказать, что
имя удаленного файла может быть использовано заново прежде, чем его структу-
структура метаданных. Следовательно, ваши улики могут находиться в свободной запи-
записи метаданных, однако вы не увидите их, потому что эта запись не связана с име-
именем. Многие программы анализа выводят список свободных записей метаданных
для проведения поиска или просмотра. Для получения списка свободных струк-
структур данных в TSK используется программа its.
Поиск и сортировка по атрибутам метаданных
На практике поиск файлов также нередко осуществляется по одному из их полей
метаданных. Допустим, имеется система обнаружения вторжений (IDS, Intrusion
Detection System) и вы хотите найти все файлы, созданные в течение ближайших
двух минут с момента полученного предупреждения. А может быть, вы анализи-
анализируете действия некоторого пользователя и хотите найти все файлы, в которые

ему разрешена запись. В общем случае на некоторой стадии расследования может
возникнуть необходимость в поиске значений метаданных. Некоторые примеры
будут рассмотрены в этом разделе.
Время обращения к файлу легко изменить в любой системе, но оно часто со-
содержит полезную информацию. Предположим, мы проверяем гипотезу, что зло-
злоумышленник получил доступ к компьютеру в 20:13 и установил в системе вредо-
вредоносный код; для этого можно провести поиск всех файлов, созданных между 20:13
и 8:23. Если за этот промежуток времени не будет найдено ни одного подозри-
подозрительного файла или мы найдем посторонний файл, созданный в другое время, это
означает, что неверно задано время создания файла или неверна наша гипотеза (а
возможно, и то и другое).
Если вы столкнулись с компьютером, о котором вам мало что известно, воз-
возможно, вам поможет список последних обращений и созданий файлов. Эта ин-
информация даст представление о том, как использовался компьютер в последнее
время.
Некоторые программы составляют временные диаграммы файловых операций.
Как правило, количество точек данных на диаграмме для каждого файла совпада-
совпадает с количеством временных штампов. Например, если в метаданных хранится
время последнего обращения, последней записи и последней модификации, на
диаграмме создаются три точки данных. В пакете TSK для построения времен-
временных диаграмм файловых операций используется программа mactime. Пример вы-
выходных данных mactime для каталога 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 /bootstat.dat
1024 mac /system32/config/default.L0G
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. У некоторых программ также возникают проблемы с летним вре-
временем.

Еще одна стандартная задача — поиск файлов, в которые некоторому пользо-
пользователю разрешена запись. Результат поиска покажет, какие файлы могли быть
созданы подозреваемым (предполагается, что ОС соблюдает разрешения досту-
доступа, а подозреваемый не имеет прав администратора). Также возможно проведе-
проведение поиска по идентификатору владельца. Обычно такие операции используют-
используются при расследовании действий конкретного пользователя.
Если ранее мы провели поиск в логической файловой системе и обнаружили
интересные данные в одном из блоков, можно попытаться найти адрес этого бло-
блока в метаданных. Возможно, поиск покажет, какому файлу был выделен блок дан-
данных, после чего можно будет найти другие блоки данных, принадлежащие тому
же файлу. Пример показан на рис. 8.16; улики были обнаружены в блоке данных
34. Поиск в метаданных показывает, что блок был выделен структуре 107 наряду
с блоками данных 33 и 36. Если ОС не стирает адреса при удалении файлов, этот
процесс также поможет найти освободившуюся запись метаданных. Программа
ifind из пакета TSK выполнит эту работу за вас.
Рис. 8.16. Поиск в структурах метаданных позволит узнать, какой из них
был выделен заданный блок данных
Порядок выделения записей метаданных
Если потребуется узнать относительный порядок выделения двух записей, воз-
возможно, это удастся сделать с применением стратегии выделения, используемой
вашей ОС. Это сложная задача, которая к тому же сильно зависит от ОС. Записи
метаданных обычно выделяются по стратегии поиска первой доступной или сле-
следующей доступной записи. Полное описание этой методики анализа выходит за
рамки книги, поскольку она зависит от прикладного уровня.
Проверка целостности данных
Проверка целостности метаданных может выявить попытки сокрытия данных.
Также может оказаться, что образ файловой системы содержит внутренние ошиб-
ошибки, которые не позволяют получить полную информацию. Проверка целостности
может выполняться только на основе необходимых данных, в том числе адресов
блоков данных, размера и состояния выделения каждой записи метаданных.
Один из способов проверки заключается в том, чтобы проверить каждую вы-
выделенную запись и убедиться в том, что выделенные ей блоки данных действи-
действительно выделены. Также можно убедиться в том, что количество выделенных

блоков данных соответствует размеру файла. Как правило, файловые системы не
выделяют больше блоков данных, чем это необходимо. В разделе «Проверка це-
целостности данных» для категории содержимого описана проверка того, что на
каждый выделенный блок данных ссылается ровно одна выделенная запись мета-
метаданных.
Также следует проверить, что записям специальных типов файлов не выделя-
выделяются блоки данных. Например, в некоторых файловых системах создаются спе-
специальные файлы, называемые сокетами и используемые при обмена данных между
процессами. Таким файлам блоки данных не выделяются.
Еще одна проверка целостности использует информацию из категории имен
файлов и убеждается в том, что каждой выделенной записи каталога назначено
имя, которое ссылается на эту запись. Существуют проверки диапазонов дат
и других вспомогательных данных, но более точные проверки в таких случаях
обычно неприменимы.
Методы надежного удаления
Метаданные могут уничтожаться при удалении файлов, чтобы затруднить их вос-
восстановление. Время, размер и адреса блоков данных заполняются нулями или
случайными данными. Эксперт может выявить факт стирания, обнаружив обну-
обнуленные или другие недействительные записи между двумя действительными за-
записями. Более разумная программа надежного удаления заполняет структуру ме-
метаданных действительными данными, не имеющими отношения к исходному
файлу. Еще более надежная программа сдвинет оставшиеся записи, чтобы между
ними не оставалось неиспользуемых. Впрочем, на такие сдвиги уйдет очень мно-
много времени.
Категория имен файлов
К категории имен файлов относятся данные, благодаря которым пользователь
может ссылаться на файл по имени (вместо адреса его метаданных). В минималь-
минимальном варианте эта категория данных включает только имя файла и адрес его мета-
метаданных. В некоторых файловых системах к ней также причисляется информация
о типе файла или временные штампы, но такая классификация не является стан-
стандартной.
Один из важных этапов анализа имен файлов — определение местонахожде-
местонахождение корневого каталога, необходимого для поиска файла по полному имени. На-
Например, в Windows каталог С:\ является корневым каталогом диска С:. В каждой
файловой системе используется свой способ определения местонахождения кор-
корневого каталога.
Общие сведения
В этом разделе мы рассмотрим общие концепции категории имен файлов. Эта
категория относительно проста; нас интересует только метод восстановления фай-
файлов по именам.

Восстановление файлов по именам
Как было показано при описании категории метаданных, удаленные файлы мож-
можно восстановить по метаданным. При восстановлении, основанном на именах фай-
файлов, имя удаленного файла и соответствующий ему адрес метаданных использу-
используются для восстановления содержимого файла по метаданным. Иначе говоря, вся
«черная работа» выполняется на уровне метаданных, а на уровне имен файлов мы
ограничиваемся идентификацией записей метаданных, используемых для восста-
восстановления.
На рис. 8.17 показаны два имени файлов и три записи метаданных. Файл favo-
rites.txt удален, а его имя ссылается на свободную запись метаданных. Мы можем
попытаться восстановить его содержимое, используя методы восстановления по
метаданным. Обратите внимание: содержимое, связанное с записью метаданных
2, тоже можно восстановить, но его имя уже утрачено. В этом разделе рассмат-
рассматриваются некоторые проблемы, связанные с восстановлением файлов по име-
именам.
Рис. 8.17. Поиск в структурах метаданных позволит узнать, какой из них
был выделен заданный блок данных
В разделе «Восстановление файлов по метаданным» приводятся примеры того,
как повторное выделение блоков данных и их десинхронизация с метаданными
усложняют процесс восстановления. Сейчас мы рассмотрим эти примеры более
подробно и разберемся, как нарушается синхронизация имен файлов с метадан-
метаданными.
Допустим, имеется файл, в структуре имени файла которого присутствует имя
fHel.dat; структура ссылается на запись метаданных 100 (рис. 8.18 (А)). Файл был
удален, а обе структуры (имени файла и метаданных) были освобождены, однако
указатель в структуре имени файла не был стерт. Новый файл fiLe2.dat создается
в новой структуре данных, и ему заново выделяется запись метаданных 100
(рис. 8.18 (В)). Позднее файл file2.dat также был стерт, а его структуры имени
файла и метаданных освободились (рис. 8.18 (С)). Если проанализировать систе-
систему в этом состоянии, мы найдем в ней две структуры имени файла, ссылающиеся
на одну запись метаданных. Неизвестно, какому файлу принадлежит содержи-
содержимое, адрес которого хранится в записи метаданных 100— filel.dat или file2.dat

Рис. 8.18. Последовательность состояний при создании и удалении файлов: в состоянии (В)
две структуры имен файлов ссылаются на одну структуру метаданных. Невозможно
определить, к какой из них относится содержимое файла
Чтобы ситуация стала еще более запутанной, продолжим этот пример. Файл
file3.dat создается в новой записи метаданных 200 и блоке данных 1000 из преды-
предыдущего примера (рис. 8.19 (А)). Файл fHe3.dat удаляется, и структура имени фай-
файла передается файлу file4.dat (который нас не интересует). Затем создается файл
fiLe5.dat с записью метаданных 100 и блоком данных 1000 (рис. 8.19 (С)). Файл
file5.dat тоже удаляется. Наконец, создается файл file6.dat, которому повторно вы-
выделяется та же структура имени файла, что и file5.dat, но этот файл использует
новую запись метаданных 300 и новый блок данных 2000 (рис. 8.19(С)).
Рис. 8.19. Последовательность состояний при создании и удалении файлов: в состоянии (С)
нарушается синхронизация некоторых указателей

Предположим, что система анализируется в этом состоянии. Мы сталкиваем-
сталкиваемся со следующими проблемами:
• На блок данных 1000 ссылаются две записи метаданных, и мы не знаем, какая
из них была последней; также неизвестно, существовали ли другие записи ме-
метаданных, ссылавшиеся на нее с момента повторного выделения.
• На запись метаданных 100 ссылаются две структуры имен файлов, и мы не
знаем, какая из них была последней; также неизвестно, существовали ли дру-
другие записи, ссылавшиеся на нее с момента повторного выделения. В нашем
примере последним был файл file5.dat, но он более не существует.
• На запись метаданных 200 не ссылается ни одна структура имени файла, по-
поэтому мы не можем определить имя хотя бы одного файла, которому она была
выделена.
Эти проблемы могут повлиять на работу эксперта в нескольких отношениях.
Представьте программу анализа, которая читает список файлов в каталоге и вы-
выводит рядом с каждым именем соответствующие временные штампы. Информа-
Информация о времени и содержимом filel.dat и file2.dat будет неверной, потому что она
в действительности относится к файлу file5.dat, имя которого более не существу-
существует. Значения, связанные с записью метаданных 200, не будут присутствовать в
списках файлов, потому что с этой записью не связана структура имени. Именно
из-за таких ситуаций я разделил категории имен файлов и метаданных; было бы
неправильно считать, что между ними существует более тесная связь.
Итак, при анализе удаленных файлов с точки зрения имен следует помнить,
что записи метаданных и блоки данных могли быть выделены новому файлу. Так-
Также помните, что вам придется проанализировать свободные записи метаданных,
чтобы найти те из них, на которые не ссылаются структуры имен файлов.
Методы анализа
В этом разделе рассматриваются методы анализа, применимые к данным из кате-
категории имен файлов.
Получение списка имен файлов
Категория данных имен файлов предназначена для того, чтобы ассоциировать
файлы с именами. Как нетрудно предположить, одним из самых распространен-
распространенных методов анализа является получение списка файлов и каталогов. Обычно это
делается при поиске улик на основании имени, пути или расширения файла. Ког-
Когда файл будет опознан, адрес его метаданных используется для получения допол-
дополнительной информации. У этого метода есть несколько разновидностей: напри-
например, файлы можно отсортировать по расширениям, что позволяет сгруппировать
однотипные файлы.
Многие файловые системы не стирают имена удаленных файлов, поэтому
эти имена тоже будут присутствовать в списке. Впрочем, иногда адрес метадан-
метаданных стирается при удалении файла, и получить дополнительную информацию
не удастся.
Получение списка начинается с обнаружения корневого каталога файловой
системы. Обычно для этого используется процесс, который был описан ранее для

просмотра логических файлов в разделе «Категория метаданных». Строение кор-
корневого каталога хранится в записи метаданных, поэтому мы должны найти за-
запись и блоки данных, выделенные для этого каталога.
Обнаружив содержимое каталога, мы обрабатываем его, получая список файлов
и соответствующих им адресов метаданных. Если пользователь хочет просмот-
просмотреть содержимое какого-либо файла в списке, можно воспользоваться методом
просмотра логических файлов по указанному адресу метаданных. Если потребу-
потребуется вывести содержимое другого каталога, мы загружаем и обрабатываем его.
В любом случае процесс основан на просмотре логических файлов.
Эта методика поддерживается большинством программ анализа, причем мно-
многие программы объединяют информацию из категории имен файлов с информа-
информацией из категории метаданных — например, чтобы в одном представлении с име-
именами файлов выводились пометки даты и времени. На рис. 8.20 показан пример
анализа: при обработке блока данных 401 были обнаружены два имени. Нас инте-
интересует файл favorites.txt; мы видим, что его метаданные находятся в записи 3. В на-
нашей файловой системе соответствующая структура метаданных находится в бло-
блоке данных 200. Мы обрабатываем информацию из соответствующего блока данных,
получая размер и адреса содержимого этого файла.
Рис. 8.20. Чтобы получить список имен файлов, мы обрабатываем содержимое каталога
и извлекаем имена (а иногда и связанные с ним метаданные)
Данный метод анализа поддерживается многими программами. В пакете TSK
для вывода имен существующих и удаленных файлов используется программа fls.
Поиск имен файлов
Список имен файлов удобен в том случае, если вы знаете имя искомого файла, но
это не всегда так. Если полное имя файла неизвестно, можно провести поиск по
известной части. Например, мы можем знать расширение файла или его имя, но
без каталога. В результате поиска выводится список файлов, удовлетворяющих
критерию поиска. Скажем, если в ситуации на рис. 8.20 провести поиск по расши-
расширению .txt, программа просмотрит каждую запись и выведет как badstuff.txt, так

и favorites.txt. Учтите, что поиск по расширению не всегда возвращает файлы за-
заданного типа, поскольку расширение может быть изменено для скрытия файла.
Для поиска всех файлов заданного типа необходимо использовать методы при-
прикладного уровня, анализирующие строение файла.
Процесс поиска по имени сходен с процессом получения списка имен файлов.
Сначала загружается и обрабатывается содержимое каталога, затем каждая за-
запись сравнивается с заданным критерием. Если при проведении рекурсивного
поиска обнаруживается каталог, то его содержимое также участвует в поиске.
Другая разновидность поиска в этой категории — поиск имени файла, которо-
которому была выделена заданная запись метаданных. Это может быть необходимо, если
вы обнаружили улики в блоке данных, а затем нашли структуру метаданных, ко-
которой он был выделен. После обнаружения структуры метаданных среди имен
файлов ищется полное имя файла, которому был выделен блок с уликами. Задача
решается программой ffind пакета TSK.
Порядок выделения структур данных
Как уже говорилось ранее при обсуждении содержимого и метаданных, порядок
выделения структур имен файлов может использоваться для определения отно-
относительного порядка создания двух имен файлов. Метод анализа зависит от спе-
специфики ОС и выходит за рамки книги.
Проверка целостности данных
При проверке целостности данных имен файлов эксперт убеждается в том, что
все выделенные структуры имен ссылаются на выделенные структуры метадан-
метаданных. В некоторых файловых системах одному файлу может быть присвоено не-
несколько имен; как правило, эта функциональность реализуется созданием несколь-
нескольких структур имен файлов с одинаковыми адресами метаданных.
Методы надежного удаления
Программы надежного удаления в этой категории стирают имя и адрес метаданных
в структуре. Один из методов удаления может стирать поля структуры имени фай-
файла; в этом случае анализ покажет, что запись существует, но ее данные стали недей-
недействительными. Например, имя файла setuplog.txt будет заменено именем abedefgh.123.
В некоторых ОС это решение усложняется тем, что ОС помещает новое имя в ко-
конец списка, используя стратегию поиска следующей доступной структуры.
Другая методика надежного удаления имен файлов заключается в реорганиза-
реорганизации списка имен, при которой имя удаленного файла заменяется именем одного
из существующих файлов. Этот метод гораздо сложнее первого; с другой сторо-
стороны, он гораздо эффективнее в отношении сокрытия данных. Эксперт может даже
не заподозрить, что с каталогом что-то не в порядке.
Категория прикладных данных
В некоторых файловых системах хранятся данные, традиционно относящиеся
к прикладной категории. Эти данные не являются необходимыми для файловой

системы и обычно хранятся в виде специальных данных файловой системы, а не
обычных файлов, потому что такой способ более эффективен. В этом разделе рас-
рассматривается механизм журналов — один из самых распространенных механиз-
механизмов прикладной категории.
С технической точки зрения любой файл, создаваемый ОС или приложением,
может быть реализован в виде расширения файловой системы. Например, Acme
Software может решить, что ОС будет работать быстрее, если зарезервировать часть
файловой системы под адресную книгу. Вместо того чтобы хранить имена и адре-
адреса в файле, система будет сохранять их в специальном разделе тома. Возможно,
такой подход обеспечит выигрыш по эффективности, но для файловой системы
он не является обязательным.
Журналы файловой системы
Как хорошо известно любому пользователю, на компьютерах иногда происходят
сбои. Если в момент сбоя ОС записывала данные на диск или в буфере остава-
оставались несохраненные изменения, сбой может привести к нарушению целостности
системы. В системе может появиться выделенная структура метаданных с выде-
выделенными блоками данных, но ни одна структура имени файла не будет ссылаться
на эту структуру метаданных.
Для обнаружения подобных нарушений ОС запускает программу, которая скани-
сканирует файловую систему в поисках отсутствующих указателей и других признаков
повреждений. В больших файловых системах этот процесс может занять очень
много времени. Для упрощения работы программы сканирования в некоторых
файловых системах создаются журналы. Перед внесением каких-либо изменений
в метаданные файловой системы в журнале создается запись с описанием будущих
изменений. После того как изменения будут внесены, в журнале создается новая
запись с информацией об их успешном внесении. Если в системе происходит сбой,
сканирующая программа читает журнал и находит незавершенные операции. За-
Затем программа либо вносит изменения, либо возвращает их в исходное состояние.
Многие современные файловые системы поддерживают журналы, потому что
они экономят время при загрузке больших систем. Журнальные данные относят-
относятся к категории прикладных данных, потому что файловая система может функ-
функционировать и без них. Эти данные существуют лишь для того, чтобы ускорять
проверку целостности данных.
Журналы файловой системы могут пригодиться при расследованиях, хотя до
настоящего времени они еще не использовались в полной мере. В журналах содер-
содержится информация о недавно происходивших событиях файловой системы, а эта
информация может помочь при реконструкции недавнего инцидента. Большинство
программ анализа не обрабатывает содержимое журналов файловой системы. В па-
пакет TSK входят программы jls и jcat, выводящие содержимое некоторых журналов.
Методы поиска на прикладном уровне
В начале книги я упоминал о том, что в модели анализа основное внимание бу-
будет уделяться уровням томов и файловой системы. В этом разделе мы перейдем

на прикладной уровень и рассмотрим пару методов восстановления удаленных
файлов и упорядочения выделенных файлов для анализа. Эти методы не зависят
от файловой системы, поэтому в последующих главах они обсуждаться не будут.
Оба метода основаны на том факте, что многие файлы имеют четко определенный
формат и включают сигнатуру, уникальную для данного типа файла. Сигнатура
может использоваться для определения типа неизвестного файла. Команда file, при-
присутствующая во многих системах семейства UNIX, содержит базу данных сигнатур
для идентификации структуры неизвестных файлов (ftp://ftp.astron.com/pub/fiLe).
Восстановление файлов на прикладном уровне
Извлечением данных (data carving) называется процесс поиска во фрагменте дан-
данных начальной и конечной сигнатуры для известных типов файлов. В результате
строится список файлов, содержащих одну из сигнатур. Как правило, эта проце-
процедура выполняется со свободным пространством файловой системы и позволяет
аналитику восстанавливать файлы, на которые не ссылается ни одна структура
метаданных. Например, изображение в формате JPEG содержит стандартный за-
заголовок и завершитель. Если аналитику потребуется восстановить удаленные
графические изображения, он сохранит в файле содержимое свободных блоков
и запустит программу извлечения данных. Программа ищет заголовки JPEG и из-
извлекает данные, находящиеся между заголовком и завершителем.
Примером программы, выполняющей такую операцию, является программа
foremost (http://foremost.sourceforge.net), разработанная специальными агентами
Крисом Кендаллом (Kris Kendall) и Джессе Корнблумом (Jesse Kornblum) из Бюро
специальных расследований ВВС США. Программа foremost анализирует файло-
файловую систему или дисковый образ на основании содержимого конфигурационного
файла, в котором создается запись для каждой сигнатуры. В записи указывается
известное значение заголовка, максимальный размер файла, признак учета реги-
регистра символов в заголовке, типичное расширение этого типа файлов и необяза-
необязательный завершитель. Например, для файлов JPEG запись выглядит так:
jpg у 2000000 \xff\xd8 \xff\xd9
Это означает, что файл имеет типичное расширение .jpg, в его заголовке и за-
завершителе учитывается регистр символов, заголовок равен 0xffd8, а завершитель —
0xffd9. Максимальный размер файла составляет 200 000 байт, и если заголовок не
найден в пределах этого смещения, извлечение данных прерывается. В наборе дан-
данных на рис. 8.21 заголовок JPEG расположен в двух первых байтах сектора 902,
а завершитель — в середине сектора 905. Содержимое секторов 902,903,904 и в на-
начале сектора 905 извлекается как изображение JPEG.
Рис. 8.21. Блоки физических данных, анализ которых обнаруживает графическое
изображение в формате JPEG в секторах 902-905
Аналогичная программа Lazarus из пакета The Coroner's Toolkit (http://www.porcu-
pine.org/forensics/tct.htmL), автор — Дэн Фармер (Dan Farmer), просматривает

каждый сектор низкоуровневого образа и выполняет для него команду file. В ре-
результате создаются группы смежных секторов, относящихся к одному типу. Ко-
Конечный результат работы программы представляет собой список с указанием каж-
каждого сектора и его типа. Фактически программа дает возможность сортировать
данные по их содержимому. Концепция интересная, однако программа написана
на Perl и иногда работает довольно медленно.
Сортировка файлов по типу
Тип файлов может использоваться для упорядочения файлов в файловой сис-
системе. Если вы ищете файлы конкретного типа, отсортируйте их на основании
структуры содержимого. Например, для каждого файла можно выполнить ко-
команду file и сгруппировать однотипные файлы: в одну группу входит графика,
в другую — исполняемые файлы, и т. д. Такая возможность предусмотрена во мно-
многих программах анализа, но не всегда ясно, как осуществляется сортировка: по
расширению или по сигнатуре файла. Программа sorter из пакета TSK сортирует
файлы по сигнатуре.
Конкретные файловые системы
В оставшихся главах книги мы рассмотрим способы хранения данных в системах
FAT, NTFS, Ext2/Ext3 и UFS и применим к ним структуру из пяти категорий.
В табл. 8.1 приведены имена структур данных в каждой категории данных для фай-
файловых систем, описанных в книге.
Таблица 8.1. Структуры данных в файловых системах, описанных в книге
(деление по категориям)
Файловая Содержимое Метаданные Имя файла Прикладные
система данные
ExtX Суперблок, Блоки, битовая I-узлы, карта Записи Журнал
дескриптор карта блоков i-узлов, каталога
группы расширенные
атрибуты
FAT Загрузочный Кластеры, FAT Записи Записи —
сектор, каталога, FAT каталога
FSINFO
NTFS $Boot, Кластеры, $MFT, $mfTMirr, $FILE_NAME, Дисковые
$Volume, $Bitmap $STANDARD_ $IDX_ROOT, квоты,
$AttrDef INFORMATION, $IDX_ журнал,
$DATA, ALLOCATION, журнал
$ATTRIBUTE_ $BITMAP изменений
LIST, $SECURITY_
DESCRIPTOR
UFS Суперблок, Блоки, фраг- I-узлы, карта Записи —
дескриптор менты, битовая i-узлов, расши- каталога
группы карта блоков, ренные атрибуты
битовая карта
фрагментов

Существуют и другие файловые системы, которые не вошли в книгу, но могут
встретиться в вашей работе. Например, 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, Выбор метода поиска в зависимости от типа искомых улик
Требуется найти Категория данных Метод поиска
Файл по имени, расширению Имя файла Поиск по имени файла или вывод
или каталогу содержимого каталога
Существующий или удален- Имя файла и метаданные Поиск по атрибутам метаданных
ный файл по временным
штампам
Существующий файл по зна- Имя файла (с использова- Поиск по логическим файлам
чению, присутствующему нием метаданных и данных
в содержимом содержимого)
Существующий файл Имя файла (с использова- Поиск по логическим файлам
по хеш-коду SHA-1 нием метаданных и данных с хеш-кодами
содержимого)
Существующий файл Имя файла (с использова- Поиск по логическим файлам
или свободный блок данных нием метаданных и данных с восстановлением по метаданным
по значению, присутствую- содержимого) и поиском в логической файловой
щему в содержимом системе
Все удаленные файлы Прикладные данные и со- Восстановление на прикладном
по типу приложения держимое уровне (извлечение данных)
в свободных блоках
Свободные данные по со- Данные содержимого Поиск в логической файловой
держимому (без учета системе
типа приложения)

Библиография
• Apple. «Technical Note TNI 150-HFS Plus Volume Format». March 2004. http://
developer.apple.com/technotes/tn/tnll50.htmL
• Buchholz, Florian, «The Structure of the Reiser File System». August 17, 2003.
http://www.cerias.purdue.edu/homes/florian/reiser/reiserfs.php.
• Carrier, Brian. «Digital Forensic Tool Testing Images», 2004. http://dftt.source-
forge.net.
• Casey, Eoghan. «Practical Approaches to Recovering Encrypted Digital Evidence».
International Journal of Digital Evidence, 1 C), 2002. http://www.ijde.org.
• IBM. «Journaled File System Technology for Linux». 2004. http://www.ibm.com/
developerworks/oss/jfs/.
• Kruse, Warren. «Computer Forensics Primer». CSI 30th Annual Computer Security
Conference, November 3, 2003. http://csiannual.com/classes/jl.pdf.
• Kurz, Gerson. «ReiserFS Docs», 2003. http://p-nand-q.com/download/rfstool/rei-
serfs_docs.html.
• Reiser, Hans. «Reiser4». 2003. http://www.namesys.com.
• Wolfe, Hank. «Penetrating Encrypted Evidence». Journal of Digital Investigation,
1B), 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 заключается в том, что каждому
файлу и каталогу выделяется структура данных, называемая записью каталога.
В этой структуре хранится имя файла, его размер, начальный адрес содержимого

файла и другие метаданные. Содержимое файлов и каталогов хранится в блоках
данных, называемых кластерами. Если файлу или каталогу выделяется более одно-
одного кластера, остальные кластеры находятся при помощи структуры данных, назы-
называемой FAT. Структура FAT используется как для идентификации следующих
кластеров в файлах, так и для определения состояния выделения кластеров. Таким
образом, она задействована как в категории содержимого, так и в категории мета-
метаданных. Существует три версии FAT: FAT12, FAT16 и FAT32. Они отличаются
друг от друга прежде всего размером записей в структуре FAT. Мы изучим связи
между структурами данных более подробно, а их общая схема показана на рис. 9.1.
Рис. 9.1. Отношения между записями каталогов, кластерами и FAT
Файловая система FAT делится на три физические области (рис. 9.2). Первая
область называется зарезервированной; в ней хранятся данные из категории файло-
файловой системы. В FAT12 и FAT16 зарезервированная область занимает всего 1 сек-
сектор, но формально ее размер определяется в загрузочном секторе. Вторая область —
область FAT — содержит основные и резервные структуры FAT. Она начинается
в секторе, следующем за зарезервированной областью, а ее размер определяется
количеством и размером структур FAT. Третья область — область данных — со-
содержит кластеры, выделяемые для хранения файлов и содержимого каталогов.
Рис. 9.2. Физическая структура файловой системы 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 адаптироваться к появлению

поврежденных секторов в начале области данных и увеличивать размер каталога
до необходимого размера. Корневой каталог FAT 12/16 обладает фиксированным
размером, заданным в загрузочном секторе. Начальный адрес корневого каталога
FAT32 хранится в загрузочном секторе, а его размер определяется по структуре
FAT. На рис.9.3 показаны разные поля загрузочного сектора, используемые для
определения структуры файловых систем FAT12/16 и FAT32.
Рис. 9.3. Структура файловой системы FAT и данные загрузочного сектора,
используемые для вычисления начальных адресов и размеров
Вспомогательные данные загрузочного сектора
Помимо информации о структуре системы в загрузочном секторе хранится много
вспомогательных данных. Эти данные не являются необходимыми для сохране-
сохранения и чтения файлов, существуют исключительно для удобства и могут содер-
содержать неверную информацию. Одно из таких значений — строка из 8 символов,
называемая меткой OEM. В ней может храниться обозначение системы, создав-
создавшей экземпляр FAT, но это значение не является обязательным. Например, сис-
система Windows 95 заносит в это поле строку «MSWIN4.0», Windows 98 — строку
«MSWIN4.1», a Windows XP и 2000 — «MSDOS5.0». Я выяснил, что команда Linux
mkfs.msdos заполняет его строкой mkdosfs, некоторые флэш-диски USB записы-
записывают случайные данные, а некоторые карты памяти цифровых фотоаппаратов
используют имена, напоминающие модель камеры. Значение можно легко изме-
изменить в шестнадцатеричном редакторе, но оно поможет определить, на каком типе
компьютера была отформатирована дискета. Некоторые версии Windows требу-
требуют, чтобы значение было обязательно задано.

Файловым системам FAT назначается 4-байтовый серийный номер тома, кото-
который в соответствии со спецификацией Microsoft определяется временем создания
файловой системы с использованием текущего времени, хотя операционная систе-
система, создающая файловую систему, может задать любое значение. Тестирование по-
показало, что разные версии Windows ведут себя по-разному. Так, система Windows
98 вела себя так, как сообщает Крейг Уилсон (Craig Wilson) [Wilson, 2003]: серий-
серийный номер представлял собой результат сложения полей даты и времени в опреде-
определенном порядке. Формула приводится в разделе «Загрузочный сектор» главы 10.
В Windows XP этот алгоритм не использовался. Windows использует серийный
номер тома при работе со съемными носителями и определяет факт замены диска.
Также в загрузочном секторе присутствует поле из 8 символов, содержащее
строку «FAT12», «FAT16», «FAT32» или «FAT». Большинство систем, создаю-
создающих экземпляры FAT, корректно заполняют эту строку, но это не обязательно.
Существует только один способ определения фактического типа системы — вы-
вычисление по формуле, к которой мы придем позже. Последним идентификацион-
идентификационным маркером является 11-символьная метка тома, которую вводит пользователь
при создании файловой системы. Метка тома также хранится в корневом катало-
каталоге файловой системы. Я заметил, что при добавлении метки тома в ХР она запи-
записывается только в корневой каталог, но не в загрузочный сектор.
Загрузочный код
Загрузочный код в файловой системе FAT чередуется со структурами данных
файловой системы [Microsoft, 2003e]. В этом FAT отличается от файловых сис-
систем UNIX, где используется полностью изолированный загрузочный код. Пер-
Первые три байта загрузочного сектора содержат машинный код команды перехода,
которая заставляет процессор обойти конфигурационные данные и передать уп-
управление основному загрузочному коду. Как будет видно из структуры данных в
следующей главе, загрузочный сектор занимает 512 байт, причем байты 62-509 в
FAT12/16 и байты 90-509 в FAT32 не используются. Эти байты содержат загру-
загрузочный код, а в F AT32 дополнительный загрузочный код может находиться в сек-
секторах, следующих за загрузочным сектором.
Файловые системы 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

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 также существуют резервные копии обеих структур данных.

Факторы анализа
Как вы убедились, данные этой категории предоставляют структурную информа-
информацию о файловой системе, причем большая часть этих данных неподконтрольна
пользователю. Следовательно, никаких сенсационных находок ожидать не стоит.
Вы не найдете значений, показывающих, где и когда была создана файловая сис-
система; впрочем, метка OEM и метка тома, хотя и относятся к вспомогательным
данным, могут предоставить некоторую полезную информацию, потому что в раз-
разных системах используются разные значения по умолчанию. Позднее мы увидим,
что в FAT существует специальный файл, имя которого совпадает с именем тома,
и этот файл может содержать время создания системы.
Существует ряд мест, не используемых файловой системой; в них могут хра-
храниться данные, скрытые от пользователя. Например, между концом загрузочного
сектора и завершающей сигнатурой хранятся свыше 450 байт данных. Windows
обычно использует это пространство для хранения загрузочного кода системы,
но в файловых системах, не являющихся загрузочными, оно не используется.
FAT32 обычно выделяет много секторов в зарезервированную область, но лишь
небольшая часть из них используется для хранения основной и резервной копий
загрузочного сектора и структуры данных FSINFO. Следовательно, эти секторы
могут содержать скрытые данные. Кроме того, в FAT32 структура FSINFO содер-
содержит сотни неиспользуемых байтов. ОС обычно стирает содержимое секторов в ре-
резервной области при создании файловой системы.
Скрытые данные также могут находиться между концом файловой системы
и концом тома. Сравните число секторов файловой системы, заданное в загрузочном
секторе, с количеством секторов тома, чтобы определить резервное пространство
тома. Учтите, что создать резервное пространство тома относительно несложно —
для этого достаточно изменить общее количество секторов в загрузочном секторе.
В файловых системах FAT32 присутствует резервная копия загрузочного секто-
сектора, которая должна находиться в секторе 6. Основная копия сравнивается с резер-
резервной для выявления расхождений. Если основная копия окажется поврежденной,
следует проанализировать резервную копию. Если пользователь изменил какие-
либо из меток или других полей основного загрузочного сектора в шестнадцате-
ричном редакторе, возможно, резервная копия будет содержать исходные данные.
Сценарий анализа
При обыске в доме подозреваемого в шкафу был найден жесткий диск. В процессе
снятия данных выяснилось, что первые 32 сектора диска повреждены и прочитать
их не удастся. Вероятно, подозреваемый положил диск в шкаф после сбоя и восполь-
воспользовался новым диском, но мы хотим проанализировать старый диск на наличие
улик. На компьютере подозреваемого установлена система Windows ME, соот-
соответственно, используется файловая система FAT. Этот сценарий показывает, как
найти файловую систему далее в том случае, если таблицы разделов не существует.
Чтобы найти начало файловой системы FAT, мы проведем поиск по сигнатурам
0x55 и ОхАА в последних двух байтах загрузочного сектора. При проведении только
одного поиска следует ожидать большого количества ложных совпадений. Если диск
заполнен случайными данными, можно ожидать, что сигнатура будет встречаться

каждые 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 обнаружено совпадение. Этот сектор находится за концом

предыдущей файловой системы, которая завершается в секторе 20 482 874. Одна-
Однако закономерность совпадений, начиная с сектора 20 482 875, отличается от
предыдущих: следующее совпадение найдено со смещением 63 сектора, а потом
следуют несколько близких совпадений. Просматриваем сектор 20 482 875 и вы-
выясняем, является ли совпадение ложным:
# dd if=disk-9.dd bs=512 skip=20482875 count=l | xxd
0000000: 088c 039a 5f78 7694 8f45 bf49 e396 00c0 ...._xv..E.I....
0000016: 889d ddcO 6d36 60df 485d adf7 46dl 3224 ... .m6\H]. .F.2$
0000032: 3829 95cd ad28 d2a2 dc89 f357 d921 cfde 8)...( W.!..
0000048: df8e Ifd3 303e 8619 641e 9c2f 95b4 d836 0>..d../...6
[...]
0000416: 3607 e7be 1177 db5f Ilc9 fbal c913 Ia3d 6....w._ =
0000432: da81 143d 00c7 7083 9d42 330c 0287 0001 ...-..p..B3
0000448: clff Obfe ffff 3fOO 0000 fc8a 3801 0000 ? 8...
0000464: clff 05fe ffff 3b8b 3801 7616 7102 0000 :.8.v.q...
0000480: 0000 0000 0000 0000 0000 0000 0000 0000
0000496: 0000 0000 0000 0000 0000 0000 0000 55aa 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 показано графическое представление этого примера.
На нем изображены две файловые системы, обнаруженные нами, а также некото-
некоторые ложные совпадения и расширенные таблицы разделов.
Рис. 9.4. Результаты поиска сигнатуры загрузочного сектора FAT на диске,
не содержащем таблицы разделов
Этот пример показывает, что файловую систему FAT32 можно найти при нали-
наличии загрузочного сектора. Поиск 2-байтовой сигнатуры выдает много ложных со-
совпадений, но FAT32 несколько упрощает задачу, потому что мы ожидаем найти со-
совпадения со смещением 1,6 и 7 секторов от структуры данных FSINFO и резервных
копий. С FAT 12/16 дело обстоит сложнее; резервные структуры в этих системах

отсутствуют, но все, что потребуется, — это найти первое совпадение. Можно на-
начать поиск с сектора 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).
Рис. 9.5. В файловой системе FAT12/16 кластер 2 следует за корневым каталогом, а в FAT32
кластер 2 является первым сектором области данных

Адреса кластеров и секторов
Как мы только что обсуждали, адресация кластеров начинается только с области
данных. Следовательно, для адресации данных в зарезервированной области и
области 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, Oxfff7 для FAT16 или OxOfff fff7 для FAT32, кластер помечен как по-
поврежденный и не может выделяться файлам. Все остальные значения означают,
что кластер выделен, а их интерпретация будет рассмотрена позднее, в разделе
«Категория метаданных».
Алгоритмы выделения
При выделении кластеров ОС использует определенный алгоритм. Тестирова-
Тестирование систем Windows 98 и Windows XP показало, что в обоих случаях использовал-
использовался алгоритм поиска следующего доступного кластера. Этот алгоритм ищет первый
доступный кластер, начиная от предыдущего выделенного кластера. Предполо-
Предположим, кластер 65 выделен новому файлу, а кластер 62 свободен. Следующий поиск
начнется с кластера 66, а кластер 62 на некоторое время останется свободным (рис.

9.6). Процесс выделения кластеров зависит от многих факторов, и идентифици-
идентифицировать точный алгоритм трудно.
Чтобы найти свободный кластер для выделения файлу, ОС сканирует FAT
и ищет запись, содержащую 0. Вспомните, что в резервной области FAT32 хранится
структура данных FSINFO с номером следующего свободного кластера, которым
операционная система может руководствоваться при поиске. Если потребуется
перевести кластер в свободное состояние, система находит соответствующую за-
запись в структуре FAT и заполняет ее нулями. Большинство операционных сис-
систем не стирает содержимое кластеров при освобождении, если только эта опера-
операция не реализована как функция надежного удаления информации.
Рис. 9.6. Поиск свободного кластера начинается не от начала файловой системы,
а с последнего выделенного кластера
Методы анализа
Анализ данных в категории содержимого выполняется для нахождения конкрет-
конкретного блока данных, проверки его статуса выделения и выполнения операций с со-
содержимым. Найти конкретный блок данных в FAT сложнее, чем в других файло-
файловых системах, потому что адресация кластеров начинается не с начала файловой
системы. При обращении к блоку данных, расположенному до начала области
данных, необходимо использовать адрес сектора. Для блоков в области данных
могут использоваться как адреса секторов, так и адреса кластеров.
Состояние выделения каждого кластера определяется по записи кластера
в FAT. У свободных кластеров значение записи равно нулю, а у выделенных оно
отлично от нуля. Если потребуется извлечь содержимое всех свободных класте-
кластеров, переберите все записи FAT и извлеките каждый кластер с нулевым значени-
значением в таблице. Блоки данных, расположенные до начала области данных, в FAT не
представлены, следовательно, они не имеют формального состояния выделения,
хотя большинство таких блоков используется файловой системой. Проверьте свои
программы анализа и выясните, считают ли они свободными блоки, предшеству-
предшествующие области данных.
Факторы анализа
В процессе анализа файловой системе FAT следует изучить содержимое класте-
кластеров, помеченных как поврежденные — многие диски обрабатывают поврежден-
поврежденные секторы на аппаратном уровне, и операционная система их вообще не видит.

Поврежденные блоки данных необходимо анализировать в файловых системах
любого типа, но Microsoft сообщает, что некоторые защищенные приложения хра-
хранят информацию в кластерах FAT, помеченных как поврежденные. По этой при-
причине программа ScanDisk для Windows не проверяет, действительно ли повреж-
повреждены помеченные секторы [Microsoft, 2004b]. Некоторые версии команды format
для Windows сохраняют статус поврежденных кластеров при повторном форма-
форматировании файловой системы.
Размер области данных может оказаться некратным размеру кластера, поэто-
поэтому в конце области данных могут располагаться секторы, не принадлежащие кла-
кластеру. Такие секторы используются для скрытия информации или содержат дан-
данные, оставшиеся от предыдущей файловой системы. На рис. 9.7 показан пример
файловой системы с кластерами, состоящими из 2 секторов, и нечетным количе-
количеством секторов. Последний сектор, помеченный серым цветом, не имеет адреса
кластера.
Рис. 9.7. Последние секторы области данных не образуют полноценного кластера,
поэтому в них может храниться скрытая информация или данные
от предыдущей файловой системы
Чтобы узнать, присутствуют ли в системе неиспользуемые секторы, вычтите
адрес сектора для кластера 2 из общего количества секторов и разделите разность
на количество секторов в кластере. Если деление выполняется с остатком, значит,
неиспользуемые сектора присутствуют:
(общее количество секторов - адрес сектора для кластера 2) / (количество секторов
в кластере)
Скрытые данные также могут храниться между концом последней действи-
действительной записи основной структуры FAT и началом резервной копии или же между
концом последней записи резервной FAT и началом области данных. Чтобы вы-
вычислить объем неиспользуемого пространства, сравните размер каждой структу-
структуры FAT, указанный в загрузочном секторе, с размером, необходимым для хране-
хранения фактического количества секторов в файловой системе. Например, в файловой
системе FAT32, которую мы ранее анализировали командой fsstat, каждой копии
FAT было выделено 797 секторов. Каждая запись таблицы в файловой системе
FAT32 занимает четыре байта, следовательно, каждый 512-байтовый сектор со-
содержит 128 записей. В каждой таблице помещается
797 секторов * 128 (записей/сектор) = 102 016 записей
Из выходных данных fsstat видно, что количество кластеров равно 102 002,
следовательно, в таблице имеется 14 неиспользуемых записей, а их общий размер
составляет 64 байта.
Не каждому сектору тома ставится в соответствие адрес кластера, поэтому ре-
результаты поиска по логическому тому и логической файловой системе могут раз-
различаться. Протестируйте свои программы и определите, проводят ли они поиск

в загрузочном секторе и областях 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.
Рис. 9.8. Структура диска в примере с поиском кластера 812
Категория метаданных
К категории метаданных относятся данные, описывающие файлы или каталоги:
местонахождение содержимого, дата и время, права доступа. Эта категория дан-
данных будет использоваться для получения дополнительной информации о файле
и идентификации подозрительных файлов. В файловой системе FAT эта инфор-
информация хранится в структуре записи каталога. Структура FAT также используется
для хранения метаданных, описывающих файлы и каталоги.

Записи каталога
Записью каталога называется структура данных, создаваемая для каждого файла
и каталога. Ее размер равен 32 байтам; в структуре хранятся атрибуты файла, его
начальный кластер, дата и время. Запись каталога занимает важное место в кате-
категории метаданных и имен файлов — ведь в этой структуре содержится имя файла.
Записи каталогов могут находиться в любом месте области данных, потому что
они хранятся в кластерах, выделенных каталогам. В файловой системе FAT ката-
каталоги интерпретируются как особая разновидность файлов. Структура данных за-
записей каталогов подробно описывается в главе 10.
Каждый раз, когда в системе создается новый файл или каталог, в родительском
каталоге для него создается запись каталога. Поскольку каждая запись каталога
обладает фиксированным размером, содержимое каталога можно представить себе
как таблицу записей каталогов. В отличие от кластеров, записям каталогов не
присваиваются уникальные числовые адреса, поэтому возможен только один стан-
стандартный способ адресации каталогов: использовать полное имя файла или ката-
каталога, которому принадлежит эта запись. Мы вернемся к этой теме в разделе «Ад-
«Адреса записей каталогов».
Структура записи каталога содержит поле атрибутов. Для каждого файла мож-
можно задать значения семи атрибутов, хотя ОС (или программа анализа) могут про-
проигнорировать некоторые из них. Мы начнем с рассмотрения обязательных атри-
атрибутов — игнорировать эти атрибуты нельзя, потому что они влияют на процесс
обработки записей каталогов. Атрибут каталога используется для идентифика-
идентификации записей каталогов, относящихся к каталогам (в отличие от файлов). Класте-
Кластеры, ассоциированные с записью каталога, должны содержать новые записи ката-
каталогов. Атрибут длинного имени файла является признаком записей особого типа,
имеющих другую структуру. Эта тема подробно рассматривается в разделе «Имя
файла». Последний обязательный атрибут предназначен для хранения метки
тома] согласно спецификации, он может быть установлен только у одной записи.
Я заметил, что в Windows XP задаваемая пользователем метка тома сохраняется
именно здесь, а не в загрузочном секторе. Если ни один из этих атрибутов не уста-
установлен, значит, запись относится к обычному файлу.
Также существует четыре необязательных атрибута, которые могут устанав-
устанавливаться для каждого файла или каталога. Последствия их установки зависят от
того, насколько жестко операционная система соблюдает соответствующие пра-
правила. Атрибут доступа только для чтения должен предотвращать запись в файл,
однако эксперименты показали, что в системах Windows XP и Windows 98 в ката-
каталогах, доступных только для чтения, возможно создание новых файлов. Атрибут
скрытого файла должен исключать файлы и каталоги из выводимых списков, но
обычно их вывод включается установкой параметра конфигурации ОС. Атрибут
системного файла должен идентифицировать файл как системный, а атрибут
архивного файла обычно устанавливается Windows при создании файла или за-
записи в него. По состоянию этого атрибута программы архивации данных иденти-
идентифицируют файлы, изменившиеся с момента создания последнего архива.
В каждой записи каталога хранится три временных штампа: для создания, пос-
последнего обращения и последней модификации. У FAT есть одна странная особен-
особенность: большой разброс точности в этих значениях. Время создания не является
обязательным и измеряется с точностью до секунды; время обращения также не

обязательно и измеряется с точностью до дня; наконец, согласно спецификации
время последней модификации является обязательным и измеряется с точностью
до двух секунд. Никаких спецификаций по поводу того, при каких операциях
должно обновляться то или иное время, не существует, поэтому каждая ОС,
в которой используется 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.
Рис. 9.9. Таблица FAT с цепочкой кластеров 40-41-45

Максимальный размер файловой системы FAT зависит от размера записей
FAT. Размер записи определяет максимальный адрес следующего кластера в це-
цепочке; таким образом, адреса кластеров ограничены. В файловой системе FAT32
используются только 28 бит 32-разрядной записи, поэтому она позволяет адресовать
только 268 435 456 кластеров (на самом деле немного меньше, потому что некото-
некоторые значения зарезервированы для маркера EOF и поврежденных кластеров).
Каталоги
При создании нового каталога для него выделяется кластер, заполняемый нуля-
нулями. Поле «размер» в записи каталога не используется и всегда должно быть рав-
равно 0. Единственный способ определить размер каталога — использовать началь-
начальный кластер из записи каталога и следовать по цепочке кластеров структуры FAT
до обнаружения маркера конца файла.
Первые две записи каталога предназначены для элементов «.» и «..». Эти обо-
обозначения хорошо знакомы пользователям, работающим в режиме командной стро-
строки. Имя «.» обозначает текущий каталог, а имя «..» — родительский каталог. В дей-
действительности они представляются записями каталога с установленным атрибутом
каталога, но, похоже, система Windows не обновляет значения после их создания.
Временные штампы создания, обращения и модификации сохраняют значения,
заданные в момент создания каталога. Это поведение также может использовать-
использоваться для проверки времени создания каталога, значение которого должно совпа-
совпадать со значениями «.» и «..». Впрочем, подтвердить время последней модифика-
модификации каталога невозможно, потому что записи «.» и «..» не обновляются при каждой
модификации каталога. Ситуация показана на рис. 9.10: время создания dirl от-
отличается от времени создания записей «.» и «..». Пользователь мог сделать это
с целью маскировки своих действий, или же дата могла быть модифицирована
каким-то приложением в системе.
Рис. 9.10. Время создания записи каталога не совпадает
с временем создания записей «.» и «..»
Адреса записей каталогов
Как упоминалось ранее, существует только один стандартный способ адресации
записей каталогов: использование полного имени файла или каталога, с которым
она ассоциируется. При этом возникают минимум две проблемы, которые будут
рассмотрены в этом разделе.
Допустим, потребовалось найти все выделенные структуры каталогов. Для
этого мы начинаем поиск с корневого каталога и рекурсивно просматриваем все
выделенные каталоги. В каждом каталоге мы анализируем 32-байтовую структу-
структуру и пропускаем свободные. Адрес каждой структуры образуется из имени ката-
каталога, просматриваемого в настоящий момент, и имени файла.

Такое решение отлично работает для обычных операций с файловой систе-
системой, но аналитику нередко требуется решить обратную задачу — найти все сво-
свободные записи каталогов. Здесь возникает первая проблема. При освобождении
записи каталога первая буква имени пропадает. Если каталог содержит два фай-
файла, A-1.DAT и B-1.DAT, которые были удалены, обе записи будут содержать одинако-
одинаковое имя _-l.DAT. Таким образом, возникает конфликт уникальности имен.
Вторая проблема возникает при удалении каталога и освобождении его запи-
записи. В этом случае не остается указателя на файлы и каталоги, находившиеся в уда-
удаленном каталоге, поэтому у них не будет адреса. На рис. 9.11 (А) запись каталога
ссылается на кластер 210. Каталог удаляется, а запись каталога позднее выделя-
выделяется заново; в новом варианте она указывает на кластер 400 (рис. 9.11 (В)). Сво-
Свободные записи каталогов в кластере 210 остаются, однако их не удастся найти
простым перемещением по дереву каталогов. Но даже если эти записи будут най-
найдены, адресов у них не будет. Такие файлы называются зависшими.
Рис. 9.11. (А) — существующий каталог и его содержимое; (В) — состояние системы после
удаления каталога и повторного выделения его записи в родительском каталоге
Чтобы найти зависшие файлы, необходимо проанализировать все секторы об-
области данных. Стандартного способа не существует; один из вариантов заключа-
заключается в анализе первых 32 байтов каждого сектора (не кластера!) и их сравнении
с полями записи каталога. Если данные лежат в правильном диапазоне, обраба-
обрабатывается остаток сектора. При просмотре секторов могут обнаружиться записи
в резервном пространстве кластеров, которые были выделены другим файлам.
Другой аналогичный способ — просмотр первых 32 байтов каждого кластера для
отыскания записей «.» и «..», которые являются первыми двумя записями каждо-
каждого каталога (пример будет приведен далее). Этот способ позволяет найти только
первый кластер каталога, но не его фрагменты.
Один из способов решения подобных проблем основан на использовании дру-
другого метода адресации. Например, в TSK используется метод, который также при-
применяется в некоторых версиях UNIX; предполагается, что каждый кластер и сек-
сектор может быть выделен каталогу. Таким образом, можно представить, что каждый
сектор разделен на 32-байтовые записи, в которых могут храниться записи ката-
каталогов, а каждой записи сопоставлен уникальный адрес. Первой 32-байтовой за-
записи первого сектора ставится в соответствие адрес 0, второй — адрес 1, и т. д.
Это решение работает, но возникает небольшая проблема. Числовыми адреса-
адресами обладают все каталоги и файлы, кроме корневого каталога. Вспомните, что
местонахождение и размер корневого каталога задаются в загрузочном секторе,
а не в записи каталога. В TSK для решения этой проблемы корневому каталогу

присваивается адрес 2 (потому что именно такой способ используется в большин-
большинстве файловых систем UNIX), а первой записи первого сектора присваивается
адрес 3. На рис. 9.12 секторы 520 и 1376 представлены в расширенном виде, с по-
показом адресов содержащихся в них записей. Каждый 512-байтовый сектор вме-
вмещает 16 структур записей каталогов, поэтому в секторе 520 хранятся записи 3-18.
Рис. 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 приводится время и дата создания, после-
последнего обращения и модификации файла, а также атрибуты файла. Поскольку имя
файла хранится в записи каталога, для его определения достаточно одного адре-
адреса, без полного пути.
Алгоритмы выделения
В категории метаданных существует два типа данных, задействованных в проце-
процедурах выделения. Для новых файлов выделяются записи каталогов, а для суще-
существующих файлов и каталогов обновляются временные штампы. Как и в боль-

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