Так что вместо разработки вредоносной начинки будем совершенствовать вирус в другом направлении. При повторном заражении файла текущая версия необратимо затирает оригинальный код своим телом, в результате чего файл станет неработоспособным. Вот беда! Как же ее побороть? Можно добавить проверку на зараженность перед копированием вируса в файл. Для этого следует вызвать функцию 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 не торопится сделать этот шаг, возможно, оставляя эти усовершенствования как задел для будущих версий. "Защита" от непреднамеренного удаления реализована исключительно на интерфейсном уровне, а это не только неудобно, но и ненадежно.