Система и способ выполнения антивирусной проверки файла на виртуальной машине

Система и способ выполнения антивирусной проверки файла на виртуальной машине

Иллюстрации

Показать все

Реферат

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

Изобретение относится к системам и способам выполнения антивирусной проверки файла на виртуальной машине.

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

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

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

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

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

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

Настоящее изобретение относится к системам и способам выполнения антивирусной проверки файла на виртуальной машине.

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

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

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

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

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

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

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

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

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

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

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

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

Согласно другому частному варианту реализации число итераций упомянутого цикла превышает заданное администратором компьютера предельное число итераций.

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

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

Согласно другому частному варианту реализации сигнатура первого типа дополнительно содержит правило, согласно которому в первом журнале число записей из следующего списка API-функций: «GetTickCount», «SysAllocString», «_wcsnicmp», «LCMapString», «wcschr», «CoTaskMemFree», «iswalpha», «iswalnum», «CompareString», «GetCurrentThreadId», «_wcsicmp» - превышает заранее определенное число.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно одному из частных вариантов число итераций упомянутого цикла превышает заданное администратором компьютера предельное число итераций.

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

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

Согласно одному из частных вариантов реализации сигнатура первого типа дополнительно содержит правило, согласно которому в первом журнале число записей из следующего списка API-функций: «GetTickCount», «SysAllocString», «_wcsnicmp», «LCMapString», «wcschr», «CoTaskMemFree», «iswalpha», «iswalnum», «CompareString», «GetCurrentThreadId», «_wcsicmp» - превышает заранее определенное число.

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

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

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

Согласно другому частному варианту реализации вредоносные сигнатуры дополнительно содержат строки по меньшей мере из одного или нескольких дампов памяти ОС.

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

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

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

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

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

На Фиг. 1 представлена система выполнения антивирусной проверки файла на виртуальной машине.

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

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

На Фиг. 4 приведен пример объединения трех журналов.

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

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

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

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

На Фиг. 1 представлена компьютерная система выполнения антивирусной проверки файла на виртуальной машине. Система содержит антивирусное приложение 101, предназначенное для исполнения файла 104 на виртуальной машине 102. В частном варианте реализации на виртуальной машине 102 исполняется операционная система (ОС) 103, в которой в свою очередь происходит исполнение файла 104. Во время исполнения файла 104 на виртуальной машине 102, средство журналирования 105, связанное с антивирусным приложением 101 вносит записи (сохраняет в журнал) о вызовах API-функций, а также внутренние события в первый журнал 110, второй журнал 111 и третий журнал 112. Более подробно об отличиях между журналами 110-112 будет написано ниже. Внутренними событиями являются системные вызовы процесса, запущенного из файла 104, к ядру ОС 103 в процессе исполнения. В частном варианте реализации информация о внутренних событиях может быть получена путем перехвата системных вызовов, а также с использованием механизмов нотификации ядра ОС и путем встраивания драйвера антивирусного приложения в стек драйверов ОС (например, в стек файловой системы или стек сетевых драйверов). Перехват системных вызовов может быть осуществлен известными из уровня техники способами, например путем подмены адреса системного вызова.

В частном варианте реализации в первый журнал 110 и третий журнал 112 дополнительно происходит внесение записей возвратов из API-функций, прямых вызовов Windows NT Native API-функций и возвратов из Windows NT Native API-функций, а также информации о событиях выключения или перезагрузки компьютерной системы.

В частном варианте реализации каждая запись первого журнала 110 и третьего журнала 112 о вызове API-функции содержит следующую информацию:

- имя вызванной функции;

- уникальный идентификатор процесса (от англ. process identifier, PID), запущенного из файла 104;

- уникальный идентификатор потока (от англ. thread identifier, TID), запущенного из упомянутого процесса;

- набор аргументов упомянутой функции.

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

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

В частном варианте реализации каждая запись каждого журнала 110-112 о внутреннем событии содержит следующую информацию:

- имя внутреннего события;

- тип системного вызова;

- уникальный идентификатор процесса, запущенного из файла 104;

В другом частном варианте реализации каждая запись каждого журнала 110-112 о внутреннем событии дополнительно содержит следующую информацию:

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

- уникальный идентификатор процесса объекта ядра ОС, к которому обращен системный вызов;

- уникальный идентификатор потока упомянутого объекта ядра ОС;

- путь к упомянутому объекту ядра ОС.

В таблице 1 приведены примеры записей о внутренних событиях. Например первая запись описывает следующее внутреннее событие: процесс с идентификатором «PID» удалил ключ реестра «Key».

