Общая распаковка приложений для обнаружения вредоносных программ

Общая распаковка приложений для обнаружения вредоносных программ

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Уровень техники

Современная доставка кода приложения обычно включает в себя его сжатие с использованием процесса упаковки. При использовании процесса упаковки можно уменьшить размеры двоичных файлов, и многочисленные файлы можно объединить в один файл. Современные процессы упаковки создают "самораспаковывающиеся исполняемые модули", которые могут быть исполнены для распаковки содержимого упакованного кода. Иными словами, упакованный код непосредственно сопровождается секцией исполняемого кода, которая при исполнении приводит к "раздуванию" или к развертыванию упакованного кода. Соответственно, запуск самораспаковывающегося исполняемого модуля может привести к расширению исполняемого модуля упакованного кода на диске, в памяти или и то и другое.

Чтобы создать самораспаковывающийся исполняемый модуль при упаковке файла, можно использовать многие различные типы алгоритмов сжатия и технологий упаковки. Некоторые из них известны и задокументированы, тогда как другие нет. Применение различных технологий в отношении одного и того же файла для создания самораспаковывающегося исполняемого модуля приведет к различным файлам – как код упаковки, так и упакованный код могут отличаться из-за различных упаковщиков и различных результатов, получаемых при использовании различных алгоритмов сжатия. Кроме того, если неизвестные и незадокументированные технологии используются для упаковки файла в самораспаковывающийся исполняемый модуль, это может затруднить даже определение различия между кодом упаковки и упакованным кодом.

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

Чтобы попытаться преодолеть эти усилия по сокрытию вредоносной программы, антивирусной программы и программы, обнаруживающей вредоносную программу, можно использовать многочисленные технологии. Одна технология состоит в том, чтобы извлекать упакованный код в памяти без его исполнения и затем попытаться просканировать несжатый двоичный файл для сигнатур вредоносной программы. Упакованный код можно извлечь путем эмуляции его исполнения или, если известен алгоритм упаковки, выполнения извлечения с помощью антивирусной программы. Если технология упаковки известна или задокументирована, извлечение упакованного кода под управлением антивирусной программы может оказаться невозможным. К тому же многие алгоритмы упаковки используют антиэмуляционные и противоотладочные технологии, чтобы просто завершить процесс распаковки после обнаружения выполнения распаковки распаковщиком или через эмуляцию исполнения. Части назначения временных меток кодового потока представляют собой стандартный способ, который можно использовать для определения эмуляции кода. Аналогичным образом, идентифицируют, что код отлаживается, можно легко определить путем опроса операционной системы.

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

Другая технология преодоления усилий, направленных на то, чтобы скрыть вредоносную программу, состоит в добавлении сигнатур известных самораспаковывающихся исполняемых модулей, которые содержат вредоносную программу в антивирусной базе данных сигнатур после того, как идентифицирована такая новая сигнатура упакованной вредоносной программы. Недостаток этой технологии состоит в том, что можно легко избежать, что ее можно легко "обойти" путем незначительного изменения кода упаковщика или технологии изменения, что приводит к другому самораспаковывающемуся исполняемому модулю и, таким образом, к другой сигнатуре. Добавление сигнатур с учетом этих различий в технологиях упаковки в антивирусную базу данных сигнатур служит для увеличения размера базы данных сигнатур. Это приводит к проблеме, которая заключается в том, что число сигнатур и трудность поддержания файлов сигнатур может соответствующим образом увеличиться. Кроме того, эти усилия могут быть в дальнейшем сведены на нет, так как процесс упаковки можно повторять любое число раз, используя различные алгоритмы упаковки в различных порядках, создавая при этом даже большее количество сигнатур для идентификации и поддержания.

Краткое описание чертежей

На фиг.1 показана блок-схема 100, иллюстрирующая упрощенную структуру исполняемого файла 101 и сжатый самоизвлекающийся исполняемый модуль 102 (предположительно меньшего размера), как известно в данной области техники.

На фиг.2 показана блок-схема, иллюстрирующая сетевую архитектуру 300, выполненную с возможностью выполнения одного или более раскрытых вариантов осуществления.

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

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

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

На фиг.6A показана блок-схема последовательности операций, иллюстрирующая технологию установки разрешений для страницы памяти и нарушений разрешений для страницы памяти адреса для управления доступом памяти к страницам памяти во время общей распаковки и фаз исполнения исполняемого модуля согласно одному или более раскрытым вариантам осуществления.

