Восстановление данных. Практическое руководство

Касперски Крис

NTFS содержит большое количество служебных файлов (метафайлов) строго определенного формата. Важнейший из метафайлов,

$MFT

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

Краткие сведения о назначении важнейших метафайлов приведены в табл. 6.11. К сожалению, в пределах одной главы нет возможности подробно рассмотреть структуру всех существующих метафайлов, поэтому заинтересованным читателям рекомендуется искать эту информацию в документации к Linux-NTFS Project.

Таблица 6.11. Назначение основных метафайлов NTFS

Inode	Имя файла	ОС	Описание
0	$MFT	Любая	Главная файловая таблица (Master File Table, MFT)
1	$MFTMirr	Любая	Резервная копия первых четырех элементов MFT
2	$LogFile	Любая	Журнал транзакций (transactional logging file)
3	$Volume	Любая	Серийный номер, время создания, флаг не сброшенного кэша (dirty flag) тома
4	$AttrDef	Любая	Определение атрибутов
5	. (точка)	Любая	Корневой каталог (root directory) тома
6	$Bitmap	Любая	Карта свободного/занятого пространства
7	$Boot	Любая	Загрузочная запись (boot record) тома
8	$BadClus	Любая	Список плохих кластеров (bad clusters) тома
9	$Quota	Windows NT	Информация о квотах (quota information)
9	$Secure	Windows 2000	Использованные дескрипторы безопасности (security descriptors)
10	$UpCase	Любая	Таблица заглавных символов (uppercase characters) для трансляции имен
11	$Extend	Windows 2000	Каталоги: $ObjId , $Quota , $Reparse , $UsnJrnl
12-15	не используется	Любая	Помечены как использованные, но в действительности пустые
16-23	не используется	Любая	Помечены как неиспользуемые
Любой	$ObjId	Windows 2000	Уникальные идентификаторы каждого файла
Любой	$Quota	Windows 2000	Информация о квотах (quota information)
Любой	$Reparse	Windows 2000	Информация о точке передачи (reparse point)
Любой	$UsnJrnl	Windows 2000	Журнал шифрованной файловой системы (journaling of encryption)
>24	Пользовательский файл	Любая	Обычные файлы
>24	Пользовательский каталог	Любая	Обычные каталоги

Практический пример

Рассказ о файловой системе NTFS был бы неполным без практической иллюстрации техники разбора файловой записи вручную. До сих пор мы витали в облаках теоретической абстракции. Пора спускаться на грешную землю.

Воспользовавшись любым дисковым редактором, например, Disk Probe, попробуем декодировать одну файловую запись вручную. Найдем сектор, содержащий сигнатуру

FILE

в его начале (не обязательно брать первый встретившийся сектор). Он может выглядеть, например, как в листинге 6.4.

Листинг 6.4. Ручное декодирование файловой записи (разные атрибуты выделены разным цветом)

: 00 01 02 03 04 05 06 07 | 08 09 0A 0B 0C 0D 0E 0F

