Способы защиты РПС от изучения и особенности функционирования подсистемы предварительной обработки исполняемых файлов

Большинство современных разрушающих программных средств защищают свой код от анализа, при этом выделяют следующие механизмы самозащиты:

1) методы блокирования или уничтожения самих антивирусных средств;

2) методы маскирования присутствия РПС в программном коде или в операционной системе:

– на уровне программного кода (методы, позволяющие не обнаружить присутствие РПС при анализе программного кода РПС антивирусным средством):

обфускация кода (запутывающие преобразования);

полиморфизм;

методы выявления и выведения из строя эмуляторов программного кода;

применение навесных упаковщиков программного кода;

– на уровне функционирования операционной системы (стелс-технологии):

маскирование файлов на жестком диске (без учета особенностей структуры файловой системы (ФС), с учетом особенностей структуры ФС, с учетом особенностей функционирования ФС);

маскирование вирусов, прописанных в реестре;

маскирование вирусов во время своего присутствия в оперативной памяти.

Наиболее популярным и в тоже время наиболее перспективным способом защиты в настоящее время является применение навесных упаковщиков.

Под упакованным исполняемым файлом понимается исполняемый файл, прошедший обработку и структурное изменение под воздействием особого вида программ (упаковщиков) для сжатия и затруднения анализа программного кода.

Упаковщиков исполняемых файлов условно разделяют на два типа:

1) сжимающие, цель которых – устранение избыточности программного кода и соответственно уменьшение размера файла (например, UPX, AsPack, NsPack);

2) протекторы, дополнительно обладающие механизмами затруднения исследования программы на предмет ее безопасности (например, PeCompact, AsProtect, Yoda, Obsidium, Telock, Armadillo, Orient).

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

Типовая структура упакованного исполняемого файла представлена на рисунке 2.6 и условно состоит из двух частей:

1) заголовков исполняемого файла и сжатого или зашифрованного тела оригинальной программы;

2) программного кода самого распаковщика.

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

Рис. 2.6. Типовая структура упакованного исполняемого файла

Этапы функционирования любого упаковщика следующие:

1) упаковщик "запоминает" точку входа в оригинальную программу для того, чтобы после завершения функционирования тела распаковщика корректно передать управление на первую инструкцию оригинальной программы;

2) сжимает тело программы (обычно структурному изменению подвергаются все секции файла, за исключением секции, в которой расположена директория ресурсов). При этом используются различные алгоритмы сжатия: JCALG, aPLib, LZW, LZMA и др.;

3) шифрует или кодирует сжатое тело программы. Обычно применяются следующие алгоритмы шифрования: DES, BlowFish, AES. Крайне редко используют различные алгоритмы простого кодирования данных: сложение по модулю 2 с некоторым числом или элементарные преобразования над данными: циклический сдвиг, сложение по модулю , вычитание или другие операции;

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

При запуске упакованного файла управление получает не основной код оригинальной программы, а код распаковщика, который сначала распаковывает оригинальную программу в оперативной памяти, а затем передает управление на первую инструкцию оригинальной программы.

Рассмотрим решение обратной задачи, суть которой сводится к тому, что исследователю или антивирусному средству представлен упакованный исполняемый файл для анализа, задача которого – извлечь код оригинальной программы.

Для данной задачи антивирусному средству необходимо решить следующие подзадачи:

1) определить факт упакованности исполняемого файла, идентифицировать тип упаковщика (производителя и версию упаковщика);

2) выбрать механизм распаковки в зависимости от типа упаковщика;

3) распаковать исполняемый файл;

4) передать распакованный виртуальный образ оригинальной программы для дальнейшего анализа на предмет зараженности.

Определение факта упакованости антивирусными компаниями проводится в настоящее время на основе двух методов:

1) сигнатурного метода, основанного на выделении последовательности байт и однозначно идентифицирующего тип распаковщика;

2) метода динамической распаковки исполняемого файла в безопасной среде выполнения.

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

1) изменение или уничтожение сигнатуры упаковщика путем замены команд процессора на эквивалентные и зашумления кода распаковщика, а также модификация сигнатуры упаковщика любым другим способом приводит к невозможности распаковки исполняемого файла. Программы, выполняющие такие преобразования, называются модификаторами исполняемых файлов (например, PeStub, PeHide);

2) целенаправленная замена сигнатуры упаковщика на сигнатуру другого упаковщика приводит к неправильному распознаванию типа упаковщика, и соответственно к некорректной распаковке декодируемого файла (например, PeStub, EPProt);

3) невозможность определения факта упакованности файла в случае применения полиморфного упаковщика (например, PolyOne);

4) невозможность распаковки уникального упаковщика (уникального, с той точки зрения, что он не известен антивирусной программе). В настоящее время разрабатывается множество "клонов" широко известных упаковщиков, поставляемых с исходными текстами (например, SHProtector разработан на базе YodaCrypt).

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

Разработка системы динамической распаковки исполняемых файлов включает в себя решение следующих задач:

1) определения факта упакованности исполняемого файла;

2) алгоритма выполнения тела распаковщика и виртуализации операционной среды, в которой происходит моделирование процесса выполнения исполняемого файла. Данная задача решается посредством разработки алгоритма, моделирующего процесс функционирования процессора спецификации IA 32 (разработки "виртуального" процессора), и реализации следующих элементов операционной системы: виртуального адресного пространства, загрузчика исполняемых файлов, подсистемы обработки структурных исключений, блоков формирования окружения процесса и первичного потока, а также эмуляции механизма вызова импортируемых функций;

3) идентификации факта того, что распаковщик закончил свое функционирование и необходимо произвести остановку процесса моделирования выполнения программы и запомнить новый адрес первой инструкции оригинальной программы в модифицированном виртуальном адресном пространстве. Данная задача была решена с учетом того, что после выполнения программного кода распаковщика необходимо восстановление состояния стека оригинальной программы, и только в этих условиях анализируемая программа будет функционировать корректно. Данное обстоятельство позволяет сформировать простой критерий прекращения функционирования "виртуального" процессора – после выполнения любой управляющей команды необходимо проверить наличие двух событий: изменились ли значения байт, расположенных по адресу перехода, по сравнению с первоначальным состоянием (в момент проецирования файла в адресное пространство) и восстановлен ли регистр-указатель на вершину стека ESP.

После распаковки анализируемой программы по новому адресу в модифицированном адресном пространстве располагается оригинальная программа, возможно, содержащая вредоносный код злоумышленника.

Для определения факта упакованности исполняемых файлов в настоящее время применяется энтропийный подход, который подразумевает расчет энтропии исполняемого файла и сравнение ее с граничным значением.

Для расчета значения энтропии некоторой секции i использовано следующее выражение:

,

где – вероятность появления байта со значением в секции .

Максимальное значение энтропии на множестве всех секций файла и есть искомое значение энтропии данного исполняемого файла. Исследования показали, что файл считается упакованным в случае, если

.

Дата добавления: 2014-12-27