На фиг.6B иллюстрирует диаграмму 650 состояний, которая показывает переходы состояний для управляемого исполнения исполняемого модуля из своего двоичного времени загрузки в завершение его исполнения.

На фиг.7 показана блок-схема, иллюстрирующая стадии разрешений для страницы памяти во время общей распаковки и фаз исполнения и исполняемого модуля согласно одному или более раскрытым вариантам осуществления.

Подробное описание изобретения

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

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

Как будет дополнительно объяснено ниже, раскрытые технологии направлены на эти и другие проблемы с помощью систем и способов общей распаковки однократно или многократно упакованного приложения управляемым образом с целью обнаружения вредоносной программы. Общая распаковка упакованного приложения позволяет распаковать приложение независимо от знания алгоритма распаковки и независимо от знания реализации фиктивного модуля распаковки. Функциональные возможности, связанные с виртуализацией с аппаратной поддержкой, можно использовать для облегчения общей распаковки упакованного приложения управляемым образом. Эти технологии позволяют снизить или устранить необходимость в поддержании множества сигнатур для одного типа вредоносной программы.

Ссылаясь на фиг.1, блок-схема 100 иллюстрирует внутренние секции в двух файлах – исполняемый файл и упакованная версия этого файла согласно предшествующему уровню техники. Общий исполняемый модуль 101 представляет собой исполняемый двоичный файл в расширенном (то есть во время исполнения) в виде. Упакованный исполняемый модуль 102, который представляет собой результат общего исполняемого модуля 101, который модифицируется в процессе упаковки, также проиллюстрирован. Исполняемый модуль 101 был создан разработчиком, который выполняет процесс компиляции и связи над исходным кодом, объектными файлами и библиотеками. Исполняемый модуль 101 можно организовать в виде трех различных секций. Заголовок 105 двоичного файла содержит информацию относительно организации оставшейся части исполняемого двоичного файла, включающего в себя секцию(и) 110 кода и секцию(и) 115 данных. Заголовок 105 двоичного файла также включает в себя разрешения для памяти для всех секций, включенных в файл, который будет приводиться в исполнение загрузчиком операционной системы при загрузке исполняемого модуля 101 в память. После загрузки в память каждая секция начинается на границе страницы памяти, которая определена операционной системой. Секция из файла не должна охватывать только одну страницу памяти, а скорее всего каждая секция может занимать целое число страниц.

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

Упаковщик может упаковать и сжать исполняемый файл 101, чтобы создать упакованный исполняемый файл 102, что упоминается здесь как процесс упаковки. Типичные упаковщики могут выполнять сложные и уникальные операции, но почти все упаковщики выполняют относительно простой набор операций, с точки зрения высокого уровня, как будет описано ниже. При создании упакованного исполняемого модуля 102, процесс упаковки сжимает секцию(и) 110 кода и секцию(и) 115 данных исполняемого модуля 101 с использованием алгоритма сжатия по отношению к секциям. Обычно это выполняется в первую очередь при попытке уменьшить размер файла исполняемого модуля, но, как и в случае вредоносной программы, это в первую очередь выполняется для изменения сигнатуры вредоносной программы. После сжатия секций их можно разместить в новой секции, упаковать код и данные 135 в упакованном исполняемом файле 102. Альтернативно, упаковщики могут упаковать код и данные в одной и той же секции, в которой содержится распаковывающий код. Таким образом, секция 130 кода упаковщика и упакованные код и данные 135 могут находиться в отдельных секциях или в одной секции.

Процесс упаковки также типично создает виртуальную секцию 125 кода заданного размера, который будет занимать память при исполнении. Этот размер обычно вычисляется таким образом, чтобы быть большим или равным размеру несжатого упакованного кода и данных 135, как это будет обнаружено в исходном исполняемом модуле 101. Так как виртуальная секция 125 кода представляет собой секцию, предназначенную для несжатых данных памяти, она не должна занимать какое-либо пространство в непосредственно упакованном исполняемом модуле 102. Скорее всего, ее размер в файле, содержащем упакованный исполняемый модуль 102, можно представить в виде числа страниц памяти, необходимых в памяти перед исполнением процесса распаковки кода упаковщика. Подробности виртуальной секции 125 кода точно определены в измененном заголовке 120 двоичного файла с помощью кода преобразования упаковщика. Когда двоичный исполняемый модуль будет загружаться в память с помощью операционной системы, число страниц памяти, которые будут занимать конкретную секцию в памяти, также обычно определяется заголовке (например, 105 или 120) двоичного файла. Поэтому даже в том случае, если размер секции исполняемого файла на диске равен нулю, то секция может занимать некоторое пространство в памяти после загрузки операционной системой. Таким образом, процесс упаковки уменьшает размер всего двоичного файла (то есть размер диска и размер загрузки) путем сжатия кода и данных, но предусмотрел адекватную память для удержания несжатого кода и данных после распаковки в памяти при исполнении.

