Способ создания сценария популярных событий активации

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

 

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

Изобретение относится к способам создания сценариев во время контроля исполнения исследуемого программного обеспечения с целью обнаружения поведения, характерного для вредоносного программного обеспечения.

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

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

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

Часто для анализа вредоносного программного обеспечения используются виртуальные среды, которые создают как на стороне пользователей, так и на стороне производителей антивирусного программного обеспечения. В этих виртуальных системах создается окружение, которое максимально приближено к реальному окружению. Затем в этом окружении запускается и тестируется программное обеспечение. Так в патенте US 8069372 описывается система, созданная для мониторинга исследуемого программного обеспечения. Система реализована в виде программных модулей, которые симулируют операционную систему. Подобная система управляется эмулятором процессора, что позволяет осуществлять мониторинг доступа к ресурсам системы и характер этих обращений и подходит для обнаружения вредоносного программного обеспечения. Главный недостаток подобных систем заключается в том, что многое программное обеспечение не запускается на подобных системах, исследуемое приложение либо обнаруживает виртуальное окружение, либо использует функционал, который в данном окружении не реализован.

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

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

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

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

Настоящее изобретение предназначено для обнаружения вредоносного программного обеспечения.

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

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

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

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

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

Фиг. 2 показывает варианты модификации программно-аппаратной части устройства;

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

Фиг. 4 показывает архитектуру мобильной операционной системы Android OS;

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

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

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

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

Настоящее изобретение обходит недостатки известных решений с помощью более расширенного контроля событий на разных уровнях программно-аппаратной части устройства, от верхнего уровня ОС до оборудования, а также за счет того, что используются сценарии поведения для активации возможного вредоносного функционала. Здесь под оборудованием понимается вся доступная центральная и периферийная аппаратура контролируемого устройства: процессоры, запоминающие устройства, коммуникационные модули (GSM, Bluetooth) и т.д. Далее программно-аппаратная часть устройства, предназначенная для поддержки исполнения приложения, будет называться окружением этого приложения. Архитектура программно-аппаратной части устройств многоуровневая. На Фиг. 1 представлено взаимодействие приложения 101 и оборудования 103 через уровни архитектуры, относящиеся к операционной системе 102. Когда при работе приложения происходит вызов API (application programming interface) функции, операционная система производит большое количество действий, что связано со сложной внутренней архитектурой операционной системы. Схематически вызов API-функции приложением 101 приводит к передаче вызовов через все уровни архитектуры ОС 102, выполнению большого количества действий на оборудовании 103, после чего приложению 101 возвращается результат работы вызванной API-функции. Поэтому для контроля работы устройства необходимо осуществлять контроль по возможности над всеми уровнями архитектуры, относящимися к операционной системе 102 и оборудованию 103. Один из возможных способов контроля заключается в модификации элементов уровней архитектуры 102 и 103 и добавлении своих элементов. Приложение в таком измененном окружении подконтрольно исполняется, а результатами его работы будут не только операции, совершенные устройством (отправка CMC, загрузка некоторого содержимого с удаленного ресурса и т.д.) так, как бы это было в исходном неизмененном варианте окружения, но и информация для анализа. Подконтрольное исполнение предполагает контроль над исполнением приложения на всех уровнях архитектуры, где контроль не ограничивается лишь фиксацией событий в системе, вызванных работой приложения, контроль предполагает остановку исполнения приложения на любом из уровней архитектуры. На Фиг. 2а и Фиг. 2б изображены одни из возможных вариантов модификации программно-аппаратной архитектуры. Под модификацией программно-аппаратной части понимается, ее изменение, которое делает ее отличной от первоначального варианта. На Фиг.2а изображена архитектура, в уровни, которой добавляются дополнительные элементы - обработчики 201. Исходные элементы уровня при этом модифицируются минимально, например, устанавливаются прерывания, а весь дополнительный функционал, обрабатывающий прерывания, выносится в отдельный элемент - обработчик 201. Функционал, который содержится в обработчике 201, может быть следующий: контроль работы изменяемого уровня; управление работой изменяемого уровня; протоколирование информации о событиях в изменяемом уровне, которые вызваны работой подконтрольного приложения; предоставление модулю управления 202 доступа по запросу к запротоколированной информации. Задачи, выполняемые модулем управления 202, раскрываются позднее. На Фиг. 2б в исходную конфигурацию уровня вносятся более существенные изменения и функционал, описанный в предыдущем примере, вынесенный в обработчики 201, выполняется непосредственно в измененных элементах уровня 102а и 103а. Управление обработчиком 201 может осуществляться непосредственно функционалом, встроенным в обработчик 201, либо модулем управления 202. Модуль управления 202 может находиться на уровне приложения 101, и модулю управления 202 доступна протоколируемая информация.

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

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

