Система и способ обнаружения вредоносного кода в файле

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно другому частному варианту реализации подозрительным событием дополнительно является по меньшей мере одно из следующих: вызов API-функции из списка подозрительных API-функций; возникновение исключительной ситуации в ходе выполнения процесса; выделение процессом динамической памяти заданное число раз; исполнение процессом программного кода на стеке; отсутствие инструкции call перед инструкцией ret; изменение процессом обработчика исключений; нарушение прав доступа при выполнении инструкции call; указатель на стек процесса вышел за границы области, указанные в ТЕВ (thread exection block).

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

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

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

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

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

Согласно другому частному варианту реализации сигнатура второго типа включает следующие события: получение адресов дескрипторов системных библиотек; выделение памяти; чтение системных структур (англ. process environment block - РЕВ); последовательное получение дескрипторов файлов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно другому частному варианту реализации подозрительным событием дополнительно является по меньшей мере одно из следующих: вызов API-функции из списка подозрительных API-функций; возникновение исключительной ситуации в ходе выполнения процесса; выделение процессом динамической памяти заданное число раз; исполнение процессом программного кода на стеке; отсутствие инструкции call перед инструкцией ret; изменение процессом обработчика исключений; нарушение прав доступа при выполнении инструкции call; указатель на стек процесса вышел за границы области, указанные в ТЕВ (thread exection block).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На Фиг. 3 представлен подробный способ выполнения процесса на эмуляторе.

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

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

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

На Фиг. 1 представлена компьютерная система обнаружения вредоносного кода в файле. В частном варианте реализации вредоносным кодом может быть шелл-код (англ. shellcode, код запуска оболочки). Шелл-код обычно внедряется в память процесса, загруженного из файла, после чего на него передается управление, например, путем переполнения буфера, в том числе переполнение буфера на стеке. В результате исполнения шелл-кода, злоумышленник может выполнить вредоносные действия на компьютере, например, выполнить загрузку исполняемого вредоносного файла из сети и сохранить его на компьютер жертвы. Песочница (англ. sandbox) 130 представляет собой компьютерную среду для безопасного исполнения процессов. В частном варианте реализации, песочница может быть реализована, например, в виде виртуальной машины, на основе частичной виртуализации файловой системы и реестра, на основе правил доступа к файловой системе и реестру или на основе смешанного подхода. На Фиг. 1 представлен пример реализации песочницы в виде виртуальной машины, на которой установлена операционная система (ОС) 131. Песочница 130 предназначена для исполнения процесса, запущенного из файла 134, под контролем антивирусного приложения 110. Стоит отметить, что файл 134 может являться файлом любого формата данных и может содержать любые данные. В частном варианте реализации, файл 134 может быть файлом формата офисных приложений (например, Microsoft Word, Excel, PowerPoint, Access; Adobe Acrobat и т.д.), наиболее подверженных уязвимостям. Соответственно в этом случае процесс, запущенный из файла 134 будет процессом соответствующего приложения (Например, процесс WINWORD.EXE для приложения Microsoft Word). В другом частном варианте реализации, файл 134 может быть исполняемым файлом, например РЕ-файлом (англ. Portable executable - переносимый исполняемый).

Внутри песочницы содержится средство проверки 132 и связанное с ним средство журналирования 132. Во время исполнения процесса, средство журналирования 133 перехватывает вызовы API-функций и последовательно вносит записи о них в первый журнал 137, также расположенный в песочнице 130. На момент перехвата вызовов API-функций средством журналирования 133, средство проверки 132 сохраняет дампы памяти процесса в базу дампов 136.

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

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

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

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

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

Средство журналирования 133 также передает перехваченные вызовы API-функций средству проверки 132, которое на основании вызовов API-функций определяет произошедшие во время исполнения процесса подозрительные события из списка подозрительных событий, которые хранятся в базе данных подозрительных событий 135. Подозрительное событие - это событие, произошедшее в результате вызовов процессом API-функций и свойственное исполняющемуся вредоносному коду. Таким образом, подозрительное событие определяется на основании вызовов API-функций, снимков внутреннего состояния процессора, регистров процессора, содержимого стека. Например, подозрительным событием может быть вызов API-функции из списка подозрительных API-функций, таких как WinExec, CreateProcess, GetFileSize и пр. Список подозрительных событий может быть заранее составлен антивирусным аналитиком и помещен в базу данных подозрительных событий 135. Ниже будут рассмотрены другие подробные примеры подозрительных событий.