В качестве альтернативы, вместо использования секции 125 виртуального кода, фиктивный модуль распаковщика, который находится в секции 130 кода упаковщика, может выделить достаточную память для процесса во время исполнения для удержания несжатого кода и данных при распаковке в памяти. Однако фиктивный модуль распаковщика должен по-прежнему маркировать эти страницы памяти в виде исполняемого модуля для их исполнения, и это можно контролировать. Поэтому, после начала исполнения, если страницы памяти выделены с помощью разрешений на исполнение, эти страницы памяти можно идентифицировать как возможно содержащие несжатые код и данные. Если используется эта технология для выделения памяти, диапазон выделенной памяти можно идентифицировать путем контроля выделения памяти, и диапазон выделенной памяти можно рассматривать в качестве секции 125 виртуального кода. Так как большинство упаковщиков применяют технологию использования секции 125 виртуального кода в виде полей для заполнения для несжатых кода и данных, эта технология рассмотрена в приведенных ниже примерах.

Секция 130 кода упаковщика представляет собой новую секцию кода, добавленную в упакованный исполняемый модуль 102, который содержит код фиктивного модуля распаковщика во время исполнения. Этот фиктивный модуль распаковщика будет считывать упакованные код и данные из секции 135 упакованных кода и данных, распаковывает его и размещает его в секции 125 виртуального кода. Более конкретно, распакованный код может размещаться в памяти, выделенной для удержания секции виртуального кода. Во время первоначального процесса распаковки заголовок 105 двоичного файла модифицируется в заголовок 120 двоичного файла, чтобы убедиться, что поле точки входа заголовка будет способствовать применению фиктивного модуля распаковщика в секции 135 кода упаковщика.

Упаковку, передачу и последующую распаковку исполняемого модуля можно выполнить в контексте сетевой инфраструктуры. Обратимся теперь к фиг.2, на которой схематично показана инфраструктура 200. Инфраструктура 200 содержит компьютерные сети 202. Компьютерные сети 202 включают в себя многочисленные различные типы компьютерных сетей, доступных сегодня, таких как Интернет, корпоративная сеть или локально-вычислительная сеть (LAN). Каждая из этих сетей может содержать проводные или беспроводные устройства и работать с использованием любого числа сетевых протоколов (например, TCP/IP). Сети 202 подсоединены к шлюзами и маршрутизаторам (обозначенным поз.208), компьютерам 206 конечных пользователей и компьютерным серверам 204. В инфраструктуре 200 также показана сотовая сеть 203 для использования с сотовой связью. Как известно в данной области техники, сотовые сети поддерживают сотовые телефоны и многие другие типы устройств (например, планшетные компьютеры, которые не показаны). Сотовые устройства в инфраструктуре 200 проиллюстрированы в виде сотовых телефонов 210. Любое из устройств, показанных в инфраструктуре 200, может пытаться исполнить самоизвлекающийся исполняемый модуль. Если процессор устройства включает в себя необходимые возможности, то он позволяет реализовать концепции настоящего раскрытия. Инфраструктура 200 является иллюстративной и показана только в качестве примера, и при необходимости в раскрытых технологиях можно использовать другие инфраструктуры.