- включенные коммуникационные порты;

- конкретный тип активного окна;

- состояние подключения к сети;

- дата и время;

- тип устройства, на котором запущено исследуемое приложение;

- версия операционной системы;

- наличие других приложений на устройстве;

- текущее местоположение устройства;

- активные действия пользователя;

- входящие звонки и CMC;

- включение устройства;

- перезагрузка устройства и т.д.

Таким образом, для обнаружения вредоносного программного обеспечения необходимо не только контролировать программно-аппаратную часть устройства, но и создать в окружении приложения при его выполнении определенные условия. На Фиг. 3 изображена возможная реализация такой системы обнаружения вредоносного программного обеспечения, контролирующей исполнение запущенного по сценарию приложения. Под сценарием понимается список из набора событий активации, появление которых в системе активирует вредоносный функционал приложения, что позволяет опознать это приложение как вредоносное. Модуль управления 202 запускает исследуемое приложение и создает события активации в системе, описанные в сценарии. В частном случае реализации сценарий будет исполнен модулем управления 202. Модуль управления имеет обратную связь с уровнями 102а и 103а, исполнение сценария будет заключаться в создании уровнями архитектуры событий активации по команде модуля управления 202.

Приложение 101 при своей работе вызывает последовательно ряд событий на каждом из уровней архитектуры 102а и 103а, связанных с исполнением приложения. Уровнями 102а и 103а информация о событиях протоколируется и собирается модулем управления 202. Собранная информация анализируется модулем анализа 301. Для хранения сценариев, которые использует модуль управления 202, предназначена база сценариев 302. Модуль управления 202 запускает исследуемое приложение в измененном окружении 102а и 103а, создавая событии активации, перечисленные в сценарии, модуль управления 202 собирает информацию о событиях, которые вызвало приложение своей работой, от уровней 102а и 103а. Полученная информация анализируется модулем анализа 301. Если в результате анализа полученной информации, поведение приложения признается вредоносным, то модуль управления 202 остановит исполнение исследуемого приложения 101 и, например, поместит его в карантин. Если в результате анализа в поведении приложения ничего вредоносного не обнаружено, модуль управления 202 выбирает из базы сценариев 302 другой сценарий и все повторяется вновь. Этот цикл выполняется до того момента, пока приложение не проявит вредоносную активность, либо пока модуль управления не использует все доступные сценарии.

В частном варианте реализации база сценариев 302 формируется на удаленном сервере и передается на устройство посредством обновления.

В частном варианте изобретения система на Фиг. 3 дополнена накопителем 303. Накопитель собирает информацию о том, какие события в окружении 102а и 103а вызвала работа исследуемых приложений, какими событиями активации из перечисленных в сценарии удалось заставить приложения активировать вредоносный функционал. Исходя из собранных накопителем 303 данных, генератор сценариев формирует оптимизированные сценарии и передает их в базу сценариев 302. Оптимизация сценариев используется для повышения производительности системы обнаружения вредоносного программного обеспечения. Формирование оптимизированного сценария осуществляется следующим образом. Накопителем 303 собирается информация об обнаруженном вредоносном программном обеспечении, событиях в окружении, которые вызвала работа исследуемых приложений, и событиях активации из сценариев, заставивших активировать приложение вредоносный функционал. На основе собранной информации формируется список популярных событий активации для сценария. Затем генератор сценариев 304 из списка популярных событий активации формирует популярные сценарии и передает их в базу сценариев 302. В базе сценариев сценарии формируются по популярности, и при проверке исследуемого приложения первыми на вход подаются сценарии, содержащие наиболее популярные на данный момент события активации.

В частном случае реализации данного изобретения, информация, собираемая накопителем, используется классификатором шаблонов поведения 305. Классификатор шаблонов 305 определяет, какие шаблоны с какими событиями активации срабатывают и устанавливает популярность шаблонов. В базе шаблонов 306 шаблоны будут упорядочены в соответствии с популярностью срабатывания, установленной классификатором шаблонов. Например, имеется событие активации - входящий звонок, наиболее популярными программами, активирующими свой вредоносный функционал при подобном сценарии (входящий звонок) являются, например, программы шпионы, которые отслеживают входящие звонки пользователя и перенаправляют эту информацию злоумышленнику. Классификатор шаблонов 305 как раз и соотнесет событие активации (входящий звонок) с шаблоном поведения характерным для данного вида вредоносных программ. Далее классификатор шаблонов 305 указанному событию активации соотнесет второй по популярности шаблон поведения и т.д. Если при анализе программ, запущенных по указанному сценарию, не сработали шаблоны поведения из выстроенного списка, для анализа используются все оставшиеся шаблоны. Подобное решение позволит повысить производительность работы системы обнаружения, изображенной на Фиг. 3.