Средство проверки 132 служит также для внесения записей о подозрительных событиях в первый журнал 137 и для сохранения дампа памяти процесса в базу дампов 136 на момент выявления подозрительного события или на момент перехвата вызова API-функции средством журналирования 133. В частном варианте реализации средство проверки 132 сохраняет дамп памяти процесса начиная с начального адреса, в котором произошло подозрительное событие или вызов API-функции, выравненного до нижней границы страницы, до конечного адреса, увеличенного на заданное число относительно начального адреса, при выявлении подозрительного события или при перехвате вызова API-функции. Например, дамп памяти может содержать 16 страниц, начиная с адреса, в котором произошло подозрительное событие или вызов API-функции. В другом частном варианте реализации, начальный адрес памяти может быть дополнительно уменьшен на заданное число. В еще одном частном примере реализации, для более точного вычисления начального и конечного адресов, может быть вызвана процедура ZwQueryVirtualMemory, возвращающая информацию о регионе памяти и, в частности, если она отработана успешно, можно получить базовый адрес региона и размер региона. В этом случае, в качестве начального адреса дампа памяти будет взято максимальное значение из базового адреса региона памяти и ранее определенного начального адреса дампа памяти. А конечный адрес дампа памяти вычисляется как минимальное значение из ранее вычисленного значения конечного адреса дампа памяти и базового адреса региона памяти, увеличенного на размер региона памяти.

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

Средство проверки 132 проверяет условие выхода после выполнения предыдущего шага (сохранение дампа памяти). В частном варианте реализации условием выхода является одно из:

- процесс завершился;

- истек заданный период времени;

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

- количество выполненных процессом инструкций превысило заданный порог количества инструкций (например, 100000 инструкций);

- количество подозрительных событий, определенных средством проверки, превысило заданный порог количества подозрительных событий (например, 3 подозрительных события).

Если условие выхода не выполнилось, средство проверки 132 инициирует повторение предыдущих шагов (см. подробнее в описании к Фиг. 2).

Если условие выхода выполнилось, т.е. завершено исполнение процесса, запущенного из файла 134 в песочнице 130, антивирусное приложение 110 сохраняет записи первого журнала 137, содержащегося в песочнице, в первый журнал 122, содержащийся в операционной системе, в которой работает антивирусное приложение 110. Записи базы дампов 136 сохраняются в базу дампов 121.

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

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

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

- вызов API-функции из списка подозрительных API-функций (например, список может содержать следующие API-функции: WinExec, CreateProcess, GetFileSize);

- возникновение исключительной ситуации в ходе выполнения процесса;

- многократное (заданное число раз) выделение процессом динамической памяти (например, 200 раз);

- исполнение процессом программного кода на стеке;

- отсутствие инструкции call перед инструкцией ret;

- изменение процессом обработчика исключений;

- нарушение прав доступа при выполнении инструкции call;

- указатель на стек процесса вышел за границы области, указанные в ТЕВ (thread environment block).

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

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

- нарушение прав доступа при выполнении инструкции call;

- нарушение прав доступа при записи в память;

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

- нарушение политики предотвращения выполнения данных;

- переполнение буфера на стеке;

- повреждение динамической памяти (англ. heap corruption);

- попытка выполнить запрещенную, некорректную или привилегированную инструкцию.

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

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

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

После выявления сигнатуры первого типа, антивирусное приложение 110 передает на исполнение в эмулятор 111 по меньшей мере один сохраненный дамп памяти. Эмулятор 111 дизассемблирует исполняемый код, содержащийся в дампах памяти, и, исполняет его в своей виртуальной среде. Во время исполнения, эмулятор 111 определяет переходы по адресам вызовов API-функций (например, оператор call CreateFile, передающий управление API-функции CreateFile). Далее, эмулятор 111 производит последовательное внесение во второй журнал 125 записей о вызовах API-функций.

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

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

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

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

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

В частном варианте реализации антивирусное приложение 110 дополнительно предназначено для записи трассы выполнения процесса во второй журнал 125 во время исполнения процесса на эмуляторе 111. Трасса выполнения процесса содержит непрерывную последовательность выполняемых на процессоре инструкций и снимки внутреннего состояния процессора при выполнении каждой инструкции.

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

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

- получение адресов дескрипторов системных библиотек (например, kernel32.dll, ntdll.dll);

