СПОСОБ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ РАБОТЫ АППАРАТНОГО УСКОРЕНИЯ ЭМУЛЯЦИИ ПРИЛОЖЕНИЙ

Область техники

Изобретение относится к антивирусным решениям, а более конкретно к способам повышения эффективности работы аппаратного ускорения эмуляции приложений.

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

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

Рассмотрим пример последовательности выполнения приложения, показанный на Фиг.1. Последовательность выполнения программы складывается из так называемых базовых блоков, т.е. последовательности машинных инструкций, выполняемых до первого перехода (передачи управления). На Фиг.1 в виде прямоугольников с содержащимися в них инструкциями схематически отображены базовые блоки, связанные между собой переходами, как условными, так и безусловными. На языке ассемблера инструкциями могут быть такие команды, как MOV, ADD, LEA и другие; в качестве примеров условных переходов могут быть приведены инструкции JZ или JNA; в качестве примера инструкции безусловного перехода - JMP. Важно отметить, что большая часть кода выполняется не один раз, а несколько: это связано с тем, что выполнение кода по большей части представляет собой выполнение циклов и подпрограмм. Особенно актуально это для вредоносных приложений, в которых присутствует упаковка (сжатие) кода ("Compiler Techniques for Code Compaction" by Saumya Debray, William Evans, Robert Muth and Bjorn De Sutter) с последующей распаковкой кода при непосредственном выполнении, что требует большого количества циклических операций.

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

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

Исходная инструкция:

mov eax, [edi]

Оттранслированный псевдокод состоит из следующего набора шагов:

1. Чтение edi;

2. Чтение памяти по адресу, полученному в 1-й операции;

3. Запись в еах значения, считанного из памяти во 2-й операции. Кроме того, каждый шаг подобного псевдокода будет содержать

определенное количество машинных инструкций, в результате чего одна исходная инструкция при трансляции приводит к выполнению десятков и даже сотен инструкций на процессоре. Отметим, что однажды оттранслированный код при повторном исполнении не требуется транслировать заново, так как операция по трансляции кода уже была выполнена. Учитывая, что большая часть кода выполняется в рамках циклов, динамическая трансляция активно используется для процессов эмуляции уже достаточно давно и подробно раскрыта в таких публикациях, как US80603 56, US5751982, US6631514, US20030093775.

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

Однако подобный подход также включает недостаток, связанный с тем, что выполнение инструкций на реальном процессоре прекращается, например, при вызове исключения или API-функции. Далее под исключением будет подразумеваться исключительная ситуация, возникшая при выполнении программы (например, деление на ноль, ошибка чтения страницы памяти, неверный код машинной команды и т.д.), а под вызовом API-функцией - вызов одной из базовых функций интерфейсов программирования приложений операционных систем (например, для ОС Windows это будет Win32 API). С учетом того, что процесс инициализации ускорителя эмуляции, описанного в патенте US7603713, достаточно ресурсоемок (код ускорителя работает в режиме ядра), эффективность работы ускорителя может быть низкой в том случае, если после своей ресурсоемкой инициализации он выполнит всего несколько инструкций на реальном процессоре, после чего последует исключение или вызов API-функции, что приведет к возврату обработки инструкций в стандартный эмулятор и необходимости инициализировать ускоритель в следующий раз снова.

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

Раскрытие изобретения

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

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

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

,

где N - количество тактов процессора, которое ушло на обработку инструкций с помощью ускорителя, а

K - известное количество тактов процессора, за которое происходит перевод процесса эмуляции из эмулятора в ускоритель.

В еще одном частном варианте реализации используют динамическую трансляцию кода при низком значении эффективности.

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

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

Фиг.1 иллюстрирует пример последовательности выполнения приложения в виде базовых блоков.

Фиг.2 изображает применение системы аппаратного ускорения эмуляции приложений в рамках реализации, описанной в уровне техники.

Фиг.3 показывает систему, которая лежит в основе реализации настоящего изобретения.

Фиг.4 иллюстрирует способ работы настоящего изобретения.

Фиг.5 представляет пример компьютерной системы общего назначения на которой может быть реализовано настоящее изобретение.

Описание вариантов осуществления изобретения

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