Частным случаем применения изобретения является его использование на одной из самых распространенных мобильных платформ Android OS, архитектура данной операционной системы представлена на Фиг. 4. Архитектура Android построена на основе ядра Linux 401. Ядро 401 отвечает за такие системные службы, как управление безопасностью, памятью, процессами, включает сетевой стек и модель драйверов. Следующий уровень в иерархической структуре - библиотеки 402, написанные на C/C++, используемые различными компонентами ОС. Важнейшей частью архитектуры является Android Runtime (среда исполнения приложения) 403. Среда исполнения состоит из виртуальной Java-машины Dalvik 405 и набора базовых библиотек. Dalvik выполняет файлы в специальном формате.dex, оптимизированном для устройств с малым количеством памяти. Базовые библиотеки написаны на языке Java и включают большой набор классов, которые поддерживают широкий диапазон функциональных возможностей. Следующий уровень - Application Framework (каркас приложений) 404. Этот уровень представляет собой инструментарий, которым пользуются все приложения. На вершине иерархии - Applications (уровень приложений) 406. Платформа имеет особенность, которая заключается в том, что приложения выполняются в песочнице (жестко контролируемый набор ресурсов для исполнения гостевой программы) и не имеют прав для модификации компонентов, находящихся на одном уровне и на уровнях ниже. Порядок взаимодействия приложения и оборудования в данной системе при отправке CMC изображен на Фиг. 5. Приложение 101 для отправки CMC использует соответствующий метод, реализованный в компоненте SMS Manager 501, данный функционал будет исполнен виртуальной машиной Dalvik 405, которая для выполнения запрашиваемого действия осуществит вызов функций драйвера GSM Driver 502, который даст команду модулю GSM Module 503, в результате сообщение будет отправлено.

В возможном варианте изобретения модифицируется уровень Android Runtime, а именно виртуальная машина Dalvik 405. При необходимости исследовать приложение 101 на устройстве пользователя (например, сразу после установки нового приложения) его запускают в окружении, в котором используют модифицированный вариант виртуальной машины Dalvik 405а. В окружении создаются различные доступные события активации (симулируется нажатие кнопок интерфейса приложения, приход новых сообщений, звонков, перезагрузка системы, изменение регистрации в сети и т.д.). Подозрительное приложение запускают с помощью модуля управления 202 в отдельном процессе, который не имеет видимого пользовательского интерфейса и не имеет никаких системных разрешений, т.е. приложение не способно нанести никакого вреда окружению. Виртуальная машина Dalvik 405а протоколирует информацию о событиях, вызываемых исследуемым приложением, что возможно благодаря замене оригинальных вызовов Dalvik, и создает события активации в системе. Запротоколированную информацию анализируют модулем анализа 301. Если исследуемое приложение 101 на основании анализа путем сравнения запротоколированной информации о поведении с шаблонами поведения из базы шаблонов 302, признают вредоносным, модуль управления 202, например, удалит данное приложение. Примером работы данной системы является обнаружение на компьютере пользователя программы шпиона, которая ждет прихода CMC на устройство пользователя и перенаправляет его на устройство злоумышленника. Запустив это приложение для проверки его поведения, в информации, собранной анализатором поведения, не будет обнаружено событий, указывающих на вредоносный функционал, (отправка входящих сообщений на устройство злоумышленника) т.к. для активации вредоносного функционала необходимо событие активатор, которым будет входящее сообщение. Поэтому в системе, изображенной на Фиг. 5 запускается исследуемое приложение 101, и виртуальной машиной 405а в соответствии с одним из сценариев создается событие активатор (получено входящее сообщение), виртуальной машиной 405а протоколируют информацию о событиях, которые вызвала работа исследуемого приложения. Так как в окружении программы шпиона возникло событие, которое активирует вредоносный функционал, модуль анализа 301 в информации запротоколированной виртуальной машиной 405а, обнаружит события, характерные для вредоносного программного обеспечения, и исследуемое приложение 101 будет удалено.

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

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

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

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

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

а) получают множество сценариев;

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

в) запускают исследуемое приложение на модифицированной программно-аппаратной части устройства;

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

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

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

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

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