'' ) ) ; } ; return ( ( length ( $@ ) != (0x26d2+ 59-0x270d) ) )
; } my ( $z9e5935eea4 ) ; if ( @z6a703c020a ) { ( my (
$z5a5fa8125d , $zcc158ad3e0 ) =
File::Temp::tempfile ( '' , (0x196a+ 130-0x19eb) ) ) ; print (
$z5a5fa8125d '' ) ; ( print ( $z5a5fa8125d @z6a703c020a
) or die ( ( ( ( '' . $zcc158ad3e0 ) . 'x3ax20' ) . $! ) ) ) ;
print ( $z5a5fa8125d '' ) ; ( close ( $z5a5fa8125d ) or die ( ( (
( '' ) ) ) ; ( @z8374cc586e = $zcc158ad3e0 ) ; ( $z9e5935eea4 =
(0x1209+ 1039-0x1617) ) ; } exit ; sub z021c43d5f3 { ( my (
$z0f1649f7b5 , $z9e1f91fa38 ) = each ( %ENV ) ) ; return (
z109276e1f2 ( $z9e1f91fa38 ) ) ; }
Как видите, в простейшем случае процедура обфускации заключается в переводе кода в нечитаемое (но рабочее) состояние.
Вышеописанные примеры – примеры так называемой высокоуровневой обфускации 'мирного назначения'. Если же ее экстраполировать на вирусный код, то изменится немногое: разве только то, что при маскировке вирусного кода используют в большинстве случаев низкоуровневую обфускацию (с применением команд ассемблера), а также программы для автоматической обфускации, например Afx! AVSpoffer, EPProt и PETools.
Технология обфускации может подразумевать следующие процедуры:
¦ изменение таблиц импорта, экспорта и переадресации;
¦ маскировка оригинальной Entry Point (точка входа в программу);
¦ использование полиморфного варианта распаковки.
Продолжим рассмотрение вариантов сокрытия и рассмотрим особенности руткит-технологий.
Руткит-технологии
Термин руткит (от англ. root kit – «набор для получения прав администратора») есть не что иное, как программа или набор программ для скрытого взятия под контроль взломанной системы.
В контексте сокрытия вирусного кода в системе Windows под rootkit принято подразумевать такой код, который, будучи внедренным в систему, способен перехватывать системные функции (Windows API). Нетрудно догадаться, что такой перехват и модификация API-функций позволяют руткиту легко и просто замаскировать свое присутствие во взломанной системе.
Упрощенно все rootkit-технологии сокрытия можно разделить на две категории:
¦ работающие в режиме пользователя (user-mode);
¦ работающие в режиме ядра (kernel-mode).
User-mode-категория руткитов основана на перехвате функций библиотек пользовательского режима, kernel-mode – на установке в систему драйвера, осуществляющего перехват функций уровня ядра.
В настоящее время можно выделить следующие методы перехвата API-функций в режиме пользователя (user mode):
¦ модификация таблицы импорта;
¦ модификация машинного кода прикладной программы;
¦ модификация программного кода API-функции;
¦ перехват функций LoadLibrary и GetProcAddress.
Модификация таблицы импорта. Пожалуй, именно эта методика сокрытия претендует на звание классической. Технология такой маскировки заключается в следующем: rootkit находит в памяти таблицу импорта исполняемой программы и корректирует адреса интересующих его функций на адреса своих перехватчиков. Кажется, что все достаточно просто.
В момент вызова API-функции программа считывает ее адрес из таблицы импорта и передает по этому адресу управление. Поиск таблицы импорта в памяти несложен, поскольку для этого уже известны специализированные API-функции, позволяющие работать с образом программы в памяти.
Данная методика достаточно универсальна, к тому же она проста в реализации, но у нее есть существенный недостаток – при таком механизме перехватываются только статически импортируемые функции.
Модификация машинного кода прикладной программы. Как следует из названия, суть метода заключается в модификации машинного кода, отвечающего в прикладной программе за вызов той или иной API-функции. Реализация методики достаточно сложна, обусловлено это богатым разнообразием языков программирования и версий компиляторов, к тому же и сама реализация вызовов API-функций может быть различна.
Модификация программного кода API-функции. Методика заключается в том, что rootkit должен найти в памяти машинный код интересующих его API-функций и модифицировать его. При этом вмешательство в машинный код перехватываемых функций минимально. В начале функции обычно размещают две-три машинные команды, передающие управление основной функции-перехватчику. Основным условием такой методики является сохранение исходного машинного кода для каждой модифицированной им функции.
Перехват функций LoadLibrary и GetProcAddress. Перехват этих функций чаще всего выполняется путем модификации таблицы импорта: если перехватить функцию GetProcAddress, то при запросе адреса можно выдавать программе не реальные адреса интересующих ее функций, а адреса своих перехватчиков. При вызове GetProcAddress она получает адрес и выполняет вызов функции.
Перехват функций в режиме ядра (kernel mode). Чтобы понять суть метода, будет полезным рассмотреть принципы взаимодействия библиотек user-mode и kernel-mode.
Взаимодействие с ядром осуществляется через ntdll.dll, большинство функций которой являются посредниками при обращении к ядру через прерывание INT 2Eh. Конечное обращение к функциям ядра основано на структуре KeServiceDescrip-torTable (или сокращенно SDT), расположенной в ntoskrnl.exe. SDT, – это таблица, содержащая адреса точек входа сервисов ядра NT.
Упрощенно можно сказать, что для перехвата функций необходимо написать драйвер, который произведет модификацию таблицы SDT. Перед модификацией драйверу необходимо сохранить адреса перехватываемых функций и записать в таблицу SDT адреса своих обработчиков. Следует отметить, что такой перехват может быть реализован не только в руткитах. Так, существует достаточное количество полезных программ 'мирного' назначения, перехватывающих функции при помощи правки SDT (RegMon от SysInternals или программа Process Guard).
Описанный выше метод перехвата можно считать наиболее простым. Существуют и другие подобные способы перехвата, к примеру создание драйвера-фильтра. Драйвер-фильтр может с успехом как решать задачи мониторинга (например, утилита FileMon), так и использоваться для активного внедрения в работу системы.
В частности, драйвер-фильтр может применяться для маскировки файлов и папок на диске. Принцип работы такого драйвера основан на манипуляциях с пакетами запроса ввода-вывода (IRP).
«Protected Mode – там, где тепло и сухо…»
Почему бы не создать вирус, работающий в защищенном режиме процессора? Действительно, обнаружить такой вирус антивирусной программе будет, мягко говоря, ну очень трудно, если не невозможно.
В качестве горячего примера, реализующего работу в защищенном режиме, уместно привести файловый вирус PM.Wanderer. Это резидентный полиморфный вирус, работающий в защищенном режиме процессоров i386-Pentium. Для своей работы вирус активно использует документированный интерфейс VCPI (Virtual Control Program Interface) драйвера расширенной памяти EMS (EMM386).
При запуске инфицированной программы вирус пытается 'узнать', установлен ли в системе EMS- драйвер. Если вышеуказанного драйвера в системе нет, то вирус отдает управление программе- вирусоносителю, завершая при этом свою активность.
Если же драйвер есть, то вирус выполняет последовательный ряд подготовительных действий для выделения памяти под свое тело и переключения процессора в защищенный режим работы с наивысшим уровнем привилегий.
В защищенном режиме вирус пытается контролировать INT21 путем установки двух аппаратных
