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

Изобретение относится к выполнению антивирусной проверки файла на виртуальной машине. Технический результат заключается в обнаружении вредоносного файла, содержащего программный код, который затрудняет обнаружение данного вредоносного файла при исполнении файла на виртуальной машине. Реализуемый компьютером способ выполнения антивирусной проверки файла на виртуальной машине, в котором: исполняют файл на виртуальной машине с последовательным внесением записей о вызовах API-функций и внесением записей о внутренних событиях в первый журнал, выявляют в первом журнале сигнатуру первого типа из базы данных сигнатур первого типа, производят повторное исполнение файла на виртуальной машине с внесением записей о внутренних событиях во второй журнал, после чего выявляют во втором журнале сигнатуру второго типа из базы данных сигнатур второго типа и определяют критерий внесения записей о вызовах API-функций на основании второго и первого журналов, производят третье исполнение файла на виртуальной машине с внесением в третий журнал записей только о внутренних событиях до тех пор, пока не будет выполнен критерий внесения записей о вызовах API-функций, после которого производится внесение записей о вызовах API-функций, выполняют антивирусную проверку файла путем выявления в третьем журнале вредоносной сигнатуры с использованием базы данных вредоносных сигнатур, файл будет признан вредоносным, когда вредоносная сигнатура будет выявлена в третьем журнале. 2 н. и 38 з.п. ф-лы, 3 табл., 6 ил.

 

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

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

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

Традиционный сигнатурный анализ не всегда позволяет обнаружить вредоносный файл, особенно полиморфные вирусы, а также измененные версии вредоносного файла. Поэтому современные антивирусные приложения дополнительно используют проверку с использованием виртуальной машины. Проверяемый файл исполняется на виртуальной машине. При этом события, возникающие в результате выполнения процесса, запущенного из файла, сохраняются в журнал с использованием перехвата различных процедур, выполняемых как процессом, так и операционной системой (ОС). Антивирусное приложение далее анализирует полученный журнал. В журнале обычно сохраняются вызовы 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 на шаге 203 будет выше скорости исполнения файла 104 на виртуальной машине 102 на шаге 201. Таким образом, если исполнение файла 104 было прервано по прошествии заданного периода времени, на шаге 203 было исполнено большее число инструкций программного кода файла 104, чем на шаге 201.

Стоит отметить, что в большинстве случаев на шаге 201 и шаге 203 внутренние события, записанные в первый и второй журналы 110-111 соответственно, будут совпадать. Внутренние события возникают вследствие вызовов API-функций файлом 104 в ОС и характеризуют поведение файла 104 в процессе исполнения. На Фиг. 3 приведен пример дополнения второго журнала 111 записями из первого журнала 110. Если первый журнал 110 содержит N1 записей о вызовах API-функций и M1 записей о внутренних событиях (суммарно N1+M1 записей), а второй журнал 111 содержит М2 записей о внутренних событиях, то М2≥Ml, и все M1 записей первого журнала 110 совпадают с первыми M1 записями второго журнала 111. Таким образом, дополнение второго журнала 111 может быть произведено путем замены первых M1 записей второго журнала 111 на все N1+M1 записи первого журнала 110. В итоге результирующее число записей дополненного второго журнала 111 будет содержать N1+M2 записей, из них N1 записей о вызовах API-функций и М2 записей о внутренних событиях.

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

На шаге 204 средство проверки 106 выявляет во втором журнале 111 сигнатуру второго типа из базы данных сигнатур второго типа 121. Сигнатура второго типа содержит не менее, чем две записи о внутренних событиях.

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

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

Для этого на шаге 205 антивирусное приложение 101 определяет критерии внесения записей о вызовах API-функций на основании второго журнала 111 и первого журнала 110. Например, критерием внесение записей о вызовах API-функций может быть следующее условие: наступление внутреннего события с порядковым номером записи во втором журнале 111, которая находится во втором журнале 111 перед первой записью выявленной сигнатуры второго типа. В еще одном примере критериями внесения записей о вызовах API-функций может быть внесение записей о вызовах API-функций после обнаружения сигнатур второго типа во втором журнале 111 и первом журнале 110.

На шаге 206 антивирусное приложение 101 производит третье исполнение файла 104 на виртуальной машине 102, при этом во время исполнения файла 104 в третий журнал 112 с помощью средства журналирования 105 производится внесение записей только о внутренних событиях до тех пор, пока не будут выполнены условия критерия внесения записей о вызовах API-функций, после чего в третий журнал 112 начинает производиться внесение записей о вызовах API-функций. Также, как и на этапах 201 и 203, исполнение файла 104 на этапе 206 происходит до наступления одного из событий: истек заданный период времени исполнения, или завершено исполнение программного кода файла 104.

