Результат интеллектуальной деятельности: Система и способ оптимизации антивирусной проверки файлов

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

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

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

Запуск исполняемого файла (от англ. Portable Executables, РЕ), в том числе динамической библиотеки (от англ. Dynamic Link Library, DLL), может быть не безопасным для пользователей, т.к. наибольшее распространение вредоносного кода производится с помощью исполняемых файлов (например, при помощи вирусов и троянских программ). Поэтому перед запуском исполняемого файла желательно производить антивирусную проверку таких файлов. При этом антивирусная проверка может основываться как на простых методах проведения проверки, так и на сложных. Примером простой проверки является сигнатурное сканирование, которое позволяет выявлять известные вредоносные программы среди всех программ, но при этом является длительной процедурой, так как антивирусная база данных, с использованием которой требуется произвести проверку, может быть огромной. Примером же сложных проверок являются различные технологии, использующие анализ поведения исполняемых файлов. Данные технологии могут использовать эмулятор кода с аналитическим модулем для проведения глубокого анализа файлов. Все указанные проверки позволяют обеспечить безопасность как ресурсов компьютерных систем, так и личных (конфиденциальных) данных пользователей. При этом в зависимости от вида антивирусной проверки требуется различное количество компьютерных ресурсов для ее выполнения. В то же время компьютер обладает ограниченным количеством ресурсов.

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

Одни из таких подходов для оптимизации антивирусных проверок файлов связаны, как правило, с использованием так называемых «белых списков» (от англ. whitelist) и «черных списков» (от англ. blacklist) или основаны на отслеживании факта модификации файла (например, через временные метки), после которого будет произведена проверка. При этом указанные подходы могут быть связаны с различными видами исполняемых файлов, такими как объектный код (от англ. object code), исполняемые файлы формата РЕ, макросы (от анг. macros), сценарии (от англ. scripts) и т.д.

Так, например, в патенте US 7490352B2 описан подход проверки доверенности исполняемого файла на момент начала исполнения файла. Подход заключается в определении принадлежности проверяемого файла к вредоносному типу файлов, проверке целостности файла и надежности источника, который передает или запускает файл.

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

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

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

Сущность изобретения

Изобретение предназначено для оптимизации процесса антивирусной проверки файлов путем исключения исполняемых файлов, а именно динамических библиотек и/или ресурсных файлов (таких как NE-файлы (файлы формата New Executable)), из антивирусной проверки.

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

В качестве одного из вариантов исполнения предлагается система исключения из антивирусной проверки динамической библиотеки, которая не содержит исполняемого кода, при этом указанная система включает в себя: средство проверки, предназначенное для получения динамической библиотеки на антивирусную проверку, передачи динамической библиотеки средству разбора и исключения из антивирусной проверки динамической библиотеки, которая не содержит исполняемого кода, на основании полученного от средства анализа решения; упомянутое средство разбора, предназначенное для разбора структуры динамической библиотеки, во время которого определяют формат динамической библиотеки с помощью проверки заголовка динамической библиотеки, при этом форматом является один из: «Native DLL» и «.NET Assembly DLL», и передачи информации о формате динамической библиотеки и структуры динамической библиотеки средству анализа; упомянутое средство анализа, предназначенное для выбора перечня условий из базы данных на основании информации о формате динамической библиотеки, при этом перечень условий содержит условия для анализа структуры динамической библиотеки, проведения анализа структуры динамической библиотеки с использованием выбранного перечня условий, при этом анализ заключается в проверке выполнения каждого условия из выбранного перечня условий, формирования результата упомянутого анализа, который содержит информацию о выполнении каждого проверенного условия, вынесения решения об отсутствии исполняемого кода в динамической библиотеке при выполнении всех условий из перечня условий и передачи вынесенного решения упомянутому средству проверки; упомянутую базу данных, связанную с упомянутым средством анализа, предназначенную для хранения перечней условий.

В другом варианте исполнения системы средство разбора определяет формат динамической библиотеки на основании анализа заголовка динамической библиотеки по значению поля «characteristics».

В еще одном варианте исполнения системы перечень условий для формата «Native DLL» содержат по крайней мере три из следующих условий:

- адрес и размер секции Resource table (секция ресурсов) не равны нулю;

- адрес и размер секции Export table (секция экспортов) равны нулю;

- адрес и размер секции Import table (секция импортов) равны нулю;

- адрес и размер секции Import address table (секция таблицы импортов) равны нулю;

- адрес и размер секции Thread local storage table (секция памяти потока) равны нулю.

