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

от начала сектора лежит 16-разрядный указатель на нее, равный в данном случае (значит, это NTFS 3.0 или более ранняя версия). А что у нас лежит по смещению ? Это — пара байт . Данная последовательность представляет собой номер последовательности обновления. Сверяем его с содержимым двух последних байт этого и следующего секторов (смещения и соответственно). Они равны! Следовательно, данная файловая запись цела (по крайней мере, на первый взгляд), и можно переходить к операции ее восстановления. По смещению расположен массив, содержащий оригинальные значения последовательности обновления. Количество элементов в нем равно содержимому 16-разрядного поля, расположенному по смещению от начала сектора и уменьшенного на единицу (в данном случае имеем ). Извлекаем два слова, начиная со смещения (в данном случае они равны и ) и записываем их в конец первого и последнего секторов.

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

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

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

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

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

, значит, перед нами атрибут типа . 32-разрядное поле длины атрибута, находящееся по смещению и равное в нашем случае байт, позволяет нам вычислить смещение следующего атрибута в списке: (смещение нашего атрибута) (его длина) (смещение следующего атрибута). Первое двойное слово следующего атрибута равно , значит, это атрибут типа , и следующее 32-разрядное поле хранит его длину, равную в данном случае . Сложив длину атрибута с его смещением, мы получим смещение следующего атрибута — . Первое двойное слово третьего атрибута равно , следовательно, это атрибут типа , хранящий основные данные файла. Складываем его смещение с длиной — . И вот здесь мы наткнулись на частокол , сигнализирующий о том, что атрибут последний в списке.

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

от начала атрибутного заголовка (и по смещению от начала сектора), содержит флаг нерезидентности. В данном случае этот флаг равен нулю. Это значит, атрибут резидентный, и его тело хранится непосредственно в самой файловой записи, что уже хорошо. 16-разрядное поле, расположенное по смещению от начала атрибутного заголовка (и по смещению от начала сектора) равно нулю, следовательно, тело атрибута не сжато и не зашифровано. Таким образом, можно приступать к разбору тела атрибута. 32-разрядное поле, расположенное по смещению от начала атрибутного заголовка (и по смещению от начала сектора), содержит длину атрибутного тела, равную в данном случае байт. 16-разрядное поле, расположенное по смещению от начала атрибутного заголовка и по смещению от начала сектора, хранит смещение атрибутного тела, равное в данном случае . Следовательно, тело атрибута располагается по смещению от начала сектора.

Формат атрибута типа

описан в табл. 6.9. Первые восемь байт содержат ссылку на родительский каталог этого файла, равную в данном случае (индекс — , номер последовательности — ). Следующие 32 байта содержат данные о времени создания, изменения и времени последнего доступа к файлу. По смещению от начала тела атрибута и от начала сектора лежит 64-разрядное поле выделенного размера, а за ним — 64-разрядное поле реального размера. Оба равны нулю, что означает, что за размером файла следует обращаться к атрибутам типа .

Длина имени файла содержится в 8-разрядном поле, находящемся по смещению

байт от начала тела атрибута и по смещению от начала сектора. В данном случае оно равно . Само же имя начинается со смещения от начала тела атрибута и со смещения от начала сектора. И здесь находится имя файла llfak.dbx.

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

от начала атрибутного заголовка и по смещению от начала сектора, равен , следовательно, атрибут нерезидентный. 16-разрядный флаг, расположенный по смещению от начала атрибутного заголовка и по смещению от начала сектора, равен нулю, значит, атрибут не сжат и не зашифрован. 8-разрядное поле, расположенное по смещению от начала атрибутного заголовка и по смещению от начала сектора, равно нулю — атрибут безымянный. Реальная длина тела атрибута (в байтах) содержится в 64-разрядном поле, расположенном по смещению от начала атрибутного заголовка и по смещению от начала сектора. В данном случае она равна (5.165.552). Два 64-разрядных поля, расположенных по смещениям и байт от начала атрибутного заголовка/сектора соответственно, содержат начальный и конечный номер виртуального кластера нерезидентного тела. В данном случае они равны: и соответственно.

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

от начала атрибутного заголовка и 120h от начала сектора. В данном случае поле равно , что соответствует смещению от начала сектора в . Сам же список отрезков выглядит так: . Ага! Два байта занимает поле длины (равное в данном случае кластерам) и три — поле начального кластера (). Завершающий ноль на конце говорит о том, что этот отрезок последний в списке отрезков.

Подытожим полученную информацию. Файл называется llfak.dbx, он начинается с кластера

и продолжается вплоть до кластера , при реальной длине файла в 5.165.552 байт. Это все, что надо! Теперь остается только скопировать файл на резервный носитель (например, ZIP или стример).

Сейчас мы немного отвлечемся и поговорим о... компьютерных вирусах, обитающих внутри NTFS и активно использующих ее расширения в своих личных целях. В любом случае конструирование вирусов — отличный стимул к изучению ассемблера! И хотя вирус в принципе можно написать и на Си, это будет как-то не по-хакерски и вообще неправильно! Настоящие хакеры пишут только на FASM. Итак, запускаем Multi-Edit или TASMED и погружаемся в мрачный лабиринт кибернетического мира, ряды обитателей которого скоро пополнятся еще одним зловредным созданием...