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

Формат атрибута типа 
$FILE_NAME
 описан в табл. 6.9. Первые восемь байт содержат ссылку на родительский каталог этого файла, равную в данном случае 
11ADBh:01
 (индекс — 
11ADBh
, номер последовательности — 
01h
). Следующие 32 байта содержат данные о времени создания, изменения и времени последнего доступа к файлу. По смещению 
28h
 от начала тела атрибута и 
D0h
 от начала сектора лежит 64-разрядное поле выделенного размера, а за ним — 64-разрядное поле реального размера. Оба равны нулю, что означает, что за размером файла следует обращаться к атрибутам типа 
$DATA
.
Длина имени файла содержится в 8-разрядном поле, находящемся по смещению 
40h
 байт от начала тела атрибута и по смещению 
E8h
 от начала сектора. В данном случае оно равно 
09h
. Само же имя начинается со смещения 
42h
 от начала тела атрибута и со смещения 
EAh
 от начала сектора. И здесь находится имя файла llfak.dbx.
Переходим к атрибуту основных данных файла, пропустив атрибут стандартной информации, который не содержит решительно ничего интересного. 8-разрядный флаг нерезидентности, расположенный по смещению 
08h
 от начала атрибутного заголовка и по смещению 
108h
 от начала сектора, равен 
01h
, следовательно, атрибут нерезидентный. 16-разрядный флаг, расположенный по смещению 
0Ch
 от начала атрибутного заголовка и по смещению 
10Ch
 от начала сектора, равен нулю, значит, атрибут не сжат и не зашифрован. 8-разрядное поле, расположенное по смещению 
09h
 от начала атрибутного заголовка и по смещению 
109h
 от начала сектора, равно нулю — атрибут безымянный. Реальная длина тела атрибута (в байтах) содержится в 64-разрядном поле, расположенном по смещению 
30h
 от начала атрибутного заголовка и по смещению 
130h
 от начала сектора. В данном случае она равна 
4ED1F0h
 (5.165.552). Два 64-разрядных поля, расположенных по смещениям 
10h/110h
 и 
18h/118h
 байт от начала атрибутного заголовка/сектора соответственно, содержат начальный и конечный номер виртуального кластера нерезидентного тела. В данном случае они равны: 
0000h
 и 
4EDh
 соответственно.
Остается лишь декодировать список отрезков, адрес которого хранится в 16-разрядном поле, находящемся по смещению 
20h
 от начала атрибутного заголовка и 120h от начала сектора. В данном случае поле равно 
40h
, что соответствует смещению от начала сектора в 
140h
. Сам же список отрезков выглядит так: 
32 EE 04 D9 91 00 00
. Ага! Два байта занимает поле длины (равное в данном случае 
04EEh
 кластерам) и три — поле начального кластера (
0091h
). Завершающий ноль на конце говорит о том, что этот отрезок последний в списке отрезков.
Подытожим полученную информацию. Файл называется llfak.dbx, он начинается с кластера 
0091h
 и продолжается вплоть до кластера 
57Fh
, при реальной длине файла в 5.165.552 байт. Это все, что надо! Теперь остается только скопировать файл на резервный носитель (например, ZIP или стример).
   
Возможные опасности NTFS
 
Сейчас мы немного отвлечемся и поговорим о... компьютерных вирусах, обитающих внутри NTFS и активно использующих ее расширения в своих личных целях. В любом случае конструирование вирусов — отличный стимул к изучению ассемблера! И хотя вирус в принципе можно написать и на Си, это будет как-то не по-хакерски и вообще неправильно! Настоящие хакеры пишут только на FASM. Итак, запускаем Multi-Edit или TASMED и погружаемся в мрачный лабиринт кибернетического мира, ряды обитателей которого скоро пополнятся еще одним зловредным созданием...
  
Простейший вирус под Windows NT
 
Внедрение вируса в исполняемый файл, в общем случае, достаточно сложный и мучительней процесс. Как минимум для этого требуется изучить формат РЕ-файла и освоить десятки API-функций. Но ведь такими темпами мы не напишем вируса и за сезон, а хочется создать его прямо здесь и сейчас. Но хакеры мы или нет? Файловая система NTFS (основная файловая система Windows NT/2000/XP) содержит потоки данных (streams), называемые также атрибутами. Внутри одного файла может существовать несколько независимых потоков данных (рис. 6.4).
Рис. 6.4. Файловая система NTFS поддерживает несколько потоков в рамках одного файла
Имя потока отделяется от имени файла знаком двоеточия (
:
), например: 
my_file:stream
. Основное тело файла хранится в безымянном потоке, но мы также можем создавать и свои потоки. Заходим в FAR Manager, нажимаем клавиатурную комбинацию <Shift>+<F4>, вводим с клавиатуры имя файла и потока данных, например: 
<i>xxx:yyy</i>
, и затем вводим какой-нибудь текст. Выходим из редактора и видим файл нулевой длины с именем 
<i>xxx</i>
. Почему же файл имеет нулевую длину? А где же введенный нами только что текст? Нажмем клавишу <F4> и... действительно не увидим никакого текста. Однако ничего удивительного в этом нет. Если не указать имя потока, то файловая система отобразит основной поток, а он в данном случае пуст. Размер остальных потоков не отображается, и дотянуться до их содержимого можно, только указав имя потока явно. Таким образом, чтобы увидеть текст, необходимо ввести следующую команду: 
more &lt; xxx:yyy
.
Будем мыслить так: раз создание дополнительных потоков не изменяет видимых размеров файла, то пребывание в нем постороннего кода, скорее всего, останется незамеченным. Тем не менее, чтобы передать управление на свой поток, необходимо модифицировать основной поток. Контрольная сумма при этом неизбежно изменится, что наверняка не понравится антивирусным сканерам. Метод, применяемый для обмана антивирусных программ, мы рассмотрим в дальнейшем, а пока определимся со стратегией внедрения.
Алгоритм работы вируса
Закройте руководство по формату исполняемых файлов (Portable Executable, РЕ). Для решения поставленной задачи оно нам не понадобится. Действовать будем так: создаем внутри инфицируемого файла дополнительный поток, копируем туда основное тело файла, а на освободившееся место записываем наш код, делающий свое черное дело и передающий управление на основное тело. Работать такой вирус будет только на Windows NT/2000/XP и только под NTFS. На работу с файловой системой FAT он изначально не рассчитан. Оригинальное содержимое заражаемого файла на разделах FAT будет попросту утеряно. То же самое произойдет, если упаковать файл с помощью ZIP или любого другого архиватора, не поддерживающего файловых потоков. В качестве примера архиватора, поддерживающего файловые потоки, можно привести RAR. В диалоговом окне Имя и параметры архива есть вкладка Дополнительно, которая содержит группу опций Параметры NTFS (рис. 6.5). В составе этой группы опций есть флажок Сохранять файловые потоки. Установите эту опцию, если при упаковке файлов, содержащих несколько потоков, требуется сохранить их все.