В итоге на шаге 207 с помощью средства проверки 106 выполняется антивирусная проверка файла 104 путем выявления в третьем журнале 112 вредоносной сигнатуры с использованием базы данных вредоносных сигнатур 122. Каждая вредоносная сигнатура содержит по крайней мере одну запись, содержащую в свою очередь по меньшей мере информацию о вызовах API-функций или о внутренних событиях. Файл будет признан вредоносном, когда упомянутая вредоносная сигнатура будет выявлена по меньшей мере в третьем журнале.

Под подозрительными активностями в рамках настоящего изобретения понимаются события, получаемые с помощью антивирусного приложения 101 на основании записей журналов 110-112 о вызовах API-функций и о внутренних событиях. Т.е. подозрительные активности определяют действия, выполняемые в результате вызова соответствующих API-функций, содержащихся в первом журнале 110. В таблице 2 на Фиг. 6 приведены примеры подозрительных активностей. Например, первая запись таблицы 2 содержит информацию о подозрительной активности autorun, содержащей следующие поля: уникальный идентификатор процесса (PID); уникальный идентификатор потока (TID); имя ключа реестра (registry_key); путь к файлу, который добавлен в автозапуск (Target_file); путь к файлу, из которого был запущен процесс, совершающий действие (Image_path). Данная подозрительная активность описывает процесс, запущенный из «image_path», который добавил файл «Target_file» в автозапуск (ключ реестра «registry_key»). Конкретный пример такой подозрительной активности представлен в таблице 2. В частном варианте реализации сигнатура второго типа дополнительно содержит записи о подозрительных активностях.

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

