Содержание к диссертации
Введение
Глава 1. Анализ современного состояния в оценке эффективности методов обфускации 12
1.1 Оценка по трем критериям 15
1.2 Оценка методов на основе циклической сложности и ветвления потока управления 17
1.3 Эмпирические методы оценки обфускации 20
1.4 ГОСТ Р ИСО/МЭК 25010-2015 23
1.5 Вывод к первой главе 30
Глава 2. Моделирование предметной области 31
2.1 Построение математической модели приложения 31
2.2 Построение математической модели оценки эффективности методов обфускации 34
2.3 Построение математической модели обфускации 35
2.4 Вывод ко второй главе 36
Глава 3. Применение модели к конкретному языку программирования 37
3.1 Класс-файл 39
3.2 Иерархия классов 40
3.3 Выделение полей метаданных для языка программирования Java 41
3.4 Существующие методы обфускации
3.4.1 Расширение условий для условных операций 43
3.4.2 Обфускация вычислений
3.4.3 Изменение имен переменных 54
3.4.4 Смешивание однотипных переменных 57
3.4.5 Изменение имен полей 63
3.4.6 Изменение имен методов 67
3.4.7 Изменение имен классов 70
3.4.8 Изменение имен пакетов 73
3.4.9 Добавление недостижимого кода 73
3.4.10 Разделение и слияние пакетов 76
3.4.11 Добавление диспетчер-методов 79
3.4.12 Слияние методов 81
3.4.13 Разделение методов 84
3.4.14 Внедрение рефлексии 86
3.4.15 Внедрение invokeDynamic 87
3.5 Вывод к третьей главе 91
Глава 4. Апробация и оценка эффективности 93
4.1 Обзор исходных данных для апробации 93
4.2 Рассмотрение применимости методики на представленных исходных данных 95
4.3 Описание применяемых методов обфускации 96
4.4 Применение методики оценки эффективности ГОСТ 97
4.5 Применение разработанной методики оценки 98
4.6 Вывод к четвертой главе 100
Заключение 101
Список сокращений и условных обозначений 102
Словарь терминов 103
Список рисунков
- Оценка методов на основе циклической сложности и ветвления потока управления
- Построение математической модели обфускации
- Расширение условий для условных операций
- Применение методики оценки эффективности ГОСТ
Оценка методов на основе циклической сложности и ветвления потока управления
В рамках подхода рассматриваются критерии эффективности методов обфускации основанные на метриках сложности программ. Используемые метрики: Метрикой называется отображение, ставящее в соответствие каждой программе некоторое число. Метрика LC размера процедуры — простейшая метрика сложности кода. Чем больше процедура, тем выше априорная оценка её сложности. Размер каждой процедуры будет измерен в инструкциях промежуточного представления. Метрика YC сложности циклической структуры определяется как мощность транзитивного замыкания отношения достижимости в графе потока управления процедуры. Метрика DC сложности потока данных процедуры — позволяет оценить сложность зависимостей по данным в процедуре. Значение метрики DC вычисляется как количество дуг в графе, достигающих определений процедуры. Метрика МС усложнения программы при запутывании вычисляется по формуле: Оценка методов на основе циклической сложности и ветвления потока управления рассматривает критерии эффективности методов обфускации, основанные на метриках сложности графа потока управления программ. Метрикой называется отображение, ставящее в соответствие каждой программе некоторое число. Данный подход рассматривается в работах Курмангалеева Ш. Ф., Корчагина В. П. и Матевосяна Р. А. [69;81] Используемые метрики: Метрика LC размера процедуры — простейшая метрика сложности кода. Чем больше процедура, тем выше априорная оценка её сложности. Размер каждой процедуры будет измерен в инструкциях промежуточного представления. Метрика YC сложности циклической структуры определяется как мощность транзитивного замыкания отношения достижимости в графе потока управления процедуры. Метрика DC сложности потока данных процедуры — позволяет оценить сложность зависимостей по данным в процедуре. Значение метрики DC вычисляется как количество дуг в графе, достигающих определений процедуры. Метрика МС усложнения программы при запутывании вычисляется по формуле: УС(после защиты) 1)С(после защиты) УС (до защиты) DC (до защиты)
Наилучшими параметрами обладают преобразования повышения косвенности, вставки непрозрачных предикатов и введения диспетчера. Очевидно, что устойчивость к анализу возрастет, при применении нескольких запутывающих преобразований. Но также можно повысить сложность самих преобразований путем связывания потоков данных, вводимых преобразованием с потоками данных исходной программы, и устранения слабых мест преобразований. Этот подход также оценивает метод обфускации, основываясь на вносимых модификаций в поток управления ПП. Из основного уравнения данного метода видно, что сравнивается состояние до обфускации и после.
Чем больше метрика усложнения программы, тем сложнее для понимания становится замаскированная программа в силу увеличения числа информационных и управляющих связей. Так же приводится сводная таблица метрики МС для различных методов обфускации (табл. 1).
Видно, что наилучшими параметрами обладают преобразования, повышения косвенности, вставки непрозрачных предикатов, и введения диспетчера. Очевидно, что устойчивость к анализу возрастет, при применении нескольких
Сводная таблица характеристик маскирующих преобразований запутывающих преобразований. Но также можно повысить сложность самих преобразований путем связывания потоков данных, вводимых преобразованием, и потоков данных исходной программы, и устранения слабых мест преобразований. Например, для переплетения процедур таким слабым местом является единственная точка диспетчеризации по дополнительному параметру для выбора рабочей процедуры. Метрика на основе циклической сложности и ветвления потока управления является наиболее эффективной методикой оценки сложных методов обфускации. Рассмотрение ветвления потока управления является наиболее перспективной технологией с учетом современных средств редактирования кода. Большинство имен переменных, используемых в программе может быть легко изменено повсеместно в приложении, в то время как поток управления анализируется с учетом многопоточных вычислений и многократных вызовов. Поток управления сильно зависит не только от непосредственных вызовов методов, но и от вероятности наступления условий. Таким образом, любая oneрация передачи управления (условная или безусловная) является усложнением сложности согласно данной методики. Использование методики оценки на основе циклической сложности и ветвления потока управления сопровождается полным анализом основных характеристик графа управления. Подобный анализ не может производиться без специальных программных средств. Также в оценке конкретных комбинированных методов должен участвовать квалифицированный эксперт в области защиты информации. Оценка собственных методов обфускации должна производиться отдельно. Это означает, что данная методика позволяет систематизировать подход оценки эффективности методов для многократного использования. Таким образом наиболее эффективна данная методика будет при повторном использовании результатов оценки методов обфускации, сокращая участие эксперта обфускации до одного раза для первоначальной оценки. В дальнейшем работа эксперта сводится к правильному использованию заданной методики.
Построение математической модели обфускации
Настройки С будут использоваться для выявления методов, приносящих максимальную пользу для защиты информации. Поскольку, анализ исходного кода на предмет вносимых изменений сопоставим по времязатратам и вычислительным ресурсам с непосредственным внесением этих изменений, анализ чувствительности является одной из самых эффективных математических основ для проведения обфускации данного уровня. Также данный подход позволяет сократить затраты на разработку алгоритма по анализу применимости метода обфускации к блоку кода, используя непосредственно алгоритм обфускации для проведения оценки. В таком случае, любое исключительное условие приводящее к невозможности дальнейшей обфускации является достаточным для того, чтобы считать данный метод не применимым к конкретному блоку кода, результат воздействия которого считается негативным.
Для выявления наиболее эффективного метода обфускации на каждом из этапов для каждого из блоков кода требуется выявить список методов, изменения которых превосходят минимальные изменения из настроек с последующим ранжированием по суммарному взвешенному влиянию каждого из них. (5) С помощью этого выбирается наиболее эффективный метод обфускации и операция повторяется. В качестве ограничений количества повторов могут служить счетчик количества итераций, счетчик времени, затрачиваемый на процесс обфускации и постепенное ухудшение степени изменений каждым из методов в отдельности после каждого применения. При этом последний из ограничителей является условным и должен сопровождаться проверкой на достаточную деградацию изменений при повторном использовании. В случаях когда метод не может гарантировать данную деградацию, требуется исключить его из использования в рамках данной модели.
Поскольку приложение состоит из отельных блоков кода, можно выделить блоки кода не связанные друг с другом и проводить обфускацию этих блоков параллельно. Такой подход позволяет сокращать время затрачиваемое на обфускацию ПП. Особенный выигрыш это может принести при использовании автоматических обфускаторов в многопроцессорной среде. Параллельное выполнение задач обфускации на различных процессорах может принести существенный выигрыш во времени.
Построение математической модели обфускации в рамках данного исследования основывается на сложности анализа эффективности отдельных методов т для подходящих блоков кода сЬ. В связи с тем, что для проведения оценки требуется полноценный анализ данных bd, который сопоставим с самим процессом обфускации, выбрана модель апробации метода обфускации для оценки. Это позволяет сократить количество процессов, необходимых для актуализации в связи с изменениями технологий, усложняя при этом сам процесс обфускации. Усложнение процесса обфускации заключается в том, что помимо обфусцированного кода, метод обфускации также должен вернуть численную характеристику произведенных изменений. Для сравнения комбинированного подхода из нескольких методов, требуется сохранять различные параметры об-фускации раздельно друг от друга. Для демонстрации произведенных изменений метод обфускации обязан отразить свои изменения в bd на соответствующие параметры Ьт. Далее для оценки процесса обфускации комбинированных методов и раздельных рассчитывается взвешенная сумма изменений каждым из способов, которая считается итоговым изменением в продукт. На базе полученной суммы определяется наиболее эффективный алгоритм. В рамках данного исследования далее будет предполагаться, что все методы обфускации комута-тивны и ассоциативны, в то время как в конкретной ситуации это может быть не так.
Во второй главе сделано построение модели обфускации и оценки процесса обфускации для абстрактного языка программирования, позволяющая порти-ровать его на произвольный язык. Также данная модель не накладывает никаких ограничений не только на язык программирования, но и на сами методы обфускации. При необходимости, список методов может быть дополнен. Математическая модель приложения описывает метаданные только в части общей реализации и может быть адаптирована и развита в последующем. Это дает возможность начать применение модели в упрощенной форме, используя минимальное количество свойств блоков кода. При дальнейшем развитии языковых конструкций конкретного языка программирования все необходимые изменения могут вноситься с сохранением обратной совместимости. Также добавление методов обфускации в список методов может производиться уже после практической апробации наиболее простых. Также за рамками исследования осталось исследование некомутативных и неассоциативных методов обфускации на предмет применения их в оптимальном порядке.
Расширение условий для условных операций
Для построения методики потребуется оценить каждый из методов об-фускации по выделенным критериям. В связи с тем, что каждый метод вносит определенный вид модификаций требуется установить какие элементарные операции деобфускации потребуется выполнить для получения исходного кода. Каждая из операций деобфускации предъявляет определенные требования к деобфускатору. Чем выше эти требования, тем меньше вероятность деобфускации со стороны специалистов. Для выведения качественных характеристик требуется рассмотреть свойства деобфускатора.
Рассмотрим лексическую значимость названия (метод, поле, переменная. ..). Смысловая нагрузка названия метода - краткое указания алгоритма, который он в себе содержит. В случае, когда название метода не отражает суть алгоритма, деобфускатор может вводиться в заблуждение о функциональности данного метода. В связи с этим первым критерием, которых требуется выделить в методе - необходимость обладания специальными знаниями в предметной области приложения (далее погружение в предметную область).
Предполагается, что всеми необходимыми знаниями в области информатики и математики деобфускатор владеет в совершенстве, но из-за особенностей реализации различных алгоритмов, имен переменных, некоторые виды обфус-кации могут потребовать абстрактных знаний в области теории алгоритмов и структур данных. Подобные методы увеличивают степень абстракции алгоритмов и структур данных (далее увеличение абстракций информатики).
В связи с ограничением на количество воспринимаемых операций деобфус-катором за раз, задачей обфускации является увеличение количества инструкций, анализируемых за один заход (далее увеличение количества инструкций). Деобфускатору потребуются дополнительные усилия на различие связей и разбиение исходного кода на логические единицы. Важно отметить, что увеличение связности данных является частным случаем увеличения количества воспринимаемых за раз инструкций.
Расширение области действия переменной с одной стороны вынуждает де-обфускатора увеличить количество анализируемых за раз инструкций. С другой стороны, эти инструкции могут быть проанализированы независимо друг от друга. На основе этого прецедента выделим свойство увеличения связности графа приложения (далее увеличение связности).
Важно также отметить, что любые переименования, в частности слияние и разделение пакетов, является одноразовой операцией, которая теряет свой смысл при повторном использовании.
Данные критерии позволят оценить вклад каждого из методов в обфус-кацию приложения в целом. Такой подход позволит защитить приложение от автоматической деобфускации и составить методику обфускации Java-приложения. В отличии от методов шифрования, методы обфускации развиваются вместе с развитием языка, на базе которого производится обфускация. Так, например, для языка программирования JavaScript не существует методов обфускации байт-кода, так как приложение передается в виде исходных кодов. В рамках данного исследования будут рассмотрены наиболее популярные методы обфускации, которые могут быть применены к языку программирования Java. Некоторые из рассмотренных методов могут быть применены и к другим языкам. Применимость к каждому отдельному языку должна рассматриваться в отдельности. При модификации байт-кода существуют особенности, накладывающие свои ограничения на применимость тех или иных методов обфускации. В частности, иногда связь классов друг с другом вынесена в специальный конфигурационный файл (прим. библиотека Spring). Изменение любых сигнатур должно сопровождаться специальным анализом сопутствующих ресурсных файлов и связанного нативного кода. Изменение логики приложения также сильно зависит от применяемых библиотек в связи с необходимостью гарантировать определенную очередность загрузки классов. Добавление связей с другими классами может привести к блокировке загрузчика классов. В связи с этим все последующие методы должны применяться с крайней осторожностью. Приложение должно успешно проходить все регрессионные тесты после обфускации. Из-за того, что обфускацию рекомендуется производить после тестирования приложения, для исключения некорректной реализации конкретных методов обфускации рекомендуется дополнительно запускать тесты после обфускации.
На листинге 3.1 представлена исходный код с использованием условного оператора. В данном случае переход осуществляется согласно логике приложения. Переход обусловлен значениями переменных, которые и должны повлиять на принятие решения о переходе. Данный код полностью отражает логику работы приложения. Такой исходный код может быть представлен в виде байт-кода Asmifier. Данный код представлен на листинге 3.2.
Листинг 3.2 представляет собой пример байт-кода с условным переходом. В данном байт-коде можно увидеть каждую переменную, которая загружается в стэк для дальнейших вычислений. В данном примере видно, как загружаются переменная args, выполняется получение количества элементов в данном массиве, и константа 3.3 для определения результата предиката перехода используется команда IF_ICMPLE, которая производит условный переход по операции « ». Данный условный переход является простейшим и его предикаты очевидны. Для обфускации данного кода может быть применено расширение условий для условных операций. В рамках такого преобразования можно использовать добавление конструкции «ИЛИ ЛОЖЬ». Для языка программирования Java данная конструкция будет выглядеть как « false». Поскольку компилятор Java уже научен выявлять подобные операции для оптимизации приложения, мы добавим данный предикат через функцию, возвращающую значение статической переменной.
Применение методики оценки эффективности ГОСТ
Изменение имени пакета - процедура аналогичная изменению имени класса. В отличии от класса, сигнатура пакета может присутствовать отдельно в приложениях. Так, например, библиотека Spring умеет самостоятельно сканировать классы, входящие в определенный пакет. В остальном, переименование метода производится аналогично изменению имени класса. Изменение имен пакетов производится аналогично изменению имени класса. В связи с этим и результат данного метода является увеличение количества абстракций информатики.
Добавление недостижимого кода является простейшей операцией, которая добавляет произвольный исходный код в те участки программы, которые никогда не могут быть выполнены. Эти преобразования позволяют увеличить количество связей между классами и методами, но легко устраняется при анализе исполнения программы. Также большинство компиляторов, оптимизирующих приложение самостоятельно удаляют некоторые конструкции, которые никогда не будут исполнены. Добавление недостижимого кода осуществляется вместе с изменением графа управления. А именно, на условные операции, позволяющие добавить ветвление, добавляются ветки программы, которые не могут быть выполнены, однако содержат дополнительные инструкции. Помимо ветвления кода методов или конструкторов, можно добавлять статические блоки инициализации классов, которые могут инициализировать какие-либо переменны в зависимости от глобальных переменных.
При добавлении дополнительных переменных при обфускации требуется увеличивать их связь с остальным исходным кодом. В частности, как здесь представлено, через системные переменные. В программный продукт могут примешиваться произвольные классы, сгенерированные на основе существующих исходных кодов. В общем случае добавление подобных классов позволяет достичь целей, аналогичных целям добавления недостижимого кода. Добавление недостижимого кода, является операцией, направленной на увеличение количества исходных кодов, анализируемых за один заход. Для отделения недостижимого кода требуется разобраться какие из инструкций не могут быть выполнены. В качестве недостижимого кода может использоваться произвольный код. В частности, увеличивающий количество связей графа приложения. Данный метод позволяет увеличить количество инструкций и увеличить связность.
Разделение и слияние пакетов производится переименованием сигнатуры пакета при объявлении класса. Это значит, что для того, чтобы переименовать пакет, требуется переименовать сигнатуру каждого класса, который содержится в пакете. Помимо сигнатуры, объявляемой в классе, пакеты отвечают за расположение класс-файлов внутри jar-файла. Переименование неизбежно влечет перемещение соответствующего файла в директорию с новым именем. Пакеты, в свою очередь отдельно могут задаваться в произвольном формате для различных библиотек. Такие названия тоже требуется изменять при переименовании пакета. Также требуется уделить отдельно внимание переименованию при использовании Reflection или доступу к ресурсам. Для слияния пакетов требуется убедиться в отсутствии конфликтов имен внутри этих пакетов. Такие конфликты на данном этапе могут быть одновременным переименованием классов. При отсутствии конфликтов, пакеты могут быть потенциально соединены в один. На листинге 27 можно ознакомиться с сигнатурой класса. В данном примере класс должен находиться в директории ru/ifmo/obfuscation/research. При перемещении класса, в пакет ru.ifmo.obfuscation.refactoring потребуется изменить сигнатуру класс-файла, а также переместить класс-файл в ru/ifmo/obfuscation/refactoring. Разделение пакетов является более сложной операцией, которая должна выполняться с большей осторожностью. При разделении пакетов, классы начинают находиться в различных пакетах. Ранее работавшие package-private связи могут перестать работать. Поэтому, при разнесении классов по различным пакетам требуется дополнительно анализировать видимость классов друг другу, а также их полей и методов, имеющих не публичный доступ. Для упрощения данной задачи все классы, поля и методы могут быть сделаны публичными. В таком случае, разделение пакетов будет происходить проще, но данный метод неприемлем, если об-фусцированным приложением является библиотека. Это связано с тем, что при обфускации библиотеки, ее интерфейс должен остаться неизменным даже после обфускации. Важно учитывать, что операции с пакетами могут влиять не только на видимость, доступность и конфликты классов, но и на работу библиотек, полагающих определенную иерархию пакетов и соответствующее расположение классов в ней (Например, SpringBoot). При использовании подобных средств требуется избегать данного метода обфускации или же накладывать специальные ограничения на метод обфускации и принципы переименования пакетов. Добавление неэффективных полей и методов При добавлении неэффективных полей и методов, в класс-файл внедряются дополнительные инструкции, содержащие записи о полях и методах, не участвующих в реальных вычислениях