Способ обнаружения вредоносных исполняемых файлов, содержащих интерпретатор, посредством комбинирования эмуляторов

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

 

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

Изобретение относится к антивирусным решениям, а более конкретно к обнаружению вредоносных объектов посредством эмуляции.

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

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

AutoIt - свободно распространяемый язык программирования для автоматизации выполнения задач в Microsoft Windows. В ранних версиях программы, написанные на этом языке, преимущественно использовалась для создания сценариев автоматизации для программ Microsoft Windows. Такие сценарии полезны для выполнения часто повторяющихся задач, таких как инсталляция идентичных наборов программ на большое количество компьютеров. В более поздних версиях AutoIt существенно возросла общая функциональность языка, что приблизило AutoIt к языкам программирования общего назначения. Сценарий, написанный на языке AutoIt, может быть скомпилирован в независимый от каких-либо библиотек исполняемый файл. Широкие возможности языка написания сценариев AutoIt и удобная для распространения конечная форма представления сценария в виде исполняемого файла - все это привлекло повышенное внимание вирусописателей к данному языку.

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

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

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

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

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

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

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

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

Еще в одном частном варианте сценарий написан на языке программирования Autolt.

В другом частном варианте осуществления до преобразования команд из сценария в псевдокод осуществляется деобфускация исходного кода сценария.

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

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

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

Фиг. 1 показывает структуру исполняемого файла, скомпилированного при помощи AutoIt.

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

Фиг. 3 показывает систему обнаружения вредоносного исполняемого файла.

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

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

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

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

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

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

Эмулятор сценариев, в отличие от эмулятора машинного кода, содержит в себе интерпретатор, и у эмулятора сценариев отсутствуют виртуальные копии компонентов операционной системы. Интерпретатор может работать как с исходным кодом сценария, так и с псевдокодом. Псевдокод - это промежуточная форма представления (код) между командами понятными человеку, например, командами языка программирования, на котором написан сценарий (например, языка программирования AutoIt), и командами, понятными средству их обработки, которым в данном случае является интерпретатор в рамках эмулятора сценариев. В программировании псевдокод известен так же, как байт-код или пи-код (от англ. bytecode и p-code соответственно). По сравнению с исходным кодом сценария, удобным для анализа и понимания человеком, полученным, например, в результате декомпиляции, псевдокод является компактным представлением сценария. С технической точки зрения, псевдокод представляет собой машинно-независимый код низкого уровня, генерируемый транслятором (в рамках данного изобретения данную функцию выполняет анализатор, описание которого будет приведено далее) из исходного кода сценария. Использование псевдокода позволяет облегчить и ускорить работу интерпретатора. По виду псевдокод похож на машинный код, но предназначен для исполнения не реальным процессором, а виртуальной машиной. В качестве виртуальной машины в рамках данного изобретения выступает интерпретатор языка написания сценариев (например, языка программирования AutoIt). Длина каждого кода операции традиционно составляет один байт. Каждая инструкция обычно представляет собой однобайтовый код операции (от 0 до 255), за которым могут следовать различные параметры, например, номер регистра или адрес в памяти. Один и тот же сценарий в псевдокоде может выполняться интерпретатором на разных платформах и архитектурах, для которых реализован интерпретатор, в отличие от машинного кода, который является архитектурно-зависимым кодом. Основной алгоритм работы эмулятора сценариев: прочитать команду в псевдокоде; определить при помощи интерпретатора соответствующие действия; осуществить эмуляцию соответствующих действий; и записать результат эмуляции в журнал работы эмуляторов. Эмулятор сценариев позволяет понизить ресурсоемкость и ускорить процесс исследования исполняемого файла, содержащего интерпретатор языка сценариев и связанного с ним сценария. Однако в процессе эмуляции выполнения сценария может быть осуществлен переход из псевдокода, с которым работает интерпретатор в рамках эмулятора сценариев, в машинный код, для эмуляции выполнения которого необходимо запустить эмулятор машинного кода. Такой переход может быть осуществлен в результате обнаружения в процессе эмуляции кода, относящегося к:

- вызовам API-функций операционной системы;

- вызовам функций из динамических библиотек;

- обращениям к ресурсам исполняемого файла;

- коду, который не может быть обработан эмулятором сценариев.

Стоит отметить, что эмулятор машинного кода позволяет работать со всеми присутствующими в рамках операционной системы библиотеками и интерпретаторами (например, .NET, Java, AutoIt и др.). Также позволяет производить эмуляцию пакетных и управляющих файлов, таких как пакетный файл (batch file) с расширением .bat или .cmd, powershell-сценариев, AutoIt-сценариев, reg-файлов для внесения данных в реестр и других типов файлов, запуск которых приводит к исполнению кода на компьютере пользователя. Таким образом, в одном из вариантов осуществления данного изобретения, если даже в процессе эмуляции одного сценария будет осуществлено переключение процесса эмуляции на эмулятор машинного кода, и при этом будет запущен на исполнение другой сценарий, например, содержащийся в ресурсах исходного упомянутого исполняемого файла, то этот сценарий может также быть обработан эмулятором машинного кода, после чего процесс эмуляции будет обратно переключен на эмуляцию исходного сценария, содержащегося в упомянутом исполняемом файле. В другом варианте реализации, если было осуществлено переключение процесса эмуляции на эмулятор машинного кода, и при этом был запущен на исполнение другой сценарий, то процесс эмуляции вновь переключается на эмулятор сценариев. Еще в одном варианте реализации для обработки дополнительного сценария, запуск которого был осуществлен в процессе работы эмулятора машинного кода, может быть параллельно запущен дополнительный эмулятор сценариев. При этом результаты работы основного эмулятора сценариев, эмулятора машинного кода и дополнительного эмулятора сценариев записываются в один общий журнал работы эмуляторов и обрабатываются анализатором.

