СИСТЕМА УСКОРЕНИЯ ЭМУЛЯЦИИ ПРОЦЕССОВ

Область техники
Настоящая полезная модель относится к системам обнаружения вредоносных программ, и более конкретно к устройствам для сокращения времени выполнения эмуляции программ.
Уровень техники
Структура современных программ, в том числе вредоносных программ, представляет собой сложный набор инструкций: переходов, вызовов, циклов и т.д. С развитием микропроцессорной техники увеличивается сложность исполняемых файлов. Количество инструкций может превышать несколько миллионов. Это относится как к доверенным программам, так и к вредоносным.
Вирусописатели часто используют специальные методы усложнения инструкций, именуемые обфускаторами, которые добавляют к исходному коду инструкции, которые не несут функциональной нагрузки. Такие инструкции называют пустыми. Это делается для затруднения декомпиляции, анализа и для невозможности их детектирования средствами антивирусной защиты. Одним из методов исследования потенциально вредоносной программы является эмулятор, который анализирует поведение программы, выполняя ее инструкции в защищенной среде.
Основная проблема существующих эмуляторов - это проблема скорости выполнения эмуляции программ. При выполнении большого количества инструкций исполняемой программы на эмулированном процессоре и эмулированной оперативной памяти производительность их исполнения становится гораздо медленнее, чем если бы они исполнялись на реальных вычислительных ресурсах компьютерной системы.
Скорость исполнения эмулируемого кода крайне важна, т.к. современные вирусы часто могут содержать большое количество исполняемых инструкций. Более того, многие вредоносные компоненты разработаны таким образом, что при запуске на компьютере они, в первую очередь, запускают большое количество процессов, которые являются по сути безопасными. Основная цель этих процессов заключается в том, чтобы затормозить работу эмулятора и увеличить нагрузку на вычислительные ресурсы до уровня, когда система не сможет эффективно эмулировать вредоносные процессы, следующие за ними.
Дополнительные безопасные, по сути безопасные, процессы могут совершать миллионы бессмысленных операций, которые задерживают эмуляцию процессов на время от нескольких секунд до нескольких минут, что составляет очень значительный отрезок времени в обнаружении вредоносной программы. Такие бессмысленные операции часто называют «пустые циклы». Например, такой процесс как распаковка может потребовать довольно большое количество времени, расчет значения π с высокой точностью является очень интенсивным процессом и может быть совершенно не относящимся к целям программы, а предназначенным для загрузки ЦП и эмулятора. Эта идея может быть применена и для других интенсивных процессов, таких как распаковка, расшифровка и т.д. Для эффективного обнаружения вредоносной программы, эмуляция должна проходить не дольше чем несколько секунд, а иногда не более 1-2 секунд. Таким образом, эмулятор будет выполнять только пустые циклы (или часть из них) и остановит работу до того, как дойдет до эмуляции процедур, способных нанести вред. Поэтому эмуляция вредоносных компонент останавливается до наступления опасного кода, что является серьезной проблемой для компьютерной безопасности, так как некоторые вредоносные программы могут быть пропущены во время эмуляции. Соответственно задача ускорения эмуляции программ является актуальной в настоящее время.
В патенте US 6882968 раскрывается система эмуляции процесса на заданной скорости исполнения. Но такая система не отвечает основным требованиям безопасности, когда не все процессы могут быть исполнены на реальном процессоре, поскольку это может привести к заражению и неисправности компьютерной системы.
В патенте US 5946472 описывается ускоритель, выполняющий параллельные инструкции. Такое устройство моделирует последовательные процессоры. Ключевая особенность описанной в этом патенте системы заключается в том, что эмулятор работает медленнее, чем используемый процессор, поскольку код исполняется не на реальном процессоре.
В силу раскрытых обстоятельств становится ясно, что необходима новая система, позволяющая быстро обрабатывать большое количество безопасных инструкций, для того, чтобы приступить к эмуляции потенциально вредоносного кода.
Сущность полезной модели
Настоящая полезная модель предназначена для решения проблемы сокращения времения эмуляции процессов с целью обнаружения вредоносного компонента.
Техническим результатом настоящей полезной модели является сокращение времени эмуляции исполнения процессов за счет ускорителя, который передает часть кода на исполнение в центральный процессор. Описанная далее система позволяет исполнять код в реальном процессоре, что сокращает время анализа всего процесса в эмуляторе. Системе ускорения эмуляции процессов содержит: (а) набор процессов, загруженных в память и выполняемых в процессоре, часть из которых может содержать вредоносные инструкции; (б) эмулятор, предназначенный для эмуляции процессов, связанный с ускорителем эмулятора, которому эмулятор передает управление для обработки фрагмента инструкций процесса; (в) ускоритель эмулятора, предназначенный для сокращения времени эмуляции процессов, выполнения фрагмента инструкций, переданного от эмулятора, в процессоре путем загрузки инструкций процесса в память, обработки исключений и передачи управления эмулятору.
В частном варианте реализации эмулятор предназначен также для перехвата и загрузки запускаемого процесса в память эмулятора и исполнения инструкций в эмулированном процессоре.
Еще в одном частном варианте реализации при загрузке процесса из ускорителя в эмулятор, в память эмулятора копируются, по меньшей мере, регистры процессора, адресное пространство памяти; а при загрузке процесса в ускоритель копируются состояния эмулированного процессора в процессор и эмулированной памяти в память.
В другом частном варианте реализации эмулятор предназначен также для инициирования исполнения немодифицированного процесса в ускорителе эмулятора.
Частным вариантом реализации служит система, в которой эмулятор предназначен также для разделения немодифицированного процесса на фрагменты исполнения, начиная с определенного количества инструкций после точки входа и/или исключения в порядке исполнения инструкций и заканчивая появлением следующего исключения.
Примером данной системы может служить вариант реализации, в котором эмулятор предназначен также для установки ограничения по количеству инструкций на фрагмент и ограничения времени исполнении фрагмента для каждого фрагмента исполнения.
В одном из частных вариантов реализации ускоритель предназначен для остановки исполнения инструкций процесса при появлении исключений, включающих, по меньшей мере:
(а) исключение процессора;
(б) программные и аппаратные прерывания,
(в) нетипичное потребление ресурсов;
(г) подключение сопроцессора;
(д) превышение ограничения выделенного на фрагмент исполнения количества инструкций и/или времени его исполнения и/или выделенной памяти;
(е) RDTSC, SSE-инструкции;
(ж) дополнительная загрузка текущей страницы памяти;
(з) попытка исполнения привилегированных инструкций
(и) деление на ноль;
(к) попытки обращения к несуществующему адресу
(л) попытки изменения флагов или системных регистров
Примером данной системы также может служить вариант реализации, в котором ускоритель предназначен для самостоятельной обработки некоторых исключений, включающих, по меньшей мере:
#PF (PageFault, исключение 14);
#NM (NoMathCoprocessor, исключение 7);
#GP (GeneralProtection, исключение 13) если он вызван инструкцией RDTSC;
и исполнения фрагмента исполнения далее до появления исключения, которое ускоритель не способен обработать самостоятельно.
Другим примером данной системы служит вариант реализации, в котором ускоритель предназначен также для распаковки запакованных файлов и расшифровки зашифрованных файлов.
Еще одним примером данной системы может служить вариант реализации, в котором ускоритель предназначен также для контроля режима исполнения процесса, и при попытке перехода из менее привилегированного режима в более привилегированный режим, останавливает выполнение процесса в ускорителе.
Одним из частных вариантов реализации является система, в которой эмулятор предназначен также для записи результатов исполнения процесса до момента остановки процесса в ускорителе.
Примером данной системы может служить вариант реализации, в котором эмулятор предназначен также для создания отчета о результате эмуляции и исполнении процесса в ускорителе.
В еще одном частном варианте реализации эмулятор предназначен также для сравнения процесса с сигнатурами известных вредоносных компонент.
Краткое описание прилагаемых чертежей
Сопровождающие чертежи, которые включены для обеспечения дополнительного понимания полезной модели и составляют часть этого описания, показывают варианты осуществления полезной модели и совместно с описанием служат для объяснения вариантов осуществления полезной модели.
Заявленная полезная модель поясняется следующими чертежами, на которых:
Фиг.1 показывает структурную блок-схему системы, в которой может быть реализована настоящая полезная модель.
Фиг.2 показывает блок схема представления эмулятора компьютерной системы.
Фиг.3 показывает схему эмуляции с применением ускорителя в рамках настоящей полезной модели.
Фиг.4 показывает алгоритм работы системы эмуляции процессов.
Подробное описание предпочтительных вариантов осуществления
Чаще всего исполняемый файл содержит двоичное представление машинных инструкций для определенного процессора или инструкции на интерпретируемом языке программирования, которые интерпретатор или операционная система переводит в бинарный формат. Исполнением бинарных файлов занимаются аппаратно- и программно-реализованные машины. К первым относятся центральные процессоры, ко вторым - виртуальные машины. Формат бинарного файла определяется архитектурой исполняющей его машины. Основной объем программного кода состоит из инструкций. Зачастую исполняемые файлы содержат вызовы библиотечных функций, например, вызовы функций операционной системы. Помимо вызова функций, программа может содержать переходы, циклы и т.д.
Некоторые инструкции или набор инструкций характеризуют программу как вредоносную или потенциально опасную, а в некоторых случаях даже идентифицируют известную вредоносную программу. Однако остальные инструкции можно условно назвать «безопасными», т.к. они не несут в себе вредоносных функций и/или по ним не удастся определить характер исполняемого процесса. При этом необходимо выполнять инструкции в заданном порядке, чтобы не нарушить логическую последовательность и не упустить подозрительного «поведения программы». В связи с этим отсутствует возможность проверки отдельных инструкций.
Один из методов эвристического анализа - это анализ поведения программы. Для этого необходимо запустить ее на исполнение, но появляется возможность заражения. Эту проблему решает эмулятор, который изолирует выполнение программы от системы. Существуют различные способы эмуляции. Один из них это программная имитация процессора, памяти и других устройств, путем создания виртуальных копий регистров процессора, ячеек памяти и набора инструкций устройства (в частности процессора). Таким образом, инструкции программы исполняются не на реальном процессоре, а на его виртуальной копии, а обращения к ядру и областям памяти других процессов перехватывают и имитируют или пересылают (в случае «чтения») ответ. Эмулятор также характеризуется собственной скоростью работы и качеством детализации системы. Описанный эмулятор медленный потому, что исполнить инструкцию на настоящем процессоре намного быстрее, чем исполнить подпрограмму, эмулирующую эту инструкцию и состоящую из множества команд.
Система безопасности должна проанализировать все неизвестные программы, которые отсутствуют в списке доверенных программ, а так же постоянно анализировать программы, обладающие возможностью интерпретации кода, такие как браузер, офисные приложения с возможностью запуска макросов и сценариев и другие. В результате, если эмулятор будет проверять все инструкции каждой анализируемой программы - система будет сильно загружена, что противоречит фактору доступности информации. Для того чтобы подобное не происходило, эмулятор ограничивают: определяют количество исполняемых инструкций и/или время эмуляции для каждого процесса или части процесса.
Вирусописатели знают, что загрузив систему большим количеством вызовов программ или пустых инструкций до исполнения вредоносного компонента программы, система безопасности, в данном случае эмулятор, не успеет его обнаружить, т.к. все ресурсы будут расходоваться на обработку этих пустых инструкций. К подобным методам загрузки эмулятора относятся модули упаковки, шифраторы, обфускаторы, пустые циклы и т.д. Таким образом, остро встает вопрос необходимости ускорения эмуляции процесса.
Предлагаемая система решает данную проблему с помощью ускорителя эмулятора, который изолирует процесс от системы и загружает на исполнение в центральный процессор. Ускоритель используют в случае, если исполнение процесса проходит без подозрительных действий, иначе его анализ продолжает эмулятор.
На Фиг.1 показана структурная блок-схема системы эмулятора в компьютерной системе в общем случае в соответствии с примером реализации. Хост 100 - это компьютерная система, которая включает в себя операционную систему 110, которая в свою очередь содержит эмулятор 120. Эмулятор 120 содержит также эмулированный центральный процессор (ЦП) 140 и эмулированную оперативную память (ОЗУ) 150. Процессор и память реализуются программно, имитируя инструкции реального процессора, например, семейства х86, копируя также состояние регистров процессора и адресное пространство операционной памяти. Эмулятор обособлен от системы и все исполняющиеся программы, запускаемые в эмуляторе, не имеют прав доступа для изменения данных в операционной системе. При запуске исполняющейся программы в эмуляторе создается процесс 130, который использует вычислительные ресурсы эмулятора для исполнения своих инструкций. Объем физической памяти, выделяемой под эмулятор в оперативной памяти системы, является динамическим - определяется памятью эмулируемого процесса. Оптимизация этой системы представлена далее.
На Фиг.2 показана блок-схема эмуляторов, которая предназначена для отображения всей системы в целом в виде набора устройств, к которым происходит обращение центрального процессора и памяти. Помимо эмуляции ЦП 240 и ОЗУ 250, эмулятор также эмулирует и файловую систему 210, устройства ввода/вывода 220 (такие как клавиатура и указательное устройство), сетевой интерфейс 230. Помимо описанных устройств эмулятор может описывать и другие устройства компьютерной системы.
На Фиг.3 изображено применение системы ускорения выполнения инструкций исполняющей программы. Для реализации ускорения изолированное адресное пространство 320 процесса 330 со всеми состояниями регистров и памятью передается напрямую процессору и оперативной памяти в хост компьютерной системы 310. Изолированное пространство 320, в которое помещается контекст процесса 330, отделено от хоста операционной системы 360, т.е. при попытке процесса обратиться к области памяти другого процесса исполнение ускорителем прекратится и процесс вернется в эмулятор. При исполнении процесса 330 изолированное пространство 320 отделяется от эмулятора 370, расположенного внутри хоста операционной системы 360, и ему передается управление вычислительными ресурсами компьютерной системы - ЦП 340 и ОЗУ 350. Некоторое количество времени инструкции процесса 330 исполняются на процессоре до возникновения ситуаций, при которых управление возвращается эмулятору 370. Такими условиями могут быть любые исключения процессора, такие как нехватка ресурсов, завершение выполнения инструкций, а также исполнение инструкции RDTSC, дополнительная загрузка существующей страницы, подключение сопроцессора. Аппаратные прерывания передают хосту операционной системы 360 по мере их поступления. Также не все инструкции выполняются на процессоре. Часть инструкций, такие как привилегированные инструкции, RDTSC и SSE, эмулируются в обычном режиме без использования ускорителя 320. К привилегированным инструкциям относятся операции ввода-вывода к периферийным устройствам, изменение параметров защиты памяти, настроек виртуальной памяти, системных параметров и прочих параметров конфигурации.
Важно отметить, что в эмулятор процесс загружается без модификаций. Существуют различные методы бинарной трансляции кода, когда аппаратно-зависимую часть кода преобразуют под имеющуюся систему, таким образом, обеспечивая корректное исполнение программы. В других случаях программы изменяют, удаляя привилегированные инструкции. Однако все это может сильно исказить процесс и неверно его интерпретировать.
Анализ процесса начинается в эмуляторе, где обрабатываются первые N инструкций. N - параметр проверки, который выбирается экспертом. Это число может составлять от 100 до 10000 инструкций. При этом эвристический анализатор, как правило, после каждой инструкции, группы инструкций или по окончанию исполнения проверяет сходство данного процесса с поведенческими сигнатурами известных вредоносных компонент. Сравнение происходит благодаря отчету об исполнении процесса, который составляет эмулятор. По отчету исполнения процесс классифицируется - в зависимости от действий процесса, присваивается статус безопасного файла, вируса, трояна или других вредоносных компонент. Сравнение и классификацию производит уже эвристический анализатор.
Если в результате первых N инструкций не обнаружено опасных признаков, эмулятор отправляет процесс в ускоритель. Состояние виртуального процессора и виртуальной памяти загружают в реальную систему для неразрывности исполнения процесса. Ускоритель начинает на скорости вычислений реального процессора исполнять инструкции. При этом количество инструкций в одном фрагменте ограничивается. Пределы, установленные в эмуляторе, составляют 15 миллионов инструкций в программе и/или 150 миллионов операций в процессоре. Управление процессом вернется эмулятору по достижению данных пределов или в случае появления исключений. Как было сказано ранее, исключения могут быть различными. Некоторые из них обрабатываются ускорителем, а некоторые нет.
Исключения в данном контексте нужно понимать как исключения процессора, аппаратные и программные прерывания, которые приведены в системных таблицах (например, IDT, LDT и др. для Intel-архитектуры). Существует несколько случаев, когда ускоритель может самостоятельно обработать прерывание или другое событие, и после возникновения таких исключений исполнение продолжится на реальном процессоре. К подобным исключениям относятся: #PF (PageFault, исключение 14), #NM (NoMathCoprocessor, исключение 7) и #GP (GeneralProtection, исключение 13), если оно вызвано инструкцией RDTSC. Превышение ограничений по количеству инструкций, обращение к адресному пространству операционной системы и другие события, которые описаны выше, вызывают те или иные исключения. Таким образом, ускоритель представляет собой некий монитор, который отслеживает системные прерывания, по возможности обрабатывает их, а в случае невозможности самостоятельно обработать их, загружает в эмулятор.
Изоляция процесса достигается за счет изменения регистров управления процессора (например, CR-0, CR-1, CR-3, CR-4 для Intel-архитектуры) таким образом, что в них намеренно будет отсутствовать адресное пространство ядра.
На Фиг.4 показана блок-схема алгоритма работы ускорителя эмулятора. На шаге 410 процесс, который необходимо эмулировать, загружается в эмулятор. Вместе с процессом в эмулятор загружается состояние системы: процессора, памяти и т.д. Для заданного процесса создается адресное пространство на шаге 420. Из адресного пространства процесса удаляются все данные об операционной системе. Передача процесса на выполнение процессору и оперативной памяти происходит на шаге 430. По мере исполнения инструкций ускоритель будет обрабатывать исключения. В случае если исключения не удастся обработать самостоятельно на шаге 440, то процесс ускорения останавливается, происходит возврат в эмулятор процесса и сохраненного на шаге 450 состояния системы. В эмуляторе происходит обработка исключений, а затем дальнейшее выполнение процесса на шаге 460. Если при выполнении инструкций в заданном фрагменте кода не встретилось исключение на шаге 440, процесс завершается, сохраняет состояние системы 470 и составляется отчет 480. После этого управление процессором и памятью, а также отчет исполнения процесса передается эмулятору.
Представленная система позволяет достигать скорости эмуляции близкой к скорости исполнения инструкций в ЦП. Скорость исполнения инструкций эмулятора меньше скорости реального процессора из-за периодических возвратов процесса эмулятору. При этом данная система не предполагает бинарной трансляции кода - исполняемый модуль анализируется «как есть».
В заключении следует отметить, что приведенные в описании сведения являются только примерами, которые не ограничивают объем настоящей полезной модели, описанной формулой. Специалисту в данной области становится понятным, что могут существовать и другие варианты осуществления настоящей полезной модели, согласующиеся с сущностью и объемом, настоящей полезной модели.