Листинг 5.9. Открытие непосредственного доступа к жесткому диску под Windows NT

XOR EAX,EAX

PUSH EAX; hTemplateFile

PUSH dword FILE_ATTRIBUTE_NORMAL; dwFlagsAndAttributes

PUSH dword OPEN_EXISTING; dwCreationDisposition

PUSH EAX; lpSecurityAttributes

PUSH dword FILE_SHARE_WRITE; dwShareMode

PUSH dword (GENERIC_WRITE OR GENERIC_READ); dwDesiredAccess

PUSH DEVICE_NAME; Имя устройства

CALL CreateFile; Открываем устройство

INC EAX

TEST EAX,EAX

JZ error

DEC EAX

...

DEVICE_NAME db "\\.\PHYSICALDRIVE0",0

BUF RB 512; Буфер

Открыв физический диск и убедившись в успешности этой операции, мы должны прочитать оригинальный MBR-сектор в буфер, перезаписать первые 1BBh байт, ни в коем случае не трогая таблицу разделов и сигнатуру 55h AAh (мы ведь не хотим, чтобы диск перестал загружаться, верно?). Теперь остается записать обновленный код MBR на место и закрыть дескриптор устройства. После перезагрузки все изменения вступят в силу.

Примечание

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

Под Windows 9 x, разумеется, трюк с CreateFile не работает. Но там можно воспользоваться симуляцией прерываний из DMPI или обратиться к драйверу ASPI. Оба способа были подробно описаны в моей книге "Техника защиты компакт-дисков от копирования". Однако, хотя в ней речь идет о CD, а не о HDD, жесткие диски программируются аналогично.

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

□ Ge2000.asm — тщательно прокомментированный Stealth-вирус, подменяющий системный загрузчик своим собственным. Хоть это и вирус, но он не опасен и может быть использован в учебных целях.

□ Mbr.asm — предельно простой, но полнофункциональный загрузчик с поддержкой разделов свыше 8 Гбайт.

□ Bootasm — отличный менеджер мультизагрузки с подробными комментариями, переходит в защищенный режим, может грузиться с дискеты, компакт-диска, zip-дискеты, винчестера и т.д. Поддерживает разделы свыше 8 Гбайт, показывает индикатор загрузки и делает множество других полезных вещей, которые не помешает изучить.

Отладка кода загрузчика

Отлаживать код загрузчика невероятно трудно. Загрузчик получает управление задолго до запуска операционной системы, когда никакие отладчики еще не работают. Несколько лет назад это представляло огромную проблему, и при разработке "навороченных" загрузчиков приходилось либо встраивать в них интегрированный мини-отладчик, либо выискивать ошибки вручную, изучая листинги с карандашом в руке. С появлением эмуляторов все изменилось. Достаточно запустить такой эмулятор, как BOCHS (рис. 5.5), и вы сможете отлаживать загрузчик как и любую другую программу!

Рис. 5.5. Внешний вид эмулятора BOCHS в процессе отладки загрузочного сектора

Программирование загрузчиков — одна из тех немногих областей, в которых применение ассемблера действительно обоснованно. Языки высокого уровня для этого слишком абстрагированы от оборудования. Кроме того, они недостаточно гибки. Вот почему хакеры так любят возиться с загрузчиками, добавляя сюда множество новых возможностей, включая автоматическую загрузку с CD-ROM или дисков SCSI, противодействие вирусам, парольную защиту с шифрованием данных и т.д. Здесь действительно есть, где развернуться, и есть на чем показать все свои возможности. В качестве дополнительного чтения я рекомендовал бы вам несколько весьма интересных источников. Вот они:

□ MBR and OS Boot Records — масса интересного материала по MBR (на английском языке): http://thestarman.narod.ru/asm/mbr/MBR_in_detail.htm;

□ BOCHS — отличный эмулятор со встроенным отладчиком, значительно облегчающий процесс "пуско-наладки" загрузочных секторов. Бесплатен, распространяется с исходными текстами: http://bochs.sourceforge.net;

□ http://www.koders.com (рис. 5.6) — отличный поисковик, нацеленный на поиск исходных кодов, по ключевому слову MBR выдает огромное количество загрузчиков на любой вкус;

Рис. 5.6. Поиск исходных текстов загрузчиков MBR на сайте Koders

□ Ralf Brown Interrupt List (рис. 5.7) — знаменитый "Список прерываний" (Interrupt List) Ральфа Брауна (Ralf Brown), описывающий все прерывания, включая недокументированные (на английском языке): http://www.pobox.com/~ralf;

