Листинг 7.1. Восстановление удаленного файла при помощи chkdsk

C:\chkdsk D: /F

Тип файловой системы: NTFS.

Проверка файлов завершена.

Проверка индексов завершена.

Восстановление потерянных файлов.

Восстановление потерянного файла test.txt в файле каталога 5

Замена неправильного идентификатора безопасности для файла 29

Проверка дескрипторов безопасности завершена.

Исправление ошибок в атрибуте BITMAP основной таблицы файлов.

Windows сделала изменения в файловой системе.

1068290 КБ всего на диске.

20 КБ в 2 файлах.

4 КБ в 9 индексах.

0 КБ в поврежденных секторах.

7894 КБ используется системой.

7392 КБ занято под файл журнала.

1060372 КБ свободно на диске.

Размер кластера: 2048 байт.

Всего кластеров на диске: 534145.

530186 кластеров на диске.

Восстанавливаем руины

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

С нерезидентными файлами, хранящими свое тело вне MFT, ситуация обстоит не так плачевно, хотя и здесь проблем тоже хватает. Порядок размещения файла на диске хранится в списке отрезков (run-list) внутри файловой записи в MFT. При этом, поскольку файловая запись уже затерта, возможен лишь контекстный поиск по содержимому. Запускаем дисковый редактор, вводим последовательность, заведомо содержащуюся в удаленном файле, но не встречающуюся во всех остальных, и даем редактору команду начать поиск. Для ускорения поиска можно искать только в свободном дисковом пространстве (за это отвечает файл /$BITMAP). Известные мне редакторы напрасно пренебрегают этой возможностью, однако утилиту "продвинутого" поиска несложно написать и самостоятельно.

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

Внимание!

Повторюсь еще раз — ни в коем случае не записывайте файлы не на сам восстанавливаемый том!

Единственная проблема заключается в определении оригинальной длины. Некоторые типы файлов допускают присутствие "мусора" в своем хвосте. В этом случае можно следовать правилу, гласящему, что перебор лучше недобора. Однако это справедливо не для всех файлов! Если конец файла не удается определить визуально (например, pdf-файлы завершаются сигнатурой %%EOF), проанализируйте заголовок файла. Как правило, наряду с прочей полезной информацией там присутствует и размер файла. В данном случае все зависит от структуры конкретного файла, и универсальных рекомендаций дать невозможно.

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

В ходе анализа списков отрезков сильно фрагментированных дисков мне удалось установить следующие закономерности. Сначала заполняются самые большие "дыры", причем заполнение происходит в направлении от конца зоны MFT к концу диска. Затем драйвер файловой системы возвращается назад и начинает заполнять "дыры" поменьше. Так продолжается до тех пор, пока файл не оказывается на диске целиком. В последнюю очередь заполняются "дыры" размером в один кластер. Просматривая карту диска, представленную файлом /$BITMAP, мы можем в точности восстановить порядок размещения фрагментов удаленного файла, наскоро собрав их воедино. Во всяком случае, теоретически такая возможность существует. На практике же на этом пути нас ждут коварные препятствия. Дело в том, что с момента создания восстанавливаемого файла карта свободного дискового пространства могла радикально измениться. Всякая операция удаления файлов высвобождает одну или несколько "дыр", хаотично перемешивающихся с "дырами" восстанавливаемого файла. Как этому противостоять? Сканируем MFT в поисках записей, помеченных как удаленные, но еще не затертых. Декодируем списки отрезков и вычеркиваем соответствующие им фрагменты из списка кандидатов на восстановление. Это существенно сужает круг поиска, хотя количество комбинаций, в которые можно собрать фрагментированный файл, по- прежнему остается велико. Но это не самое главное.

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

Хуже всего поддаются восстановлению документы, созданные в Microsoft Office. Происходит это потому что приложение создает большое количество резервных копий редактируемого файла, как в текущем каталоге, так и в каталоге %TEMP%. Разобраться с тем, какой фрагмент какому файлу принадлежит, очень нелегко!

Проще всего восстанавливать ZIP-архивы. Для этого вам даже не потребуется запускать дисковый редактор. Откройте временный файл на запись, сделайте seek на размер свободного дискового пространства, закройте файл. А теперь обработайте его утилитой pkzipfix.exe (или запустите стандартный pkzip.exe с ключом Fix). В "исправленном" файле волшебным образом появятся все уцелевшие ZIP-архивы! Внутренняя структура ZIP-архива такова, что pkzipfix легко распознает даже переупорядоченные блоки, поэтому высокая степень фрагментации ему не помеха.

Дефрагментация тоже происходит интересно. Стандартный API дефрагментации в силу малопонятных ограничений оперирует не единичными кластерами, а блоками! Минимальный размер блока составляет 16 кластеров, причем начало блока должно быть кратно 16 кластерам в файле! Количество мелких "дыр" после дефрагментации только возрастает, а непрерывных областей свободного пространства практически совсем не остается.

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

На томе С: свободно 17%, но только 5% доступно для использования

дефрагментатора диска. Для эффективной работы дефрагментатор требует

по крайней мере 15% доступного свободного места.