На Фиг. 1 изображена структура исполняемого файла 100, скомпилированного при помощи AutoIt. Можно выделить две основные составляющие части таких исполняемых файлов: сценарий 102, написанный на языке AutoIt, содержащийся внутри исполняемого файла 100 и интерпретатор 101. Интерпретатор 101 встраивается в любой исполняемый файл 100, скомпилированный из сценария 102, написанного на языке AutoIt, и, если исходный сценарий 102 не был скомпилирован с директивой #NoAutoIt3Execute, запрещающей интерпретатору исполнять сторонние сценарии, то интерпретатор 101 может быть использован для исполнения кода другого сценария 103, написанного на языке AutoIt. Исполнения кода можно добиться двумя способами:

- посредством параметра «/AutoIt3ExecuteLine», через который интерпретатору на исполнение передается непосредственно код, написанный на языке AutoIt, например:

- посредством параметра «/AutoIt3ExecuteScript», через который интерпретатору на исполнение передается сценарий, написанный на языке AutoIt, например:

Возможность исполнения сценария 103 посредством интерпретатора 101, относящегося к исполняемому файлу 100, содержащему сценарий 102, позволяет вирусописателям реализовывать многокомпонентные вредоносные объекты, каждый компонент которых в отдельности может быть признан доверенным в результате антивирусного исследования. Например, исполняемый файл 100 может содержать зашифрованный вредоносный код, находящийся в ресурсах, но при обычном запуске исполняемого файла 100, посредством интерпретатора 101 осуществляется исполнение сценария 102, в результате которого не происходит расшифровывание и запуск вредоносного кода. Однако при осуществлении запуска исполняемого файла 100 с параметром «/AutoIt3ExecuteScript», через который интерпретатору на исполнение передается сценарий 103, происходит обращение к ресурсам исполняемого файла 100, расшифровывание и выполнение вредоносного кода. При этом запуск исполняемого файла может осуществить третий компонент, который осуществляет загрузку сценария 103 из сети Интернет. Для обнаружения многокомпонентных вредоносных исполняемых файлов процесс эмуляции необходимо начинать со сценария 103, то есть сценария внешнего по отношению к интерпретатору 101, а для обнаружения однокомпонентных вредоносных исполняемых файлов процесс эмуляции начинается со сценария 102. Для этого в одном из вариантов реализации данного изобретения осуществляется перехват события запуска исполняемого файла 100, и, если параметры, с которыми осуществлялась попытка запуска упомянутого исполняемого файла, содержат сценарий, то процесс эмуляции начинается с передаваемого в параметрах сценария, если такие параметры отсутствуют, то процесс эмуляции начинается со сценария 102, содержащегося внутри исследуемого исполняемого файла 100.

Фиг. 2 показывает один из вариантов осуществления способа обнаружения вредоносного исполняемого файла, содержащего сценарий. Согласно упомянутому способу на этапе 201 осуществляется преобразование исследуемого сценария в псевдокод. Использование псевдокода позволяет облегчить и ускорить работу интерпретатора, используемого в рамках эмулятора сценариев. Как упоминалось выше, сценарием, в отношении которого осуществляется анализ на вредоносность, может быть сценарий 102, содержащийся в исполняемом файле 100, или сценарий 103, переданный на исполнение интерпретатору 101 исполняемого файла 100.

Для исследования сценария 102, содержащегося внутри исполняемого файла 100, его необходимо предварительно извлечь из исполняемого файла 100. При этом, если сценарий 102 был запакован с использованием программ-упаковщиков, то в процессе его извлечения осуществляется процедура его распаковывания. Извлеченный сценарий 102 подвергается процедуре декомпиляции, то есть восстановлению исходного кода сценария 102 на языке программирования, на котором данный сценарий был написан. Декомпиляция кода сценария 102 необходима для осуществления деобфускации его исходного кода. Деобфускация (от англ. obfuscate - делать неочевидным, запутанным, сбивать с толку) - это процедура избавления от кода, затрудняющего анализ, но не изменяющего функциональность, заложенную в сценарий. Таким кодом, например, могут быть: бесполезные вычисления или обособленные циклы, результаты вычислений, в рамках которых нигде не используются. Если же исследуемым сценарием является сценарий 103, то перед преобразованием сценария 103 в псевдокод он может быть подвергнут процедуре деобфускации.

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

