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

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

Info

Publication number
RU2757807C1
RU2757807C1 RU2020128086A RU2020128086A RU2757807C1 RU 2757807 C1 RU2757807 C1 RU 2757807C1 RU 2020128086 A RU2020128086 A RU 2020128086A RU 2020128086 A RU2020128086 A RU 2020128086A RU 2757807 C1 RU2757807 C1 RU 2757807C1
Authority
RU
Russia
Prior art keywords
file
files
executable file
executable
assembly
Prior art date
Application number
RU2020128086A
Other languages
English (en)
Inventor
Юлиана Константиновна Яшина
Александр Павлович Борисов
Алексей Михайлович Пахомов
Original Assignee
Акционерное общество "Лаборатория Касперского"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Акционерное общество "Лаборатория Касперского" filed Critical Акционерное общество "Лаборатория Касперского"
Priority to RU2020128086A priority Critical patent/RU2757807C1/ru
Application granted granted Critical
Publication of RU2757807C1 publication Critical patent/RU2757807C1/ru

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/563—Static detection by source code analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/564—Static detection by virus signature recognition

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Virology (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

Область техники
Изобретение относится к области информационной безопасности, а более конкретно к системам и способам проверки файлов на наличие вредоносного кода.
Уровень техники
Количество создаваемых пользователями и компаниями новых приложений продолжает непрерывно расти. Улучшенные среды программирования и готовые конструкторы программ значительно упрощают и ускоряют процесс создания или изменения приложений. Создание версий и альтернативных сборок одного приложения редко приводит к появлению совершенно нового исполняемого файла. Зачастую разница функциональности упомянутых исполняемых файлов при детальном анализе может оказаться незначительной.
Существующие методы компиляции ввиду своей сложности позволяют создавать приложения одинаковой функциональности в виде различных исполняемых файлов. С другой стороны, существует возможность создать два одинаковых исполняемых файла, которые будут иметь разный набор функций.
Непрерывно растущее количество приложений и их постоянное изменение, например, в результате установки обновлений, не позволяет пользователю иметь актуальную информацию о текущей корректно работающей и наиболее безопасной версии сборки приложения. В то же время создатели программного обеспечения не всегда имеют возможность следить за выпуском различных версий сборок создаваемых ими приложений. Этой ситуацией может воспользоваться злоумышленник.
Злоумышленники могут воспользоваться упомянутой сложностью и намеренно создать вредоносный исполняемый файл, который будет похож на исполняемый файл известного приложения, но иметь вредоносный функционал. С другой стороны, возможно создание нескольких разных вредоносных исполняемых файлов, которые будут иметь один или похожий вредоносный функционал. Для выявления функциональных отличий используют анализ информации о файлах исходного кода исполняемых файлов.
В настоящее время существуют решения, предназначенные для детального сравнения файлов исходного кода. Например, в публикации US9569199B2 описана система, в которой осуществляют сравнение текста файлов исходного кода. Результаты сравнения используют для быстрого создания обновления или новой версии сборки приложения.
Хотя описанный выше способ работы успешно справляется с задачей детального сравнения файлов исходного кода, но он не подразумевает выполнения антивирусной проверки функциональности различных версий сборки приложения. Настоящее изобретение позволяет эффективно решать эту задачу.
Раскрытие изобретения
Изобретение относится к области информационной безопасности, а более конкретно к системам и способам проверки файлов на наличие вредоносного кода. Изобретение предназначено для проверки наличия вредоносного кода в исполняемом файле. Технический результат настоящего изобретения заключается в обеспечении защиты информационной безопасности. Указанный технический результат достигается путем выполнения проверки наличия вредоносного кода в исполняемом файле, схожем по метаданным с доверенным файлом.
В одном из вариантов реализации предоставляют способ обнаружения вредоносного кода в исполняемом файле, по которому: определяют метаданные, содержащие информацию о версии сборки исполняемого файла; выбирают из базы данных доверенных файлов по меньшей мере один исполняемый файл, метаданные которого схожи с определенными метаданными; определяют функциональный блок в исполняемом файле, который отсутствует по меньшей мере в одном выбранном исполняемом файле; обнаруживают наличие вредоносного кода в исполняемом файле при помощи правил проверки сборки и на основании определенного функционального блока.
В другом варианте реализации способа под метаданными, содержащими информацию о версии сборки исполняемого файла, выступают по меньшей мере следующие метаданные: номер версии сборки; имя файла; размер файла; уникальные строки, выделенные из файла; структура файла; и содержимое секций импорта, экспорта и ресурсов.
Еще в одном варианте реализации способа в базе данных доверенных файлов хранят исполняемые файлы, списки файлов и модулей исходного кода, отдельные файлы и модули исходного кода, файлы символов различных версий сборок исполняемых файлов и приложений, которые соответствуют по меньше мере одному из следующих условий: в отношении которых ранее была выполнена проверка на наличие вредоносного кода, происхождение которых подтверждено создателем программного обеспечения.
В другом варианте реализации способа функциональный блок представляет совокупность программных инструкций, обеспечивающих выполнений заданной задачи.
Еще в одном варианте реализации способа определение функционального блока в исполняемом файле выполняют на основании по меньшей мере одного файла исходного кода, которые отсутствуют в выбранном файле.
В другом варианте реализации способа определяют функциональный блок в исполняемом файле на основании по меньшей мере одного модуля исходного кода, которые отсутствуют в выбранном файле.
Еще в одном варианте реализации способа исполняемый файл и файл, выбранный из базы данных доверенных файлов, принадлежат версиям сборки одного и того же приложения.
В другом варианте реализации способа под правилом проверки сборки понимают набор условий, при выполнении которого, определяют вероятность того, что исполняемый файл содержит вредоносный код.
Краткое описание чертежей
Фиг. 1 иллюстрирует структуру системы обнаружения вредоносного кода в исполняемом файле.
Фиг. 2 иллюстрирует алгоритм системы обнаружения вредоносного кода в исполняемом файле.
Фиг. 3 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер.
Хотя изобретение может иметь различные модификации и альтернативные формы, характерные признаки, показанные в качестве примера на чертежах, будут описаны подробно. Следует понимать, однако, что цель описания заключается не в ограничении изобретения конкретным его воплощением. Наоборот, целью описания является охват всех изменений, модификаций, входящих в рамки данного изобретения, как это определено в приложенной формуле.
Описание вариантов осуществления изобретения
Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, необходимыми для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.
Исполняемый файл - файл, содержащий программу или ее часть, написанную на каком-либо из языков программирования, предназначенный для запуска операционной системой.1 (1 Феликс Воройский. Информатика. Энциклопедический словарь-справочник. - Litres, 2017-01-12. - 769 с. - ISBN 9785457966338.)
Сборка приложения - исполняемый файл, набор файлов или логическая структура, содержащая программный код, метаданные и ресурсы, необходимые для корректной компиляции или исполнения приложения. В. NET Core и .NET Framework сборку можно создать из одного или нескольких файлов исходного кода. В. NET Framework сборки могут содержать один или несколько модулей. В крупных проектах несколько разработчиков могут работать с отдельными файлами или модулями исходного кода, которые вместе образуют единую сборку.2 (2 Официальный сайт корпорации Microsoft. URL: https://docs.microsoft.com/ru-ru/dotnet/standard/assembly/#assembly-manifest (дата обращения 30.07.2020).)
Функциональный блок - объект аппаратного средства и/или программного обеспечения, выполняющий определенную задачу.3 (3 ГОСТ Ρ 53195.4-2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению.) Исходный код программы при создании может быть поделен на функциональные блоки. Отдельный файл или модуль исходного кода приложения может быть функциональным блоком. Совокупность файлов и модулей исходного кода, которая отвечает за выполнение отдельного действия, также может быть функциональным блоком.
Файл символов - файл, предназначенный для хранения отладочной информации о программе, включая информацию о символах, которая состоит из списка всех символов в программном модуле с адресами, именем файла и строкой, в которой был объявлен символ, информацию об оптимизации указателей на записи активации, название и информацию о типе локальных переменных и структуре данных. Среди файлов символов известны файлы с расширениями COFF, DBG, SYM, PDB.4 (4 Официальный сайт корпорации 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. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.

Claims (12)

1. Способ обнаружения вредоносного кода в исполняемом файле, по которому:
а) определяют метаданные, содержащие информацию о версии сборки исполняемого файла;
б) выбирают из базы данных доверенных файлов по меньшей мере один исполняемый файл, метаданные которого схожи с определенными метаданными;
в) определяют функциональный блок в исполняемом файле, который отсутствует по меньшей мере в одном выбранном исполняемом файле;
г) обнаруживают наличие вредоносного кода в исполняемом файле при помощи правил проверки сборки и на основании определенного функционального блока.
2. Способ по п. 1, по которому под метаданными, содержащими информацию о версии сборки исполняемого файла, выступают по меньшей мере следующие метаданные: номер версии сборки; имя файла; размер файла; уникальные строки, выделенные из файла; структура файла; и содержимое секций импорта, экспорта и ресурсов.
3. Способ по п. 1, по которому в базе данных доверенных файлов хранят исполняемые файлы, списки файлов и модулей исходного кода, отдельные файлы и модули исходного кода, файлы символов различных версий сборок исполняемых файлов и приложений, которые соответствуют по меньше мере одному из следующих условий: в отношении которых ранее была выполнена проверка на наличие вредоносного кода, происхождение которых подтверждено создателем программного обеспечения.
4. Способ по п. 1, по которому функциональный блок представляет совокупность программных инструкций, обеспечивающих выполнение заданной задачи.
5. Способ по п. 1, по которому определение функционального блока в исполняемом файле выполняют на основании по меньшей мере одного файла исходного кода, который отсутствует в выбранном файле.
6. Способ по п. 1, по которому определяют функциональный блок в исполняемом файле на основании по меньшей мере одного модуля исходного кода, который отсутствует в выбранном файле.
7. Способ по п. 1, по которому исполняемый файл и файл, выбранный из базы данных доверенных файлов, принадлежат версиям сборки одного и того же приложения.
8. Способ по п. 1, по которому под правилом проверки сборки понимают набор условий, при выполнении которых, определяют вероятность того, что исполняемый файл содержит вредоносный код.
RU2020128086A 2020-08-24 2020-08-24 Система и способ обнаружения вредоносного кода в исполняемом файле RU2757807C1 (ru)