Обратимся теперь к фиг.3, на которой проиллюстрировано в виде блок-схемы примерное устройство 300 обработки для использования в раскрытых технологиях способов согласно различным вариантам осуществления. Устройство 300 обработки можно реализовать в различных устройствах, таких как сотовый телефон 210, шлюз или маршрутизатор 208, клиентский компьютер 206 или компьютерные серверы 204. Примерное устройство 300 обработки содержит системный блок 305, который можно опционально подсоединить к устройству 330 ввода (например, к клавиатуре, мыши, сенсорному экрану и т.д.) и к дисплею 335. Устройство 340 хранения программ (PSD) (которое иногда упоминается как жесткий диск, флэш-память или машиночитаемый носитель информации) включается с помощью системного блока 305. Кроме того, включенным с помощью системного блока 305 может быть сетевой интерфейс 320 для связи через сеть (такую как сотовая сеть 203 или компьютерная сеть 202) с другими вычислительными и корпоративными инфраструктурными устройствами (не показаны) или другими сотовыми устройствами связи. Сетевой интерфейс 320 может быть включенным в системный блок 305 или внешним по отношению к системному блоку 305. В любом случае, системный блок 305 коммуникативно связан с сетевым интерфейсом 320. Устройство 340 хранения программ представляет собой любую форму энергонезависимого запоминающего устройства, включающего в себя, но не ограниченного этим, все формы оптической и магнитной памяти, в том числе твердотельной, элементы хранения, в том числе съемные носители информации, и могут быть включены в системный блок 305 или быть внешними по отношению к системному блоку 305. Устройство 340 хранения программ можно использовать для хранения программного обеспечения в управляющем системном блоке 305, данных, которые используются устройством 300 обработки или обоими.

Системный блок 305 можно запрограммировать на выполнение способов в соответствии с раскрытием. Системный блок 305 содержит один или более блоков обработки (представленных с помощью блока обработки или процессора 310), шину 325 ввода-вывода (I/O) и память 315. Доступ к памяти 315 может осуществляться с использованием шины 325 связи. Блок 310 обработки может включать в себя любое программируемое устройство контроллера, в том числе, например, электронно-вычислительные машины, процессор сотового телефона или один или более элементов из семейства процессоров INTEL^® ATOM™, INTEL^® CORE™, PENTIUM^® и CELERON^®, выпускаемых корпорацией Intel, и семейства процессоров Cortex и ARM, выпускаемых корпорацией АРМ (ARM). (INTEL, INTEL ATOM, CORE, PENTIUM, и CELERON представляют собой зарегистрированные торговые знаки корпорации Intel. CORTEX – зарегистрированный торговый знак корпорации ARM Limited Corporation. АРМ – зарегистрированный торговый знак компании ARM Limited Company). Память 315 может включать в себя один или более модулей памяти и содержать оперативное запоминающее устройство (RAM), постоянное запоминающее устройство (ROM), программируемое постоянное запоминающее устройство (PROM), программируемую память с оперативной записью и считыванием и твердотельную память. Блок 310 обработки может также включать в себя некоторую внутреннюю память, включающую в себя, например, кэш-память или память, выделенную для конкретного блока обработки и изолированную от других блоков обработки для использования при распаковке исполняемого двоичного файла.

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

При подготовке к выполнению раскрытых вариантов осуществления на устройстве 300 обработки, программные инструкции для конфигурации устройства 300 обработки в целях выполнения раскрытых вариантов осуществления могут храниться на любом типе постоянных машиночитаемых носителей информации или могут загружаться с сервера 204 в устройство 340 хранения программ. Несмотря на то, что на фиг. 4 изображено одно устройство 300 обработки, в устройстве, сконфигурированном согласно раскрытым вариантам осуществления, можно использовать любое число устройств 300 обработки.

Виртуализация с аппаратной поддержкой

Визуализация представляет собой особенность, которая позволяет компьютерной системе или устройству запускать многочисленные операционные системы параллельно без внесения каких-либо изменений в код операционной системы. Этот тип визуализации можно отличить от паравиртуализации, которая требует внесения изменений в размещенных операционных системах. Многие современные процессоры, исполняемые запросы потребителей, поддерживают виртуализацию с аппаратной поддержкой. Как показано на фиг.4, монитор 420 виртуальных машин (VMM), который также может быть известен как уровень гипервизора, представляет собой уровень программного обеспечения, который размещается между системными аппаратными средствами 410 (которые могут представлять собой, например, устройство 300 обработки (фиг.3)) и одну или более операционных систем ("OS") 430. Что касается виртуализированных систем, OS 430 можно называть "гостевой" OS 430. В отношении систем, которые не используют виртуализации, OS 430 типично взаимодействуют непосредственно с аппаратными средствами 410. При использовании виртуализации OS 430 взаимодействует с аппаратными средствами 410 через VMM 420. VMM 420 позволяет поддерживать многочисленные OS (такие как три OS 430, иллюстрированные на фиг.4) и назначают каждой OS 430 выделенный или совместно используемый доступ к ресурсам системы. Таким образом, каждая OS 430 может работать одновременно с другими OS 430. Кроме того, каждая OS 430 может работать с несколькими приложениями, такими как приложения 440, иллюстрированные, как работающие под OS 430 (фиг.4).