- вызовам API-функций операционной системы;

- вызовам функций из динамических библиотек;

- обращениям к ресурсам исполняемого файла;

- коду, который не может быть обработан эмулятором сценариев.

После окончания процесса эмуляции выполнения машинного кода процесс эмуляции вновь переключается на эмуляцию выполнения псевдокода исследуемого сценария. В процессе осуществления эмуляции выполнения псевдокода и машинного кода результаты эмуляции записываются в журнал работы эмуляторов. Журнал работы эмуляторов анализируется на этапе 205 с целью обнаружения вредоносного поведения. Этапы 202-205 повторяются до тех пор, пока упомянутый исполняемый файл не будет признан вредоносным на этапе 207 путем обнаружения на этапе 206 вредоносного поведения в результате осуществляемого на этапе 205 анализа журнала работы эмуляторов.

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

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

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

Фиг. 3 показывает систему, в рамках которой может быть реализовано настоящее изобретение. Допустим, на компьютере пользователя имеется исполняемый файл 310, содержащий сценарий 320, в отношении которого необходимо провести проверку, позволяющую определить, является ли исполняемый файл 310 вредоносным. Так как исполняемый файл содержит сценарий, то ресурсоемкость и временные затраты на проведение эмуляции исполняемого файла могут быть существенно снижены при помощи извлечения сценария и его непосредственно эмуляции с помощью эмулятора сценариев 340. Извлечение сценария осуществляется посредством декомпиляции исполняемого файла, а также, если необходимо, распаковывания сценария, если он был упакован с использованием программ-упаковщиков. Все эти действия могут быть автоматически осуществлены анализатором 330. Перед тем как осуществить передачу сценария 320 на выполнение эмулятору сценариев 340 анализатор 330 преобразует команды из сценария 320 в псевдокод - язык, с которым работает эмулятор сценариев 340. Также для облегчения последующего процесса эмуляции код из сценария 340 может быть подвергнут процедуре деобфускации, которая осуществляется до преобразования сценария 320 в псевдокод. После передачи сценария 320, преобразованного в псевдокод, на выполнение, эмулятор сценариев 340 начинает последовательно эмулировать выполнение псевдокода и записывать результаты эмуляции в журнал работы эмуляторов 360. Анализатор 330 контролирует процесс эмуляции, выполняемый эмулятором сценариев, и при обнаружении в процессе эмуляции перехода из псевдокода в машинный код переключает процесс эмуляции на эмулятор машинного кода 350, где переход из псевдокода в машинный код, относится к:

- вызовам API-функций операционной системы;

- вызовам функций из динамических библиотек;

- обращениям к ресурсам исполняемого файла; и

- коду, который не может быть обработан эмулятором сценариев.

При переключении процесса эмуляции на эмулятор машинного кода 350, анализатором 330 временно приостанавливается работа эмулятора сценариев 340, а эмулятор машинного кода 350 приступает к эмуляции выполнения машинного кода и также осуществляет запись результатов эмуляции в журнал работы эмуляторов 360. Процесс эмуляции выполнения псевдокода с помощью эмулятора сценариев 340 возобновляется анализатором 330 после окончания эмуляции выполнения машинного кода. В другом варианте реализации данного изобретения переключение процесса эмуляции на эмулятор машинного кода 350 осуществляется эмулятором сценариев 340. Анализатор 330 осуществляет постоянный анализ журнала работы эмуляторов 360, с целью выявления вредоносного функционала (вредоносного поведения) для признания исходного исполняемого файла, содержащего сценарий, вредоносным. Исполняемый файл может быть признан доверенным, если после эмуляции всего псевдокода и машинного кода, в результате анализа журнала работы эмуляторов 360 не выявлено вредоносного функционала. Также исполняемый файл может быть признан анализатором 330 доверенным, если журнал работы эмуляторов 360, сформированный за отведенное на исследование время, не содержит вредоносного функционала.

Фиг. 4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, представляющий собой в одном из вариантов осуществления сервис анализа 202, содержащий центральный процессор 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, представленного на Фиг. 4. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

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

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

1. Способ признания вредоносным исполняемого файла, содержащего интерпретатор языка сценариев, по которому:

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

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

в) производят эмуляцию выполнения псевдокода с помощью эмулятора сценариев, и записывают результат в журнал работы эмуляторов;

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

переход из псевдокода в машинный код, относится к:

- вызовам API-функций операционной системы;

- вызовам функций из динамических библиотек;

- обращениям к ресурсам исполняемого файла; и

- коду, который не может быть обработан эмулятором сценариев;

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

д) признают упомянутый исполняемый файл вредоносным при обнаружении вредоносного поведения в результате анализа журнала работы эмуляторов с помощью анализатора.

2. Способ по п. 1, где сценарий, связанный с упомянутым интерпретатором, является сценарием, содержащимся внутри исполняемого файла.

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

4. Способ по п. 1, по которому сценарий написан на языке программирования AutoIt.

5. Способ по п. 1, по которому до преобразования команд из сценария в псевдокод осуществляется деобфускация исходного кода сценария.