Priority Applications (1)

Application Number Priority Date Filing Date Title
RU2020128086A RU2757807C1 (ru) 2020-08-24 2020-08-24 Система и способ обнаружения вредоносного кода в исполняемом файле

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
RU2020128086A RU2757807C1 (ru) 2020-08-24 2020-08-24 Система и способ обнаружения вредоносного кода в исполняемом файле

Publications (1)

Publication Number Publication Date
RU2757807C1 true RU2757807C1 (ru) 2021-10-21

Family

ID=78289556

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2020128086A RU2757807C1 (ru) 2020-08-24 2020-08-24 Система и способ обнаружения вредоносного кода в исполняемом файле

Country Status (1)

Country Link
RU (1) RU2757807C1 (ru)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050039029A1 (en) * 2002-08-14 2005-02-17 Alexander Shipp Method of, and system for, heuristically detecting viruses in executable code
US20050172338A1 (en) * 2004-01-30 2005-08-04 Sandu Catalin D. System and method for detecting malware in executable scripts according to its functionality
US20060037080A1 (en) * 2004-08-13 2006-02-16 Georgetown University System and method for detecting malicious executable code
RU2427890C2 (ru) * 2009-10-01 2011-08-27 ЗАО "Лаборатория Касперского" Система и способ сравнения файлов на основе шаблонов функциональности
US20140366137A1 (en) * 2013-06-06 2014-12-11 Kaspersky Lab Zao System and Method for Detecting Malicious Executable Files Based on Similarity of Their Resources
RU2637997C1 (ru) * 2016-09-08 2017-12-08 Акционерное общество "Лаборатория Касперского" Система и способ обнаружения вредоносного кода в файле

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050039029A1 (en) * 2002-08-14 2005-02-17 Alexander Shipp Method of, and system for, heuristically detecting viruses in executable code
US20050172338A1 (en) * 2004-01-30 2005-08-04 Sandu Catalin D. System and method for detecting malware in executable scripts according to its functionality
US20060037080A1 (en) * 2004-08-13 2006-02-16 Georgetown University System and method for detecting malicious executable code
RU2427890C2 (ru) * 2009-10-01 2011-08-27 ЗАО "Лаборатория Касперского" Система и способ сравнения файлов на основе шаблонов функциональности
US20140366137A1 (en) * 2013-06-06 2014-12-11 Kaspersky Lab Zao System and Method for Detecting Malicious Executable Files Based on Similarity of Their Resources
RU2637997C1 (ru) * 2016-09-08 2017-12-08 Акционерное общество "Лаборатория Касперского" Система и способ обнаружения вредоносного кода в файле

