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