А ты написал свой стелс?

Касатенко Иван aka SkyWriter

Спецвыпуск Xakep, номер #035, стр. 035-050-2

Но Вынь росла и ширилась, и, наконец, удвоила циферку после своего имени: Win32 получала все большее и большее распространение. Вирусописатели один за другим пересели на ASM под Win32.

Проблемы оказались в чем-то схожими с MS-DOS'овскими: надо было скрыть вирус. Правда, решение их оказалось намного сложнее: во-первых, из-за того, что Win32-приложения работают исключительно в среде защищенного режима процессора, во-вторых, в Win гораздо больше функций для работы с объектами (файлами, процессами), да и объектов стало поболее, а, значит, и больше следов, которые может оставить вирусный код.

Но гений вирьмейкеров и тут их не подвел. Бессонные ночи кодинга сделали свое дело: слово "стелс" возродилось из пепла.

Что же должен скрывать "идеальный" современный стелс-вирус (будем считать, что он резидентный и распространяется, помимо прямого заражения файлов, еще и по e-mail)? Давай по порядку.

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

Все это можно сделать, перехватив системные вызовы API на каком-либо уровне - либо на уровне пользователя, либо на уровне ядра.

Процесс, покажи личико

Начнем со скрытия процессов. Мне видится целый ряд способов, при помощи которых это можно сделать.

Итак, способ первый и самый простой: надо лишь зарегистрировать текущий процесс как сервис, воспользовавшись системной API-функцией:

...

RegisterServiceProcess(NULL, 1);

....

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

Способ номер два состоит во внедрении в тело чужого процесса в памяти прямо "на лету". Теоретически это очень просто: нужно создать область памяти, которая будет доступна жертве, а затем каким-то образом запустить в ее адресном пространстве код, который создаст еще один тред, обслуживающий вирус. На практике все немного сложнее ;-).

Для начала нам необходимо зарегистрировать фрагмент памяти, в котором будет лежать код (для этого можно воспользоваться функциями OpenFileMapping и MapViewOfFile из kernel32.dll). Туда-то мы и поместим код треда, который будет выполняться в процессе-жертве. Теперь необходимо заставить жертву запустить этот тред. Как же выполнить какой-то код в чужом адресном пространстве? Есть, пожалуй, два пути: один - это использование CreateRemoteThread, а второй - это замена адреса какой-то импортированной из системной библиотеки функции (например, GetDC из gdi32.dll) на адрес своей функции, предварительно записанной в процесс. У первого пути при всех его положительных моментах (например, предельной простоте) один минус - он работает лишь на NT, но ты ведь хочешь универсальности, правда? Поэтому рассмотрим второй.