Similar Documents

Publication Publication Date Title
US8621278B2 (en) System and method for automated solution of functionality problems in computer systems
Aljawarneh et al. Cloud security engineering: Early stages of SDLC
Shu et al. Threat intelligence computing
CN112131882A (zh) 一种多源异构网络安全知识图谱构建方法及装置
US7840573B2 (en) Trusted file relabeler
US20150207811A1 (en) Vulnerability vector information analysis
Kim et al. Software systems at risk: An empirical study of cloned vulnerabilities in practice
CN114077741B (zh) 软件供应链安全检测方法和装置、电子设备及存储介质
Koschke Large‐scale inter‐system clone detection using suffix trees and hashing
NL2027556B1 (en) Method and system for generating a list of indicators of compromise
Gegick et al. Matching attack patterns to security vulnerabilities in software-intensive system designs
Bao et al. V-SZZ: automatic identification of version ranges affected by CVE vulnerabilities
US20150213272A1 (en) Conjoint vulnerability identifiers
Christey et al. Common weakness enumeration
Dalai et al. Neutralizing SQL injection attack using server side code modification in web applications
CN114386032A (zh) 电力物联网设备的固件检测***及方法
CN111611590B (zh) 涉及应用程序的数据安全的方法及装置
Pirch et al. Tagvet: Vetting malware tags using explainable machine learning
Homaei et al. Athena: A framework to automatically generate security test oracle via extracting policies from source code and intended software behaviour
Viertel et al. Detecting Security Vulnerabilities using Clone Detection and Community Knowledge.
Salih et al. Digital forensic tools: A literature review
Akram et al. VCIPR: vulnerable code is identifiable when a patch is released (hacker's perspective)
Noseevich et al. Detecting insufficient access control in web applications
US20240054210A1 (en) Cyber threat information processing apparatus, cyber threat information processing method, and storage medium storing cyber threat information processing program
RU2757807C1 (ru) Система и способ обнаружения вредоносного кода в исполняемом файле