Методы и средства обфускации программ

Российский государственный социальный университет Кафедра информационных технологий Факультет информационной безопасности Курсовой проект по дисциплине

«Программно-аппаратная защита информации»

на тему:

«Методы и средства обфускации программ»

Выполнил студент

5 курса, группы КЗИ В5

Коршиков Н. С.

Проверил:

преподаватель:

Хорев П. Б Москва

СОДЕРЖАНИЕ Содержание Введение Глава 1. Общие сведения, разновидности и методы обфускации

1.1 Методы запутывания программ

1.2 Преобразования форматирования

1.3 Применение запутывающих преобразований

1.4 Недостатки

1.5 Алгоритмы процесса обфускации

1.6 Процесс деобфускации

1.7 Оценка процесса обфускации

Глава 2. Обзор средств обфускации

2.1 Обзор средств обфускации

2.2 Сравнение средств обфускации Заключение Список литературы Приложение к курсовому проекту

1. Методы анализа программ

2. Анализ запутанных программ

ВВЕДЕНИЕ

На сегодняшний день, быстрое развитие мультимедиа и Интернет технологий вызывает потребность в защите такой интеллектуальной собственности, как программные продукты (ПП).

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

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

К настоящему времени разработано около двух десятков различных обфускаторов (в основном Java-программ), среди которых есть и коммерческие. Развитые обфускаторы программ на языке Java, а так же обфускаторы программ на других языках программирования выполняют преобразования графа потока управления программы и её структур данных. В работе приведена классификация таких методов обфускации.

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

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

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

Обфускация: основные понятия и цели Обфускация (от лат. obfuscare — затенять, затемнять; и англ. obfuscate — делать неочевидным, запутанным, сбивать с толку), или запутывание кода — приведение исходного текста или исполняемого кода программы к виду, сохраняющему ее функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции.

Запутанной (obfuscated) называется программа, которая на всех допустимых для исходной программы входных данных выдаёт тот же самый результат, что и оригинальная программа, но более трудна для анализа, понимания и модификации. Запутанная программа получается в результате применения к исходной незапутанной программе запутывающих преобразований (obfuscating transformations).

Цели обфускации.

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

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

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

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

Затруднение декомпиляции проприетарных программ с целью предотвращения обратной разработки или обхода DRM и систем проверки лицензий.

Нарушение авторских прав программистов и скрытие авторства.

При создании данного проекта ставлю перед собой цель, рассказать и раскрыть такое понятие как «Обфускация», пояснить принцип работы, привести примеры работы различных программ организующих обфускацию данных. Так же отдельным разделом расскажу о средствах обфускации, приведу примеры конкретных программ на основе работ программиста из Санкт-Питербурка с интернет именем Antelle (желает сохранить конфиденциальность своих персональных данных), обзор средств обфускации взят из его работы, выложенной в открытый источник под название Хабрахабр (в списке литературы привожу полную ссылку на обзор Antelle). Так же в работе расскажу о различных методах обфускации программ.

Глава 1. Общие сведения, разновидности и методы обфускации

1.1 Методы запутывания программ Задачи запутывания и анализа запутанных программ имеют как минимум два аспекта:

— теоретический;

— прикладной.

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

Прикладной — разработку конкретных методов запутывания (распутывания), то есть наилучших комбинаций алгоритмов, эмпирический сравнительный анализ различных методов, эмпирический анализ устойчивости методов, и т. д.

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

Уже разработано около двух десятков различных запутывателей Java-программ, среди которых есть и коммерческие. Простые обфускаторы удаляют таблицы символов и отладочную информацию из скомпилированных классов и заменяют исходные имена методов бессмысленными короткими именами. В результате размер файлов уменьшается (до 50%), а скорость выполнения программы значительно возрастает, поэтому такое запутывание может рассматриваться и как один из способов оптимизации программ. Более развитые обфускаторы программ на языке Java, а также запутыватели программ на других языках программирования выполняют преобразования графа потока управления программы и её структур данных. Методы, используемые в них, как правило, подобраны эмпирически и слабо обоснованы теоретически.

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

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

