CC BY
0
Селищев Валерий Анатольевич, канд. техн. наук, доцент, [email protected]. Россия, Тула, Тульский государственный университет
RESEARCH OF AN ADAPTIVE ALGORITHM FOR DETECTING COMPROMISES WEB SESSION USING MACHINE LEARNING METHODS
I.D. Krylov, A.A. Zhdanov, D.K. Shulga, I.O. Elfimov, V.A. Selishchev
Protection of authentication procedure by tracking compromised user actions while using a browser is considered. An algorithm for tracking users' browser fingerprints based on machine learning as an additional authentication method is proposed.
Key words: authentication, browser fingerprint, algorithm, machine learning, program code.
Krylov Ilya Dmitrievich, student, [email protected]. Russia, Saint-Petersburg, National Research University
ITMO,
Zhdanov Anton Aleksandrovich., student, [email protected], Russia, Saint-Petersburg, National Research University ITMO,
Shulga Dmitry Konstantinovich, student, [email protected], Russia, Saint-Petersburg, National Research University ITMO,
Elfimov Ilya Olegovich, student, [email protected], Russia, Saint-Petersburg, National Research University ITMO,
Selischev Valery Anatolievich, candidate of technical sciences, docent, sel648val@rambler. ru, Russia, Tula, Tula State University
УДК 004.052.42; 519.1
DOI: 10.24412/2071-6168-2023-12-514-515
МЕТОДЫ ФОРМАЛЬНОГО ОПИСАНИЯ КОДА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В ЗАДАЧАХ АВТОМАТИЧЕСКОГО АНАЛИЗА ПОВЕДЕНИЯ ПРОГРАММ
С.И. Плаксин
Рассматриваются методы генерации формального описания кода программного обеспечения. Проводится их обзор и определяется их возможность применения для использования при поиске вложенных циклов. В качестве оптимального метода выбирается гибридный анализ программы, позволяющий совершить полное покрытие кода и учитывать параллелизм в программе.
Ключевые слова: уязвимости, граф выполнения программы, статический анализ кода, динамический анализ кода, вложенные циклы.
Современные программы становятся все масштабнее и сложнее, что усложняет восприятие их структуры в особенности для новых разработчиков. Отсутствие полноценного понимания программы может приводить к ошибкам и нежелательным структурам. Вложенные циклы, особенно если они имеют большую глубину вложенности, могут значительно замедлить выполнение программы. Для их поиска могут использоваться представление программного кода в виде графа и последующего анализа циклов в нём [1]. Однако данный метод не позволяет обрабатывать программы с динамической памятью из-за применения статического анализа. Что является проблемой и затрудняет поиск таких циклов в многопоточных программах.
Важным является разработка алгоритма точного поиска вложенных циклов в программах, использующих распараллеливание. Для чего потребуется сначала выбрать метод анализа программы для поиска в нём вложенных циклов. Среди методов анализа программного обеспечения можно выделить основные:
Статический анализ [2]. Этот метод подразумевает анализ исходного кода программы без фактического его выполнения. В общем виде задача статического анализа алгоритмически неразрешима по теореме Райса [3]. В следствии чего допускается неточность получаемых результатов, таких как ложных срабатываний и пропуска уяз-вимостей. Такой анализ может производится на любом этапе разработки программы.
Сначала на основе кода программы строится промежуточное представление (модель кода). Модель кода может быть представлена в зависимости от используемого анализатора в виде исходного кода, графа потока управления CFG (Control Flow Graph) [4] (рис. 1), дерева синтаксического разбора, трёхадресного кода, машинного кода и т.д. Для построения модели кода используется лексический и синтаксический анализ для создания дерева разбора AST (Abstract Syntax Tree), аналогично компиляторам. Лексический анализатор преобразует исходный текст программы в поток лексем за счёт разбиения его на минимальные смысловые элементы. Синтаксический анализ проверяет является ли данный поток лексем грамматике используемого языка программирования. В результате строится AST, который проверяется на более сложные и комплексные отношения семантическим анализом. В результате дерево разбора можно привести в другие формы, одной из которых является CFG. Граф потока управления является основной моделью кода для многих алгоритмов статического анализа.
Затем к представлению применяются алгоритмы статического анализа, задачей которых является дополнение модели кода полезной информации, которая упростит последующий анализ. Анализ делится на внутрипроце-дурный и межпроцедурный, но на практике приходится решать обычно задачи межпроцедурного анализа из-за редкости нахождения уязвимости или структуры полностью в отдельной функции. Существует несколько общих подходов для решения таких задач:
- Встраивание функций (inline). При вызове функции осуществляется её полное встраивание, тем самым задача межпроцедурного анализа превращается в внутрипроцедурный. Однако в реальности вложенность функций в функции приводит к быстрому росту объёму исследуемой информации, а в случае рекурсии невозможности применения такого решения. Что делает такой поход применимым с ограничениями для малых программ.
- Построение общего CFG программы. Аналогичен предыдущему подходу, однако вместо встраивания полного содержания функции указывается ссылка на это содержание, а в конце обработки функции происходит обратный переход. Является более эффективным, но всё же применим при ограниченной глубине вызова функций.
- Построение информации о функциях (function summary). Для каждой функции создаётся summary, состоящее из правил, описывающих изменение информации при использовании функции в зависимости от разных входных данных. Что позволяет значительно уменьшить объём обрабатываемых действий при вызове функции, т.к. вместо её содержания будет обрабатываться summary. Для определения правильного порядка обработки функций создаются итеративные графы вызовов функций (Call Graph) [5] на основе структуры программы, т.к. подразумевается, что любая встречаемая функция должна уже иметь собранное для неё summary.
Сложность задачи межпроцедурного анализа является экспоненциальной, в связи с чем анализатору необходимо проводить ряд оптимизаций и допущений. В результате при создании анализаторов для поиска сложных уязвимости ищется компромисс между объемом потребляемых ресурсов, временем анализа, количеством ложных срабатываний и найденных уязвимостей.
После заполнения этого представления дополнительной полезной информацией оно обрабатывается в соответствии с правилами поиска уязвимостей или структур. Правила задают какие флаги или наборы терминов нужно искать в модели кода для определения наличия соответствующих им уязвимостей или структур.
Граф получаемый в результате преобразования промежуточного представления является детерминированным и независимым от конкретных входных данных, за счёт обработки исходного кода программы без её запуска. В связи с чем может применятся к любому языку программирования и независим от среды выполнения. Однако имеет ограниченную точность для отражения поведения программы во время ее выполнения.
Рис. 1. Пример Control Flow Graph
К алгоритмам статического анализа относятся:
- Анализ потока управления (Control Flow Analysis) [6]. Изучает порядок выполнения инструкций в программе, позволяя определять, как программа переходит между различными участками кода. Применяется для обнаружения недостижимых участков кода и оптимизации. Алгоритм анализа потока управления можно разбить на следующие шаги:
1. Сначала строится CFG для представления структуру управления выполнения программы.
2. Проводится анализ пути выполнения на основе CFG, что позволяет определить, какие части кода будут выполнены при разных входных данных и условий.
3. Затем выполняется анализ контрольных зависимостей для определения какие инструкции зависят друг
от друга.
4. Проводится анализ CFG для выделения точек возврата, циклов и других структур.
5. Производится анализ свойств потока управления для поиска ошибок в CFG, например, множественные переходы и недостижимые участки кода.
- Анализ потока данных (Data Flow Analysis) [7]. Изучает порядок распределения данных в программе, позволяя определять зависимости между переменными, возможные принимаемые значения и в каких участках кода они могут быть изменены. Данная информация позволяет проводить оптимизацию кода и находить конструкции и уязвимости. Алгоритм анализа потока данных можно разбить на следующие шаги:
1. Сначала строится CFG.
2. На основе CFG строится DFG (Data Flow Graph) [8][9] (рис. 2), представляющий поток данных между переменными в программе.
3. Для каждой переменной создаются уравнения потока данных, отображающие зависимость значения переменной от значения других переменных в разных точках программы.
4. Проводится анализ потока данных, который может быть прямым или обратным. Что в результате создаёт для каждой переменной множества зависимостей от других переменных, достижимых значений и других данных.
5. Для обнаружения более точной информации решаются системы уравнений потока данных с использованием анализа констант и живых переменных, аппроксимации и других методов.
- Модельная проверка (Model Checking) [10]. Применяется для верификации программы на соответствие формальной модели или спецификации. Алгоритм модельной проверки можно разбить на следующие шаги:
1. Создаётся формальная модель программы в виде абстрактного описания работы программы без учёта особенностей ее отдельной реализации. Такое описание задаётся в виде конечных автоматов, математических структур, логических формул и других, которые могут описать поведение программы.
2. Задаются спецификации, которым должны удовлетворять программа и формальная модель.
3. Строится граф всех возможных состояний программы.
4. Алгоритм сверяет каждое состояние программы на соответствие заданным спецификациям обходя построенный граф в глубину или ширину, тем самым обрабатывая все ветки программного кода.
5. При обнаружении несоответствия спецификации создаётся контрпример, содержащий путь выполнения программы и входные данные, которые приводят к этому нарушению.
- Анализ аннотаций (Annotation-Based Analysis) [11]. Подробно изучает и анализирует информацию, добавляя к ней дополнительные сведения (аннотации и метаданные), которые могут помочь в понимании контекста и взаимосвязей Алгоритм анализа аннотаций можно разбить на следующие шаги:
1. Сначала вручную создаются аннотации в исходном коде программы. Такие метаданные для кода предоставляют дополнительную информацию о структуре, назначении и ожидаемом поведении. Такие аннотации доступны в языках программирования Java, C#, TypeScript, PHP, Python.
2. Анализатор собирает все аннотации из исходного кода с учётом их расположения и связи в коде.
3. Проверяется соответствует ли фактический код заданным параметрам в аннотации. И в случае несоответствия предоставляется рекомендация о необходимости исправления.
- Анализ потока уязвимостей (Vulnerability Flow Analysis) [12]. Специализируется на выявлении уязви-мостей в коде, которые могут быть использованы злоумышленниками, таких как утечки памяти, XSS-атаки и другие. Алгоритм анализа потока уязвимостей можно разбить на следующие шаги:
1. Сначала строится AST.
2. Определение точек входа в программу, таких как ввод пользователем данных, вызовы внешнего API и
другие.
3. Проводится анализ потока данных из точек входа в программу как они обрабатывают и передаются между функциями.
4. Поиск инъекций SQL, кросс-сайт скриптинга, уязвимостей, связанных с утечкой информации и другие. И определение их источника (точки входа) и возможных путей эксплуатации.
К средствам для поиска структур и уязвимостей в программном обеспечении и генерации графов выполнения программы на основе статического анализа относятся:
- GCC (GNU Compiler Collection) [13]. Является одним из наиболее популярных и мощных инструментов для компиляции исходного кода на языках программирования, таких как C, C++, Objective-C, Java, Fortran, и Ada. Использование флага -fdump-tree-cfg позволяет создавать CFG отображающий структуру потока управления в программе [14].
- Clang Compiler [15]. Компилятор с открытым исходным кодом для языков программирования C и C++. В сравнении с GCC он имеет более высокую производительность и более быстрое обновление под новые изменения и поддержку современных стандартов C и C++. Также Clang разработан с расчётом на модульность, что позволяет более простое внедрение и расширение новых функций. Однако получаемый CFG не всегда охватывает полностью все пути выполнения программы и может выдавать ложные срабатывания предупреждений об ошибках.
- Cppcheck [16]. Инструмент c открытым исходным кодом для статического анализа исходного кода на языках программирования C и C++. CFG получаемое в результате анализа позволяет обнаружение сложных ошибок, связанные с ветвлением, циклами и зависимостями данных, которые могли бы быть упущены при более поверхностном анализе, а также определять сложность и структуру кода. Имеет высокую точность при выявлении ошибок, снижая количество ложных срабатываний. Однако процесс анализа является ресурсоёмким.
- Coccinelle [17]. Инструмент c открытым исходным кодом для автоматизированного анализа и рефак-торинга исходного кода на языках программирования C/C++. Позволяет определять паттерны и шаблоны кода, которые нужно найти или заменить, для чего используется специальный язык, который позволяет описывать структуры исходного кода.
Статический анализ позволяет получить общую информацию о структуре всей программы, но плохо масштабируется для больших программ. Граф получаемый в результате требует много времени на обработку, имеет много лишней информации и покрывает ветки кода, которые могут не затрагиваться при эксплуатации. Также такой анализ не отражает последовательность и особенность преобразования данных при параллельной обработке. Что в совокупности делает его подходящим для поставленной задачи, позволяя делать полное покрытие кода программы без параллелизма для поиска циклов.
int а, Ь, с;
void fctO {
b++;
if (a > 0) с = a + b;
else
с = a * b; a = c;
}
В
-v , у
Рис. 2. Пример Data Flow Graph
516
Динамический анализ [18]. В процессе выполнения программы собираются данные о её исполнении. Делится на несколько шагов:
- Подготовка данных для тестирования программы. Включает как входные данные, так и ожидаемые выходные данные.
- Проведение тестирования программы и сбор информации о её выполнении. Запуск программы, её мониторинг использования ресурсов и профилирование производительности.
- Анализ полученных результатов. Во время выполнения программы собираются данные, такие как ло-ги, отладочная информация, результаты выполнения и другие сведения, которые могут быть полезны для анализа. Ищутся признаки или паттерны указывающие на наличие ошибки.
Для проведения анализа требуется провести компиляцию программы без ошибок, что делает невозможным использование на ранних этапах разработки в отличии от статического анализа. Существуют разные методы взаимодействия динамического анализа с программой:
- Инструменты исходного кода - внедрение дополнительного кода в исходный код программы до компиляции.
- Инструменты объектного кода - внедрение дополнительного кода в исполнимый файл программы. Позволяет проводить анализ программы без необходимости доступа к её исходному коду.
- Инструменты этапа компиляции - внедрение дополнительного кода через специальные ключи компилятора.
- Специальные библиотеки для этапа выполнения - специализированные для поиска ошибок и отладки библиотеки.
Динамический анализ наиболее полезен в системах, где надёжность и потребляемые ресурсы являются решающими критериями, например, системы реального времени, где любая ошибка может быть критической. В большинстве случаев не склонен к ложным срабатывания предупреждений об ошибках, т.к. все обнаруженные ошибки происходят в момент её возникновения во время работы программы. Такой анализ не определяет логические ошибки, но может учитывает особенности среды выполнения и определять функции, которые не являются частью статического анализа. Даёт представление о производительности при текущей конфигурации и узких местах программы. Позволяет проводить анализ многопоточного кода. Эффективность анализа и покрытие кода сильно зависит от качества и количества входных данных для проводимого тестирования. Результаты могут сильно различаться в зависимости от системы, входных данных и покрытия при тестировании. Внедрения инструментов для динамического анализа в программу также может негативно сказываться на её производительности и поведении. Определение местоположение обнаруженной ошибки в исходном коде может быть затруднительным процессом.
К алгоритмам динамического анализа относятся:
- Анализ ошибок среды выполнения (Runtime Error Analysis) [19]. Используется для поиска ошибок при фактическом выполнении программы, такие как деление на ноль, выход за пределы массива и другие. Алгоритм анализа ошибок среды выполнения можно разбить на следующие шаги:
1. Сначала в исходный код программы вносятся инструменты для логирования и проверки данных при выполнении программы.
2. Во время тестирования программы собираются данные о взаимодействии программы с памятью, файлами, ресурсами, выполнении потоков и т.д.
3. Собранные данные анализируются для выявления ошибок. Каждая операция проверяется на наличие попыток деления на ноль, на попытки доступа к памяти за пределами выделенной области или освобождённой памяти. Анализируются параллельные операции на попытку одновременного обращения к ресурсам без синхронизации. Изучается выделение и освобождение памяти для определения утечки памяти.
- Динамический анализ уязвимостей (Dynamic Application Security Testing - DAST). Используется для оценки безопасности веб-приложений и сервисов в реальном времени. Алгоритм DAST можно разбить на следующие шаги:
1. Сначала определяется целевое приложение через указание URL-адреса или IP-адреса веб-приложения.
2. Активное тестирование за счёт отправки различных запросов и анализа ответов от приложения на наличие признаков уязвимостей, например, недостаточная фильтрация ввода, SQL-инъекции, межсайтовый скрип-тинг и другие уязвимости.
3. Пассивное тестирование за счёт наблюдения за трафиком между клиентом и сервером на наличие уяз-
вимостей.
- Профилирование среды выполнения (Runtime Profiling) [20]. Собирает данные о выполнении кода в реальном времени. Применяется для измерения времени выполнения и потребляемых ресурсов, анализа вызова функций во время работы программы и поиска утечек памяти. Позволяет учитывать специфику параллелизма в программе. Алгоритм профилирования среды выполнения можно разбить на следующие шаги:
1. Сначала в исходный код программы вносятся инструменты, такие как временных меток, счетчиков и другие. Данный процесс может проводится вручную или автоматически.
2. Проводится выполнение программы и собираются метрики, поступающие со встроенных инструментов, содержащие такие данные, как время выполнения функций, количество вызовов функций, использование памяти и другие.
3. Полученные данные анализируются выбранным инструментов для профилирования. Существуют различные инструменты для профилирования для тестирования разных аспектов программы, например, использования памяти, производительности, сетевого взаимодействия, безопасности, многозадачности и потоков, работы с базами данных и другие.
- Анализ потока данных (Data Flow Analysis). Изучает порядок распределения данных в процессе работы программы, позволяя определять зависимости между переменными, возможные принимаемые значения и в каких участках кода они были изменены. Данная информация позволяет проводить оптимизацию кода и находить уязвимости и структуры. Алгоритм анализа потока данных для динамического анализа аналогичен статическому, но для
построения CFG используются данные от внедрённых в код инструментов. Такой анализ позволяет анализировать фактическую структуру программы даже с учётом параллелизма. Для поиска вложенных циклов, можно обнаружить зависимости между индексами или переменными, используемыми для итерации, и определить их вложенность.
- Трассировка выполнения (Execution Tracing) [21]. Изучает порядок выполнения инструкций в программе и позволяет отслеживать изменения в переменных, используемых для управления циклами, и находить совпадения между началом и концом циклов. Эти данные позволяют построить граф выполнения программы (Execution Graph) [22], который отражает реальный порядок выполнения инструкций во время работы. Такой граф хранит меньше лишней для поиска циклов информации и требует меньшее время обработки информации в сравнении с CFG.
К средствам для поиска структур и уязвимостей в программном обеспечении и генерации графов выполнения программы на основе динамического анализа относятся:
- GDB (GNU Debugger) [23]. Мощный отладочный инструмент для разработки программного обеспечения на языке C, C++, Ada, Assembly, D, Fortran, Go, Objective-C, OpenCL C, Modula-2, Pascal, Rust. Он является частью проекта GNU. Сторонний инструмент Valgrind позволяет создавать граф выполнения и обнаруживать ошибки в программе, такие как утечки памяти и прочие.
- LLDB (LLVM Debugger) [24]. Отладчик с открытым исходным кодом, разработанный как часть проекта LLVM (Low-Level Virtual Machine). Он предназначен для отладки программного обеспечения, написанного на языках программирования, таких как C, C++.
- Dynamic Binary Instrumentation (DBI) [25]. Технология, которая позволяет анализировать и модифицировать исполняемый бинарный код программы во время выполнения. DynamoRIO [26] - это гибкий и мощный фреймворк для Dynamic Binary Instrumentation.
Динамический анализ позволяет быстро независимо от размеров программы получить информацию об отдельных ветках кода в результате их выполнения в программе, но для полного покрытия структуры программы может потребоваться много запусков для обхода всех возможных веток кода. Однако это также позволяет проводить тестирование только определённых функций программы, что требует значительно меньше ресурсов и быстрее, чем полноценный анализ. Данный подход позволяет отслеживать порядок действий внутри отдельных потоков. Что делает данный анализ подходящим для формирования графа для поиска вложенных циклов с учётом параллелизма, но покрытие кода ограничено глубиной тестирование.
Гибридный анализ [27]. Подход предполагающий совмещение информации от статического и динамического анализов, что позволяет получать более полное представление о зависимостях и взаимодействиях в коде программы. Расхождение результатов могут указывать на некоторые уязвимости, которые невозможно обнаружить при применении лишь одного метода анализа. Имеет меньшее влияние ограничений от этих методов анализа, чем использование их по отдельности. Позволяет проводить глубокий и полноценный анализ программного кода. Возможны конфликты между данными от статического и динамического анализов, а также является более сложным в реализации и более требовательным в эксплуатации, чем использование анализов по отдельности. Чаще применим при необходимости комплексного анализа программы на наличие разных типов уязвимостей и структур. Позволяет более точно определять местоположение ошибок в исходном коде, которые были найдены в процессе тестирования.
К средствам для поиска структур и уязвимостей в программном обеспечении и генерации графов выполнения программы на основе гибридного анализа относятся:
- KLEE (KLEE Symbolic Execution Engine) [28]. Инструмент для гибридного анализа программного кода с использованием символического исполнения. Может применятся для языков C/C++ и других. Он позволяет исследовать все возможные пути выполнения программы, предоставляя подробную информацию о возможных ошибках, недопустимых состояниях и даже находя неочевидные проблемы в программном коде.
- Angr [29]. Фреймворк для статического и динамического анализа бинарных файлов, который может быть использован для различных целей, включая реверс-инжиниринг, анализ безопасности, и обнаружение уязвимо-стей.
Гибридный анализ предоставляет совместную информацию от статического и динамического анализов, однако большинство этой информации избыточна для нашей задачи и потребует удаление во время фильтрации незначащих вершин графа. Также такой комплексный подход потребует большие затраты времени и ресурсов, чем использование любого из этих анализов по отдельности. В связи с чем гибридный анализ подходит для решения задачи по поиску вложенных циклов, но избыточность информации и более высокие затраты ресурсов и времени делают его значительно менее эффективным для поиска лишь вложенных циклов в программе.
В результате изучения методов было выявлено, что ни статический анализ, ни динамический анализ по отдельности не позволяют точно определять вложенные циклы. Статический анализ не может учитывать параллелизм и влияние конфигурации системы на работу программы, а динамический анализ не совершает полное покрытие программного кода из-за проверки лишь тестируемых веток кода. В связи с чем использование гибридного анализа на основе совмещения данных из обоих подходов позволит точно отслеживать фактический порядок выполнения инструкций и циклов в программе. Использование анализа потока данных статического и динамического подхода поможет собрать необходимые данные и построить CFG для последующего поиска и классификации вложенных циклов. Однако требуется отдельное упрощение получаемого графа от информации, не используемой для данной задачи.
Список литературы
1. P. Arato and G. Suba. A data flow graph generation method starting from c description by handling loop nest hierarchy. 2014 IEEE 9th IEEE International Symposium on Applied Computational Intelligence and Informatics (SACI). 2014
2. Bardas A. G. et al. Static code analysis // Journal of Information Systems & Operations Management. 2010. Т. 4. №. 2. С. 99-107.
3. Rice H. G. Classes of recursively enumerable sets and their decision problems //Transactions of the American Mathematical society. 1953. Т. 74. №. 2. С. 358-366.
4. Allen F. E. Control flow analysis //ACM Sigplan Notices. 1970. Т. 5. №. 7. С. 1-19.
5. Antal G. et al. Static javascript call graphs: A comparative study // 2018 IEEE 18th International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 2018. С. 177-186.
6. Allen F. E. Control flow analysis //ACM Sigplan Notices. 1970. Т. 5. №. 7. С. 1-19.
7. Brandt J., Schneider K. Static data-flow analysis of synchronous programs //2009 7th IEEE/ACM International Conference on Formal Methods and Models for Co-Design. IEEE, 2009. С. 161-170.
8. Kavi Buckles Bhat. A formal definition of data flow graph models // IEEE Transactions on computers. 1986. Т. 100. №. 11. С. 940-948.
9. Kolbl A., Pixley C. Constructing efficient formal models from high-level descriptions using symbolic simulation //International Journal of Parallel Programming. 2005. Т. 33. С. 645-666.
10. Миронов А. М. Верификация программ методом Model Checking: [Електронний ресурс] //Режим доступу: http://intsys.msu. ru/staff/mironov/modelchk. pdf.
11. Bisognin A. et al. A-MADMAN: annotation-based microarray data meta-analysis tool //BMC bioinformatics. 2009. Т. 10. №. 1. С. 1-11.
12. Schloegel K. A., Bhatt D. Method for software vulnerability flow analysis, generation of vulnerability-covering code, and multi-generation of functionally-equivalent code : пат. 8407800 США. 2013.
13. Richard M. Stallman. GCC 14.0 GNU Compiler Collection Internals. 12th Media Services, 2018
14. Jain S., Pal R., Srivastava A. Control flow graph based framework for effective evaluation of source code //International Journal of Computer Applications. 2013. Т. 82. №. 16.
15. Babati B. et al. Static analysis toolset with Clang //Proceedings of the 10th International Conference on Applied Informatics (30 January1 February, 2017, Eger, Hungary). 2017. С. 23-29.
16. "D. Marjamaki. (2007) Cppcheck - A tool for static C/C++ "code analysis. Accessed: 2019-08-30. [Online]. Available: http://cppcheck.sourceforge.net"
17. Padioleau Y. et al. Documenting and automating collateral evolutions in Linux device drivers //Acm sigops operating systems review. 2008. Т. 42. №. 4. С. 247-260.
18. Xie T., Notkin D. An empirical study of java dynamic call graph extractors //University of Washington CSE Technical Report. 2002. С. 02-12.
19. Tomb A., Brat G., Visser W. Variably interprocedural program analysis for runtime error detection //Proceedings of the 2007 international symposium on Software testing and analysis. 2007. С. 97-107.
20. Brassel B. et al. Run-time profiling of functional logic programs //International Symposium on Logic-Based Program Synthesis and Transformation. Berlin, Heidelberg : Springer Berlin Heidelberg, 2004. С. 182-197.
21. Hojaji F. et al. Model execution tracing: a systematic mapping study //Software and Systems Modeling. 2019. Т. 18. С. 3461-3485.
22. Graham S. L., Kessler P. B., McKusick M. K. Gprof: A call graph execution profiler //ACM Sigplan Notices. 1982. Т. 17. №. 6. С. 120-126.
23. Annamalai M., Velusamy L. A Call-Graph Profiler for GNU Octave //arXiv preprint arXiv:0810.3468. 2008.
24. Lopes B. C., Auler R. Getting started with LLVM core libraries. Packt Publishing Ltd, 2014.
25. Zhao V. Evaluation of dynamic binary instrumentation approaches: Dynamic binary translation vs. dynamic probe injection. 2018.
26. Zhou N. Dynamic Program Analysis and Optimization under DynamoRIO : дис. The University of Manchester (United Kingdom), 2014.
27. Antal, G.; Toth, Z.G.; Hegedus, P.; Ferenc, R. Enhanced bug prediction in javascript programs with hybrid call-graph based invocation metrics //Technologies. 2020. Т. 9. №. 1. С. 3.
28. Cadar C. et al. Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs //OSDI. 2008. Т. 8. С. 209-224.
29. Cheng E. Binary Analysis and Symbolic Execution with angr : дис. PhD thesis, The MITRE Corporation,
2016.
Плаксин Сергей Игоревич, аспирант, [email protected], Россия, Тула, Тульский государственный университет
METHODS FOR FORMAL DESCRIPTION OF SOFTWARE CODE IN TASKS OF AUTOMATIC BEHAVIOR ANALYSIS
OF PROGRAMS
S.I. Plaksin
The paper considers methods for generating a formal description of software code. Carried out their review and determined possibility of their application for use in searching loop nests. Hybrid analysis is chosen as optimal method, which allows complete code coverage and takes into account parallelism in the program.
Key words: vulnerability, program execution graph, static code analysis, dynamic code analysis, nested loops.
Plaksin Sergei Igorevich, postgraduate, [email protected], Russia, Tula, Tula State University