В другом варианте исполнения системы перечень условий для формата «.NET Assembly DLL» содержит по крайней мере три из следующих условий:

- точка входа на импортируемую функцию _CorDllMain, в которой отсутствуют другие импортируемые функции, и сама функция CorDllMain импортируется из mscoree.dll;

- отсутствуют любые импортируемые функции, кроме функции, импортируемой из библиотеки mscoree.dll;

- адрес и размер секции Export table (секция экспортов) равны нулю;

- адрес и размер секции Thread local storage table (секция памяти потока) равны нулю;

- адрес и размер секции «.NET MetaData» отличны от нуля;

- адрес и размер секции «ManagedNativeHeader» равны нулю;

- наличие управляемых ресурсов, размер которых отличен от нуля;

- в поле «MaskValid» отсутствуют биты, связанные с таблицами следующих методов: MethodDef, MethodPtr, MethodSemantics, MethodImpl и MetodSpec.

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

В другом варианте исполнения системы перечень условий для формата «Native DLL» содержат по крайней мере еще два условия, а именно адрес точки входа указывает на нулевой адрес (0×00) и в начале массива секций для каждой исполняемой секции отсутствует указатель на исполнение.

В еще одном варианте исполнения системы перечень условий для формата «.NET Assembly DLL» содержит по крайней мере еще два условия, а именно наличие одной секции с правом на исполнение и точка входа должна указывать или на нулевой адрес (0×00), или на точку входа определенной секции с правами на исполнения, при этом точка входа для файла .NET указывает на вызов функций «_CorDllMain» из библиотеки mscoree.dll.

В качестве другого варианта исполнения предлагается способ исключения из антивирусной проверки динамической библиотеки, которая не содержит исполняемого кода, при этом способ содержит этапы, на которых: получают с помощью средства проверки динамическую библиотеку на антивирусную проверку; производят с помощью средства разбора разбор структуры динамической библиотеки, во время которой определяют формат динамической библиотеки с помощью проверки заголовка динамической библиотеки, при этом форматом является один из: «Native DLL», «.NET Assembly DLL»; выбирают с помощью средства анализа перечень условий из базы данных на основании информации о формате динамической библиотеки, при этом перечень условий содержит условия для анализа структуры динамической библиотеки; проводят с помощью средства анализа анализ структуры динамической библиотеки с использованием выбранного перечня условий, при этом анализ заключается в проверке выполнения каждого условия из выбранного перечня условий; формирования с помощью средства проверки результата упомянутого анализа, который содержит информацию о выполнении каждого проверенного условия; выносят с помощью средства анализа решение об отсутствии исполняемого кода в динамической библиотеке при выполнении всех условий из перечня условий; исключают с помощью средства проверки из антивирусной проверки динамическую библиотеку, которая не содержит исполняемого кода, на основании вынесенного решения.

В другом варианте исполнения способа определяют формат динамической библиотеки на основании анализа заголовка динамической библиотеки по значению поля «characteristics».

В еще одном варианте исполнения способа перечень условий для формата «Native DLL» содержат по крайней мере три из следующих условий:

- адрес и размер секции Resource table (секция ресурсов) не равны нулю;

- адрес и размер секции Export table (секция экспортов) равны нулю;

- адрес и размер секции Import table (секция импортов) равны нулю;

- адрес и размер секции Import address table (секция таблицы импортов) равны нулю;

- адрес и размер секции Thread local storage table (секция памяти потока) равны нулю.

В другом варианте исполнения способа перечень условий для формата «.NET Assembly DLL» содержит по крайней мере три из следующих условий:

- точка входа на импортируемую функцию _CorDllMain, в которой отсутствуют другие импортируемые функции, и сама функция _CorDllMain импортируется из mscoree.dll;

- отсутствуют любые импортируемые функции, кроме функции, импортируемой из библиотеки mscoree.dll;

- адрес и размер секции Export table (секция экспортов) равны нулю;

- адрес и размер секции Thread local storage table (секция памяти потока) равны нулю;

- адрес и размер секции «.NET MetaData» отличны от нуля;

- адрес и размер секции «ManagedNativeHeader» равны нулю;

- наличие управляемых ресурсов, размер которых отличен от нуля;

- в поле «MaskValid» отсутствуют биты, связанные с таблицами следующих методов: MethodDef, MethodPtr, MethodSemantics, MethodImpl и MetodSpec.

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