Рис. 5.7. Просмотр легендарного "Списка прерываний" Ральфа Брауна

□ OpenBIOS — проект "Открытого BIOS", распространяемого в исходных текстах. Помогает понять некоторые неочевидные моменты обработки системного загрузчика: http://www.openbios.info/docs/index.html.

Динамические диски

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

Типы динамических дисков, поддерживаемые Windows 2000

Начиная с Windows 2000, операционные системы этого семейства поддерживают следующие типы динамических дисков:

□ Простые (simple) — практически ничем не отличаются от обычных разделов, за исключением того, при переразбиении диска отпадает необходимость в перезагрузке. Данный тип является базовым для всех остальных динамических дисков.

• Избыточность данных — отсутствует

• Эффективность — низкая

□ Составные (spanned) — состоят из одного или нескольких простых дисков, находящихся в различных разделах или даже на физически различных устройствах, но представленные как один логический диск. Запись данных на простые диски осуществляется последовательно (то есть составной диск представляет собой классический линейный RAID).

• Избыточность данных — отсутствует

• Эффективность — низкая

□ Чередующиеся (striped) — чередующиеся динамические диски аналогичны составным, но данные записываются параллельно на все простые диски. При условии, что простые диски расположены на различных каналах контроллера IDE, это значительно увеличивает скорость обмена данными. Иными словами, чередующиеся динамические диски представляют собой классическую реализацию RAID уровня 0.

• Избыточность данных — отсутствует

• Эффективность — средняя

□ Зеркальные (mirrored) — зеркальные динамические тома представляют собой два простых диска, расположенных на разных устройствах. Данные дублируются на оба носителя (RAID уровня 1).

• Избыточность данных — средняя

• Эффективность — средняя

□ Чередующиеся с контролем четности (striped with parity) — соответствуют RAID уровня 5. Такие тома состоят из трех или большего количества дисков. Фактически такие тома представляют собой чередующиеся тома, на которых реализован контроль ошибок. Запись данных ведется на два диска, в два блока, а на третий диск и в третий блок записывается код коррекции ошибок (error correction code, ECC), с помощью которого содержимое отказавшего блока можно восстановить по информации любого из блоков.

• Избыточность данных — высокая

• Эффективность — высокая

□ Зеркальные с чередованием (mirrored striped) — эти тома соответствуют RAID 1+0.

• Избыточность данных — средняя

• Эффективность — высокая

По умолчанию Windows создает базовые диски (basic volumes). Однако любой базовый диск в любой момент времени может быть обновлен до динамического, и это не потребует даже перезагрузки системы.

Примечание

Терминологические соответствия для обычных (basic) и динамических (dynamic) дисков приведены в табл. 5.5.

Таблица 5.5. Терминологические соответствия динамических и обычных дисков

Динамические диски не пользуются таблицей разделов, а потому и не имеют проблем, связанных с ограничением разрядности адресации CHS, и позволяют создавать тома практически неограниченного размера. Однако динамические диски, созданные путем обновления основных разделов, все-таки остаются в таблице разделов, при этом для них значение поля Boot ID меняется на 42h. Если эта информация будет удалена, система откажется подключать такой динамический диск. Между прочим, операционная система Windows может быть установлена только на такой динамический диск, который был получен путем обновления базового, так как BIOS может загружать систем) лишь с тех разделов, которые перечислены в таблице разделов. При этом динамические диски, созданные "на лету", в таблицу разделов как раз и не попадают.

Схема разбиения динамических дисков содержится в базе данных менеджера логических дисков (Logical Disk Manager Database, LDM). Это — протоколируемая (journalled) база данных, поддерживающая транзакции и устойчивая к сбоям. Если в процессе манипуляции с томами вдруг происходит сбой питания, то при последующем включении компьютера будет выполнен откат (rollback) в предыдущее состояние. При переносе винчестера, содержащего один или несколько динамических дисков, на другой компьютер они автоматически распознаются и монтируются, как обыкновенные диски.

База данных LDM хранится в последнем мегабайте жесткого диска, а для дисков, полученных путем обновления базового раздела до динамического, — в последнем мегабайте этого раздела. Как уже говорилось, идентификатор загрузки Boot ID соответствующей записи таблицы разделов принимает значение 42h. Так происходит потому, что при стандартном разбиении винчестера в его конце просто не остается свободного места, и операционной системе приходится сохранять эту информацию непосредственно на самом обновляемом диске (естественно, для этого на нем необходимо иметь по меньшей мере 1 Мбайт свободного пространства).

