Федеральное государственное образовательное бюджетное учреждение высшего образования

«Финансовый университет при Правительстве Российской Федерации»

(Финансовый университет)

Факультет Прикладной Математики и Информационных Технологий

Кафедра «Информационная безопасность»

Противодействие нелегитимному воспроизведению функций    программного обеспечения

Выполнил: 

студент группы ИБ4-1, Анточи Антон Сергеевич

Проблема распространения экземпляров программ

Полное ограничение исследователя от доступа к программному коду невозможно при распространении экземпляра программы

Все процессы этапа разработки являются обратимыми

2

Влияние цифровизации на объемы производимого ПО

Из года в год объем производимого ПО увеличивается 

Рост интереса к "Цифровой трансформации" на основе поисковых запросов Google за последние 15 лет в мире (слева) и в России в частности (справа)

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

3

Цель и задачи работы

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

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

Предмет исследования - методы и механизмы препятствования нелегитимному исследованию программного обеспечения с целью воспроизведения функционала

4

Исследование возможностей злоумышленника

Современный нелегитимный исследователь имеет богатые возможности по исследованию распространяемого ПО 

В публичном доступе существует огромное число вспомогательного ПО для упрощения и ускорения исследования, что понижает входной порог для данной деятельности 

5

Анализ возможностей противодействия

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

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

6

Требования к механизму дополнительной защиты

Механизм дополнительной защиты должен:

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

7

Механизм дополнительной защиты программ

В основе механизма лежат следующие принципы:

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

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

 

1 - высокоуровневый код, содержащий классы и подпрограммы

 

2 - низкоуровневый код точки входа

 

3 - псевдокод ассемблерного кода точки входа

8

Методология в основе механизма защиты

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

1 - исходный код, защищенный методологией «неоднозначных зависимостей»

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

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

9

Архитектура механизма защиты

Основной принцип, лежащий в основе архитектуры механизма - запрет на использование связей вида "один к одному", "один ко многим" и "многие к одному" при вызове подпрограмм

10

Модульность механизма защиты

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

Набор базовых модулей:

Структура таблицы нарушений:

1. Модуль обнаружения изменений в регионах исполняемой виртуальной памяти
    
2. Модуль анализа списка запущенных процессов
    
3. Модуль анализа времени выполнения кода
    
4. Модуль сбора системных сведений о свойствах текущего процесса

11

Тестирование защиты от динамического исследования

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

Тестирование механизма на экспериментальной программе, производящей получение местоположения пользователя по IP-адресу:

12

Оценка разработанного механизма

Оценка сложности статического анализа, обеспечиваемая использованием методологии "неоднозначных зависимостей"

Для анализа одной защищенной программной абстракции исследователю потребуется восстановить все ребра, образующие максимально возможную степень её вершины в графе вызовов (deg) :

• X - множество источников зависимостей
• Yi – множество всех цепочек зависимостей, порожденных из Xi
• Zi – множество всех упоминаний программной абстракции в Xi
• val – функция, возвращающая значение, хранящееся в Yij-цепочке, которая представлена в исходном коде как статическая переменная
• ref – функция, возвращающая значение адреса в памяти упоминания абстракции Zik внутри Xi источника зависимостей

Оценка мощностей множеств:

Требование "повышения сложности" восстановления: 

Вычислительная сложность восстановления 1 узла ≈

Объем анализируемых подпрограмм

при восстановлении 1 узла = deg

13

Оценка разработанного механизма

Оценка сложности устранения и ее влияние на объем и производительность защищаемой программы

Критерий связанности:

Критерий частоты:

• S - множество абстракций, которые передают управление механизму защиты 
• A - множество всех абстракций в коде

• si – абстракции из множества S
• f – средняя частота вызова si – абстракции в секундах

Сложность устранения будет максимальной при:

Вычислительная сложность статического устранения ≈ O(|S|)

14

Оценка разработанного механизма

Оценка сложности компроментации механизма (его модулей)

Компроментация механизма защиты эквивалента компроментации входящих в его состав модулей

Упрощенный критерий защищенности модуля:

• F – множество использованных модулем внешних подпрограмм,
• P – подмножество F (P ⊂ F) защищенных внешних подпрограмм дополнительной проверкой корректности

Уточненный критерий защищенности модуля:

• S – множество всевозможных сценариев использования внешних функций из множества F
• Sfi класс эквивалентности на множестве S:

• Q – множество всех защищенных сценариев
• Qpi – класс эквивалентности на множестве Q:

Уровень устойчивости модуля к компроментации будет максимальным при:

15

Результаты проделанной работы

1. Произведен анализ и классификация возможностей современного нелегитимного исследователя
2. Произведен анализ и систематизация способов противодействия нелегитимному исследованию с привязкой к этапам разработки ПО
3. Проанализированы недостатки современных подходов к защите от исследования
4. Разработана методология "неявных зависимостей" для пред-обработки исходного кода с целью усложнения статического анализа
5. Разработан программный механизм, использующий разработанную методологию для дополнительной защиты программы от динамического исследования
6. Произведена оценка механизма и разработаны критерии для его оценки независимыми разработчиками
7. Описан бизнес-процесс внедрения механизма в существующее ПО, нуждающееся в защите от воспроизведения

16

Спасибо за внимание.