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

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

 

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

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

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

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

В результате долгой, быстрой, а также и обычной разработки в приложении возникают уязвимости (ГОСТ 50922-2006). В общем случае, используя уязвимости в приложениях (например, эксплойты), злоумышленники могут вызвать некорректную работу приложения, в результате чего могут получить неправомерный доступ к данным пользователя и нанести ему тем самым вред или материальный ущерб.

Известны различные типы уязвимостей, например, переполнение буфера (англ. buffer overflow) - уязвимость, возникающая, когда приложение записывает данные за пределами выделенного в памяти буфера, что зачастую приводит к исполнению вредоносного кода. Также значительная часть уязвимостей привносится в приложения путем некорректного использования программного интерфейса приложений (англ. application programming interface, API) операционной системы. Кроме того, сложно проверить наличие упомянутых уязвимостей в модулях приложений, не имея доступа к исходному коду этих модулей приложений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Под средствами системы в настоящем изобретении понимаются реальные устройства, системы, компоненты, группы компонентов, реализованные с использованием аппаратных средств, таких как интегральные микросхемы (англ. application-specific integrated circuit, ASIC) или программируемые вентильные матрицы (англ. field-programmable gate array, FPGA) или, например, в виде комбинации программных и аппаратных средств, таких как микропроцессорная система и набор программных инструкций, а также на нейроморфных чипах (англ. neurosynaptic chips) Функциональность указанных средств системы может быть реализована исключительно аппаратными средствами, а также в виде комбинации, где часть функциональности средств системы реализована программными средствами, а часть аппаратными. В некоторых вариантах реализации часть средств, или все средства, могут быть исполнены на процессоре компьютера общего назначения (например, который изображен на Фиг. 3). При этом компоненты (каждое из средств) системы могут быть реализованы в рамках как одного вычислительного устройства, так и разнесены между несколькими, связанными между собой вычислительными устройствами.

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

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

В общем случае при запуске анализируемого на предмет выявления уязвимостей приложения средство модификации 110 модифицирует (изменяет и/или добавляет) исполняемый код анализируемого приложения 180 в соответствии с правилами модификации. Исполняемый код модифицируется таким образом, что вместо вызова проверяемых функций в процессе исполнения будут вызваны аналогичные функции с совпадающим двоичным интерфейсом приложений (англ. Application Binary Interface, ABI). Под проверяемыми функциями в настоящем изобретении понимаются функции операционной системы (ОС), а также функции стандартных библиотек языков программирования (например, функция "printf()"). Таким образом выполняется модифицированный код в контексте анализируемого приложения 180.

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

- сохранить аргумент функции в журнал;

- сгенерировать системное событие;

- не выполнять функцию;

- изменить значение аргумента.

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

В общем случае модификация исполняемого кода анализируемого приложения 180 средством модификации 110 заключается в выявлении в коде анализируемого приложения 180 функций согласно правилам модификации функций и в добавлении «функции-ловушки» (англ. hook), то есть кода, который осуществляет перехват (перехватывает) вызова функции и берет управление на себя. Таким образом, в результате вместо вызова оригинальной функции вызывается функция-ловушка, которая с точностью совпадает по двоичному интерфейсу приложений с оригинальной функцией, а по завершению исполнения возвращает управление в оригинальную функцию.

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

На ассемблерном уровне код функции выглядит так:

00200000	mov еах, 0
00200004	movebx, 10
00200008	add еах, ebx
0020000d	call 0x8000f0cd
00200010	cmp еах, 0x12

…

00016d8

retn

Функция вызывается таким образом:

75212412

callmy_fimc

что эквивалентно:

75212412

call 00200000

Управление передается по адресу 00200000, а при вызове retn возвращается по адресу 75212412+4 (так как команда "call" занимает 4 байта).

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

00200000	call hook
00200004	movebx, 10
00200008	add еах, ebx
0020000d	call 0x8000f0cd
00200010	cmp еах, 0x12
00016d8	retn

А именно в код добавляется функция-ловушка в виде вызова функции «hook».

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

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