В другом варианте исполнения способа перечень условий для формата «Native DLL» содержат по крайней мере еще два условия, а именно адрес точки входа указывает на нулевой адрес (0×00) и в начале массива секций для каждой исполняемой секции отсутствует указатель на исполнение.

В еще одном варианте исполнения способа перечень условий для формата «.NET Assembly DLL» содержит по крайней мере еще два условия: наличие одной секции с правом на исполнение и точка входа должна указывать или на нулевой адрес (0×00), или на точку входа определенной секции с правами на исполнения, при этом точка входа для файла.NET указывает на вызов функций «_CorDllMain» из библиотеки mscoree.dll.

Краткое описание прилагаемых чертежей

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

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

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

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

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

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

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

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

В рамках данной схемы рассматривается один из вариантов осуществления заявленной системы оптимизации антивирусной проверки, в рамках которой будет описана оптимизация антивирусной проверки, а именно исключение исполняемого файла из упомянутой антивирусной проверки, в момент перехвата антивирусной системой 110 процесса запуска исполняемого файла 100. Однако изобретение не ограничивается данным применением. Система оптимизации подходит и для случаев, когда антивирусная проверка исполняемых файлов 100 будет проводиться, например, с помощью таких технологий, как проверка по требованию (от англ. on demand scanning, ODS)) и система предотвращения вторжений (от англ. Host-based Intrusion Prevention System, HIPS). Кроме того, на фиг. 1 представлен пример взаимодействия средств системы обнаружения исполняемых файлов 130 в составе антивирусной системы 110 при проведении антивирусной проверки исполняемых файлов 100, что позволяет обнаружить исполняемые файлы 100, которые будут исключаться из антивирусной проверки. Стоит отметить, что в рамках изобретения под исполняемым файлом может пониматься любой файл, соответствующий форматам РЕ (от англ. Portable Executable) и NE (от англ. New Executable), т.е. файлы, предполагающие наличие исполняемого кода. В частности в качестве файлов формата РЕ понимаются динамические библиотеки (от англ. Dynamic Data Library, DLL), а в качестве файлов формата NE (далее - NE-файлы) понимаются ресурсные файлы (библиотеки), такие как файл, содержащий программу заставки Windows (также указанный файл называется как файл фона с расширением «scr»).

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

Стоит отметить, что исполняемые файлы не всех форматов удовлетворяют данному критерию безопасности, а именно отсутствию исполняемого кода. Поэтому в одном из вариантов реализации может предварительно быть сформирован список форматов файлов, в котором содержатся форматы только тех файлов, которые могут удовлетворять указанному критерию безопасности. Файлы только форматов, которые содержаться в списке форматов файлов, будут передаваться системе обнаружения 130 для определения безопасности файла. Список форматов файлов (далее - список форматов) является пополняемым (изменяемым). Примерами форматов файлов, которые будут содержаться в списке форматов, являются динамические библиотеки и NE-файлы (например, файлы фонов с расширением «scr») для разных операционных систем (такие как Windows, Linux и Mac OS).

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

Таким образом для проведения антивирусной проверки средство проверки 120, например, в процессе запуска исполняемого файла (например, приложения Notepad.exe), во время которого файл производит как загрузку динамических библиотек, так и открытие других файлов, перехватывает указанный запуск и передает указанные исполняемые файлы 100 (например, динамические библиотеки) системе обнаружения 130. В одном из вариантов реализации тип исполняемых файлов (например, файл является динамической библиотекой) определяется, например, по формату исполняемого файла.

Система обнаружения 130 включает по крайней мере средство разбора 150, средство анализа 160 и базу данных 170. Средство разбора 150 предназначено для разбора структуры исполняемого файла (например, динамической библиотеки), во время которого по крайней мере определяет формат исполняемого файла. В частном случае реализации для динамических библиотек форматом является один из: «Native DLL», «.NET Assembly DLL».

Кроме того, в частном случае реализации средство разбора 150 также во время разбора структуры исполняемого файла определяет наличие секций, содержащихся в структуре исполняемого файла 100 и которые имеют права на исполнение (например, на основании соответствующего указателя-флага), и определяет адрес начала исполнения программного кода исполняемого файла (т.е. точку входа). После чего средство разбора 150 передает информацию о формате исполняемого файла (динамической библиотеки) 100 и его структуре средству анализа 160.