На Фиг.2 изображено применение системы ускорения выполнения инструкций исполняющейся программы в рамках реализации, описанной в патенте US7603713. Для реализации ускорения в рамках ускорителя 220 процесса 230 (который был создан из неизвестного исполняемого файла 205 при его эмуляции) состояние всех регистров виртуальной копии процессора внутри эмулятора 270 передается напрямую в хост компьютерной системы 210. Сам ускоритель 220 представляет некоторое изолированное пространство, в которое помещается контекст процесса (виртуальное адресное пространство процесса 230, потоки выполнения, открытые описатели ресурсов, таких как файлы или семафоры и т.д.) 230 для последующего выполнения в рамках хоста операционной системы 210, практически как в случае реального процесса, используя реальные ресурсы, такие как центральный процессор 240 и оперативную память 250. Некоторое количество времени инструкции процесса 230 исполняются на процессоре до вызова исключения или API-функции, при которых управление возвращается эмулятору 270. Помимо вызова исключения или API-функции также в возвращению управления в эмулятор приводят любые исключения процессора, а также исполнение инструкции RDTSC, подкачка страницы памяти. При возникновении подобных ситуаций управление передается обратно в эмулятор 270. Часть инструкций, таких как привилегированные инструкции, RDTSC, эмулируются в обычном режиме без использования ускорителя 220. К привилегированным инструкциям относятся операции ввода-вывода к периферийным устройствам, загрузка и сохранение управляющих регистров, сброс флага переключения задачи и т.д.

Анализ процесса начинается в эмуляторе, где обрабатываются первые N инструкций. N - параметр проверки, который выбирается экспертом. Это число может составлять от 100 до 10000 инструкций. При этом эвристический анализатор, как правило, после каждой инструкции, группы инструкций или по окончанию исполнения проверяет сходство выполняемого кода данного процесса с поведенческими сигнатурами известных вредоносных приложений. Сравнение происходит на основании отчета об исполнении (точнее, эмуляции исполнения) процесса, который составляет эмулятор. По отчету исполнения процесс классифицируется - в зависимости от действий процессу присваивается статус безопасного или вредоносного.

Если в результате первых N инструкций не обнаружено опасных признаков, эмулятор отправляет процесс в ускоритель. Состояние виртуального процессора и виртуальной памяти загружают в реальную систему для неразрывности исполнения процесса, после чего процесс продолжает выполнение на реальной скорости работы процессора.

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

Для решения вышеуказанной проблемы используются улучшения, которые включены в эмулятор и отображены в виде системы на Фиг.3, которая лежит в основе реализации настоящего изобретения. В рамках этой системы эмулятор также включает модуль динамической трансляции 310 и модуль оценки эффективности 320. Модуль динамической трансляции 310 осуществляет динамическую трансляцию инструкций кода неизвестного файла 205, после чего оттранслированный код сохраняется в памяти для последующего вызова. Модуль оценки эффективности 320 позволяет оценить, насколько эффективно отработал ускоритель 220. В одном из вариантов реализации эффективность Е может оцениваться по следующей формуле:

,

где N - количество тактов процессора, которое ушло на обработку инструкций с помощью ускорителя 220, а

K - известное количество тактов процессора, за которое происходит перевод процесса эмуляции из эмулятора 270 в ускоритель 220. Очевидно, что если Е меньше единицы или лишь немного превышает ее, то работа ускорителя 220 неэффективна. Высокая эффективность достигается, когда величина Е значительно больше единицы, т.е. "включение" ускорителя 220 было оправдано большим количеством инструкций, которые были обработаны с его помощью. В качестве примера высокого значения эффективности можно привести значение Е>10, т.е. для некоторых вредоносных приложений повышение эффективности работы ускорителя может быть увеличено в десятки раз.

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

Стоит отметить, что модуль динамической трансляции 310, который осуществляет динамическую трансляцию инструкций кода неизвестного файла 205, может выполнять данную операцию только для тех базовых блоков, на которых эффективность Е не была достаточно высокой и использование ускорителя нецелесообразно.

Фиг.4 иллюстрирует способ работы настоящего изобретения. На этапе 410 неизвестный файл 205 передается на эмуляцию, и на этапе 420 начинается динамическая трансляция инструкций с помощью модуля динамической трансляции 310. По мере того, как происходит эмуляция инструкций (уже оттранслированных на этапе 420) на этапе 430, на определенном этапе происходит выполнение условий запуска ускорителя (этап 440). На начальном этапе таким условием может быть эмуляция определенного количества инструкций (например, количество может варьироваться от 100 до 10000 инструкций), и если при этом не было обнаружено опасных признаков, то для ускорения процесса эмуляции подключается ускоритель 220, который работает на этапе 450 пока не произойдет, например, вызов исключения или вызова API-функции, что приведет к возврату обработки инструкций в эмулятор 270. После этого на этапе 460 происходит оценка эффективности работы ускорителя 220 и изменение условий его запуска на этапе 470. Изменение условий запуска ускорителя 220, например, предполагает:

- указание определенных базовых блоков, которые могут быть исполнены с использованием ускорителя 220 (на Фиг.1 видно, что выполнение кода по большей части представляет собой выполнение базовых блоков в виде циклов и подпрограмм, при этом только на определенной части блоков ускоритель будет эффективен);

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

Фиг.5 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг.6. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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