Анализ данных, полученных от средства исполнения 120, которые в свою очередь получены от функций-ловушек во время вызовов функций операционной системы, а также функций стандартных библиотек языков программирования, средство выявления уязвимостей 130 производит с помощью требований безопасного исполнения (далее по тексту - требования). В одном из вариантов реализации требования хранятся в базе данных 190. Требования содержат по меньшей мере диапазон допустимых значений аргументов для функций, для которых средством модификации 110 был добавлен исполняемый код для перехвата их вызова. Требования в общем случае могут быть изменены и дополнены в процессе работы системы на основании так называемых «лучших практик» (англ. best practices), информации об устаревших (англ. obsolete) функциях и функциях, включенных производителями ПО (например, Microsoft) в список функций, призванных небезопасными (например, "strcpy()"). В одном из вариантов реализации требования содержат рекомендации в контексте безопасного программирования (например, в Windows есть безопасные и небезопасные функции по созданию файлов). В одном из вариантов реализации для по меньшей мере одного требования может быть задана степень критичности. Степень критичности есть числовая величина, чем выше которая, тем более уязвимо анализируемое приложения 180. В общем случае при несоответствии данных, полученных от средства исполнения 120, диапазону допустимых значений аргументов, содержащемуся в требовании, средство выявления уязвимостей 130 выявляет уязвимость в анализируемом приложении 180.

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

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

В одном из вариантов реализации в случае выявления уязвимости средство исполнения 120 прерывает (вплоть до прекращения исполнения) исполнение анализируемого приложения 180. В еще одном из вариантов реализации средство исполнения 120, при выявлении уязвимости создает в журнале отчет о выявленной уязвимости. Еще одном из вариантов реализации при этом учитывается степень критичности уязвимости, если она выше порогового значения, исполнение анализируемого приложения 180 прерывается. В другом варианте реализации исполнение анализируемого приложения 180 средством исполнения 120 продолжается.

Примеры работы настоящей системы описаны ниже.

Для ОС "Windows" есть требование по использованию API-функции ОС "LoadLibrary(path)": путь к загружаемой библиотеке должен быть в формате Fully-Qualified Path (например, C:\fally\qualified\path\to\module.dll). Это требование разработано для того, чтобы конкретизировать, какую динамическую библиотеку необходимо загрузить приложению, так как если передать короткий путь (например, module.dll), ОС не будет точно знать, откуда следует загружать модуль, и будет пытаться загружать его из разных мест, что может привести к загрузки неправильного экземпляра модуля, что приведет к исполнению чужого кода, что является уязвимостью. Таким образом, добавленная средством модификации 110 функция-ловушка, вызванная вместо оригинальной API-функции "LoadLibrary()", считает путь к модулю из аргумента, этот путь будет сохранен средством исполнения 120, а средство выявления уязвимостей 130 проверит его на соответствие требованиям, а именно, указан ли он в формате Fully-Qualified Path, и, если нет - вынесет решение об уязвимости.

Для ОС "Linux" есть требование, запрещающее выделение страниц памяти с атрибутами на запись и выполнение одновременно. В Linux для выделения страниц памяти есть функция "mmap()", один из аргументов которой отвечает за дескриптор доступа на выделяемой странице памяти. Функция-ловушка, добавленная средством модификации 110 и вызванная вместо оригинальной функции mmap(), прочтет аргумент, отвечающий за дескриптор доступа. Средство выявления уязвимостей 130 сравнит его со значением, которое эквивалентно правам на запись и выполнение, и, если данные биты доступа к памяти присутствуют в этом аргументе, средство выявления уязвимостей 130 вынесет решение об уязвимости.

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

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

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

На этапе 230 исполняют с помощью средства исполнения 120 анализируемое приложение 180 после добавления исполняемого кода. В одном из вариантов реализации исполнение анализируемого приложения 180 происходит с использованием автоматических тестов.

На этапе 240 с помощью средства исполнения 120 собирают данные полученные добавленным исполняемым кодом. В одном из вариантов реализации при этом выполняют описанные ранее действия путем выполненной средством модификации 110 модификации кода.

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

На этапе 260 выявляют с использованием средства анализа 130 по меньшей мере одну уязвимость в анализируемом приложении 180 в случае несоответствия упомянутых данных диапазону допустимых значений по меньшей мере одного требования.

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

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

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

средство модификации, предназначенное для:

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

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

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

- исполнения приложения после добавления исполняемого кода средством модификации;

- сбора данных с использованием добавленного исполняемого кода;

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

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

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

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

2. Система по п. 1, в которой функцией является функция операционной системы.

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

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

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

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

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

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

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

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

- исполняют приложение после добавления исполняемого кода;

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

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

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

9. Способ по п. 8, в котором функцией является функция операционной системы.

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

11. Способ по п. 8, в котором правила модификации хранятся в базе данных.

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

13. Способ по п. 8, в котором исполнение приложения происходит с использованием автоматических тестов.

14. Способ по п. 8, в котором требования безопасного исполнения хранятся в базе данных.