Средство анализа 160 предназначено для проведения анализа полученного исполняемого файла, например динамической библиотеки (далее - файл DLL), согласно перечню условий, при этом перечень условий выбирается из базы данных 170 на основании информации о формате файла, полученной от средства разбора 150. Так, для одного формата файла будет один перечень условий, а для другого формата файла соответственно другой перечень условий. Перечень условий содержит условия для анализа структуры исполняемого файла (динамической библиотеки). Примеры перечней условий приведены в рамках частных примеров реализации ниже. Анализ же заключается в проверке того, что каждое условие из перечня условий для проверяемого файла (файла DLL) выполняется. После чего средство анализа 160 формирует результат анализа. Под результатом понимается информация о выполнении каждого условия из перечня условий. В случае выполнения всех условий средство анализа 160 выносит решение об отсутствии исполняемого кода и признает проверяемый файл безопасным. В противном случае, если хотя бы одно условие не было выполнено, то средство анализа 160 выносит решение о наличии исполняемого кода и признает проверяемый файл подозрительным, который будет впоследствии подвергнут антивирусной проверке. После чего средство анализа 160 передает вынесенное решение средству проверки 120. Соответственно средство проверки 120 при получении решения об отсутствии исполняемого кода исключает указанный исполняемый файл из антивирусной проверки. В противном случае, если решение о наличии исполняемого кода, то средство проверки 120 произведет антивирусную проверку, в результате которой вынесет решение о безопасности/вредоносности файла.

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

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

Стоит отметить, что в еще одном частном случае реализации изобретения антивирусная система 110 взаимодействует с антивирусным сервером 180 с целью обмена информацией через различные виды сетей, например глобальную сеть Интернет 190. Например антивирусный сервер 280 передает информацию, связанную с новыми форматами для списка форматов или новыми или измененными перечнями условий. Также антивирусная система 110 (или изобретение) может передавать информацию о проверенных и исключенных исполняемых файлах (динамических библиотеках) антивирусному серверу 180.

Рассмотрим пример исключения из антивирусной проверки исполняемых файлов приложения Notepad.exe. В процессе запуска приложение Notepad.exe загружаются в том числе и динамические библиотеки, в которых расположены ресурсы или часть функций, требуемых для работы приложения Notepad.exe. Так, одной из динамических библиотек является динамическая библиотека Notepad.exe.mui. Следовательно, антивирусная система 110 с помощью средства проверки 120 перехватывает процесс загрузки динамической библиотеки Notepad.exe.mui и передает указанную динамическую библиотеку системе обнаружения 130, а именно средству разбора 150. В частном случае средство проверки 120 может содержать список форматов. В этом случае средство проверки 120 будет передавать средству разбора 150 только файлы, формат которых соответствует списку форматов. В данном примере динамическая библиотека Notepad.exe.mui является файлом формата DLL (далее - файл DLL), который будет соответствовать списку форматов.

После получения файла DLL средство разбора 150 производит разбор структуры файла DLL. При разборе структуры указанного файла DLL определяется (подтверждается) формат файла DLL с помощью проверки заголовка файла DLL в поле «characteristics». В указанном поле выявляется соответствующий флаг (для файла DLL установлено значение поля для структуры IMAGE_FILE_DLL). Для указанного файла DLL средство разбора 150 определит, что файл относится к виду динамических библиотек «Native DLL». После чего средство разбора 150 передает информацию о формате файла DLL (динамической библиотеки) 100 и его структуре средству анализа 160.

В частном случае средство разбора 150 также может проверить при разборе структуры наличие исполняемых секций (секции, которые имеют права на исполнения) и точку входа (начала исполнения программного кода). Данные условия (проверка секций и точки входа) могут являться дополнительными критериями при передаче указанной информации и структуры файла DLL средству анализа 160. Так, для динамических библиотек формата «Native DLL» обязательными критериями передачи могут являться следующие критерии: точка входа должна указывать на нулевой адрес (0×00), и в массиве секций для каждой исполняемой секции отсутствует указатель-флаг на исполнение. В противном случае, если по крайней мере один критерий не выполняется, средство разбора 150 не передает указанную информацию и структуру файла DLL средству анализа 160 и информирует средство проверки 120 об этом. В свою очередь средство проверки 120 произведет антивирусную проверку. Кроме того, в еще одном частном случае указанные критерии могут являться условиями, входящими в по крайней мере один перечень условий, хранящийся в базе данных 170.

Средство анализа 160 производит выбор перечня условий из базы данных 170 на основании полученной информации о формате файла DLL от средства разбора 150. Выбор перечня условий осуществляется согласно определенному формату файла. Для указанного файла DLL (Notepad.exe.mui) перечень условий будет выбран в соответствии с форматом «Native DLL». Так, например перечень условий может содержать, по крайней мере, три из следующих условий, которые направлены на анализ массива структур IMAGE_DATA_DIRECTORY:

- адрес и размер ресурсной секции Resource table (секция ресурсов) не равны нулю, т.е. присутствует информация о ресурсах;

- адрес и размер секции Export table (секция экспортов) равны нулю, т.е. отсутствует информация об экспортируемых функциях;

- адрес и размер секций Import table (секция импортов) равны нулю, т.е. отсутствуют информация об импортируемых функциях;

- адрес и размер секции Import address table (секция таблицы импортов) равны нулю, т.е. отсутствует таблица адресов импорта;

- адрес и размер секции Thread local storage (TLS) table (секция памяти потока) равны нулю, т.е. отсутствуют TLS.

Средство анализа 160 производит анализ структуры файла DLL в соответствии с выбранным перечнем условий. После проведения анализа (проверки выполнения каждого условия из перечня условий) средство анализа 160 формирует результат. Результат содержит информацию о выполнении всех условий или не выполнении по крайней мере одного условия из перечня условий. В представленном примере результат проверки файла DLL (Notepad.exe.mui) соответствует случаю выполнения всех условий. Следовательно, средство анализа 160 выносит решение об отсутствии исполняемого кода и признает проверяемый файл безопасным. Далее средство анализа 160 передает указанное решение средству проверки 120. Средство проверки 120 на основании полученного решения об отсутствии исполняемого кода исключает указанный файл DLL из антивирусной проверки.

Рассмотрим еще один вариант исключения файла из антивирусной проверки на примере файла «System.XML.resources.dll» из стандартного пакета Microsoft.NET Framework. Соответственно антивирусная система 110 перехватывает процесс загрузки файла «System.XML.resources.dll» (далее - файл.NET) с помощью средства проверки 120 и передает указанный файл .NET средству разбора 150. Средство разбора 150 производит разбор структуры указанного файла .NET, в процессе которого определяет формат файла .NET с помощью проверки заголовка файла .NET в поле «characteristics». В указанном поле выявляется (определяется) наличие соответствующего флага. Для указанного файла .NET средство разбора 150 определит, что файл .NET относится к виду динамических библиотек «.NET Assembly DLL». После чего средство разбора 150 передает информацию о формате файла.NET 100 и его структуре средству анализа 160.

Также в частном случае средство разбора 150 также может проверить при разборе структуры наличие исполняемых секций (секции, которые имеют права на исполнения) и адрес точки входа (начала исполнения программного кода). Данные критерии могут являться дополнительными критериями при передаче указанной информации и структуры файла .NET средству анализа 160. Так, для формата динамических библиотек «.NET Resource DLL» обязательным условиями передачи могут являться следующие критерии:

- наличие не более чем одной секции с правом на исполнение, т.е. секция имеет соответствующий флаг в поле «characteristics»;

- точка входа должна указывать или на нулевой адрес (0×00), или на точку входа согласно определенной секции с правами на исполнения, при этом точка входа для файла.NET указывает на вызов функции «_CorDllMain» из библиотеки mscoree.dll.

В противном случае, если по крайней мере один критерий не выполняется, средство разбора 150 не передает указанную информацию и структуру файла .NET средству анализа 160 и информирует средство проверки 120 об этом. В свою очередь средство проверки 120 произведет антивирусную проверку. Кроме того, в еще одном частном случае указанные критерия могут являться также условиями из перечней условий, хранящихся в базе данных 170. В случае, если указанные критерии являются условиями, то средство разбора 150 не использует их как дополнительные критерии передачи.

Средство анализа 160, как упоминалось выше, производит выбор перечня условий из базы данных 170 на основании полученной информации о формате файла .NET от средства разбора 150 и производит анализ файла .NET в соответствии с выбранным перечнем условий. Для файла .NET перечень условий будет выбран в соответствии с форматом «.NET Resource DLL» и может содержать, по крайней мере, три или более из следующих условий:

- точка входа на импортируемую функцию _CorDllMain, в которой отсутствуют другие импортируемые функции, и сама функция _CorDllMain импортируется из mscoree.dll;

- отсутствуют любые импортируемые функции, кроме функции, импортируемой из библиотеки mscoree.dll;

- адрес и размер секции Export table (секция экспортов) равны нулю, т.е. отсутствует информация об экспортируемых функциях;

- адрес и размер секции Thread local storage (TLS) table (секция памяти потока) равны нулю, т.е. отсутствуют TLS;

- адрес и размер секции «.NET MetaData» отличны от нуля;