На Фиг. 2 представлен способ выполнения антивирусной проверки файла на виртуальной машине. На шаге 201 антивирусное приложение 101 исполняет файл 104 на виртуальной машине 102. Во время исполнения, средство журналирования 105 последовательно вносит записи о вызовах API-функций и внутренние события в первый журнал 110. Первый журнал 110 содержит по меньшей мере одну запись о вызове API-функции и по меньшей мере одну запись о внутреннем событии. Исполнение файла 104 на виртуальной машине 102 происходит до наступления одного из событий: истек заданный (например, администратором или антивирусным приложением 101) период времени исполнения, или завершено исполнение программного кода файла 104 (то есть, либо была достигнута последняя инструкция программного кода, которая передает управление ОС, либо возникла ошибка). Как уже было упомянуто ранее, время исполнения файла на виртуальной машине может быть ограничено заданным периодом времени. В одном примере реализации такой период времени может быть заранее задан администратором. В другом примере реализации период времени может быть задан администратором или антивирусным приложением 101 исходя из статистики антивирусной проверки других файлов на виртуальной машине. Например, период времени может быть задан таким образом, чтобы вероятность обнаружения вредоносного кода в файле использующимися методами превышала заданный порог, например, 95%. То есть в этом примере, если вредоносный код в файле 104 будет обнаружен при исполнении файла на виртуальной машине в течение неограниченного периода времени, то вероятность обнаружения вредоносного кода в этом же файле во время исполнения на виртуальной машине 102 за ограниченный период времени равняется 95%.

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

Кроме этого, если программный код файла 104 был исполнен до истечения заданного периода времени, исполнение виртуальной среды 102 также будет завершено.

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

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

То есть на шаге 202 средство проверки 106, связанное с антивирусным приложением 101, выявляет (осуществляет поиск) в первом журнале 110 сигнатуры первого типа, которые хранятся в базе данных сигнатур первого типа 120. Сигнатура (антивирусная запись) первого типа включает не менее двух записей, которые содержат информацию о вызовах API-функций. В частном варианте реализации сигнатура первого типа дополнительно содержит записи, содержащие в свою очередь информацию о внутренних событиях. В частном варианте реализации сигнатура первого типа содержит записи с информацией о вызовах одной или нескольких API-функций, повторяющихся в цикле из по крайней мере двух итераций. В еще одном варианте реализации, число итераций цикла должно быть выше заданного администратором предельного числа итераций. Выявление сигнатуры первого типа осуществляется путем поиска в первом журнале 110 совпадения записей сигнатуры первого типа с записями первого журнала 110. Если совпадения на шаге 202 не было найдено, то на шаге 203а завершается работа способа, и файл 104 не будет считаться вредоносным.

В частном варианте реализации, средство журналирования 105 исполняется в операционной системе 103 на виртуальной машине 102. В другом частном варианте реализации антивирусное приложение 101 является составной частью средства журналирования 105 и также выполняется в ОС 103 на виртуальной машине 102. В еще одном частном варианте реализации средство проверки 106 является составной частью антивирусного приложения 101. В другом частном варианте реализации, средство проверки 106 является составной частью средства журналирования 105.

В частном варианте реализации сигнатура первого типа содержит записи вызовов API-функций, отвечающих за сетевую активность (например, функции «InternetGetConnectedState», «InternetOpenUrl»).

Стоит отметить, что сигнатуры могут содержать не только записи журналов 110-112, а также различные условия, которые необходимо проверить, чтобы сигнатура была выявлена. Записи журналов 110-112 могут содержать такие условия.

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

В частном варианте реализации сигнатура первого типа дополнительно содержит правило, согласно которому в первом журнале 110 число записей из следующего списка API-функций: «GetTickCount», «SysAllocString», «_wcsnicmp», «LCMapString», «wcschr», «CoTaskMemFree», «iswalpha», «iswalnum», «CompareString», «GetCurrentThreadId», «_wcsicmp» - превышает заранее определенное число (например, половину всех записей в первом журнале 110). Перечисленные выше API-функции обычно редко вызываются легитимным программным обеспечением. Однако вредоносное программное обеспечение может совершать большое число вызовов подобных функций для затруднения проверки антивирусными приложениями.

Если в журнале 110 была выявлена сигнатура первого типа, то на шаге 203 будет произведено повторное исполнение файла 104 на виртуальной машине 102. При повторном исполнении средство журналирования 105 производит внесение записей только о внутренних событиях во второй журнал 111. Повторное исполнение файла 104 на виртуальной машине 102 будет происходить до наступления одного из событий: истек заданный период времени исполнения, или завершено исполнение программного кода файла 104.

Как уже объяснялось ранее, скорость исполнения файла 104 на виртуальной машине 102 на