- выделение памяти;

- чтение системных структур (англ. process environment block - РЕВ);

- последовательное получение дескрипторов файлов.

Событие доступа процесса к памяти может быть определено из трассы выполнения процесса: по содержанию инструкции типа «mov еах, [ebx]», например:

В еще одном примере, второго типа может содержать следующую запись трассы выполнения процесса:

Приведенная выше запись трассы выполнения процесса означает, что произошло чтение памяти по адресу USER32.dll (регистр ЕАХ содержит адрес библиотеки USER32.dll).

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

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

Ниже приведены примеры таких сигнатур второго типа, содержащих упомянутые условия:

1) вызов API-функции GetFileSize был совершен 10 раз;

2) после вызова API-функции WriteFile (запись в файл) будет следовать вызов API-функции WinExec (запуск файла на исполнение);

3) чтение памяти по адресу user32.dll с последующем чтением памяти по адресу kernel32.dll;

4) создание процессом, запущенным из файла 134 вредоносного файла и добавление его в автозагрузку;

5) исполняемый процесс, скопировал файл 134, из которого он был запущен.

Кроме вызовов API-функций, с помощью средства журналирования 133 может происходить также перехват и последующее сохранение в первый журнал 137 записей, содержащих информацию о следующих объектах:

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

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

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

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

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

В частном варианте реализации эмулятор 111 предназначен для внесения во второй журнал 125 одной или нескольких записей, содержащих информацию о чтении системных структур (англ. process environment block -РЕВ), о получении адресов дескрипторов системных библиотек (например, kernel32.dll, ntdll.dll).

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

- сетью;

- реестром;

- файловой системой (например, fopen(), create());

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

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

В описанных выше примерах реализации, средство журналирования 133 получает информацию о системных вызовах одним из следующих способов:

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

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

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

Эмулятор 111 получает информацию о системных вызовах по адресам передачи управления.

На Фиг. 2 представлен вариант способа обнаружения вредоносного кода в файле (например, шелл-кода). На шаге 201 под контролем антивирусного приложения 110 с использованием песочницы 130 исполняют процесс, запущенный из файла 134. Далее, на шаге 202 с использованием средства журналирования 133 перехватывают вызовы API-функций во время исполнения процесса. На шаге 203 с использованием средства журналирования 133 производят последовательное внесение записей о перехваченных API-вызовов в первый журнал 137.

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

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

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

В итоге, на шаге 206 средство проверки 132 проверяет условие выхода и, если оно не выполнено, инициирует повтор шагов 201-205. Если же условие выхода выполнено, продолжают выполнение способа на шаге 207. В частном варианте реализации условием выхода является одно из:

i) процесс завершился;

ii) истек заданный период времени;

iii) шаги 201-205 были выполнены заданное число повторений;

iv) количество выполненных процессом инструкций превысило заданный порог количества инструкций;

v) количество подозрительных событий, определенных средством проверки превысило заданный порог количества подозрительных событий.

В частном варианте реализации, на шаге 206 при выполнении одного из условий выхода с номером ii)-v), антивирусным приложением 110 может быть сохранено состояние песочницы 130. При этом, если наступило условие выхода i), нет необходимости сохранять состояние песочницы 130, т.к. процесс завершился. На примере виртуальной машины, будет сохранен моментальный снимок виртуальной машины (англ. snapshot), который включает содержимое памяти виртуальной машины, регистры процессора и т.д. И, если на шаге 209 антивирусным приложением 110 не была выявлена сигнатура второго типа, файл 134 будет снова передан на исполнение в песочнице 130 с использованием сохраненного состояния, т.е. будут выполнены шаги 201-205 до наступления условия выхода на шаге 206. Например, шаги 201-205 были выполнены один раз до выявления первого подозрительного события, далее выполнение в песочнице 130 было приостановлено с целью дополнительного анализа файла 134 в эмуляторе 111. Однако, если эмулятор 111 не смог выявить вредоносный код в файле 134, исполнение файла 134 в песочнице 130 может быть продолжено до наступления следующего условия выхода (например, определено следующее подозрительное событие или процесс завершился). Такой вариант реализации позволяет увеличить скорость выполнения антивирусной проверки, т.к. условием выхода является определение на шаге 204 первого подозрительного события, не дожидаясь завершения исполнения процесса или истечения заданного периода времени. В то же время, качество определения вредоносного кода в файле 134 не снижается, т.к. при необходимости, шаги 201-205 будут повторены.

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

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

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