"Недоступное" для дефрагментатора пространство находится внутри зоны MFT, потому что, как вы помните, при форматировании диска для хранения файла $MFT резервируется 12,5% от емкости тома. Затем, по мере исчерпания дискового пространства, файл $MFT усекается наполовину, а освободившееся за счет этого дисковое пространство отдается для хранения пользовательских файлов. Иначе говоря, для гарантированной работы дефрагментатора ему нужно 10% + 15% == 25% свободного дискового пространства. Не слишком ли высока эта плата за дефрагментацию? Если же у вас свободно свыше 25%, настоятельно рекомендуется создать на диске временный файл и выполнить seek, чтобы заполнить все более или менее крупные "дыры", что не позволит дефрагментатору их изуродовать. Разумеется, после дефрагментации этот файл нужно удалить. К счастью, на сжатые файлы ограничение на минимальный размер блока в 16 кластеров не распространяется, поэтому мелкие файлы очень выгодно держать в сжатом состоянии, так как это существенно уменьшает фрагментацию тома. Чаще дефрагментируйте свой диск! Это не только увеличит быстродействие, но и упростит восстановление удаленных файлов с затертой файловой записью.

Вообще говоря, восстановление файлов — операция несложная, но нудная и кропотливая. Если по долгу службы или в силу иных обстоятельств вам приходится заниматься восстановлением постоянно, то этот процесс можно "автоматизировать", написав несколько простых утилит. Чтобы получить доступ к логическому разделу в Windows NT, достаточно открыть одноименное устройство с помощью функции CreateFile("\\.\X:", GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0), где X: — буквенное обозначение логического диска. Более подробную информацию по данному вопросу можно найти в документации Platform SDK.

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

Методики изучения механизма фрагментации

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

Рис. 7.3. Статический анализ стратегии выделения дискового пространства, выполняемый при помощи DiskExplorer от Runtime Software

