Система и способ обнаружения вредоносного кода в исполняемом файле Российский патент 2021 года по МПК H04L12/00 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исполняемый файл - файл, содержащий программу или ее часть, написанную на каком-либо из языков программирования, предназначенный для запуска операционной системой.¹ (¹ Феликс Воройский. Информатика. Энциклопедический словарь-справочник. - Litres, 2017-01-12. - 769 с. - ISBN 9785457966338.)

Сборка приложения - исполняемый файл, набор файлов или логическая структура, содержащая программный код, метаданные и ресурсы, необходимые для корректной компиляции или исполнения приложения. В. NET Core и .NET Framework сборку можно создать из одного или нескольких файлов исходного кода. В. NET Framework сборки могут содержать один или несколько модулей. В крупных проектах несколько разработчиков могут работать с отдельными файлами или модулями исходного кода, которые вместе образуют единую сборку.² (² Официальный сайт корпорации Microsoft. URL: https://docs.microsoft.com/ru-ru/dotnet/standard/assembly/#assembly-manifest (дата обращения 30.07.2020).)

Функциональный блок - объект аппаратного средства и/или программного обеспечения, выполняющий определенную задачу.³ (³ ГОСТ Ρ 53195.4-2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению.) Исходный код программы при создании может быть поделен на функциональные блоки. Отдельный файл или модуль исходного кода приложения может быть функциональным блоком. Совокупность файлов и модулей исходного кода, которая отвечает за выполнение отдельного действия, также может быть функциональным блоком.

Файл символов - файл, предназначенный для хранения отладочной информации о программе, включая информацию о символах, которая состоит из списка всех символов в программном модуле с адресами, именем файла и строкой, в которой был объявлен символ, информацию об оптимизации указателей на записи активации, название и информацию о типе локальных переменных и структуре данных. Среди файлов символов известны файлы с расширениями COFF, DBG, SYM, PDB.⁴ (⁴ Официальный сайт корпорации Microsoft. URL: https://devblogs.microsoft.com/devops/understanding-symbol-files-and-visual-studios-symbol-settings/ (дата обращения 30.07.2020).)

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

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

Для того чтобы выявить небезопасные приложения из перечисленных случаев, используют систему обнаружения вредоносного кода в неизвестной версии сборки приложения. Фиг 1 иллюстрирует систему обнаружения вредоносного кода в исполняемом файле, которая включает в себя базу данных доверенных файлов 110, средство обнаружения 120, средство анализа 130, средство проверки 140, базу данных правил 150.

База данных доверенных файлов 110 - хранилище исполняемых файлов, соответствующих им списков файлов и модулей исходного кода, отдельных файлов и модулей исходного кода, файлов символов различных версий сборок приложений, которые соответствуют по меньше мере одному из следующих условий: в отношении которых ранее была выполнена проверка на наличие вредоносного кода, происхождение которых может быть явно подтверждено создателем программного обеспечения. Базу данных доверенных файлов 110 пополняют из открытых репозиториев разработчиков программного обеспечения файлов исходного кода, например sourceforge, githup и прочих; закрытых репозиториев разработчиков программного обеспечения, например компаний Microsoft, Adobe и прочих. Обращение к закрытому репозиторию осуществляют, например, через прямой запрос для выполнения проверки на наличие вредоносного кода по конкретному приложению или исполняемому файлу. Помимо этого, данные могут поступать из антивирусного сервера.

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

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

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

Затем средство обнаружения 120 передает данные об исполняемом файле и о выбранном файле средству анализа 130.

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

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

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

«0 c:\program files (x86)\windows kits\10\include\10.0.17763.0\ucrt\sys\stat.h (MD5: 8DCC3C7F28EF6CADCEA54C4F1881C8D3)»

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

После определения функционального блока средство анализа 130 передает данные об определенном функциональном блоке средству проверки 140.

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

База данных правил 150 предназначена для хранения правил проверки сборки. В качестве базы данных правил 150 могут быть использованы различные виды баз данных, а именно: иерархические (IMS, TDMS, System 2000), сетевые (Cerebrum, Cronospro, DBVist), реляционные (DB2, Informix, Microsoft SQL Server), объектно-ориентированные (Jasmine, Versant, POET), объектно-реляционные (Oracle Database, PostgreSQL, FirstSQL/J), функциональные и т.д. Количество правил не ограничено примерами. Правила могут быть созданы при помощи алгоритмов машинного обучения и автоматизированной обработки больших массивов данных, и содержать иные условия или комбинации условий, вердикты.

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

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

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

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

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

В самом общем случае метаданные исполняемого файла 1, например, могут быть следующими: номер версии сборки 1, имя файла 1, размер файла 1, уникальные строки 10, структура фала 1, секция импорта содержит 18 импортируемых файлов, секция экспорта содержит 1 экспортируемый файл, секция ресурсов содержит 3 файла. Допустим, что по перечисленным метаданным в базе данных доверенных файлов 110 был найден и выбран файл 2, метаданные которого следующие: номер версии сборки 1, имя файла 1, размер 2, уникальные строки 10, структура файла 1, уникальные строки 10, структура файла 1, секция импорта содержит 19 импортируемых файлов, секция экспорта содержит 1 экспортируемый файл, секция ресурсов содержит 3 файла. Помимо этого, для файла 2 найден соответствующий ему список файлов и модулей исходного кода, состоящий из 30 позиций, по которым построены 25 функциональных блоков. Средство обнаружения 120 выявляет обнаруженные следующие отличия: размер 2 больше размера 1 на 5 процентов, 1 импортируемый файл в секции импорта выбранного файла не встречается в метаданных исполняемого файла. Подсчет степени схожести показал, что исполняемый файл схож с выбранным файлом более чем на 90 процентов. На основании этих данных средство анализа 130 определяет наличие файла символов и на его основе определяет список файлов и модулей исходного кода. Определенный список содержит 32 позиции на основе которых выявляют 26 функциональных блоков. 25 из 26 функциональных блоков и 30 из 32 файлов и модулей исходного кода являются идентичными с функциональными блоками выбранного файла. Определяем, что выбранный файл не содержит 1 функциональный блок исполняемого файла. Таким образом, за 100 процентов принимается 26 функциональных блоков, определенный функциональный блок составляет 4 процента. На основе этих данных средство проверки 140 и правил проверки сборки из базы данных правил 150 обнаруживает, что согласно второму примеру правил, исполняемый файл содержит вредоносный код с вероятностью 80 процентов. Файлы и модули исходного кода, которые содержат определенный функциональный блок, подвергаются более сложному и детальному анализу для выяснения, в каком месте и каким образом исполняется вредоносный код.

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

Фиг. 2 иллюстрирует алгоритм функционирования системы обнаружения вредоносного кода в исполняемом файле. На этапе 211 средство обнаружения 120 осуществляет определение метаданных, содержащих информацию о версии сборки исполняемого файла. На этапе 212 средство обнаружения 120 осуществляет выбор из базы данных доверенных файлов 110 по меньшей мере одного исполняемого файла, метаданные которого схожи с определенными метаданными, и передает данные об исполняемом файле и о выбранном файле средству анализа 130. На этапе 213 средство анализа 130 определяет функциональный блок в исполняемом файле, который отсутствует по меньшей мере в одном выбранном файле, и передает данные об определенном функциональном блоке средству проверки 140. На этапе 214 средство проверки 140 при помощи правил проверки сборки и на основании определенного функционального блока обнаруживает наличие вредоносного кода в исполняемом файле. При наличии вредоносного кода на этапе 215 средство проверки 140 отправляет данные об исполняемом файле, содержащем вредоносный код, на антивирусный сервер. При отсутствии вредоносного кода на этапе 216 система завершает работу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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