Сразу же за таблицей разделов по адресу 0/0/2 расположен приватный заголовок PRIVHEAD, содержащий в себе ссылки на основные структуры LDM (рис. 5.8). Если PRIVHEAD погибнет, Windows не сможет обнаружить и смонтировать динамические диски. К сожалению, гибнет он удручающе часто. Подавляющее большинство загрузочных вирусов и дисковых менеджеров считают сектор 0/0/2 свободным и используют его для хранения своего тела, необратимо затирая прежнее содержимое. Осознавая значимость заголовка PRIVHEAD, разработчики из Microsoft сохранили его в двух копиях, одна из которых хранится в конце LDM, а другая — в последнем секторе физического диска. Благодаря такой избыточности PRIVHEAD практически никогда не приходится восстанавливать вручную. Однако если такая необходимость все же возникнет, обратитесь к проекту LINUX-NTFS за подобным описанием его структуры (http://www.linux-ntfs.org/), здесь же оно по соображениям экономии места не приводится.

Рис. 5.8. База данных LDM и ее дислокация

Внутреннее устройство базы данных LDM не документировано. При этом даже поверхностный взгляд на ее структуру сразу же дает понятие о ее мощи и сложности (рис. 5.9). На самом верху иерархии расположено оглавление базы — структура TOCBLOCK (Table Of Content Block), состоящая из двух секций, config и log (причем, вероятно, в будущем их список будет расширен). Секция config содержит информацию о текущем разбиении диска на динамические тома, a log хранит журнал изменений схемы разбиения. Это — очень мощное средство в борьбе с энтропией! Если удалить один или несколько динамических разделов, информация о старом разбиении сохранится в журнале, что позволит с легкостью восстановить утерянные тома! Будучи очень важной структурой, оглавление диска защищено от случайного разрушения тремя резервными копиями, одна из которых вплотную примыкает к оригинальной версии TOCBLOCK, расположенной в начале базы LDM, а две других находятся в конце диска, между копиями PRIVHEAD.

Рис. 5.9. Внутренняя структура LDM

Внутренне секция config состоит из заголовка (VMDB) и одного или нескольких 128-байтных структур, называемых VBLKs, каждая из которых описывает соответствующий ей том, контейнер, раздел, диск или группу дисков. Заголовок VMDB не имеет копии и нигде не дублируется. Однако все его изменения протоколируются в журнале (KLOG) и потому могут быть восстановлены.

Примечание

Строение VMDB и VBLKs подробно описано в разделе "LDM Documentation" на сайте проекта LINUX-NTFS. Поэтому здесь оно не приводится в целях экономии места. Оно действительно очень громоздко, к тому же, крайне маловероятно, что кому-то потребуется восстанавливать секцию config вручную.

Для просмотра базы данных LDM и архивирования ее содержимого можно воспользоваться утилитой LDM-dump Марка Руссиновича, бесплатную копию которой можно скачать с его сайта (http://www.sysinternals.com/files/ldmdump.zip). Как вариант можно зарезервировать последний мегабайт физического диска, а также последние мегабайты всех разделов, для которых значение поля Boot ID равно 42h. Сделать это можно с помощью любого дискового редактора (например, Sector Inspector). Эту информацию рекомендуется хранить на надежном носителе (Zip-дискете, CD-R/RW). Помимо этого, не забудьте также создать и резервную копию структуры TOCBLOCK.

При восстановлении удаленных динамических дисков необходимо учитывать следующие факторы:

1. Во-первых, журнал изменений на интерфейсном уровне недоступен, и выполнить откат штатными средствами операционной системы невозможно.

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

Если размер и тип удаленного динамического диска вам известны (на дисках NTFS его можно извлечь из копии загрузочного сектора), просто зайдите в Менеджер Управления Дисками (Disk Manager) и воссоздайте его заново, от предложения отформатировать раздел любезно откажитесь и восстановите очищенный загрузочный сектор по методике, описанной в следующем разделе.

Как видно, Microsoft тщательно позаботилась о своих пользователях и тщательно проработала структуру динамических дисков, что для нее, вообще говоря, нехарактерно.

Основные сведения о загрузочном секторе

Первый сектор логического диска носит название загрузочного (boot). Он содержит код самозагрузки (bootstrap code) и важнейшие сведения о геометрии диска, без которых раздел просто не будет смонтирован. Структура загрузочного сектора определяется архитектурными особенностями конкретной файловой системы. В частности, структура загрузочного сектора NTFS описана в табл. 5.6.

Таблица 5.6. Строение загрузочного сектора NTFS

В начале всякого сектора расположена трехбайтная машинная команда перехода на код самозагрузки (обычно она имеет вид EB 52 90, хотя возможны и различные вариации). Так происходит потому, что при загрузке boot-сектора в память управление передается на его первый байт, а код самозагрузки по туманным историческим соображениям был отодвинут в конец сектора (для NTFS верхняя граница составляет 54h байт), вот и приходится прыгать блохой!

С третьего по одиннадцатый байты (считая от нуля) хранится идентификатор производителя, определяющий тип и версию используемой файловой системы (например, MSDOS5.0 для FAT16, MSWIN4.0/MSWIN4.1 для FAT32 и NTFS — для NTFS). Если это поле окажется искаженным, то драйвер не сможет смонтировать диск. В ряде случаев драйвер может даже счесть такой диск не отформатированным.

Примечание

С дисками, отформатированными для использования FAT, Windows 2000 будет работать даже в том случае, если поле OEM ID запорчено. В отношении NTFS это не так.

Следом за идентификатором расположен 25-байтовый блок параметров BIOS (BIOS Parameter Block, BPB), хранящий сведения о геометрии диска (количество цилиндров, головок, секторов, размер сектора, количество секторов в кластере и т.д.). Если эта информация окажется утерянной или искаженной, то нормальное функционирование драйвера файловой системы станет невозможным. Причем, в отличие от информации о числе цилиндров/головок/секторов, которая дублирует информацию, содержащуюся в MBR, а при ее утере элементарно восстанавливается описанным выше способом, размер кластера определить не так-то просто! Позже мы обсудим этот вопрос более подробно, пока же вполне достаточно сослаться на табл. 5.7, в которой указаны размеры кластера томов NTFS, по умолчанию выбираемые штатной утилитой форматирования.

Таблица 5.7. Размеры кластеров, по умолчанию выбираемые штатной утилитой форматирования в Windows 2000

При выборе размера кластера вручную Windows 2000 поддерживает следующий размерный ряд: 1 сектор, 2 сектора, 4 сектора, 8 секторов, 16 секторов, 32 сектора, 64 сектора и 128 секторов. Чем больше размер кластера, тем слабее фрагментация и выше предельно адресуемый объем дискового пространства. Однако потери от грануляции с увеличением размера кластера тоже растут. Впрочем, размеры кластеров редко задаются вручную.

К блоку параметров BIOS вплотную примыкает его продолжение — расширенный блок параметров BIOS (extended BPB), хранящий номер первого кластера MFT, ее размер в кластерах, номер кластера с зеркалом MFT, а также некоторую другую служебную информацию. В отличие от FAT16/FAT32, MFT может располагаться в любом месте диска (для борьбы с BAD-секторами это актуально). При нормальном развитии событий MFT располагается практически в самом начале диска (где-то в районе четвертого кластера) и, если только она не была перемещена, то ее легко найти глобальным поиском (искать следует строку FILE* по смещению о от начала сектора). При разрушении или некорректном заполнении расширенного блока параметров BIOS драйвер файловой системы отказывается монтировать раздел, объявляя его не отформатированным.

Следом за расширенным блоком параметров BIOS идет код самозагрузки (Bootstrap Code), который ищет на диске загрузчик операционной системы (у операционных систем из семейства Windows NT это — файл ntldr), загружает его в память и передает ему управление. Если код самозагрузки отсутствует, загрузка операционной системы становится невозможной, однако при подключении восстанавливаемого диска вторым раздел должен быть прекрасно виден. Повреждение кода самозагрузки вызывает перезагрузку компьютера или его зависание.

Наконец, завершает загрузочный сектор уже известная нам сигнатура 55h AAh, без которой он ни за что не будет признан загрузочным. Подробная информация обо всех полях загрузочного сектора NTFS приведена в табл. 5.8.

Таблица 5.8. Значения полей загрузочного сектора NTFS

Техника восстановления загрузочного сектора

Осознавая значимость загрузочного сектора, операционная система Windows NT при форматировании диска создает его зеркальную копию (однако делает она это только на разделах NTFS). Для различных версий Windows расположение резервной копии загрузочного сектора различно. Так, Windows NT 4.0 располагает ее в середине логического диска, a Windows 2000 — в последнем секторе раздела. Если таблица разделов уцелела, то для восстановления загрузочного сектора достаточно просто перейти в начало следующего раздела и отступить на сектор назад (Windows 2000) или поделить количество секторов логического диска пополам (с округлением в нижнюю сторону) и перейти к сектору с полученным номером, дав редактору диска команду GO (Windows NT 4.0).

Если таблица разделов разрушена, то найти резервную копию загрузочного сектора можно глобальным поиском (ищите строку NTFS по смещению 3 от начала сектора). Поскольку положение копии фиксировано и отсчитывается от начала логического диска, мы можем с абсолютной уверенностью определить границы раздела. Предположим, что копия загрузочного сектора найдена в секторе 1289724, а поле NumberSectors содержит значение 12289661. Тогда номер конечного сектора раздела равен 1289724, а номер стартового сектора можно вычислить следующим образом: 1289724 - 12289661 == 63. Поскольку загрузочный сектор расположен на расстоянии одной головки от таблицы разделов, что соответствует значению SectorPerTrack, мы сможем восстановить и ее.

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

Количество секторов в кластере определить сложнее. Это особенно справедливо, если при форматировании диска было задано количество секторов на кластер, отличное от значения по умолчанию. Но ситуация вовсе не безнадежна. Последовательно сканируя файловые записи в MFT, найдите файл с предопределенной и заранее известной сигнатурой. Пусть, для определенности, это будет файл NTOSKRNL.EXE. Откройте его аутентичную копию в HEX-редакторе, найдите уникальную последовательность, гарантированно не встречающуюся ни в каких других файлах и расположенную в пределах первых 512 байт от его начала, после чего найдите эту сигнатуру глобальным поиском по всему диску. Начальный номер кластера вам известен (он содержится в MFT), логический номер сектора известен тоже (его нашел дисковый редактор). Теперь остается лишь соотнести эти две величины между собой. Естественно, если дисковый редактор найдет удаленную копию NTOSKRNL.EXE (или на диске будут присутствовать несколько файлов NTOSKRNL.EXE), данный метод даст осечку, поэтому полученный результат необходимо уточнить, проведя аналогичные исследования с использованием других файлов.

Логический номер первого кластера MFT равен первому кластеру, в начале которого встретилась строка FILE* (конечно, при том условии, что MFT не была перемещена). По умолчанию Windows выделяет под MFT 12,5% от емкости раздела, помещая ее зеркальную копию в середину. Кроме того, ссылка на "зеркало" присутствует и в самой MFT. Если же MFT разрушена, переместитесь в середину диска, немного отступите назад и повторите глобальный поиск строки FILE* (только, смотрите, не вылетите в соседний раздел!). Первое же найденное вхождение с высокой степенью вероятности и будет зеркальной копией MFT.

Количество кластеров на сегмент обычно равно F6h, а количество кластеров на блок индексов — 01h. Других значений мне встречать не доводилось. Серийный номер тома может быть любым — он ни на что не влияет.

Для восстановления отсутствующего (искаженного) кода самозагрузки загрузите консоль восстановления Windows 2000 или Windows XP и дайте команду FIXBOOT.

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

Глава 6 Файловая система NTFS — взгляд изнутри

В этой главе будут рассмотрены основные структуры файловой системы NTFS и ее основополагающие концепции — главная файловая таблица (MFT), файловые записи, последовательности обновления, атрибуты или потоки (streams), а также отрезки (data runs).

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

Введение

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

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

Основными источниками данных по NTFS служат:

□ книга Хелен Кастер (Helen Custer) "Inside the Windows NT file system" (в русском издании она входит в состав книги "Основы Windows NT и NTFS"), подробно описывающая концепции файловой системы и дающая о ней общее представление. К сожалению, все объяснения ведутся на абстрактном уровне без указания конкретных числовых значений, смещений и структур. Кроме того, после выхода Windows 2000 и Windows XP, в файловую систему были внесены значительные изменения, никак не отраженные в упомянутой книге. Если вы не сможете найти эту книгу в магазинах — ищите её в файлообменных сетях. В них есть все! Например, попробуйте найти ее с помощью e-Mule (http://www.eMule.ru);

□ хакерская документация от коллектива "Linux-NTFS Project" (http://www.linux-ntfs.org/), чьим хобби долгое время была разработка независимого драйвера NTFS для Linux. К сожалению, сейчас энтузиазм команды начал стремительно угасать. Это выдающееся творение, подробно описывающее все ключевые структуры файловой системы (на английском языке), не заменяет книгу Кастер, но существенно расширяет ее;

Примечание

Разобраться в документации Linux-NTFS Project без знания основ NTFS очень и очень непросто! Поэтому рекомендуемый порядок чтения следующий: сначала прочтите книгу Хелен Кастер, затем приступайте к чтению хакерской документации.

□ документация от Active@Data Recovery Software, описывающая утилиту Active Uneraser (бесплатную копию этой утилиты можно найти на сайте http://www.NTFS.com). Это — своеобразное сочетание книги Хелен Кастер и документации Linux-NTFS Project, описывающее важнейшие структуры данных и обходящее стороной все вопросы, которые только можно обойти. Здесь же можно найти до предела выхолощенное изложение методики восстановления данных. В общем, если не найдете книгу Хелен, скачайте демонстрационную версию Active Uneraser и воспользуйтесь прилагаемой к ней документацией;

Примечание

Утилита Active Uneraser поставляется в двух вариантах — в виде образа дискеты и в виде образа CD. Сопроводительная документация присутствует только во втором варианте поставки.

□ контекстная помощь к программе Disk Explorer также содержит достаточно подробное описание файловой системы. Следует, правда, отметить, что это описание организовано на редкость бестолково и хаотично. Для упрощения навигации по тексту рекомендуется декомпилировать chm-файл в обычный текст, вручную преобразовав его в документ Microsoft Word, pdf, или любой другой симпатичный вам формат.

Наконец, вы можете воспользоваться этой главой. Тем не менее, наличие документации Linux-NTFS Project все же очень желательно, так как по ходу изложения материала данной главы я буду часто ссылаться на нее.

Версии NTFS

Служебные структуры файловой системы NTFS не остаются постоянными, а слегка меняются от одной версии Windows NT к другой (см. табл. 6.1). Этот факт следует принять во внимание при использовании автоматизированных "докторов". Столкнувшись с более свежей версией NTFS, "доктор", не оснащенный мощным искусственным интеллектом, может запутаться в измененных структурах и разрушить вполне здоровый том.

Таблица 6.1. Определение версии NTFS по версии Windows

Совет

Как быстро узнать тип текущего раздела — FAT или NTFS? Это очень просто — достаточно попробовать создать в его корневом каталоге файл $mft — если он будет создан успешно, то это FAT. Если создать файл с таким именем в корневом каталоге диска невозможно, значит, этот диск отформатирован для использования NTFS. Чтобы быстро определить версию NTFS, попробуйте создать в корневом каталоге диска файл $Extend. Если такой файл будет создан успешно, то версия файловой системы — 3.0 или выше.

Взгляд на NTFS с высоты птичьего полета

Основным структурным элементом всякой файловой системы является том (volume), в случае с FAT совпадающий с разделом (partition), о котором мы говорили в прошлой главе. NTFS поддерживает тома, состоящие из нескольких разделов (рис. 6.1). Подробнее схему отображения томов на разделы мы обсудим в следующей главе, а пока будем для простоты считать, что том представляет собой отформатированный раздел (то есть раздел содержащий служебные структуры файловой системы).

Рис. 6.1. Обычный (а) и распределенный (б) тома

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

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

Остальные служебные файлы, называемые метафайлами (metafiles) или метаданными (metadata), всегда имеют имена, начинающиеся со знака доллара ($), и носят сугубо вспомогательный характер, интересный только самой файловой системе. К ним, в первую очередь, относится: $LogFile — файл транзакций, $Bitmap — карта свободного/занятого пространства, $BadClust — перечень плохих кластеров и т.д. Более подробная информация о них будет приведена далее в этой главе. Текущие версии Windows блокируют доступ к служебным файлам с прикладного уровня (даже с правами администратора!), и всякая попытка открытия или создания такого файла в корневом каталоге обречена на неудачу.

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

Каждый атрибут состоит из тела (body) и заголовка (header). Атрибуты подразделяются на резидентные (resident) и нерезидентные (non-resident). Резидентные атрибуты хранятся непосредственно в $MFT, что существенно уменьшает грануляцию дискового пространства и сокращает время доступа. Нерезидентные атрибуты хранят в $MFT лишь свой заголовок, описывающий порядок размещения атрибута на диске.

Назначение атрибута определяется его типом (type), представляющим собой четырехбайтное шестнадцатеричное значение. При желании атрибуту можно дать еще и имя (name), состоящее из символов, входящих в соответствующее пространство имен (namespace). Подавляющее большинство файлов имеет, по меньшей мере, три атрибута, к числу которых относятся: стандартная информация о файле (время создания, модификации, последнего доступа, права доступа) хранится в атрибуте типа 10h, условно обозначаемом $STANDARD_INFORMATION. Ранние версии Windows NT позволяли обращаться к атрибутам по их условным обозначениям, но Windows 2000 и Windows XP лишены этой возможности. Полное имя файла (не путать с путем!) хранится в атрибуте типа 30h ($FILE_NAME). Если у файла есть одно или несколько альтернативных имен (например, имя MS-DOS), таких атрибутов может быть и несколько. Здесь же хранится ссылка (file reference) на родительский каталог, позволяющая разобраться, к какому каталогу принадлежит данный файл или подкаталог. По умолчанию данные файла хранятся в безымянном атрибуте типа 80h ($DATA). Однако при желании прикладные программы могут создавать дополнительные потоки данных, отделяя имя атрибута от имени файла знаком двоеточия (например: ECHO ххх > file:attr1; ECHO yyy > file:attr2; more < file:attr1; more < file:attr2).

Изначально в NTFS была заложена способность индексации любых атрибутов, значительно сокращающая время поиска файла по заданному списку критериев (например, времени последнего доступа). Индексы хранятся в виде двоичных деревьев, поэтому среднее время выполнения запроса оценивается как O (lg n). На практике в существующих драйверах NTFS реализована индексация лишь по имени файла. Как уже говорилось ранее, каталог представляет собой файл особого типа — файл индексов. В отличие от FAT, где файл каталога представляет собой единственный источник данных об организации файлов, в NTFS файл каталога используется лишь для ускорения доступа к содержимому каталога. Он не является обязательным, так как ссылка на родительский каталог всякого файла в обязательном порядке присутствует в атрибуте его имени ($FILE_NAME).

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

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

В процессе форматирования логического раздела в его начале создается так называемая зона MFT (рис. 6.2). По умолчанию она занимает 12,5% от емкости тома (а не 12%, как утверждается во многих публикациях), хотя, в зависимости от значения параметра NtfsMftZoneReservation, она может составлять 25%, 37% или 50%.

Рис. 6.2. Структура тома, отформатированного под NTFS

В этой области расположен файл $MFT, изначально занимающий порядка 64 секторов и растущий от начала зоны MFT к ее концу по мере создания новых пользовательских файлов и каталогов. Чем больше файлов содержится на томе, тем больше размер MFT. Приблизительный размер файла MFT можно оценить по следующей формуле: sizeof (FILE Record) * N Files, где sizeof(FILE Record) обычно составляет 1 Кбайт, а N Files — полное количество файлов и подкаталогов раздела, включая недавно удаленные.

Для предотвращения фрагментации файла $MFT зона MFT удерживается зарезервированной вплоть до полного исчерпания свободного пространства тома, затем незадействованный "хвост" зоны MFT усекается в два раза, освобождая место для пользовательских файлов. Этот процесс может повторяться многократно, вплоть до полной отдачи всего зарезервированного пространства. Решение красивое, хотя и не новое. Многие из файловых систем восьмидесятых годов прошлого века позволяли резервировать заданное дисковое пространство в хвосте активных файлов, сокращая их фрагментацию (причем любых файлов, а не только служебных). Например, такая способность была у DOS 3.0, разработанной для персональных компьютеров типа "Агат". Может быть, кто-то из вас помнит такую машину?

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

Примечание

Утилиту дефрагментации файла $MFT, а также подробное описание принципов ее работы, можно найти на сайте Марка Руссиновича (http://www.sysinternals.com). Но, как бы там ни было, заполнять том более чем на 88% его емкости категорически не рекомендуется!

При необходимости файл $MFT может быть перемещен в любую часть диска, и тогда в начале тома его уже не окажется. Стартовый адрес файла $MFT хранится в загрузочном секторе по смещению 30h байт от его начала (см. описание структуры загрузочного сектора в гл. 5). В подавляющем большинстве случаев этот адрес ссылается на четвертый кластер.

Файл $MFT представляет собой массив записей типа FILE Record (в терминологии UNIX они называются inodes), каждая из которых описывает соответствующий ей файл или подкаталог. На практике один файл или подкаталог полностью описывается единственной записью типа FILE Record, хотя в теории этих записей может потребоваться и несколько.

Для ссылки на одну файловую запись из другой используется ее порядковый номер (он же индекс) в файле $MFT, отсчитываемый от нуля. Файловая ссылка (file reference) состоит из двух частей (см. табл. 6.2) — 48-битного индекса и 16-битного номера последовательности (sequence number).

Таблица 6.2. Структура файловой ссылки

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

Первые 12 записей в MFT всегда занимают служебные метафайлы: $MFT (собственно, сам файл $MFT), $MFTMirr (зеркало $MFT), $LogFile (файл транзакций), $Volume (сведения о дисковом томе), $AttrDef (определения атрибутов), '.' (корневой каталог), $Bitmap (карта свободного пространства), $Boot (системный загрузчик), $BadClus (перечень плохих кластеров) и т.д. Более подробно эти записи описаны в табл. 6.11.

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

Записи с 12 по 15 помечены как используемые, в то время как в действительности они пусты. Как несложно догадаться, они зарезервированы для использования в будущем. Записи с 16 по 23 не задействованы и честно помечены как неиспользуемые.

Начиная с 24 записи, располагаются пользовательские файлы и каталоги. Четыре метафайла, появившихся в Windows 2000 — $ObjId, $Quota, $Reparse и $UsnJrnl, — могут располагаться в любой записи, номер которой равен 24 или больше (не забудьте, что нумерация файловых записей начинается с нуля).

Вот и вся теоретическая информация, необходимая на первых порах. Теперь можно приступать к практическому знакомству с NTFS. Для начала запустим утилиту DiskExplorer от Runtime Software, не забывая о том, что она требует прав администратора. В меню File найдем пункт Drive, и в появившемся диалоговом окне выберем логический диск, который требует редактирования. Затем из меню Goto выберем пункт Mft, заставляя DiskExplorer перейти к MFT, автоматически меняя режим отображения на наиболее естественный (рис. 6.3). Как вариант, можно нажать клавишу <F6> (View as File Entry) и пропустить несколько первых секторов нажатием клавиши <Page Down>.

Рис. 6.3. Утилита DiskExplorer отображает главную файловую запись в естественном формате

Для каждого из файлов DiskExplorer сообщает следующее.

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

□ Основное имя файла/каталога (то есть имя файла из заголовка файловой записи). Стоит напомнить, что некоторые файлы имеют несколько альтернативных имен, более подробная информация о которых будет приведена далее в данной главе. Если имя файла или каталога зачеркнуто, это означает, что он был удален, но соответствующая ему файловая запись все еще цела. Чтобы извлечь файл с диска (не важно, удаленный или нет), подведите к нему курсор и нажмите клавиатурную комбинацию <Ctrl>+<T> для просмотра его содержимого в шестнадцатеричном виде или <Ctrl>+<S> — для сохранения файла на диск. То же самое можно сделать и через контекстное меню, выбрав подпункт Recovery. При нажатии клавиатурной комбинации <Ctrl>+<C> в буфер обмена копируется последовательность кластеров, занятых файлом, например: DISKEXPL:K:1034240-1034240.

□ Тип файловой записи, указывающий, файл это или каталог.

□ Атрибуты файла или каталога: a (archive) — архивный, r (read-only) — защищенный от записи, то есть доступный только для чтения, h (hidden) — скрытый, s (system) — системный, l (label) — метка тома, d (directory) — каталог, с (compressed) — сжатый.

□ Размер файла в байтах в десятичной системе счисления (не для каталогов!).

□ Дату и время модификации файла или каталога.

□ Номер первого кластера файла или каталога (или resident — для полностью резидентных файлов и каталогов).

□ Перечень типов атрибутов NTFS, имеющихся у файла или каталога, записанных в шестнадцатеричной нотации (обычно эта строка имеет следующий вид: 10 30 80 — атрибут стандартной информации, атрибут имени и атрибут данных файла). Более подробная информация по данному вопросу будет приведена далее в этой главе.

□ Индекс файловой записи в MFT, выраженный в шестнадцатеричной и десятичной системах счисления и следующий за словом No: (сокращение от Number — номер).

□ Индекс файловой записи родительского каталога, выраженный в шестнадцатеричной и десятичной системах счисления (5h — если файл принадлежит к корневому каталогу). Для быстрого перемещения по файловым записям выберите в меню Goto пункт Mft no и введите требуемый индекс в шестнадцатеричной или десятичной нотации.

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

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

Файловые записи

Благодаря наличию утилиты DiskExplorer от Runtime Software с файловыми записями практически никогда не приходится работать вручную. Тем не менее, знание их структуры нам не помешает.

Структурно файловая запись состоит из заголовка (header) и одного или нескольких атрибутов (attributes) произвольной длины, завершаемых маркером конца (end marker) — четырехбайтным шестнадцатеричным значением FFFFFFFFh (см. листинг 6.1). Несмотря на то, что количество атрибутов и их длина меняются от одной файловой записи к другой, размер самой структуры FILE Record строго фиксирован. В большинстве случаев он равен 1 Кбайт (это значение хранится в файле $boot, причем первый байт файловой записи всегда совпадает с началом сектора).

Внимание!

Не следует путать файл $boot с загрузочным сектором (boot sector).

Если реальная длина атрибутов меньше размеров файловой записи, то ее "хвост" просто не используется. Если же атрибуты не умещаются в отведенное им пространство, создается дополнительная файловая запись (extra FILE Record), ссылающаяся на свою предшественницу.

Поиск по сайту: