Текст книги "Восстановление данных. Практическое руководство"
Автор книги: Крис Касперски
Жанры:
Компьютерное "железо"
,сообщить о нарушении
Текущая страница: 10 (всего у книги 26 страниц)
В процессе форматирования логического раздела в его начале создается так называемая зона 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. Структура файловой ссылки
00h | 6 | Индекс файловой записи (FILE record number), отсчитываемый от нуля |
06h | 2 | Номер последовательности (sequence number) |
При удалении файла или каталога соответствующая ему файловая последовательность помечается как неиспользуемая. При создании новых файлов записи, помеченные как неиспользуемые, могут задействоваться вновь, при этом счетчик номера последовательности, хранящийся внутри файловой записи, увеличивается на единицу. Этот механизм позволяет отслеживать "мертвые" ссылки на уже удаленные файлы. Номер последовательности внутри файловой ссылки в этом случае будет отличаться от номера последовательности соответствующей файловой записи. Этой проверкой занимается утилита 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). Как вариант, можно нажать клавишу
Рис. 6.3. Утилита DiskExplorer отображает главную файловую запись в естественном формате
Для каждого из файлов DiskExplorer сообщает следующее.
□ Номер сектора, к которому данная файловая запись принадлежит. Обратите внимание, что номера секторов монотонно увеличиваются на 2, подтверждая тот факт, что размер одной файловой записи равен 1 Кбайт, хотя на практике можно столкнуться и с другими значениями. Для удобства информация отображается сразу в двух системах счисления – шестнадцатеричной и десятичной.
□ Основное имя файла/каталога (то есть имя файла из заголовка файловой записи). Стоит напомнить, что некоторые файлы имеют несколько альтернативных имен, более подробная информация о которых будет приведена далее в данной главе. Если имя файла или каталога зачеркнуто, это означает, что он был удален, но соответствующая ему файловая запись все еще цела. Чтобы извлечь файл с диска (не важно, удаленный или нет), подведите к нему курсор и нажмите клавиатурную комбинацию – для сохранения файла на диск. То же самое можно сделать и через контекстное меню, выбрав подпункт Recovery. При нажатии клавиатурной комбинации 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), ссылающаяся на свою предшественницу.
Листинг 6.1. Структура файловой записи
FILE Record
Header ; Заголовок
Attribute 1 ; Атрибут 1
Attribute 2 ; Атрибут 2
... ; ...
Attribute N ; Атрибут N
End Marker (FFFFFFFFh) ; Маркер конца
Первые четыре байта заголовка заняты "магической последовательностью" FILE, сигнализирующей о том, что мы имеем дело с файловой записью типа FILE Record. При восстановлении сильно фрагментированного файла $MFT это обстоятельство играет решающую роль, поскольку позволяет отличить сектора, принадлежащие MFT, от всех остальных секторов.
Следом за сигнатурой идет 16-разрядный указатель, содержащий смещение последовательности обновления (update sequence). Под "указателем" здесь и до конца раздела подразумевается смещение от начала сектора, отсчитываемое от нуля и выраженное в байтах. В Windows NT и Windows 2000 это поле всегда равно 002Ah, поэтому для поиска файловых записей можно использовать сигнатуру FILE*x00, что уменьшает вероятность ложных срабатываний. В Windows XP и более новых версиях последовательность обновления хранится по смещению 002Dh, и поэтому сигнатура приобретает следующий вид: FILE-x00.
Размер заголовка также варьируется от одной операционной системы к другой, и в явном виде нигде не хранится. Вместо этого в заголовке присутствует указатель на первый атрибут, содержащий его смещение в байтах относительно начала файловой записи и расположенный по смещению 14h байт от начала сектора. Смещения последующих атрибутов (если они есть) определяются путем сложения размеров всех предыдущих атрибутов (размер каждого из атрибутов содержится в его заголовке) со смещением первого атрибута. За концом последнего атрибута находится маркер конца – значение FFFFFFFFh.
Длина файловой записи хранится в двух полях. Тридцатидвухразрядное поле реального размера (real size), находящееся по смещению 18h байт от начала сектора, содержит совокупный размер заголовка, всех его атрибутов и маркера конца, округленный по 8-байтной границе. Тридцатидвухразрядное поле выделенного размера (allocated size), находящееся по смещению 1Ch байт от начала сектора, содержит действительный размер файловой записи в байтах, округленный по размеру сектора. Документация Linux-NTFS Project (версия 0.4) утверждает, что выделенный размер должен быть кратен размеру кластера, но на практике это не так. Например, на моей машине длина поля выделенного размера равна четверти кластера.
16-разрядное поле флагов, находящееся по смещению 16h байт от начала сектора, в подавляющем большинстве случаев принимает одно из следующих трех значений: 00h – данная файловая запись не используется или ассоциированный с ней файл или каталог удален, 01h – файловая запись используется и описывает файл, 02h – файловая запись используется и описывает каталог.
64-разрядное поле, находящееся по смещению 20h байт от начала сектора, содержит индекс базовой файловой записи. Для первой файловой записи это поле всегда равно нулю, а для всех последующих, расширенных записей – индексу первой файловой записи. Расширенные файловые записи могут находиться в любых областях MFT, не обязательно расположенных рядом с основной записью. Следовательно, необходим какой-то механизм, обеспечивающий быстрый поиск расширенных файловых записей, принадлежащих данному файлу (просматривать всю MFT было бы слишком нерационально). Этот механизм существует, и основан он на ведении списков атрибутов ($ATTRIBUTE_LIST). Список атрибутов представляет собой специальный атрибут, добавляемый к первой файловой записи и содержащий индексы расширенных записей. Формат списка атрибутов будет подробно описан далее в этой главе.
Основные поля заголовка файловой записи описаны в табл. 6.3. Остальные поля заголовка файловой записи не столь важны, и поэтому здесь они не рассматриваются. При необходимости обращайтесь к документации "Linux-NTFS Project".
Таблица 6.3. Структура заголовка файловой записи (FILE Record)
00h | 4 | Любая | Сигнатура FILE | |
04h | 2 | Любая | Смещение номера последовательности обновления (update sequence number) | |
06h | 2 | Любая | Размер (в словах) номера последовательности обновления и массива обновления (Update Sequence Number & Array), условно S | |
08h | 8 | Любая | Номер последовательности файла транзакций ($LogFile Sequence Number или LSN) | |
10h | 2 | Любая | Номер последовательности (sequence number) | |
12h | 2 | Любая | Счетчик жестких ссылок (hard link) | |
14h | 2 | Любая | Смещение первого атрибута | |
16h | 2 | Любая | Флаги | |
0x00 | Файловая запись не используется | |||
0x01 | Файловая запись используется и описывает файл | |||
0x02 | Файловая запись используется и описывает каталог | |||
0x04 | За справками обращайтесь к Биллу Гейтсу – вероятно, только он это знает | |||
0x08 | За справками обращайтесь к Биллу Гейтсу – вероятно, только он это знает | |||
18h | 4 | Любая | Реальный размер (real size) файловой записи | |
1Ch | 4 | Любая | Выделенный размер (allocated size) файловой записи | |
20h | 8 | Любая | Ссылка (file reference) на базовую файловую запись (base FILE record) или ноль, если данная файловая запись является базовой | |
28h | 2 | Любая | Идентификатор следующего атрибута (next attribute ID) | |
2Ah | 2 | Windows XP | Используется для выравнивания | |
2Ch | 4 | Windows XP | Индекс данной файловой записи (number of this MFT record) | |
| 2 | Любая | Номер последовательности обновления (update sequence number) | ||
2S-2 | Любая | Массив последовательности обновления (update sequence array) | ||
Будучи очень важными компонентами файловой системы, $MFT, INDEX и $LogFile нуждаются в механизме контроля целостности своего содержимого. Традиционно для этого используются коды обнаружения и коррекции ошибок (ECC/EDC codes). Однако на тот момент, когда проектировалась NTFS, процессоры были не настолько быстрыми, как теперь, и расчет корректирующих кодов занимал значительное время, существенно снижающее производительность файловой системы. Именно поэтому от использования корректирующих кодов пришлось отказаться. Вместо них разработчики NTFS применили так называемые последовательности обновления (update sequences), также называемые fix-ups.
В конец каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record), записывается специальный 16-байтный номер последовательности обновления (update sequence number), дублируемый в заголовке файловой записи. При каждой операции чтения два последних байта сектора сверяются с соответствующим полем заголовка и, если драйвер NTFS обнаруживает расхождение, данная файловая запись считается недействительной.
Основное назначение последовательностей обновления – защита от "обрыва записи". Если в процессе записи сектора на диск исчезнет питающее напряжение, может случиться так, что часть файловой записи будет записана успешно, а другая часть – сохранит прежнее содержимое (файловая запись, как мы помним, обычно состоит из двух секторов). После восстановления питания драйвер файловой системы не может уверенно определить, была ли файловая запись записана целиком. Вот тут-то последовательности обновления и выручают! При каждой перезаписи сектора последовательность обновления увеличивается на единицу. Потому, если произошел обрыв записи, значение последовательности обновления, находящейся в заголовке файловой записи, не совпадет с последовательностью обновления, расположенной в конце сектора.
Оригинальное содержимое, расположенное "под" последовательностью обновления, хранится в специальном массиве обновления (update sequence array), расположенном в заголовке файловой записи непосредственно за концом смещения последовательности обновления (update sequence number). Для восстановления файловой записи в исходный вид необходимо извлечь из заголовка указатель на смещение последовательности обновления (он хранится по смещению 04h байт от начала заголовка) и сверить лежащее по этому адресу 16-байтное значение с последним словом каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record). Если они не совпадут, значит, соответствующая структура данных повреждена. Использовать такие структуры следует очень осторожно (на первых порах лучше не использовать вообще).
По смещению 006h от начала сектора находится 16-разрядное поле, хранящее совокупный размер номера последовательности обновления вместе с массивом последовательности обновления (sizeof (update sequence number) + sizeof(update sequence array)), выраженный в словах (не в байтах!). Так как размер номера последовательности обновления всегда равен одному слову, то размер массива последовательности обновления, выраженный в байтах, должен вычисляться следующим образом: (update sequence number & update sequence array – 1)*2. Таким образом, смещение массива оригинального содержимого равно: (offset to update sequence number) + 2. В Windows NT и Windows 2000 номер последовательности обновления всегда располагается по смещению 2Ah от начала заголовка файловой записи или индексного заголовка, а поле update sequence array – по смещению 2Ch. В Windows XP и более новых операционных системах эти значения располагаются по смещениям 2Dh и 2Fh соответственно.
Первое слово массива последовательности обновления соответствует последнему слову первого сектора файловой записи или индексной записи. Второе – последнему слову второго сектора и т.д. Для восстановления сектора в исходный вид необходимо вернуть все элементы массива последовательности обновления на их законные места (естественно, модифицируется не сам сектор, а его копия в памяти).
Чтобы проиллюстрировать сказанное выше, рассмотрим пример, приведенный в листинге 6.2.
Листинг 6.2. Оригинальная файловая запись до восстановления
–> начало первого сектора FILE Record
00000000: 46 49 4C 45-2A 00 03 00-7C 77 1A 04-02 00 00 00 FILE*...|w......
00000010: 01 00 02 00-30 00 01 00-28 02 00 00-00 04 00 00 ....0...(.......
00000020: 00 00 00 00-00 00 00 00-06 00 06 00-00 00 47 11 ..............G.
...
000001F0: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 06 00 ................
<– конец первого сектора FILE Record
...
000003F0: 07 СС E1 0D-00 09 00 00-FF FF FF FF-82 79 06 00 .Іа..... Вy..
<– конец второго сектора FILE Record
Сигнатура FILE указывает на начало файловой записи, следовательно, по смещению 04h байт будет расположен 16-разрядный указатель на номер последовательности обновления. В данном случае он равен 002Ah. Очень хорошо! Переходим по смещению 002Ah и видим, что здесь лежит слово 0006h. Перемещаемся в конец сектора и сверяем его с последними двумя байтами. Как и предполагалось, они совпадают. Повторяем ту же самую операцию со следующим сектором. Собственно говоря, количество секторов может и не равняться двум. Чтобы не гадать на кофейной гуще, необходимо извлечь 16-разрядное значение, расположенное по смещению 06h от начала файловой записи (в данном случае оно равно 0003h) и вычесть из него единицу. Действительно, получается два (сектора).
Теперь нам необходимо найти массив последовательности обновления, хранящий оригинальное значение последнего слова каждого из секторов. Смещение массива обновления равно значению указателя на последовательность обновления увеличенной на два, т.е. в данном случае 002Ah + 02h == 002Ch. Извлекаем первое слово (в данном случае равное 00h 00h) и записываем его в конец первого сектора. Извлекаем следующее слово (47h 11h) и записываем его в конец второго сектора.
В результате восстановленный сектор будет выглядеть, как показано в листинге 6.3.
Листинг 6.3. Восстановленная файловая запись
–> Начало первого сектора файловой записи
00000000: 46 49 4C 45-2A 00 03 00-7C 77 1A 04-02 00 00 00 FILE*...|w......
00000010: 01 00 02 00-30 00 01 00-28 02 00 00-00 04 00 00 ....0...(.......
00000020: 00 00 00 00-00 00 00 00-06 00 06 00-00 00 47 11 ..............G.
...
000001F0: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................
<– Конец первого сектора файловой записи
000003F0: 07 СС E1 0D-00 09 00 00-FF FF FF FF-82 79 47 11 .Іа..... ВyG.
<– Конец второго сектора файловой записи
Внимание!
FILE Record,INDEX Record,RCRD RecordилиRSTR Recordискажены последовательностями обновления и в обязательном порядке должны быть восстановлены перед их использованием, в противном случае вместо актуальных данных вы получите мусор!