Например, поиск первой сигнатуры будет осуществляться в третьем журнале 112. Для этого в третьем журнале 112 средство проверки 106 будет искать записи сигнатуры А) - Г) и, если они все содержатся в третьем журнале 112 согласно правилу сигнатуры, то файл 104 будет считаться вредоносным. Так, запись А) означает копирование процессом самого в себя. Запись Б) будет найдена, когда в журнале будет найден вызов API-функции, в аргументе которой содержится строка «.exe /**installservice». Аналогичное значение имеет запись В). Запись Г) означает, что журнал должен содержать вызов API-функции «DeleteFile("$selfpath\\$selfname.exe")», где «$selfpath» - путь к файлу, a «$selname.exe» - имя файла.

Вторая сигнатура в таблице 3 содержит те же записи, что и первая сигнатура, однако правило более широкое - объединенный журнал должен содержать по крайней мере любые три записи А) - Г). Объединенный журнал получается объединением записей трех журналов 110-112 и более подробно будет описан ниже.

Как объяснялось ранее, при каждом исполнении файла 104 на виртуальной машине 102 в независимости от внесения записей о вызовах API-функций внутренние события, записываемые в любой из журналов 110-112, будут одинаковыми. Таким образом, в частном варианте реализации можно объединить все три журнала 110-112 для получения наиболее полной информации об исполнении файла на виртуальной машине и на шаге 207 выполнять антивирусную проверку файла путем выявления в объединенном журнале вредоносной сигнатуры.

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

В частном варианте реализации на шаге 201 сохраняют первый дамп памяти операционной системы после завершения исполнения файла 104 на виртуальной машине 102 с помощью антивирусного приложения 101. На шаге 203 сохраняют с помощью антивирусного приложения 101 второй дамп памяти ОС после завершения исполнения файла 104 на виртуальной машине 102. На шаге 206 сохраняют третий дамп памяти ОС после завершения исполнения файла 104 на виртуальной машине 102.

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

В другом примере реализации на шаге 207 выполнение антивирусной проверки файла может происходить лишь путем выявления в одном или нескольких сохраненных дампах памяти ОС вредоносных сигнатур, при этом в данном примере вредоносные сигнатуры содержат строки из дампа памяти ОС. Ниже, в таблице 4, приведены примеры вредоносных сигнатур, использующие дамп памяти и журналы 110-112.

На Фиг. 4 приведен пример объединения трех журналов. Пусть первый журнал 110 содержит N1 записей о вызовах API-функций и M1 записей о внутренних событиях (суммарно N1+M1 записей). Второй журнал 111 содержит суммарно М2 записей о внутренних событиях (М2≥M1), и все M1 записей первого журнала 110 совпадают с первыми M1 записями второго журнала 111, а также с первыми M1 записями третьего журнала 112. Объединенный журнал получается путем замены этих M1 записей в третьем журнале 112 на N1+M1 записей о вызовах API-функций и о внутренних событиях первого журнала 110.

В конце третьего журнала 112 содержится N2 записей о вызовах API-функций и М3 записей о внутренних событиях (суммарно N2+M3 записей). Данные МЗ записей о внутренних событиях соответствуют М3 записям о внутренних событиях во втором журнале 111. При этом во втором журнале 111 после М3 записей может содержаться еще некоторое количество записей о внутренних событиях, которые будут добавлены в конце объединенного журнала.

Таким образом, в начале объединенного журнала содержатся N1+M1 записей о вызовах API-функций и внутренних событий, далее следуют М2-М1-М3-М4 записей только о внутренних событиях, далее - N2+M3 записей о вызовах API-функций и внутренних событиях и в конце - М4 записей о внутренних событиях.

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

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

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

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

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

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

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

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

1. Реализуемый компьютером способ выполнения антивирусной проверки файла на виртуальной машине, в котором:

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

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

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

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

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

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

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

2. Способ по п. 1, в котором на шаге в) с использованием средства проверки выявляют сигнатуры первого анализа с использованием второго журнала, дополненного записями из первого журнала.

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

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

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

• уникальный идентификатор процесса (process identifier, PID), запущенного из упомянутого файла, вызвавшего API-функцию;

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

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

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

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

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

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

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

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

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

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

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

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

• процедур передачи управления по адресу возврата из API-функций;

• прямых вызовов Windows NT Native API-функций;

• возвратов из Windows NT Native API-функций;

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

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

• сетью;

• реестром;

• файловой системой;

• оперативной памятью;

• процессами и потоками.

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

• путем перехвата системных вызовов;

• с использованием механизмов нотификации ядра ОС;

• путем встраивания драйвера в стек драйверов ОС.

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

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

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

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

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

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

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

• изменение списка автозагрузки через системный реестр;

• сетевую активность;

• создание новых файлов;

• процессы, удаляющие исполняемые файлы, из которых запущены упомянутые процессы.

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

18. Способ по п. 17, в котором дополнительно с помощью средства журналирования выполняют следующие действия:

• на шаге а) сохраняют первый дамп памяти ОС после завершения исполнения файла на виртуальной машине;

• на шаге в) сохраняют второй дамп памяти ОС после завершения исполнения файла на виртуальной машине;

•на шаге е) сохраняют третий дамп памяти ОС после завершения исполнения файла на виртуальной машине.

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

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

21. Система выполнения антивирусной проверки файла на виртуальной машине, содержащая:

а) антивирусное приложение, предназначенное для:

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

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

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

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

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

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

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

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

д) средство журналирования, связанное с антивирусным приложением, и предназначенное для

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

- внесения записей о внутренних событиях во второй журнал во время повторного исполнения файла на виртуальной машине;

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

- внесения записей в третий журнал вызовов API-функций, после выполнения критерия внесения записей о вызовах API-функций;

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

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

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

и) средство проверки, связанное с антивирусным приложением и предназначенное для

- выявления в первом журнале по меньшей мере одной сигнатуры первого типа из базы данных сигнатур первого типа;

- выявления во втором журнале по меньшей мере одну сигнатуру второго типа из базы данных сигнатур второго типа;

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

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

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

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

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

• уникальный идентификатор процесса (process identifier, PID), запущенного из упомянутого файла, вызвавшего API-функцию;

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

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

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

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

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

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

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

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

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

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

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

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

• процедур передачи управления по адресу возврата из API-функций;

• прямых вызовов Windows NT Native API-функций;

• возвратов из Windows NT Native API-функций;

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

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

• сетью;

• реестром;

• файловой системой;

• оперативной памятью;

• процессами и потоками.

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

• путем перехвата системных вызовов;

• с использованием механизмов нотификации ядра ОС;

• путем встраивания драйвера в стек драйверов ОС.

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

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

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

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

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

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

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

• изменение списка автозагрузки через системный реестр;

• сетевую активность;

• создание новых файлов;

• процессы, удаляющие исполняемые файлы, из которых запущены упомянутые процессы.

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

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

• сохранения первого дампа памяти ОС после завершения исполнения файла на виртуальной машине;

• сохранения второго дампа памяти ОС после завершения исполнения файла на виртуальной машине;

• сохранения третьего дамп памяти ОС после завершения исполнения файла на виртуальной машине.

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

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