| |||
[network & security news] [RSS & Twitter] [articles, programing info] [books] [links, soft & more...] [soft archive] | [home] |
Уязвимости эмуляторов кодаСодержание1. Вступление 2. Несколько слов о процедурах эмуляции кода 3. Шах и мат в две инструкции 4. История с продолжением 5. Старые песни о главном 6. Против лома нет приема ... 7. Заключение 1. ВступлениеГенераторы полиморфных шифровщиков/расшифровщиков очень часто используются для защиты исполняемых файлов (полностью либо частично) и во многих компьютерных вирусах. Для того, что бы усложнить процесс создания утилит, предназначенных для автоматического снятия защит такого рода, и обнаружения вирусов используются различные алгоритмы, называемые анти-эмуляционными трюками. Этим алгоритмам и будет посвящена данная статья. Тестирование трюков будет производиться на антивирусных программах, которые, бесспорно, содержат самые совершенные реализации эмуляторов кода. Таким образом, мы оценим качество эмуляторов следующих антивирусов:
2. Несколько слов о процедурах эмуляции кодаВ том случае, если алгоритм расшифровки данных присутствует в файле, единственным способом автоматической расшифровки является эмуляция. Процесс эмуляции может быть выполнен двумя способами:
Первый способ в "чистом виде" использовать достаточно опасно, к тому же процесс трассировки обнаружить и "обломать" не составляет особого труда. Если использовать второй способ, то процесс эмуляции программы будет занимать достаточно большой промежуток времени и разработка стабильно работающей версии займет "века". Именно по этому используют комбинацию двух вышеописанных способов. Конечно же, есть "вещи" имитацию которых реализовать достаточно тяжело (почти невозможно). Имея небольшой опыт в разработке эмуляторов кода, я могу предположить, какие области являются наиболее сложными и могут быть реализованы с ошибками или вообще не реализованы. Но чтобы знать наверняка, проверим предположения на практике. 3. Шах и мат в две инструкцииПеред процессом эмуляции, исследуемая программа читается в буфер, и для "опасных" (подозрительных) участков кода эмулятор производит полную имитацию выполнения, "безопасные" же инструкции или участки кода запускаются "напрямую". Все это означает, что местоположение эмулируемой программы в памяти изменяется. Таким образом, можно попытаться запутать эмулятор, если определить текущее местоположение и:
Если Вы решили использовать первый вариант, в случае не совпадения положения кода, можно направить эмулятор по "ложному следу". Но такой конструкции (алгоритма вычисления смещения и сравнения его с оригинальным) будет достаточно, чтобы считать ее сигнатурой свойственной данному типу расшифровщика. Таким образом, анализатор кода, использующийся в эмуляторе обнаружит эту конструкцию и использует специальный прием для "правильной" эмуляции участка. Второй вариант можно рассмотреть подробнее и проще будет сделать это "на практике". Так как писать специальную утилиту для тестов мне лень, понадобится следующее:
Загрузим инфицированный файл в отладчик и рассмотрим процедуру расшифровки вирусного кода:
После небольших изменений, расшифровщик вирусного кода будет выглядеть следующим образом:
Я думаю, суть изменений Вам понятна, ну а если нет, то я немного поясню.
Но в том случае, если анализатор кода не обнаружит наличие конкретного вируса, в дело вступает эвристический анализатор. Если будут обнаружены особенности строения, свойственные исполняемым файлам, зараженным вирусами (например, если точка входа находится в последней секции и секция имеет атрибуты, позволяющие "запись"), эвристический анализатор может выдать подозрение о наличии в файле Win32 - вируса. Но это нас не должно волновать, мы же тестируем эмуляторы. Проведенное тестирование показало, что обмануть не получается только эмуляторы антивирусов Doctor Web и NAV, остальные молчат как партизаны. 4. История с продолжениемХодит слух, что начальное значение регистра EAX, при загрузке всех win32 программ одинаковое. Этим значением является местоположение точки входа, в памяти. Я не проверял достоверность этой информации во всех версиях Windows, так что утверждать со 100% гарантией, насчет правдивости данной информации не могу. Но, так же, я не встречался со случаями, когда данное утверждение было неверным. Видоизменим расшифровщик вирусного кода, чтобы он принял следующий вид:
Проведенный тест показал, что антивирусы, которые не попались на предыдущий трюк, вышли "сухими из воды" и на этот раз. Так же не удалось обмануть и "народный антивирус" - AVP. Это говорит о том, что перед процессом эмуляции win32 программ, все антивирусные программы устанавливают значение регистра EAX, равным точке входа в программу, но из других источников так же известно, что : " В EAX должен быть ноль, как результат вызова ntdll.NtSetInformationThread, после которого сразу вызывается точка входа модуля. " Получается, что антивирусы неправильно эмулируют выполнение win32 программ? ;) 5. Старые песни о главномВ далеком 2000 году, программистом, известным мировой общественности под псевдонимом Z0MBiE, была написана очень интересная статья, посвященная корректности "работы" эмуляторов, антивирусных программ Doctor Web и AVP с инструкциями div8/16/32, idiv8/16/32. В результате проведенного дизассемблирования, процедур эмуляторов, отвечающих за имитацию выполнения этих инструкций (прокомментированные листинги так же были приведены в этой статье), было доказано, что эмуляция инструкции idiv32 (8/16/32) происходит неправильно в обеих программах.
С момента публикации данной статьи прошло уже 4 года, но так как она не попала в широкую общественность, я решил проверить,
исправили ли авторы данных программ ошибки, а за одно и посмотреть, как с процессом эмуляции данной инструкции справляются
другие антивирусы.
Для того, чтобы рассмотреть реакцию эмуляторов на различные значения параметров, была написана небольшая утилита (исходный текст доступен в примерах), которая создает файлы инфицированные win32/parite, с расшифровщиками вида :
Тест показал, что:
6. Против лома нет приема ...Операционная система Windows произвела взаимовыгодный обмен прерываний (которые в Dos'е очень активно использовались, для обмана всех и вся) на функции API (Application Programming Interface).
Допустим, что мы используем генератор полиморфных (раc) шифровщиков для защиты исполняемых файлов. Каждый из "защищаемых"
файлов импортирует функции API из различных библиотек, а вся информация об импорте, содержится в исполняемом файле.
Как Вы знаете, каждая из функций API, требует различных параметров для работы, которые должны быть загружены в стек. Помимо параметров, непосредственно используемых той или иной функцией, есть параметр, указывающий смещение, на которое будет передано управление после вызова функции. Об этом параметре мало кто знает, потому что компиляторы генерируют вызовы функций следующим образом:
Инструкция CALL заносит в стек смещение (в данном случае "continue") следующей инструкции, ну а затем
JMP вызывает функцию (GetTickCount). Вызванный сервис использует необходимое количество параметров из стека, для
выполнения своего назначения и предает управление на смещение, которое было загружено инструкцией CALL, в качестве
последнего параметра.
Мы загрузили необходимое количество параметров (в данном случае 1), необходимых для работы функции и смещение, на которое
будет передано управление. Результат работы вызванной функции CloseHandle нас не интересует вообще (следовательно и
состояние параметров, кроме смещения, необходимого для возврата), главное, что в любом случае, после выполнения функции
переход будет осуществлен к метке continue. "Под эмулятором", переход произойдет только при выполнении инструкции
ret.
Теперь готовимся к тестированию на "живце". Для вставки простейшей реализации трюка в расшифровщик нам понадобятся:
В списке импортируемых функций зараженной программы, значится GetCommandLineA. Это не может не радовать, так как
эта функция не нуждается в параметрах, а в нашем случае (когда свободного места в расшифровщике мало) это очень важно.
Кроме того, она не выполняет никаких "вредных" действий.
Как я и ожидал, ни один из антивирусов не определил наличие вируса win32/parite в зараженных файлах, измененных таким образом. 7. ЗаключениеНастало время подвести итоги тестирования:
К статье прилагается архив (пароль: 1) содержащий:
Внимание: вирусный код обрезан таким образом, что он не способен распространяться. В оригинале, вирус не содержит никаких вредоносных компонент. Не смотря на это, автор статьи и администрация сайта не несет ответственности за последствия, которые имели место, как следствие использования файлов из этого архива. Вы используете все вышеперечисленное на свой страх и риск. Что бы там не говорили, а антивирусные эмуляторы достаточно тяжело обмануть, действуя "вслепую" (предполагая). Необходимо дизассемблировать и разбирать алгоритмы их работы, но для этого требуется очень высокий уровень знаний, которым обладают единицы. Огромное спасибо всем членам команды UINC за помощь в работе над статьей. Мой почтовый ящик всегда открыт для эмоций, критики, советов (конструктивных и нет) и т.д. Заинтересовавшимся лицам рекомендуются к прочтению:
06 April 2004 Статья написана специально для UInC (http://www.uinc.ru). эмуляторы кода, обман эмуляторов кода, уязвимости эмуляторов кода, тестирование антивирусов
Все документы и программы на этом сайте собраны ТОЛЬКО для образовательных целей, мы
не отвечаем ни за какие последствия, которые имели место как следствие использования
этих материалов\программ. Вы используете все вышеперечисленное на свой страх и риск. |
[network & security news] [RSS & Twitter] [articles, programing info] [books] [links, soft & more...] [soft archive] | [home] |
2000-2015 © uinC Team |