Что происходит при форматировании
Форматирование диска— это сложная многостадийная операция, намного более сложная и намного более многостадийная, чем это может показаться на первый взгляд. Кто писал свой собственный форматер дискет (а в конце восьмидесятых—начале девяностых его писали практически все) — тот поймет. Свои исследования мы начнем с изучения NTFS-тома, отформатированного под NTFS (техника восстановления NTFS-томов, отформатированных под FAT16/32 дана в одноименной врезке).
При выполнении команды "format X: /U /FS:NTFS" в файловой системе диска X: происходят следующие изменения (форматирование диска GUI-утилитой, вызываемой из контекстного меню "проводника" осуществляется по аналогичной схеме):
q формируется boot-сектор в формате NTFS;
q генерируется новый серийный номер диска и записывается в boot-сектор по смещению 48h байт от его начала;
q рассчитывается новая контрольная сумма boot-сектора и записывается по смещению 50h от его начала (подробнее см. первую статью этого цикла: "загрузочный сектор — базовые концепции");
q создается новый $MFT-файл, содержащий сведения обо всех файлах на диске, и как правило, размещаемый поверх старого $MFT-файла; исключения здесь крайне редки — разве что прежний $MFT был заблаговременно перемещен дефрагментатором, или при форматировании назначен новый размер кластера. Во всех остальных случаях первые ~24 файловых записи (FILE Record) мрут безвозвратно. В них находится — непосредственно сам $MFT, $MFTMirr, корневой каталог, /$LogFile – файл транзакций, /$BITMAP – карта свободного пространства, /$Secure – дескрипторы безопасности и другие служебные файлы;
q инициируется $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 нам придется по частям (###эк, как тебя разворотило — укорял Василий Иванович Анку, в которую угодил артиллеристский снаряд);
q создается новый /$MFT:$BITMAP, отвечающий за занятость файловых записей в MFT — все старые записи помечаются как свободные, однако, их фактического удаления при этом не происходит (поле FileRecord.flags остается нетронутым), благодаря чему процедура восстановления заметно упрощается. Чаще всего $MFT:$BITMAP располагается на том же самом месте, что и старый (т. е. между boot-сектором и MFT), забивая прежнее содержимое нулями, однако, с помощью утилиты chkdsk его можно восстановить;
q создается новый /$BITMAP-файл, отвечающий за распределение дискового пространства (свободные и занятые кластера), опять-таки затирающий старый, но восстанавливаемый chkdsk'ом;
q создается новый файл журнала транзакций — /$LogFile, в структуру которого мы углубляться все равно не будем, хотя в NTFS LINUX Project она описана достаточно подробно, но восстанавливать транзакции — это уж слишком; ### но восстановление транзакций нам никто не оплатит, так что нехай они идут лесом;
q в заголовок файловой записи $MFT заноситься новый LogFile Sequence Number или сокращенного LSN;
q $MFT назначается новый номер последовательности обновления (Update Sequence Number);
q создается новое зеркало $MFTMirr, необратимое затирающее старое (в текущих системах оно расположено посередине NTFS-раздела), в результате чего возникает резонный вопрос — на хрена нам зеркало, которого ничего не отображает ### какой прок от зеркала, которого ничего не отражает?;
q создаются новые /$Volume, /$AttrDef и другие служебные файлы, играющие сугубо вспомогательную роль и легко восстанавливаемые chkdsk'ом (хотя и /$Volume и присутствует в зеркальной копии MFT, его ценность явно преувеличена);
q осуществляется проверка целостности поверхности и все обнаруженные плохие кластеры заносятся в файл /$BadClus;
q формируется новый корневой каталог;
q если до форматирования тома на нем присутствовал /System Volume Information-файл, то он обновляется, в противном случае новый /System Volume Information создается только после перезагрузки;
На самом деле, процесс форматирования протекает намного сложнее, но не будем в него углубляться — мы же не форматер пишем! Интересующееся могут взять в руки IDA Pro и расковырять format.com самостоятельно. Подсказка — format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки ifsutil.dll, untfs.dll и… непосредственно сам драйвер файловой системы. Так что дизассемблировать придется много. Чтобы упросить себе работу, можно пронаблюдать за процессом форматирования с помощью шпионских средств — утилит Марка Руссиновича FileMon и DiskMon, бесплатные копии которых можно скачать с www.sysinternals.com. Так же не забывайте о точках останова на основные native-API функции такие как NtFsControlFile, NtDeviceIoControlFile и т. д. Да будет soft-ice вам в помощь!
Рисунок 2 исследования процесса форматирования с помощью шпионских средств