После выполнения условия выхода, т.е. после завершения исполнения процесса в песочнице, первый журнал 137 переносится на компьютер в первый журнал 122, а база дампов 136 переносится в базу дампов 121. На шаге 207 с помощью антивирусного приложения 110 выявляют в первом журнале 122 одну или несколько сигнатур первого типа. Каждая сигнатура первого типа - это структура данных, которая содержит по меньшей мере одну запись, содержащую, в свою очередь, информацию о вызове API-функции или информацию о подозрительном событии.

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

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

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

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

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

На Фиг. 3 представлен подробный способ выполнения процесса на эмуляторе на шаге 208. Во время исполнения процесса, на шаге 301, эмулятор 111 определяет переходы по адресам вызовов API-функций (например, оператор call CreateFile, передающий управление API-функции CreateFile). В частном варианте реализации, далее, на шаге 302, эмулятор 111 производит последовательное внесение во второй журнал 125 записей о вызовах API-функций.

В еще одном частном варианте реализации после шага 301 последует шаг 303, на котором антивирусное приложение записывает трассу выполнения процесса во второй журнал 125 во время исполнения процесса на эмуляторе 111. Трасса выполнения процесса содержит непрерывную последовательность выполняемых на процессоре инструкций и снимки внутреннего состояния процессора при выполнении каждой инструкции. В этом случае сигнатура второго типа содержит инструкции процессора и записи снимков внутреннего состояния процессора.

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

В итоге, после шага 302 или шага 303 соответственно, на шаге 209 антивирусное приложение 110 определяет вредоносный код в файле 134, при выявлении во втором журнале 125 одной или нескольких сигнатур второго типа. Сигнатура второго типа является структурой данных, которая содержит по меньшей мере одну из записей: информацию о вызовах API-функций, инструкции процессора и записи снимков внутреннего состояния процессора.

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

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

Более подробное описание сигнатур второго типа было представлено ранее, в описании Фиг.1.

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

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

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

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

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

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

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

в) выполняют по меньшей мере одно из следующих действий:

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

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

- уникальный идентификатор процесса (PID);

- уникальный идентификатор потока (TID);

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

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

г) повторяют шаги а)-в) до выполнения условия выхода;

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

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

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

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

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

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

- информацию о вызове API-функции;

- инструкции процессора и записи снимков внутреннего состояния процессора.

2. Способ по п. 1, в котором условием выхода является одно из:

i) процесс завершился;

ii) истек заданный период времени;

iii) шаги а)-в) были выполнены заданное число повторений;

iv) количество выполненных процессом инструкций превысило заданный порог количества инструкций;

v) количество подозрительных событий, определенных средством проверки, превысило заданный порог количества подозрительных событий.

3. Способ по п. 2, в котором после завершения исполнения процесса в песочнице, с использованием средства проверки дополнительно сохраняют дамп памяти процесса на момент завершения его исполнения.

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

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

6. Способ по п. 5, в котором подозрительным событиям с помощью средства проверки назначают различный вес, при этом условие выхода зависит от веса подозрительных событий.

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

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

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

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

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

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

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

- исключительных ситуаций.

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

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

- сетью;

- реестром;

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

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

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

12. Способ по п. 11, в котором подозрительным событием дополнительно является по меньшей мере одно из следующих:

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

- возникновение исключительной ситуации в ходе выполнения процесса;

- выделение процессом динамической памяти заданное число раз;

- исполнение процессом программного кода на стеке;

- отсутствие инструкции call перед инструкцией ret;

- изменение процессом обработчика исключений;

- нарушение прав доступа при выполнении инструкции call;

- указатель на стек процесса вышел за границы области, указанные в блоке окружения потока (ТЕВ).

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

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

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

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

14. Способ по п. 12, в котором выявляют следующие исключительные ситуации:

- нарушение прав доступа при выполнении инструкции call;

- нарушение прав доступа при записи в память;

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

- нарушение политики предотвращения выполнения данных;

- переполнение буфера на стеке;

- повреждение динамической памяти;

- попытка выполнить запрещенную, некорректную или привилегированную инструкцию.

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

- сетью;

- реестром;

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

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

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

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

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

18. Способ по п. 1, в котором сигнатура второго типа включает следующие события:

- получение адресов дескрипторов системных библиотек;

- выделение памяти;

- чтение блока операционного окружения процесса (РЕВ);

- последовательное получение дескрипторов файлов.

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

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

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

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

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

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

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

22. Способ по п. 1, в котором вредоносный код является шелл-кодом.

23. Способ по п. 1, в котором песочница реализована одним из следующих способов:

- в виде виртуальной машины;

- на основе частичной виртуализации файловой системы и реестра;

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

- на основе смешанного подхода.

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

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

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

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

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

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

i) первый журнал;

ii) базу дампов;

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

(1) перехвата вызовов API-функций во время исполнения процесса,

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

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

- уникальный идентификатор процесса (PID);

- уникальный идентификатор потока (TID);

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

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

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

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

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

(4) проверки выполнения условия выхода после выполнения шага в) по п. 1, после выполнения предыдущего шага,

(5) инициации повторения шагов а)-в) способа по п. 1 при невыполнении упомянутого условия выхода;

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

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

ii) передачи на исполнение в эмулятор по меньшей мере одного сохраненного дампа памяти после выявления по меньшей мере одной сигнатуры первого типа;

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

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

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

- информацию о вызове API-функции;

- инструкции процессора и записи снимков внутреннего состояния процессора;

в) упомянутый второй журнал, связанный с эмулятором и антивирусным приложением;

г) упомянутую базу сигнатур первого типа;

д) упомянутую базу сигнатур второго типа.

29. Система по п. 28, в которой условием выхода является одно из:

i) процесс завершился;

ii) истек заданный период времени;

iii) предыдущие шаги были выполнены заданное число повторений;

iv) количество выполненных процессом инструкций превысило заданный порог количества инструкций;

v) количество подозрительных событий, определенных средством проверки, превысило заданный порог количества подозрительных событий.

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

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

32. Система по п. 29, в которой при выполнении одного из условий выхода с номером ii)-v) дополнительно антивирусное приложение предназначено для сохранения состояния песочницы и, если с помощью антивирусного приложения не была выявлена сигнатура второго типа, то антивирусное приложение предназначено для передачи на исполнение процесса в песочнице с использованием сохраненного состояния песочницы до наступления условия выхода.

33. Система по п. 32, в которой средство проверки предназначено для назначения различного веса подозрительным событиям, при этом условие выхода зависит от веса подозрительных событий.

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

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

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

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

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

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

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

- исключительных ситуаций.

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

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

- сетью;

- реестром;

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

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

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

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

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

- возникновение исключительной ситуации в ходе выполнения процесса;

- выделение процессом динамической памяти заданное число раз;

- исполнение процессом программного кода на стеке;

- отсутствие инструкции call перед инструкцией ret;

- изменение процессом обработчика исключений;

- нарушение прав доступа при выполнении инструкции call;

- указатель на стек процесса вышел за границы области, указанные в блоке окружения потока (ТЕВ).

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

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

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

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

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

- нарушение прав доступа при выполнении инструкции call;

- нарушение прав доступа при записи в память;

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

- нарушение политики предотвращения выполнения данных;

- переполнение буфера на стеке;

- повреждение динамической памяти;

- попытка выполнить запрещенную, некорректную или привилегированную инструкцию.

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

- сетью;

- реестром;

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

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

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

43. Система по п. 42, в которой эмулятор служит для получения информации о системных вызовах по адресам передачи управления.

44. Система по п. 28, в которой антивирусное приложение служит для выделения из трассы выполнения процесса инструкций, относящихся к процессу, запущенному из файла.

45. Система по п. 28, в которой сигнатура второго типа включает следующие события:

- получение адресов дескрипторов системных библиотек;

- выделение памяти;

- чтение блока операционного окружения процесса (РЕВ);

- последовательное получение дескрипторов файлов.

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

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

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

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

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

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

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

49. Система по п. 28, в которой вредоносный код является шелл-кодом.

50. Система по п. 28, в которой песочница реализована одним из следующих способов:

- в виде виртуальной машины;

- на основе частичной виртуализации файловой системы и реестра;

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

- на основе смешанного подхода.

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

52. Система по п. 51, в которой упомянутые условия являются следующими: проверка количества записей сигнатуры, проверка порядка следования записей сигнатуры.

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

54. Система по п. 53, в которой упомянутые условия являются следующими: проверка количества записей сигнатуры, проверка порядка следования записей сигнатуры.