В системах без виртуализации ядра OS обычно исполняет на самом высоком уровне привилегий, который выше другого программного обеспечения, исполняющего в системе. При виртуализации VMM 420 может использовать особенности аппаратной виртуализации процессора и работает при привилегии даже выше ядра OS. С помощью виртуализации с аппаратной поддержкой можно обеспечить выполнение разрешений доступа к странице памяти с помощью VMM 420. Соответственно, VMM 420 позволяет устанавливать разрешения на считывание/запись/ исполнение на страницах физической памяти. Каждая страница памяти может устанавливать разрешение/запрет для привилегий на считывание, запись и исполнение. Разрешения устанавливаются с помощью VMM 420 для исполняющейся OS 430 в системе. Если OS 430 нарушает разрешения для каждой заданной страницы памяти, управление передается непосредственно в предварительно определенное местоположение в VMM 420, приостанавливая эту OS 430. VMM 420 можно обеспечить общим распаковщиком 422, который будет помогать анализировать, категоризировать и сканировать исполняемый модуль во время исполнения в памяти после нарушений разрешений доступа к странице. Общий распаковщик 422 может содержать эвристический движок 424, сканер 426 и базу данных или память, содержащую данные 428 статистики эвристики.

Когда OS 430 запрашивает доступ к странице памяти, процессор 310 будет проверять разрешения доступа к странице памяти перед разрешением запрашиваемого типа доступа. Соответственно, процессор 310 не разрешает какое-либо исполнение из страницы памяти, если страница не имеет набора разрешений на исполнение. При компиляции программы программист может специально установить другие разрешения для страниц секции, например, используя директивы компилятора. Обратимся снова к фиг.1, на которой секция(и) 110 кода требуется по меньшей мере для того, чтобы считывать и исполнять наборы разрешений для своих страниц памяти. В противном случае во время исполнения исполняемый модуль 101 может вырабатывать отказы для предотвращения исполнения данных на исполняющем процессоре, если включена защита исполнения данных. Секция(и) 115 данных требуется для того, чтобы иметь по меньшей мере набор разрешений на считывание для своих страниц после загрузки в память. Однако и оба разрешения на считывание и запись можно установить для секции данных.

Общая распаковка с использованием виртуализации с аппаратной поддержкой

Для того чтобы обеспечить гибкое решение, которое работает во всех многочисленных упаковщиках и алгоритмах упаковки – известных или неизвестных – и ограничить трудности, связанные с распаковкой упакованного исполняемого модуля, управляемый способ позволяет обеспечить общую распаковку упакованного исполняемого модуля без конкретного знания распаковщика или алгоритма распаковки. Фиг.5 демонстрирует способ 500, в котором упакованный исполняемый модуль доставляется в целевой компьютер и начинает исполнение. На этапе 505 самоизвлекающийся исполняемый файл поступает в целевую машину в упакованном или многократно упакованном формате. На данный момент файл можно просканировать известные сигнатуры на этапе 510, чтобы увидеть совпадает ли он с какой-либо известной вредоносной программой. Однако, как описано выше, обнаружение вредоносной программы в этой точке может быть неудачным в отношении каких-либо неидентифицированных упакованных исполняемых модулей. на этапе 515 файл начинает исполнение. В этот момент сегмент кода распаковщика двоичного файла (например, секция 130 кода упаковщика, показанная на фиг.1) начинает исполнение. На этапе 520 процесс распаковки продолжается. Если файл был многократно упакован, то его необходимо многократно распаковать, как показано на этапе 525. После завершения этого процесса распаковки открывается исходный исполняемый модуль двоичного файла. Как показано на этапе 530, в данный момент, в который было завершено исполнение кода распаковщика, и исходный исполняемый модуль еще не начал исполнение, можно выполнить другое сканирование сигнатур. Другими словами, как показано на этапе 530, общая распаковка разрешит исполнение упакованного исполняемого модуля и предотвратит использование перед или только перед передачей управляющего сигнала в исходную точку входа ("OEP") исходного исполняемого модуля, показанного на этапе 535. Исходная точка входа представляет собой точку входа, которая точно определена в заголовке двоичного файла исполняемого двоичного файла, когда он находился в своем исходном распакованном виде. Как было отмечено выше, эмулированное исполнение можно использовать для получения на этом этапе, но существует много упаковщиков, которые содержат антиэмуляционный код, который предотвращает дальнейшее исполнение процесса распаковки после обнаружения того, что код упаковщика является эмулированным.

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