Универсальный запутыватель — это программа, которая для любого класса программ и любого свойства этих программ является — запутывателем.

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

Преобразования на уровне исходного текста;

Преобразования форматирования, которые изменяют только внешний вид программы.

Преобразования структур данных, изменяющие структуры данных, с которыми работает программа.

Преобразования потока управления программы, которые изменяют структуру её графа потока управления.

Обфускация на уровне Исходного текста:

Код до обфускации:

int COUNT = 100;

float TAX_RATE = 0.2;

for (int i=0; i

{

tax[i] = orig_price[i] * TAX_RATE;

price[i] = orig_price[i] + tax[i];

}

Код после обфускации:

for (int a=0;a<100;a++){b[a]=c[a]*0.2;d[a]=c[a]+b[a]; }

Обфускация на уровне машинного кода Как правило, обфускация на уровне машинного кода уменьшает (а не увеличивает) скорость выполнения программы. Поэтому она применяется в критичных к безопасности, но не критичных к скорости местах программы, таких как проверка регистрационного кода.

Простейший способ обфускации машинного кода — вставка в него недействующих конструкций (таких как or ax, ax)

Обфускация на уровне промежуточного кода В отличие от обычных языков, таких как C++ и Паскаль, компилирующих в машинный код, язык Java, NetP и языки платформы .NET компилируют исходный код в промежуточный код (байт-код), который содержит достаточно информации для адекватного восстановления исходного кода. По этой причине, для этих языков применяется обфускация промежуточного кода.

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

Простейший пример обфусцированного HTML:

Виагра

При просмотре пользователь увидит слово «Виагра», в то время как в исходном коде его нет.

Преобразования потока управления.

Преобразования потока управления изменяют граф потока управления одной функции. Они могут приводить к созданию в программе новых функций. Краткая характеристика методов приведена ниже.

Открытая вставка функций (function inlining) заключается в том, что тело функции подставляется в точку вызова функции. Данное преобразование является стандартным для оптимизирующих компиляторов. Это преобразование одностороннее, то есть по преобразованной программе автоматически восстановить вставленные функции невозможно.

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

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

Непрозрачные предикаты (opaque predicates) Основной проблемой при проектировании запутывающих преобразований графа потока управления является то, как сделать их не только дешёвыми, но и устойчивыми. Для обеспечения устойчивости многие преобразования основываются на введении непрозрачных переменных и предикатов. Сила таких преобразований зависит от сложности анализа непрозрачных предикатов и переменных.

Переменная v является непрозрачной, если существует свойство

относительно этой переменной, которое априори известно в момент запутывания программы, но трудноустанавливаемо после того, как запутывание завершено. Аналогично, предикат P называется непрозрачным, если его значение известно в момент запутывания программы, но трудноустанавливаемо после того, как запутывание завершено.

Непрозрачные предикаты могут быть трёх видов:

PF — предикат, который всегда имеет значение «ложь» ;

PT — предикат, который всегда имеет значение «истина» ;

P? — предикат, который может принимать оба значения, и в момент запутывания текущее значение предиката известно.

Использование указателей на специально создаваемые динамические структуры. В этом подходе в программу добавляются операции по созданию ссылочных структур данных (списков, деревьев), и добавляются операции над указателями на эти структуры, подобранные таким образом, чтобы сохранялись некоторые инварианты, которые и используются как непрозрачные предикаты.

Конструирование булевских выражений специального вида.

Построение сложных булевских выражений с помощью эквивалентных преобразований из формулы true. В простейшем случае мы можем взять k произвольных булевских переменных x1… xk и построить из них тождество

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

Внесение недостижимого кода (adding unreachable code). Если в программу внесены непрозрачные предикаты видов PF или PT, ветки условия, соответствующие условию «истина» в первом случае и условию «ложь» во втором случае, никогда не будут выполняться. Фрагмент программы, который никогда не выполняется, называется недостижимым кодом. Эти ветки могут быть заполнены произвольными вычислениями, которые могут быть похожи на действительно выполняемый код, например, собраны из фрагментов той же самой функции.

Внесение мёртвого кода (adding dead code). В отличие от недостижимого кода, мёртвый код в программе выполняется, но его выполнение никак не влияет на результат работы программы.

Внесение избыточного кода (adding redundant code). Избыточный код, в отличие от мёртвого кода выполняется, и результат его выполнения используется в дальнейшем в программе, но такой код можно упростить или совсем удалить, так как вычисляется либо константное значение, либо значение, уже вычисленное ранее.

Подобные алгебраические преобразования ограничены целыми значениями, так как при выполнении операций с плавающей точкой возникает проблема накопления ошибки вычислений. Например, выражение sin2x+cos2x при вычислении на машине практически никогда не даст в результате значение 1.

Преобразование сводимого графа потока управления к несводимому (transforming reducible to non-reducible flow graph). Когда целевой язык (байт-код или машинный язык) более выразителен, чем исходный, можно использовать преобразования, «противоречащие» структуре исходного языка. В результате таких преобразований получаются последовательности инструкций целевого языка, не соответствующие ни одной из конструкций исходного языка.

Например, байт-код виртуальной машины Java содержит инструкцию go to, в то время как в языке Java оператор go to отсутствует. Графы потока управления программ на языке Java оказываются всегда сводимыми, в то время как в байт-коде могут быть представлены и несводимые графы.

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

Устранение библиотечных вызовов (eliminating library calls). Большинство программ на языке Java существенно используют стандартные библиотеки. Поскольку семантика библиотечных функций хорошо известна, такие вызовы могут дать полезную информацию при обратной инженерии программ. Проблема усугубляется ещё и тем, что ссылки на классы библиотеки Java всегда являются именами, и эти имена не могут быть искажены.

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

Переплетение функции (function interleaving). Идея этого запутывающего преобразования в том, что две или более функций объединяются в одну функцию. Списки параметров исходных функций объединяются, и к ним добавляется ещё один параметр, который позволяет определить, какая функция в действительности выполняется.

Клонирование функций (function cloning). При обратной инженерии функций в первую очередь изучается сигнатура функции, а также то, как эта функция используется, в каких местах программы, с какими параметрами и в каком окружении вызывается. Анализ контекста использования функции можно затруднить, если каждый вызов некоторой функции будет выглядеть как вызов какой-то другой, каждый раз новой функции.

Развёртка циклов (loop unrolling). Развёртка циклов применяется в оптимизирующих компиляторах для ускорения работы циклов или их распараллеливания. Развёртка циклов заключается в том, что тело цикла размножается два или более раз. Если количество повторений цикла известно в момент компиляции, цикл может быть развёрнут полностью. Разложение циклов (loop fission). Разложение циклов состоит в том, что цикл со сложным телом разбивается на несколько отдельных циклов с простыми телами и с тем же пространством итерирования.

Реструктуризация графа потока управления. Структура графа потока управления, наличие в графе потока управления характерных шаблонов для циклов, условных операторов и т. д. даёт ценную информацию при анализе программы. Например, по повторяющимся конструкциям графа потока управления можно легко установить, что над функцией было выполнено преобразование развёртки циклов, а далее можно запустить специальные инструменты, которые проанализируют развёрнутые итерации цикла для выделения индуктивных переменных и свёртки цикла. В качестве меры противодействия может быть применено такое преобразование графа потока управления, которое приводит граф к однородному («плоскому») виду. Операторы передачи управления на следующие за ними базовые блоки, расположенные на концах базовых блоков, заменяются на операторы передачи управления на специально созданный базовый блок диспетчера, который по предыдущему базовому блоку и управляющим переменным вычисляет следующий блок и передаёт на него управление. Технически это может быть сделано перенумерованием всех базовых блоков и введением новой переменной, например state, которая содержит номер текущего исполняемого базового блока. Запутанная функция вместо операторов if, for и т. д. будет содержать оператор switch, расположенный внутри бесконечного цикла.

Локализация переменных в базовом блоке. Это преобразование локализует использование переменных одним базовым блоком. Для каждого запутываемого базового блока функции создаётся свой набор переменных. Все использования локальных и глобальных переменных в исходном базовом блоке заменяются на использование соответствующих новых переменных. Чтобы обеспечить правильную работу программы между базовыми блоками вставляются так называемые связующие (connective) базовые блоки, задача которых скопировать выходные переменные предыдущего базового блока в входные переменные следующего базового блока.

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

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

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

1.2 Преобразования форматирования

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

Удаление комментариев и переформатирование программы применимы, когда запутывание выполняется на уровне исходного кода программы. Эти преобразования не требуют только лексического анализа программы. При переформатировании программы исходное форматирование теряется безвозвратно, но программа всегда может быть переформатирована с использованием какого-либо инструмента для автоматического форматирования программ (например, indent для программ на Си).

Удаление отладочной информации приводит к тому, что имена локальных переменных становятся невосстановимы.

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

1.3 Применение запутывающих преобразований

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

В работах Ч. Ванг[22],[23] предлагается метод запутывания, и описывается его реализация в инструменте для запутывания программ на языке Си. Предложенный метод запутывания использует преобразование введения «диспетчера» в запутываемую функцию. В другой работе предлагается метод запутывания, основанный на следующих запутывающих преобразованиях: каждый базовый блок запутываемой функции разбивается на более мелкие части (т. н. piece) и клонируется один или несколько раз. В каждом фрагменте базового блока переменные локализуются, и для связывания базовых блоков создаются специальные связующие базовые блоки. Далее в каждый фрагмент вводится мёртвый код. Источником мёртвого кода может быть, например, фрагмент другого базового блока той же самой функции или фрагмент базового блока другой функции. Поскольку каждый фрагмент использует свой набор переменных, объединяться они могут безболезненно (при условии отсутствия в программе указателей и вызовов функций с побочным эффектом). Далее из таких комбинированных фрагментов собирается новая функция, в которой для переключения между базовыми блоками используется диспетчер. Диспетчер принимает в качестве параметров номер предыдущего базового блока и набор булевских переменных, которые используются в базовых блоках для вычисления условий перехода, и вычисляет номер следующего блока. При этом следующий блок может выбираться из нескольких эквивалентных блоков, полученных в результате клонирования. Выражая функцию перехода в виде булевской формулы, можно добиться того, что задача статического анализа диспетчера будет PSPACE-полна. В работе описывается алгоритм запутывания, но не указывается, реализован ли этот алгоритм в какой-либо системе.

Запутыватели для языка Java, например Zelix KlassMaster, как правило, используют следующее сочетание преобразований: из. class-файлов удаляется вся отладочная информация, включая имена локальных переменных; классы и методы переименовываются в короткие и семантически неосмысленные имена; граф потока управления запутываемой функции преобразовывается к несводимому графу, чтобы затруднить декомпиляцию обратно в язык Java.

1.4 Недостатки К минусам обфускации можно отнести такие недостатки как:

— Потеря гибкости кода. Код после обфускации может стать более зависимым от платформы или компилятора.

— Трудности отладки. Обфускатор не даёт постороннему выяснить, что делает код, но и не даёт разработчику отлаживать его. При отладке приходится отключать обфускатор.

— Недостаточная безопасность. Это направление является наиболее приоритетным в совершенствовании и требующим внедрения новых разработок.

1.5 Алгоритмы процесса обфускации

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

Алгоритм Колберга («Collberg`s algorithm»). [6],[7],[8],[9],[10]

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

программа «А» состоящая из исходных или объектных (двоичных) файлов «{С1,С2}» .

стандартные библиотеки, используемые программой «{L1,L2}» .

набор трансформирующих процессов «Т{Т1,Т2}» .

определенный фрагмент кода «S», который извлекается из программы «А», и который непосредственно будет подвержен трансформации.

набор функций «Е{Е1,Е2}» которые будут определять эффективность применения определенных трансформирующих процессов «{Т1,Т2}» к фрагменту кода «S» .

набор функций «I{I1,I2}» которые будут определять важность фрагмента кода «S», и в зависимости от этого будут задавать определенное значение переменной «RequireObfuscation» (чем «S» важнее тем эта переменная будет хранить большее значение).

две числовые переменные «AcceptCost» > 0, «RequireObfuscation» > 0, где первое хранит информацию о доступном максимальном увеличении системных ресурсов по требующихся программе «А» после того как она подвергнется обфускации, а вторая переменная будет хранить значение требуемого уровня осуществления обфускации (чем важнее фрагмент кода «S», тем это значение должно быть больше).

Алгоритм Колберга имеет такую последовательность операций:

Загрузка элементов «{С1,С2}» программы «А» .

Загрузка библиотек «{L1,L2}» .

Осуществление обфускации над программой «А», путем выделения фрагмента кода «S» и определения наиболее эффективного процесса трансформации для него. Этот этап повторяется до тех пор, пока не будет, достигнут требуемый уровень обфускации «RequireObfuscation» или допустимое увеличение ресурсов «AcceptCost» .

Генерация трансформируемой программы «А`» .

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

Chenxi Wang`s алгоритм.

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

создание графа потока управления этой процедуры (граф задаётся множеством блоков и множеством связей соединяющих их), после чего граф разбивается, путем замены циклических конструкций в нем на конструкции типа «if (условие) goto» .

нумерация всех блоков в графе, и добавление в код процедуры переменной (например «swVar») хранящей номер следующего выполняемого блока приведение графа к однородному («плоскому»)

Выше описанный вариант алгоритма обфускации («Chenxi Wang`s algorithm») является не сильно устойчивым, так как определить следующий выполняемый блок, нетрудно (он в нашем случае будет храниться в переменной «swVar»). Поэтому для повышения его устойчивости вводят массив (например «@gg»), содержащий помимо номеров блоков, не нужную информацию, в результате запись «$swVar = S6», можно заменить на нечто подобное «$swVar = $gg[$gg[1] + $gg[3]]» .

1.6 Процесс деобфускации

Процессу деобфускации предшествует процесс превентивной (prevent) обфускации.

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

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

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

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

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

— нахождение и оценка непрозрачных конструкций (предикатов), статический анализ, которых очень сложен;

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

— выделение в программе фрагментов кода, которые никоим образом не связанны с основными задачами, которые должна выполнять программа, то есть обнаружение ненужных (лишних) участков кода;

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

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

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

1.7 Оценка процесса обфускации

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

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

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

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

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

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

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

Глава 2. Обзор средств обфускации

2.1 Обзор средств обфускации В обзоре приведу описание нескольких сильных обфускаторов.

VMWare ThinApp [25]

Обфускатор, умеет исполнять код, внедряя в приложение предкомпилированные сборки .NET, что исключает вероятность перехвата вызовов JIT-компиляции.

Полученные приложения могут запускаться даже без установленного .NET на машине. Размер получившегося приложения — 10.50 МБ, в зависимости от того, какие библиотеки будете использовать.

Стоят эти решения очень дорого. Но, к сожалению, на PostBuild ходят кряки (даже на последний). Вероятно, в известных кругах есть и готовые распаковщики.

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

Salamander .NET [27]

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

Оригинал описания:

Salamander .NET Linker and mini-deployment tool allows you to link .NET assemblies together into a single file, and to deploy your application without installation of the whole Microsoft .NET Framework. The linker selectively links MSIL code putting together only the required classes and methods, and it is capable of linking into the Microsoft .NET framework class libraries. The mini-deployment tool then builds a minimum set of the Microsoft .NET runtime to ship with your application. This usually results in installation size of a few mega bytes, rather than tens of mega bytes, and the installation takes much less time without rebooting machines. The mini-deployed application can be launched directly from a CD, absolutely without copying files or adding registry entries. Starting from .NET 2.0, a native compilation feature will be introduced to compile all managed assemblies into x86 machine code, and thus improves performance and stops disassembling and decompilation. Not even a single MSIL instruction will be ever delivered to your customers.

There is one problem none of the current obfuscators address, that is, no matter how good the obfuscation is, there are system library calls and other external references scattered over in your code (see red in below). Since these calls are external references, obfuscators will have to leave them unchanged. However, these references help a lot to understand the decompiled code, because they are well documented and public APIs. The linker removes or reduces such public APIs by linking the framework APIs into your own code, and thus makes your code much more difficult to decompile after obfuscation. Below shows sample MSIL code before and after the linker is used.

before: (no obfuscators are able to rename the following code in red, since they are external public

APIs)

IL_0000: ldarg.0

IL_0001: call instance void [System.Windows.Forms]System.Windows.Forms.Form:.ctor ()

IL_0006: ldarg.0

IL_0007: newobj instance void [System.Windows.Forms]System.Windows.Forms.TextBox:.ctor ()

IL_000c: stfld class [System.Windows.Forms]System.Windows.Forms.TextBox A. A:A

IL_0011: ldarg.0

IL_0012: ldfld class [System.Windows.Forms]System.Windows.Forms.TextBox A. A:A

IL_0017: call valuetype [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color:get_Cyan ()

IL_001c: callvirt instance void [System.Windows.Forms]System.Windows.Forms.TextBoxBase:set_BackColor (valuetype [System.Drawing]System.Drawing.Color)

IL_0021: ldarg.0

after: (absolutely no clue Windows. Forms APIs are used, a high obstacle for a hacker to understand this

junk)

IL_0000: ldarg.0

IL_0001: call instance void a. A:.ctor ()

IL_0006: ldarg.0

IL_0007: newobj instance void D. c:.ctor ()

IL_000c: stfld class D. c A.A:A

IL_0011: ldarg.0

IL_0012: ldfld class f.aA.A:A

IL_0017: call valuetype a. B ()

IL_001c: callvirt instance void D. c (valuetype g. e)

IL_0021: ldarg.0

DotFuscator [26]

DotFuscator — этот продукт широко известен разработчикам .Net, так как он входит в стандартный пакет Visual Studio .Net 2003.

Данный обфускатор является одним из немногих, позволяющих обфусцировать поток управления. Однако бедный интерфейс и, порой, не понятные настройки делают его сложным для работы. Одним из его плюсов является интеграция с Visual Studio .Net.

2.2 Сравнение средств обфускации Бесплатные обфускаторы весьма слабые и пригодны только для простого переименования. О control flow знают из них лишь немногие;

Существуют весьма неплохие решения (control flow, MSIL encryption) стоимостью до $ 500;

Серьезные решения стоят около $ 5000, но к сожалению, для многих из них есть распаковщики. Некоторые из них взломаны.

Взломали обфускатор — значит поняли его систему защиты. На помойку такой обфускатор.

Есть решения для неопытных взломщиков — сборка шифруется полностью и расшифровывается на лету. Взломать символьным отладчиком такую сборку просто. Записи в табличке 2.1. идут по алфавиту.

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

Flow Control (Управление потоком передачи данных) — в компьютерных сетях, механизм, который компенсирует различия в скорости передатчика и приёмника.

Различают два способа: аппаратный (CTS/RTS) или программный (XOn/XOff).

Предпочтительно использовать аппаратное управление потоком. Для этого нужно выбрать соответствующий пункт в меню терминальной программы и проинициализировать модем для работы с Hardware Flow Control.

NET Framework — программная платформа, выпущенная компанией Microsoft в 2002 году. Основой платформы является исполняющая среда Common Language Runtime (CLR), способная выполнять как обычные программы, так и серверные веб-приложения. .NET Framework поддерживает создание программ, написанных на разных языках программирования.

Считается, что платформа .NET Framework явилась ответом компании Microsoft на набравшую к тому времени большую популярность платформу Java компании Sun Microsystems (ныне принадлежит Oracle).

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

Рисунок. 1.3. Диаграмма программных средств обфускации.

Вывод:

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

Поддерживалась производителем;

Не была раскрыта или взломана ранее;

Обфусцировала данные не простым переименованием или добавлением простых символов, которые легко отличимы;

Поддерживала современные стандарты .NET;

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

Заключение

Сегодня, есть много различных мнений нужна ли вообще и можно ли с выгодой использовать обфускацию как средство защиты от несанкционированного хищения или вскрытия того или инного продукта. Где? и Когда? применять обфускацию. На мой взгляд эти споры рискуют стать бесконечными, потому как сколько людей, столько и мнений. Я считают что обфускация может занять свою нишу в процессе защиты информации от хищения и несанкционированнго доступа к данным какого либо продукта или программы. На мой взгляд методы обфускации можно с легкостью и достаточной практичностью применять в мобильных технологиях, а так же в сфере где по открытым каналам связи передаются документы исходный текст которых необходимо надежно защитить от кражи или не законного копирования. Как развитие обфускации вижу создание программных средств работающих и создающих документы которые проходят определенный процесс обфускации, затем защищают исходный код созданного файла и сам файл какими то известными криптографическими методами защиты и в таком виде передают его открытым каналам связи. Получатель же сможет открыть этот файл, только применив сходное, специальное программное средство. В случае если злоумышленник перехватит такой файл он не сможет прочитать его содержимое не сломав две защиты.

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

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

Запутывание не должно быть регулярным. Регулярная структура запутанной программы или её фрагмента позволяет человеку отделить запутанные части и даже идентифицировать алгоритм запутывания.

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

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

Другим направлением является разработка методов запутывания и методов анализа запутанных программ на уровне языка ассемблера (машинного кода). Хотя методы запутывания низкого уровня могут оказаться непереносимыми на другие архитектуры, в низкоуровневом запутывании скрыт большой потенциал.

В заключение к всему вышесказанному, подвожу черту. Цели которые были поставлены и соответственно описаны во «Введении» перед началом создания курсового проекта достигнуты. А имено:

курсовой проект подробно рассказывает о понятие «Обфускация»;

на примере показывает и определяет принципы работы программ Обфускации;

освещает методы работы алгоритмов «Обфускации».

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

1. А. В. Чернов. Интегрированная среда для исследования «обфускации» программ. Доклад на конференции, посвящённой 90-летию со дня рождения А. А. Ляпунова. Россия, Новосибирск, 8−11 октября 2001 года. http://www.ict.nsc.ru/ws/Lyap2001/2350/ ;

2. «Анализ запутывающих преобразований программ», автор Чернов А. В.

3. B. Barak, O. Goldreich, R. Impagliazzo, S. Rudich, A. Sahai, S. Vadhan, K. Yang. On the (Im)possibility of Obfuscating Programs. LNCS, 2001, 2139, pp. 1−18.

4. S. Chow, Y. Gu, H. Johnson, V. Zakharov. An approach to the obfuscation of control-flow of sequential computer programs. LNCS, 2001, 2200, pp. 144−155.

5. C. Cifuentes, K. J. Gough. Decompilation of Binary Programs. Technical report FIT-TR-1994;03. Queensland University of Technology, 1994. http://www.fit.qut.edu.au/TR/techreports/FIT-TR-94−03.ps

6. C. Collberg, C. Thomborson, D. Low. A Taxonomy of Obfuscating Transformations. Department of Computer Science, The University of Auckland, 1997. http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborsonLow97a

7. C. Collberg, C. Thomborson, D. Low. Breaking Abstractions and Unstructuring Data Structures. In IEEE International Conference on Computer Languages, ICCL'98, Chicago, IL, May 1998.

8. C. Collberg, C. Thomborson, D. Low. Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs. In Principles of Programming Languages 1998, POPL'98, San Diego, CA, January 1998.

9. C. Collberg, C. Thomborson. On the Limits of Software Watermarking. Technical Report #164. Department of Computer Science, The University of Auckland, 1998. http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborson98e

10. C. Collberg, C. Thomborson. Watermarking, Tamper-Proofing, and Obfuscation — Tools for Software Protection. Technical Report 2000;03. Department of Computer Science, University of Arizona, 2000. http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborson2000a

11. G. Hachez, C. Vasserot. State of the Art in Software Protection. Project FILIGRANE (Flexible IPR for Software Agent Reliance) deliverable/V2. http://www.dice.ucl.ac.be/crypto/filigrane/External/d21.pdf

12. M. Hind, A. Pioli. Which pointer analysis should I use? In ACM SIGSOFT International Symposium on Software Testing and Analysis, pp. 113−123, August 2000. The International Obfuscated C Code Contest. http://www.ioccc.org

13. M. Jalali, G. Hachez, C. Vasserot. FILIGRANE (Flexible IPR for Software Agent Reliance). A security framework for trading of mobile code in Internet. In Autonomous Agent 2000 Workshop: Agents in Industry, 2000.

14. H. Lai. A comparative survey of Java obfuscators available on the Internet. http://www.cs.auckland.ac.nz/~cthombor/Students/hlai

15. D. Low. Java Control Flow Obfuscation. MSc Thesis. University of Auckland, 1998. http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/thesis.ps

16. J. MacDonald. On Program Security and Obfuscation. 1998. http://www.xcf.berkeley.edu/~jmacd/cs261.pdf

17. M. Mambo, T. Murayama, E. Okamoto. A Tentative Approach to Constructing Tamper-Resistant Software. In ACM New Security Paradigms Workshop, Langdale, Cumbria UK, 1998.

18. A. von Mayrhauser, A. M. Vans. Program Understanding: Models and Experiments. In M. Yovits, M. Zelkowitz (eds.), Advances in Computers, Vol. 40, 1995. San Diego: Academic Press, pp. 1−38.

19. S. Muchnick. Advanced Compiler Design and Implementation. Morgan Kaufmann Publishers, 1997. SourceAgain Java decompiler. http://www.ahpah.com

20. F. Tip. A survey of program slicing techniques. Journal of Programming Languages, 3(3): 121−189, September 1995.

21. E. Walle. Methodology and Applications of Program Code Obfuscation. Faculty of Computer and Electrical Engineering, University of Waterloo, 2001. http://walle.dyndns.org/morass/misc/wtr3b.doc

22. C. Wang. A Security Architecture for Survivability Mechanisms. PhD Thesis. Department of Computer Science, University of Virginia, 2000. http://www.cs.virginia.edu/~survive/pub/wangthesis.pdf

23. C. Wang, J. Davidson, J. Hill, J. Knight. Protection of Software-based Survivability Mechanisms. Department of Computer Science, University of Virginia, 2001. http://www.cs.virginia.edu/~jck/publications/dsn_distribute.pdf

24. Zelix KlassMaster Java Code Obfuscator and Obfuscation. http://www.zelix.com

Сведения из Интернета.

25. http://habrahabr.ru/post/97 062/

26. http://www.gotdotnet.ru/blogs/sieben/6488/

27. http://www.remotesoft.com/linker/

Приложение к курсовому проекту

1. Методы анализа программ

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

Методы анализа программ могут быть разделены на 4 группы:

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

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

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

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

Краткая характеристика важнейших для нас методов анализа программ приведена ниже.

Статический анализ алиасов (alias analysis) необходим в языках, в которых несколько имён могут быть использованы для доступа к одной и той же области памяти. Например, некоторый элемент массива a может быть адресован в программе как a[0] (каноническое имя элемента массива), как a[j] или вообще как b[-4]. В результате анализа алиасов каждому оператору, выполняющему косвенную запись в память или косвенное чтение из памяти, ставится в соответствие множество имён переменных, которые могут затрагиваться данной операцией.

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