Утилита Diskmon.exe, разработанная Марком Руссиновичем (Mark Russinovich) и доступная для свободного скачивания на его сайте (http://www.sysinternals.com), позволяет заглянуть в "святая святых" файловой системы и увидеть, как именно она выделяет дисковое пространство для хранения файлов (рис. 7.4). Особенно интересно запускать Diskmon.exe параллельно с дефрагментатором или утилитой chkdsk, так как в этом случае все тайное сразу становится явным.

Рис. 7.4. Динамический анализ стратегии выделения дискового пространства, выполняемый при помощи Дискового Монитора Марка Руссиновича

Совет

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

Восстановление разделов NTFS после форматирования

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

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

Проще всего начать с форматирования. Для экспериментов нам потребуется утилита format.com, входящая в стандартный комплект поставки Windows NT/2000/XP, а также дисковый раздел, не содержащий никакой ценной информации.

С овет

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

Рис. 7.5. Форматирование виртуального диска в среде VMWare

"Живой" винчестер лучше не трогать, во всяком случае, до тех пор, пока вы не научитесь его восстанавливать. Кроме виртуальной машины, можно использовать привод ZIP (который, кстати говоря, намного надежнее оптических накопителей) и форматировать дискеты под NTFS, поскольку штатная утилита форматирования это позволяет. С обычными трехдюймовыми дискетами дело обстоит сложнее. По мнению Microsoft, их емкости недостаточно для размещения всех структур данных, хотя, простейший расчет показывает, что это утверждение не соответствует действительности, что утилита NTFSflp от Марка Руссиновича, собственно говоря, и демонстрирует. Статья "NTFS Support for Floppy Disks" (http://www.sysinternals.com/ntw2k/freeware/ntfsfloppy.shtml) подробно описывает, как обхитрить систему, заставив ее отформатировать гибкий диск под NTFS. Следует, правда, отметить, что для этого вам потребуется SoftIce.

Действия, выполняемые при форматировании

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

При выполнении команды format X: /U /FS:NTFS в файловой системе диска X: происходят следующие изменения (форматирование диска утилитой GUI, вызываемой из контекстного меню "проводника", осуществляется по аналогичной схеме):

1. Формируется загрузочный сектор NTFS.

2. Генерируется новый серийный номер тома, который затем записывается в загрузочный сектор по смещению 48h байт от его начала.

3. Рассчитывается новая контрольная сумма загрузочного сектора, которая затем записывается по смещению 50h от его начала (более подробная информация была приведена в гл. 5).

4. Создается новый файл $MFT, содержащий сведения обо всех файлах на диске. Как правило, он записывается поверх старого файла $MFT. Исключения из этого правила бывают, но они крайне редки. Обычно они происходят, если прежний файл $MFT был заблаговременно перемещен дефрагментатором, или если при переформатировании был назначен новый размер кластера. Во всех остальных случаях первые 24 файловых записи (FILE Record) погибают безвозвратно. Эти записи содержат непосредственно сам файл $MFT, $MFTMirr, корневой каталог, /$LogFile — файл транзакций, /$BITMAP — карту свободного пространства, /$Secure — дескрипторы безопасности, а также ряд других служебных файлов.

5. Инициализируется файл $MFT:$DATA — назначаются новая длина файла (инициализируются $MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize и $MFT:$80.LastVCN), дата и время создания и последней модификации (инициализируются $MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime и $MFT:$30.FileReadTime) и, самое главное, создается новый список отрезков (data-runs), необратимо затирающий старый. Это значит, что собирать фрагментированный файл $MFT нам придется по частям.

6. Создается новый файл /$MFT:$BITMAP, отвечающий за занятость файловых записей в MFT. При этом все старые записи помечаются как свободные, однако их фактического удаления не происходит (поле FileRecord.flags остается нетронутым), благодаря чему процедура восстановления заметно упрощается. Чаще всего $MFT:$BITMAP располагается на том же самом месте, что и старый (т.е. между загрузочным сектором и MFT), забивая прежнее содержимое нулями, однако с помощью утилиты chkdsk его можно восстановить.

7. Создается новый файл /$BITMAP, отвечающий за распределение дискового пространства (свободные и занятые кластеры). Этот файл также записывается поверх прежнего файла /$BITMAP, который, тем не менее, может быть восстановлен с помощью chkdsk.

8. Создается новый файл журнала транзакций — /$LogFile, структура которого подробно описана в документации LINUX-NTFS Project.

9. В заголовок файловой записи $MFT заносится новый LSN (LogFile Sequence Number).

10. $MFT назначается новый номер последовательности обновления (Update Sequence Number).

11. Создается новое зеркало $MFTMirr, необратимо затирающее старое (в текущих версиях файловых систем оно расположено в середине раздела NTFS).

12. Создаются новые /$Volume, /$AttrDef и другие служебные файлы, играющие сугубо вспомогательную роль и легко восстанавливаемые утилитой chkdsk. Следует отметить, что хотя /$Volume и присутствует в зеркальной копии MFT, его ценность явно преувеличена.

13. Осуществляется проверка целостности поверхности диска, и все обнаруженные плохие кластеры заносятся в файл /$BadClus.

14. Формируется новый корневой каталог.

15. Если до форматирования тома на нем присутствовал файл /System Volume Information, то он обновляется, в противном случае новый файл /System Volume Information создается только после перезагрузки.

На самом деле процесс форматирования протекает намного сложнее. Тем не менее, для восстановления данных с непреднамеренно переформатированных разделов приведенной здесь информации вполне достаточно. Углубленное обсуждение этих технических деталей требуется только программисту, разрабатывающему собственную нестандартную утилиту форматирования. Заинтересованные читатели могут самостоятельно дизассемблировать утилиту format.com (рекомендуется делать это с помощью IDA Pro).

Совет

Утилита format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки ifsutil.dll, untfs.dll, и непосредственно на сам драйвер файловой системы. Так что дизассемблировать придется много. Чтобы упросить себе работу, можно пронаблюдать за процессом форматирования с помощью шпионских средств (рис. 7.6), например, утилит Марка Руссиновича Filemon.exe, Diskmon.exe, бесплатные копии которых можно скачать с сайта http://www.sysinternals.com. Кроме того, не забывайте о точках останова на основные функции native API, такие как NtFsControlFile, NtDeviceIoControlFile и т.д.

Рис. 7.6. Исследование процесса форматирования с помощью шпионских средств

Автоматическое восстановление диска после форматирования

Форматирование не уничтожает файловые записи пользовательских файлов, и они могут быть полностью восстановлены. Существует множество утилит для восстановления данных, например, R-Studio, EasyRecovery, GetDataBack, и т.д. Тем не менее, прямых наследников утилиты unformat среди них не наблюдается. Утилита unformat.exe восстанавливала весь том целиком, а все перечисленные выше современные средства всего лишь извлекают отдельные уцелевшие файлы и каталоги, переписывая их на новый носитель. Вот здесь мы сталкиваемся с рядом проблем. Во-первых, это выбор носителя, на который будут извлекаться восстанавливаемые данные. Запись на оптические накопители отпадает сразу же. так как количество носителей, потребное для сохранения содержимого жесткого диска объемом 80–120 Гбайт, неприемлемо велико. Кроме того, непосредственная запись CD-R/RW не всегда возможна, ведь при крахе системы восстанавливающие утилиты приходится загружать с CD-ROM, а в большинстве компьютеров установлен только один оптический привод. Наконец, ни одна из известных мне утилит автоматического восстановления данных не позволяет "разрезать" большие файлы на несколько маленьких. Если в вашем распоряжении есть локальная сеть, можно перегнать данные по ней. Еще один вариант — установка дополнительного жесткого диска (при условии наличия свободных каналов контроллера). Выбирая этот подход, следует иметь в виду, что, если корпус компьютера опечатан, то его вскрытие автоматически лишает вас гарантии. То есть вам в любом случае не обойтись без определенных финансовых затрат. Тем не менее, для извлечения пары сотен особо ценных файлов такая методика вполне подходит.

Продемонстрируем технику автоматического восстановления данных на примере утилиты R-Studio от компании R-TT Inc. (http://www.r-tt.com). Это — довольно мощный и в тоже время простой в управлении инструмент, на который можно положиться. После запуска утилиты на экране появится окно Drive View, где перечислены все физические устройства и логические разделы. Найдите среди них тот, который требуется восстановить, и, нажав правую кнопку мыши, выберите опцию Scan.

Программа предложит указать начальный сектор для сканирования (поле Start), который по умолчанию равен 0. Это значение следует оставить без изменений. Размер сканируемой области (поле Size) по умолчанию развертывается на весь раздел. Это гарантирует, что сканер обнаружит все уцелевшие файловые записи, хотя сам поиск займет значительное время. Можно ли ускорить этот процесс? Давайте возьмем ручку и подсчитаем. Предположим, что восстанавливаемый раздел содержит сто тысяч файлов. Типичный размер файловой записи составляет 1 Кбайт. При условии, что файл $MFT не фрагментирован, достаточно просканировать всего около 100 Мбайт от начала раздела. Если эта величина (размер пространства, зарезервированного под MFT) не превышает 10% от полной емкости тома и диск никогда не заполнялся более чем на 90%, то, скорее всего, все так и есть. В противном случае файл $MFT фрагментирован и живописно разбросан по всему диску. Впрочем, в случае ошибки мы ничем не рискуем. Вводим значение N Кбайт, где N — предполагаемое количество файлов (каталог также считается файлом), и выполняем сканирование. Если один или несколько файлов останутся необнаруженными, возвращаемся к настройкам по умолчанию и повторяем процедуру сканирования вновь (если количество имеющихся файлов заранее неизвестно, следует указать значение, равное 10% от емкости тома). В поле File System выбираем файловую систему NTFS, сбрасывая флажки напротив двух других доступных опций (FAT и Ext2fs). Затем нажмите кнопку Scan и сканирование начнется (рис. 7.7).

Рис. 7.7. R-Studio осуществляет поиск уцелевших файловых записей

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

Рис. 7.8. Восстановленная структура каталогов

Удаленные файловые записи могут ссылаться на уже уничтоженные каталоги. R-Studio собирает их в папку $$$Folder XXX, где XXX — порядковый номер каталога. Поэтому иерархия подкаталогов в большинстве случаев успешно восстанавливается.

Просмотр виртуального дерева обнаруженных файлов осуществляется нажатием кнопки <F5> или с помощью соответствующей команды контекстного меню. Выбрав файл (или даже целый каталог с большим количеством вложенных подкаталогов), нажмите клавишу <F2>. При желании можно выполнить предварительный просмотр или редактирование (выбрав из контекстного меню пункт Edit|View). Это достаточно мощный инструмент, отображающий содержимое восстанавливаемого файла со всеми его атрибутами, списками отрезков и т.д. в удобочитаемом формате. При желании можно восстановить все файлы за одну операцию (Recover All) или выбрать восстановление по маске (Mask). Хваленая утилита EasyRecovery от Data Recovery Software (рис. 7.9), вопреки своему названию, простотой управления отнюдь не отличается и имеет довольно специфические особенности поведения. С настройками по умолчанию никаких файлов на отформатированном разделе эта утилита не увидит. Чтобы заставить ее работать, необходимо нажать кнопку Advanced Options и в раскрывшемся окне выбрать опцию Ignore MFT. Однако и в этом случае качество восстановления будет оставлять желать лучшего.

Рис. 7.9. Красивый интерфейс EasyRecovery еще не говорит о высоком качестве восстановления данных

Ручное восстановление жесткого диска после форматирования

Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все что для этого потребуется — это любой редактор диска (предпочтительнее всего, конечно же, NT Explorer от Runtime Software, но на крайний случай сойдут и бесплатные Disk Probe и Sector Inspector от Microsoft) в комбинации со встроенной утилитой chkdsk.

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

Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что требуется сделать, сводится к воссозданию прежнего файла $MFT:$DATA и его размещению поверх старых файловых записей. В простейшем случае, если файл $MFT:$DATA не фрагментирован, это достигается так называемым спекулятивным увеличением его длины. Как это сделать?

Запускаем NT Explorer, переходим в начало MFT (Goto|Mft), выделяем файл $MFT, находим атрибут $DATA (80h) и увеличиваем поля Allocated size, Real Size и Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков (рис. 7.10). Поле Last VCN трогать не нужно, так как оно будет исправлено утилитой chkdsk. Как определить длину нефрагментированного файла MFT? Она равна разнице номеров первого и последнего секторов, в начале которых присутствует сигнатура FILE, умноженной на 512 байт (исключая сектора, принадлежащие $MFTMirr). Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. К счастью, точную длину MFT определять совершенно необязательно, и вполне допустимо взять ее с запасом, так как лишнее все равно отсеет chkdsk. Действуйте по принципу — лучше перебрать, чем недобрать.

Рис. 7.10. Ручное восстановление MFT. Подчеркнуты поля, подлежащие изменению

Утилита NT Explorer не позволяет редактировать поля в естественном режиме отображения, заставляя нас переключаться в HEX-mode и искать смещения всех значений самостоятельно. Найти заголовок атрибута $DATA очень просто — в его начале расположена последовательность 80 00 00 00 xx 00 00 00 01. В NTFS версии 3.0 она находится по смещению F8h от начала сектора. Поле Real size во всех версиях NTFS располагается по смещению 30h относительно заголовка, а поля Allocated Size и Initialized Size, соответственно, по смещениям 28h и 38h байт, причем значение Allocated Size должно быть кратно размеру кластера. Убедитесь, что при переформатировании диска размер кластера не изменился, в противном случае у вас ничего не получится. Как восстановить исходный размер кластера? Да очень просто — набраться мужества и переформатировать восстанавливаемый диск с ключом /A:x, где x — размер кластера. А как его определить? Возьмем любой файл с известным содержимым и проанализируем его список отрезков. Запускаем контекстный поиск по всему диску, находим файл, запоминаем (записываем на бумажке) его стартовый сектор, после чего открываем закрепленную за ним файловую запись, декодируем список отрезков и вычисляем номер первого кластера. Делим номер сектора на номер кластера и получаем искомую величину.

Теперь необходимо сгенерировать новый список отрезков. В общем виде он будет выглядеть так: 13 XX XX XX YY 00, где XX XX XX — трехбайтное значение размера $MFT в кластерах, a YY — стартовый кластер. Стартовый кластер обязательно должен указывать на первый кластер MFT, в противном случае chkdsk не сможет работать. Если новый список отрезков длиннее нынешнего (скорее всего, именно так и будет), то необходимо скорректировать длину атрибутного заголовка (она расположена по смещению 04h от его начала). Проделав эту нехитрую операцию, запустим chkdsk с ключом /F и блаженно откинемся на спинку кресла, созерцая, как возрождаются наши милые папки и файлы. Единственное, что не восстанавливается — так это дескрипторы безопасности. Всем файлам и папкам будут назначены права доступа по умолчанию. Во всех остальных отношениях с отремонтированным таким образом диском вполне можно будет работать, не опасаясь, что он рухнет окончательно. Файлы, ссылающиеся на несуществующие каталоги, складываются в папку Found.xxx. Это — "долгожители", пережившие несколько циклов переформатирования, в буквальном смысле вытащенные из небытия.

Сложнее восстановить том, чья MFT сильно фрагментирована. Прежний список отрезков при форматировании был уничтожен, зеркальная копия также пострадала. Ничего другого не остается, как собирать все фрагменты руками. К счастью, на практике это оказывается не так сложно, как может показаться на первый взгляд. В отличие от всех остальных файлов диска, файл $MFT имеет замечательную сигнатуру file, присутствующую в начале каждой файловой записи. Поэтому все, что нам требуется сделать, сводится к следующим операциям. Последовательно сканируя раздел от первого кластера до последнего, выпишите начало и конец каждого из фрагментов, принадлежащих MFT. Затем из этой цепочки необходимо исключить файл $MFTMirr. Его легко узнать, так как он расположен в середине раздела и содержит копии файловых записей $MFT, $MFTMirr, $LogFile и $Volume, причем $MFTMirr ссылается на себя. В рассматриваемом примере наш список выглядит так: 08h–333h, 669h–966h, 1013–3210h. В грубом приближении ему будет соответствовать следующий список отрезков: 12 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00. Подробная информация о кодировании и декодировании списков отрезков была приведена в гл. 6.

"В грубом приближении" сказано потому, что мы не знаем, в какой последовательности располагались эти отрезки в файле (порядок расположения фрагментов на диске далеко не всегда совпадает с порядком отрезков в списке отрезков). Что произойдет, если порядок сборки файла $MFT окажется нарушен? Внутри MFT все файловые записи ссылаются друг на друга по своим порядковым номерам, представляющим собой индексы массива. Эти ссылки необходимы для восстановления структуры каталогов, организации жестких ссылок (hard links) и еще некоторых служебных структур. Ссылки на родительский каталог дублируются в индексах и восстанавливаются элементарно.

Жесткие ссылки теряются безвозвратно (единственный способ восстановить их заключается в повторении попытки сборки файла $MFT в другом порядке). Однако они практически нигде и никак не используются, так что их потеря не столь уж существенна. По-настоящему туго приходится сильно фрагментированным файлам, занимающим несколько файловых записей, раскиданных по разным фрагментам $MFT. Здесь выручает только перестановка фрагментов. К счастью, количество комбинаций обычно бывает невелико, и процедура восстановления занимает совсем немного времени. Хорошая новость — начиная с NTFS версии 3.1 (соответствующей Windows XP) в MFT номера файловых записей хранятся в явном виде (четырехбайтовое поле, расположенное по смещению 2Ch от начала файловой записи), что делает задачу восстановления тривиальной.

Восстановление после тяжелых повреждений

В результате сбоя содержимое дискового тома может стать недоступным операционной системе. При попытке чтения оглавления такого тома будут выдаваться различные сообщения об ошибках (рис. 7.11). Chkdsk сообщает о повреждении MFT и прекращает работу.

Рис. 7.11. Безуспешная попытка прочитать поврежденный том

Не паникуйте! Попробуйте запустить NT Explorer и посмотрите, что он покажет. Маловероятно, чтобы содержимое всего тома было утеряно целиком. Если хотя бы часть файловых записей уцелела, то R-Studio. GetDataBack или EasyRecovery их обязательно восстановят!

Анализ показывает, что основной причиной, по которой chkdsk отказывается проверять том, обычно становится порча файловой записи, описывающей $MFT. Если в процессе обновления $MFT внезапно отключить питание, то такой исход вполне вероятен, особенно на жестких дисках с емким аппаратным кэшем. Такие диски не успевают завершить сохранение секторов, потребляя энергию, накопленную в конденсаторах, а вот их младшие собраться с этим справляются. То же самое происходит при неудачном перемещении файла $MFT или физическом разрушении первого сектора MFT. Зеркальная копия $MFT во всех этих случаях остается цела, однако chkdsk по каким-то таинственным причинам не хочет ей пользоваться, и вы должны восстановить ее самостоятельно. Просто скопируйте первый сектор $MFTMirr в первый сектор $MFT! Поклонники утилиты Sector Inspector могут воспользоваться для этого командным файлом, приведенным в листинге 7.2.

Листинг 7.2. Командный файл для ручного восстановления $MFT из $MFTMirr, XXX — номер сектора $MFTMirr, YYY — номер сектора $MFT

SECINSPECT.EXE -backup d: backup.dsk XXX 1

SECINSPECT.EXE -restore d: backup.dsk YYY CONFIRM

Теперь можно смело запускать chkdsk. Если же chkdsk по-прежнему не работает, это может происходить по одной из следующих причин.

□ Повреждение загрузочного сектора. Решить проблему можно, восстановив загрузочный сектор, используя методику, рассмотренную в гл. 5.

□ Несовпадение списка отрезков файла $MFT:$DATA с истинным началом MFT. Чтобы решить эту проблему, найдите сектор с файловой записью $MFT и исправьте список отрезков. Вопросы, связанные с кодированием и декодированием списка отрезков, были изложены в гл. 6, а методика исправления списка отрезков — ранее в этой главе.

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

Если же сбой был настолько серьезен, что вместе с $MFT пострадало и зеркало, задача сводится к восстановлению отформатированного диска. При тяжелых разрушениях файловой структуры, когда на диске образуется настоящий кавардак, восстановление тома полезно начинать не с чего-нибудь, а именно с его форматирования. Нет, это не первоапрельская шутка! Утилита format.exe формирует заведомо исправные ключевые структуры, а подключение файловых записей — не проблема. Главное — сохраните список отрезков файла $MFT:$DATA, если, конечно, он еще уцелел. Все остальное — дело техники!

Наш затянувшийся разговор о восстановлении данных подходит к своему логическому завершению, однако NTFS не стоит на месте, а интенсивно развивается. И хотя до сих пор эти изменения носили чисто косметический характер, в Windows Longhorn все обещает кардинальным образом измениться. Microsoft активно работает над новой файловой системой — Windows File System (WinFS). Сроки выхода WinFS постоянно переносятся, что и неудивительно, ведь разработка файловой системы — это не шутка!

По словам вице-президента Microsoft Боба Маглиа (Bob Muglia), WinFS — это все та же NTFS, дополненная расширениями SQL и XML. Насколько изменятся базовые структуры файловой системы, общественности до сих пор неясно. И уж совсем непонятно, зачем NTFS понадобились расширения SQL, когда эти возможности в нее закладывались изначально, просто их не успели завершить. Любой системный программист без проблем напишет драйвер, принимающий SQL/XML запросы и транслирующий их в обращения к драйверу текущей файловой системы! Что-либо менять в самой NTFS совсем необязательно. Как лично мне кажется, это всего лишь очередной маркетинговый трюк, подталкивающий пользователей к переходу на Longhorn!

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

Восстановление тома NTFS после форматирования под FAT16/32

При переформатировании диска операционные системы семейства Windows NT никогда не изменяют тип файловой системы, если только им не дать такое указание явно. Поэтому непреднамеренное переформатирование раздела NTFS под FAT16/32 крайне маловероятно. Windows 9x и MS-DOS, напротив, любой диск стремятся отформатировать под FAT16/32, не замечая, что на нем что-то уже находится. Непреднамеренная порча разделов NTFS в процессе установки Windows 9x/MS-DOS поверх Windows NT — обычное дело, через которое проходит уже второе поколение пользователей.

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

Файлы с уцелевшей файловой записью легко восстанавливаются с помощью утилит R-Studio, GetDataBack или EasyRecovery. Для ручного восстановления всего тома его необходимо заново отформатировать под NTFS, предварительно определив количество секторов в кластере. Далее действуем по плану — увеличиваем размер $MFT, запускаем chkdsk и собираем все, что только можно собрать. Поскольку количество файлов, хранящихся на современных дисках, зачастую исчисляется многими миллионами, потеря первой тысячи из них не так уж и страшна (если только по закону подлости они не окажутся самыми ценными из всего, что хранилось на диске).

Источники угрозы

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

□ Ошибки оператора, вирусы, троянские программы.

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

□ Некорректное поведение различных дисковых утилит (Partition Magic, Ahead Nero, Norton Disk Doctor и т.д.).

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

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

Полезные советы

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

□ Переместите $MFT подальше от начала раздела. Первые секторы раздела — это, как показала практика, самое небезопасное место (рис. 7.12). Во-первых, сюда стремятся попасть практически все вирусы. Невозможность прямого доступа к диску под управлением операционных систем из семейства Windows NT — это всего лишь миф. Если вам требуется аргументированное опровержение этого мифа, прочтите описание функции CreateFile и инструкцию к драйверу ASPI32. Во-вторых, некоторые утилиты (и в частности, Ahead Nero) при некоторых обстоятельствах путают жесткий диск с оптическим накопителем, записывая образ не "туда". Это значит, что в первых ~700 Мбайт физического диска (обратите внимание — физического диска, а не логического тома) не должно содержаться ничего ценного. В-третьих, если вы вдруг запустите WipeDisk или любую другую затирающую утилиту, первым погибнет именно $MFT, без которого весь дисковый том — это просто груда мусора. Можно привести и множество других, самых различных причин! Поэтому просто переместите $MFT, тем более, что это совсем несложно. Достаточно взять любой дефрагментатор, распространяющийся в исходных текстах (энтузиасты! ау! присоединяйтесь к проекту http://sourceforge.net/projects/opendefrag/), и слегка доработать его (рис. 7.13). Разумеется, резервная копия при этом всегда должна находиться под рукой.

Рис. 7.12. Нормальный дисковый том (MFT расположена в начале раздела)

Рис. 7.13. "Иммунизированный" дисковый том (MFT расположена в середине)

□ Не допускайте фрагментации файла $MFT! Не создавайте на диске огромного количества мелких файлов и не заполняйте его более чем на 90%. Стандартный дефрагментатор, входящий в комплект штатной поставки Windows 2000/XP, не позволяет дефрагментировать $MFT. Для этой цели приходится прибегать к сторонним средствам, лучшим из которых, на мой взгляд, является О&О Defrag Pro от одноименной компании (http://www.oo-software.com). Это — действительно профессиональный дефрагментатор, к тому же поддерживающий командную строку.

□ Периодически создавайте резервную копию файловой записи $MFT. Для этого достаточно сохранить один-единственный сектор — первый сектор MFT, номер которого содержится в загрузочном секторе. Только не забывайте его периодически обновлять, ведь при добавлении новых файлов и каталогов MFT планомерно расширяется, и старые списки отрезков становятся все менее и менее актуальны.

Глава 8 Восстановление данных под Linux/BSD

Главный недостаток UNIX-подобных систем — отсутствие нормальных драйверов под множество разнообразного оборудования, с которым Windows справляется без проблем. Несколько лет назад ситуация с драйверами под Linux и BSD была просто катастрофической. Поддерживалось лишь некоторое оборудование, и железо для UNIX-машин приходилось закупать отдельно. Тогда операционная система Linux еще не вышла из стадии "конструктора" для хакеров, a BSD в основном использовалась на серверах, все оборудование которых сводилось к сетевой карте и контроллеру SCSI. Поэтому основной массе пользователей жаловаться не приходилось.

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

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

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

Виртуальные машины

Прежде чем ставить Linux/BSD задумайтесь — а зачем вам, собственно, все это нужно? Если просто хотите протестировать альтернативную систему, освоить средства разработки или компилировать исходные тексты, то наилучшим выбором будет виртуальная машина, например, VMWare (рис. 8.1). Fedora Core на ней, конечно, будет работать очень медленно (например, на P-III 733 работать вообще невозможно), но Debian с KDE будет "пахать" вполне нормально. Хочешь — разрабатывай программы, хочешь — читай руководства (man pages). Еще и в игры типа Star Wars можно поиграть. Никаких драйверов сверх того, что есть в любом "правильном" дистрибутиве, для этого не потребуется. Большинство разработчиков именно так и поступают. Как ни крути, а любой уважающий себя UNIX-программист вынужден держать на компьютере десяток различных операционных систем, чтобы тестировать свои программы на совместимость. На "живом" компьютере переключения между ними происходят только путем перезагрузки, что не слишком удобно. Виртуальные машины при этом можно переключать в любом порядке и с любой скоростью (главное — это иметь как можно больше памяти!).

Рис. 8.1. Виртуальная машина Linux, работающая в среде Windows

Можно поступить и наоборот. Установить Linux/BSD как базовую систему, a Windows водрузить на виртуальную машину (рис. 8.2). Так как VMWare дает прямой доступ к портам COM, LPT и USB, то подключение сканера, принтера или цифровой камеры к вашей машине перестанет быть проблемой. С этим оборудованием будет работать Windows! Базовая машина UNIX в этом случае получает в свое распоряжение все системные ресурсы, и падения производительности уже не происходит, но появляются другие проблемы. Приложения Windows (например, игры) будут либо сильно тормозить, либо откажутся запускаться совсем, к тому же со всеми остальными типами устройств, например, интегрированной платой WLAN или видеокартой, Windows работать не сможет. А все потому, что VMWare представляет собой "черный ящик", отгороженный от базовой операционной системы толстой стеной эмулятора. Вот если бы существовала возможность предоставить виртуальной машине полный доступ ко всему физическому оборудованию, вот тогда бы... Готовьтесь! Именно такой способ мы и собираемся описать!

Рис. 8.2. Виртуальная машина Windows в среде Linux

Перенос драйверов Windows в Linux/BSD

Начнем с простого, но до сих пор никем не решенного вопроса. Разумеется, на самом-то деле вопрос этот, конечно, уже давно решен, но совсем не так, как следовало бы. Известно, что поддержка разделов NTFS в Linux/BSD представляет собой сплошную проблему. Драйверы, способные осуществлять запись на разделы NTFS, появились совсем недавно, да и то лишь затем, чтобы покрасоваться на выставках. Для реальной работы они непригодны, потому что работают не очень стабильно и страдают множеством ограничений. Сжатые файлы, транзакции и множество других возможностей все еще не поддерживаются. Кроме того, NTFS не стоит на месте и хоть и медленно, но совершенствуется. Можно ли, хотя бы теоретически, написать стопроцентно совместимый драйвер, корректно работающий со всеми новыми версиями NTFS без участия программиста? Этот вопрос совсем не так глуп, как кажется. Для чего программистам тратить силы и время на собственный драйвер, когда под рукой есть уже готовый — NTFS.SYS. Если заставить его заработать под Linux, то все проблемы решатся сами собой.

Несмотря на то, что на уровне ядра между Linux/BSD и Windows существует большое количество различий, но и кое-что общее между ними все-таки имеется. И Windows, и Linux, и BSD работают на процессорах семейства x86 в защищенном режиме, используют страничную организацию виртуальной памяти и, наконец, все они взаимодействуют с оборудованием в строго установленном порядке (через иерархию физических и виртуальных шин). Высокоуровневые драйверы, такие, например, как NTFS.SYS, вообще не работают с оборудованием напрямую и содержат минимум системно-зависимого кода. Почему же тогда драйвер от одной системы не работает в другой? А потому, что интерфейс между ОС и драйвером в каждом случае различен, а также потому, что драйвер использует библиотеку функций, экспортируемых системой, и эти функции у каждой системы свои.

Перенести драйвер Windows в Linux/BSD вполне реально! Для этого даже не потребуется его исходный код. Достаточно лишь написать тонкий и несложный "переходник" между драйвером и операционной системой, принимающий запросы и транслирующий их по всем правилами "этикета", а также перенести библиотеку функций, необходимых драйверу для работы. Конечно, для этого необходимо уметь программировать! Для простых пользователей такой рецепт совершенно не годится, но тут уж ничего не поделаешь. Тем не менее, перенести готовый драйвер намного проще, чем переписать его с нуля. Нам не потребуется проводить кропотливую работу по дизассемблированию оригинального кода, заменяющую собой поиск технической документации (которая либо совсем отсутствует, либо отдается только под подписку о неразглашении, зачастую запрещающую открытое распространение исходных текстов). Наконец, при выходе новых версий драйвера Windows процедура его переноса в Linux/BSD проста до тривиальности — достаточно скопировать новый файл поверх старого файла. Однако все это лишь сухая теория. Перейдем к деталям.

Модель ядра Windows NT и всех производных от нее операционных систем (включая Windows 2000, XP, 2003, Longhorn) достаточно проста (рис. 8.3). С "внешним" миром ядро связывает диспетчер системных сервисов, "подключенный" к NTDLL.DLL, которая находится уже за "скорлупой" ядра и исполняется в режиме пользователя. Диспетчер системных сервисов, реализованный в NTOSKRNL.EXE, опирается на вызываемые интерфейсы ядра, часть которых реализована в самом файле NTOSKRNL.EXE, а часть — во внешних драйверах, к числу которых, в частности, принадлежит диспетчер питания. Определенный класс драйверов, называемый драйверами устройств и файловой системы, находится в своеобразной "скорлупе" и взаимодействует с диспетчером системных вызовов через диспетчер ввода-вывода, реализованный опять-таки в NTOSKRNL.EXE!

Рис. 8.3. Архитектура систем из семейства Windows NT

Ядро, на котором, как на фундаменте, держатся все вышеупомянутые компоненты, представляет собой просто совокупность низкоуровневых функций, сосредоточенных в NTOSKRNL.EXE. Ниже находится только уровень аппаратных абстракций (Hardware Abstraction Level, HAL). Когда-то у Microsoft была идея разделить ядро на системно-зависимую и системно-независимую части, чтобы упростить перенос Windows на другие платформы. Однако уже во времена Windows NT 4 все перемешалось, и большая часть системно-зависимых функций попала в NTOSKRNL.EXE. На сегодняшний день ситуация такова, что HAL медленно, но неотвратимо умирает. В нем осталось небольшое количество действительно низкоуровневых функций, непосредственно взаимодействующих с оборудованием, например, с портами и с DMA. Но в ядре Linux/BSD есть свои функции для работы с DMA, так что тащить за собой HAL нам совершенно необязательно, тем более что драйверы взаимодействуют с DMA не напрямую, а через диспетчер Plug and Play, который находится в NTOSKRNL.EXE.

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

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