Управляемое исполнение двоичного файла: виртуализация с аппаратной поддержкой

Захват вредоносной программы непосредственно перед тем, как управление передается в OEP, является целью любого решения относительно общей распаковки. Чтобы достичь этого этапа, распаковывающий код исполняется управляемым образом, и пространство памяти исполняемого модуля сканируется и сравнивается с сигнатурами через одинаковые промежутки времени.

Управляемое исполнение можно добиться с помощью виртуализации с аппаратной поддержкой. Как обсуждено выше, VMM 420, который исполняется на самом высоком уровне привилегий, может установить защиты доступа к считыванию/записи/исполнению (R/W/X) при детализации уровня страницы для доступов к странице OS. Этот механизм установки защит памяти на страницах OS для доступов OS можно использовать для установки защит в секциях упакованного исполняемого модуля и связанной с ним памяти. Всякий раз при возникновении нарушений разрешений доступа к странице, VMM 420 получает управление исполнением и может эвристически проверить, произойдет ли передача OEP или произошла ли достаточная распаковка. На этом этапе можно выполнить сканирование сигнатур вредоносных программ или можно выполнить другие технологии обнаружения вредоносных программ.

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

Ссылаясь на фиг.6A, блок-схема 600 демонстрирует способ управления исполнением самоизвлекающегося исполняемого модуля. Во время 605 загрузки двоичного файла проводится детальный анализ всех секций в заголовке упакованного исполняемого двоичного файла. На этапе 610, где секции маркируются как исполняемые и записываемые (RWX) в заголовке двоичного файла, разрешения на считывание и исполнение (R_X) назначаются с использованием VMM 420 на страницах, связанных с этой секцией, в памяти. Разрешения на запись удаляется для этих страниц. "RWX" и "R_X" являются примерами обозначения, показывающими установку одного или более разрешений на считывание, запись и исполнение. Если страницы этих секций попытаются исполнить в будущем без записи в них, то флаг не устанавливается. Однако, если страница одной из одной из этих секций исполняется после записи в нее, то существует вероятность того, что она представляет собой исходный распакованный код, который является исполняемым. Это связано с тем, что исходный код мог не записаться на странице памяти во время процесса распаковки (то есть доступа к записи), и последующее исполнение может показать, что исполняется исходный исполняемый модуль. В ситуации, когда файл был упакован много раз, запись может представлять собой запись этого следующего уровня распаковывающего кода на странице памяти, и, таким образом, последующее исполнение не будет представлять собой исходный исполняемый модуль, а итерацию распаковывающего кода. В любом случае, этот период времени представляет собой этап, на котором можно выполнить сканирование вредоносной программы. Таким образом, доступ к записи на любой из этих страниц вырабатывает "vmexit", и управление передается VMM 420.

"vmexit" представляет собой механизм виртуализации с аппаратной поддержкой, который передает управление из OS 430 в VMM 420. В то время как управление осуществляется с помощью VMM 420, можно записать состояние регистров процессора, указатель стека и другие состояния, относящиеся к исполнению кода распаковщика. После записи состояний и выполнения других задачи (например, выработка данных эвристики, сканирование), управление может быть передано обратно в OS 430, которое выработало vmexit, или может быть передано подпрограмме для обработки ошибок.

На этапе 615 можно идентифицировать страницу, которая содержит точку входа самоизвлекающегося исполняемого модуля, и разрешения для этой страницы должны быть установлены как только считывание (R__). После того как все разрешения в памяти страницы были установлены с помощью VMM 420, управление возвращается в OS 430 на этапе 620. В ходе исполнения точки входа будет вырабатываться vmexit во время нарушения исполнения точки входа, как показано на этапе 625, и управление перейдет к VMM 420. Соответственно, на этом этапе значение указателя стека и содержимое стека, предс