00000000: 46 49 4C 45 2A 00 03 00 | 60 79 1A 04 02 00 00 00 FILE*...`y......

00000010: 01 00 01 00 30 00 01 00 | 50 01 00 00 00 04 00 00 ....0...P.......

00000020: 00 00 00 00 00 00 00 00 | 04 00 03 00 00 00 00 00 ................

00000030: 10 00 00 00 60 00 00 00 | 00 00 00 00 00 00 00 00 ................

00000040: 48 00 00 00 18 00 00 00 | B0 D5 C9 2F C6 0B C4 01 H.......░╒╔/╞.─.

00000050: E0 5A B3 7B A9 FA C3 01 | 90 90 F1 2F C6 0B C4 01

рZ│{й·├.PPё/╞.─.

00000060: 50 7F BC FE C8 0B C4 01 | 20 00 00 00 00 00 00 00 P⌂╝■╚.─. .......

00000070: 00 00 00 00 00 00 00 00 | 00 00 00 00 05 01 00 00 ................

00000080: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 ................

00000090: 30 00 00 00 70 00 00 00 | 00 00 00 00 00 00 02 00 0...p...........

000000A0: 54 00 00 00 18 00 01 00 | DB 1A 01 00 00 00 01 00 T.......█.......

000000B0: B0 D5 C9 2F C6 0B C4 01 | B0 D5 C9 2F C6 0B C4 01 ░╒╔/╞.─.░╒╔/╞.─.

000000C0: B0 D5 C9 2F C6 0B C4 01 | B0 D5 C9 2F C6 CB C4 01 ░╒╔/╞.─.░╒╔/╞.─.

000000D0: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 ................

000000E0: 20 00 00 00 00 00 00 00 | 09 03 49 00 6C 00 66 00 ..........I.l.f.

000000F0: 61 00 6B 00 2E 00 64 00 | 62 00 78 00 00 00 00 00 a.k...d.b.x.....

00000100: 80 00 00 00 48 00 00 00 | 01 00 00 00 00 00 03 00 А...H...........

00000110: 00 00 00 00 00 00 00 00 | ED 04 00 00 00 00 00 00 ........э.......

00000120: 40 00 00 00 00 00 00 00 | 00 E0 4E 00 00 00 00 00 @........рN.....

00000130: F0 D1 4E 00 00 00 00 00 | F0 D1 4E 00 00 00 00 00 Ё╤N.....Ё╤N.....

00000140: 32 EE 04 D9 91 00 00 81 | FF FF FF FF 82 79 47 11 2ю.┘С..Б ВyG.

000001F0: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 03 00 ................

: 00 01 02 03 04 05 06 07 | 08 09 0A 0B 0C 0D 0F 0F

Первым делом необходимо восстановить оригинальное содержимое последовательности обновления. По смещению

04h

от начала сектора лежит 16-разрядный указатель на нее, равный в данном случае

2Ah

(значит, это NTFS 3.0 или более ранняя версия). А что у нас лежит по смещению

2Ah

? Это — пара байт

03 00

. Данная последовательность представляет собой номер последовательности обновления. Сверяем его с содержимым двух последних байт этого и следующего секторов (смещения

1FEh

и

3FEh

соответственно). Они равны! Следовательно, данная файловая запись цела (по крайней мере, на первый взгляд), и можно переходить к операции ее восстановления. По смещению

2Ch

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

06h

от начала сектора и уменьшенного на единицу (в данном случае имеем

03h - 01h == 02h

). Извлекаем два слова, начиная со смещения

2Ch

(в данном случае они равны

00 00

и

00 00

) и записываем их в конец первого и последнего секторов.

Теперь нам необходимо выяснить, используется ли данная файловая запись, или же ассоциированный с ней файл или каталог был удален. 16-разрядное поле, расположенное по смещению

16h

, содержит значение

01h

. Следовательно, перед нами файл, а не каталог, и этот файл еще не удален. Но является ли эта файловая запись базовой для данного файла или мы имеем дело с ее продолжением? 64-разрядное поле, расположенное по смещению

20h

, равно нулю, следовательно, данная файловая запись — базовая.

Очень хорошо, теперь переходим к исследованию атрибутов. 16-разрядное поле, находящееся по смещению

14h

, равно

30h

, следовательно, заголовок первого атрибута начинается со смещения

30h

от начала сектора.

Первое двойное слово атрибута равно

10h

, значит, перед нами атрибут типа

$STANDARD_INFORMATION

. 32-разрядное поле длины атрибута, находящееся по смещению

04h

и равное в нашем случае

60h

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

30h

(смещение нашего атрибута)

+ 60h

(его длина)

== 90h

(смещение следующего атрибута). Первое двойное слово следующего атрибута равно

30h

, значит, это атрибут типа

$NAME

, и следующее 32-разрядное поле хранит его длину, равную в данном случае

70h

. Сложив длину атрибута с его смещением, мы получим смещение следующего атрибута —

90h + 70h == 100h

. Первое двойное слово третьего атрибута равно

80h

, следовательно, это атрибут типа

$DATA

, хранящий основные данные файла. Складываем его смещение с длиной —

100h + 32h == 132h

. И вот здесь мы наткнулись на частокол

FFFFFFh

, сигнализирующий о том, что атрибут

$DATA

последний в списке.