- адрес и размер структуры ManagedNativeHeader равны нулю, т.е. проверяемый файл.NET не является NativeImage-файлом;

- наличие управляемых ресурсов, размер которых отличен от нуля;

- в поле MaskValid отсутствуют биты, связанные с таблицами следующих методов: MethodDef, MethodPtr, MethodSemantics, MethodImpl и MetodSpec.

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

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

- количество секций равно нулю (Count of file segments=0, Automatic data seg.number=0);

- адрес и размер секции Heap allocation (секция резервирования памяти) равны нулю;

- адрес и размер секции Stack allocation (размещение в стеке) равны нулю;

- управляющие регистры инициированы нулями (IP=0, CS=0, SP=0, SS=0);

- отсутствуют библиотеки для импорта (секция ImportNames указывает на нулевой адрес 0×0000).

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

На фиг. 2 показан способ исключения исполняемого файла 100, в частности динамических библиотек, не содержащих исполняемый код. Во время проведения антивирусной проверки, если файл оказывается исполняемым, то перед проведением антивирусной проверки производится выполнение указанного способа исключения исполняемых файлов из антивирусной проверки. По результатам проведения указанного способа может быть принято решение об исключении из антивирусной проверки исполняемых файлов, в частности динамических библиотек и NE-файлов.

На этапе 210 получают исполняемый файл на антивирусную проверку или производят перехват процесса запуска исполняемого файла, т.е. получают файл на антивирусную проверку, с помощью средства проверки 120. Далее средство проверки 120 передает полученный файл средству разбора 150. Средство разбора 150 на этапе 220 определяет формат полученного файла на основании разбора структуры проверяемого файла и выявлении в заголовке файла в поле «characteristics» соответствующего флага о формате файла. Например то, что указанный файл является динамической библиотекой (формат «Native DLL», управляемой динамической библиотекой «.NET Assembly DLL») или NE-файлом (формат MZ-NE). После чего на этапе 230 производится сравнение определенного формата файла со списком форматов файлов. Список форматов содержит форматы, файлы которых можно исключить из антивирусной проверки в случае успешного выполнения дальнейшей проверки. В том случае, если формат указанного файла присутствует в списке форматов, средство разбора 150 производит дальнейший разбор проверяемого файла. В противном случае производится антивирусная проверка файла на этапе 235 средством проверки 120.

Далее средство разбора 150 определяет секции, имеющие право на исполнение (отмечены соответствующим флагом в поле «characteristics») программного кода, на этапе 240 и определяет адрес начала исполнения программного кода (точку входа) в исполняемом файле на этапе 250. При этом указанные условия (проверка секций и точки входа) сравниваются с соответствующими критериями для определенного формата файла. Стоит отметить, что примеры выполнения действий на этапах 240 и 250 представлены при описании фиг. 1. Так, например данные условия (проверка секций и точки входа) для файла формата «Native DLL» должны удовлетворять следующим критериям: точка входа должна указывать на нулевой адрес, и в начале массива секций для каждой исполняемой секции должен отсутствовать указатель-флаг на исполнение. В случае несоответствия указанным условиям на этапе 255 работа прекращается (о чем информируется средство проверки 120), и средство проверки 120 переходит к этапу 235. В ином случае средство разбора 150 передает информацию о формате файла и его структуре средству анализа 160.

В свою очередь средство анализа 160 на этапе 260 выбирает перечень условий на основании полученной информации о формате файла для проведения анализа. После чего средство 160 производит анализ согласно выбранному перечню условий на этапе 270 и формирует результат анализа. Анализ заключается в проверки того, что каждое условие из перечня условий для проверяемого файла выполняется. Под результатом анализа же понимается информация о выполнении каждого условия из перечня условий. На этапе 280 формируется решение о выполнении всех условий на основании результата анализа. Так, если хотя бы одно условие не было выполнено, то средство анализа 160 выносит решение о наличии исполняемого кода и признает проверяемый файл подозрительным, над которым необходимо провести антивирусную проверку на этапе 235 с помощью средства проверки 120. В другом случае, если все условия выполнены, то средство анализа 160 выносит решение об отсутствии исполняемого кода и признает проверяемый файл безопасным. После чего средство анализа 160 передает решение об отсутствии исполняемого кода средству проверки 120. В свою очередь средство проверки 120 на основании полученного решения исключает указанный исполняемый файл из антивирусной проверки на этапе 290.

На фиг. 3 показана компьютерная система, на которой может быть использовано изобретение.

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

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

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