Unformat для NTFS

       

Что происходит при форматировании


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


Содержание раздела