Содержание к диссертации
Введение
Глава 1. Анализ существующих систем защиты ПО 9
1.1 Подходы к защите исполняемого кода 13
1.1.1 Системы противодействия процедурам дизассемблирования и дампирования 16
1.1.2 Системы затруднения отладки 23
1.1.3 Системы контроля целостности 27
1.2 Требования к современным программным защитам 29
1.2.1 Показатели применимости 29
1.2.2 Критерии оценки 32
1.3 Особенности ПО, распространяемого через Internet 34
Постановка задачи диссертационного исследования 37
Глава 2. Разработка конечно-автоматной модели защиты, систем маскировки и контроля целостности 39
2.1 Конечно-автоматная модель защиты 40
2.1.1 Модель функционирования 40
2.1.2 Двухуровневые и двухфазные модели 44
2.1.3 Особенности применения моделей 49
2.2 Маскировка фрагментов кода 51
2.2.1 Потоковые графы 52
2.2.2 Расширение операций над потоковыми графами 54
2.2.3 Типичные примеры 61
2.3 Контроль целостности кода 63
2.3.1 Хэш-функции 63
2.3.2 Модель контроля целостности кода 65
2.3.3 Примеры расширений моделей зашиты 69
Выводы 74
Глава 3. Алгоритмизация и реализация комплексной комбинированной системы защиты исполняемого кода 76
3.1 Реализация модели функционирования защиты 77
3.1.1 Особенности применения программных меток 77
3.1.2 Алгоритм построения защиты отдельных фрагментов кода 80
3.1.3 Реализация многофазных, многоуровневых и смешанных защит 85
3.2 Реализация алгоритмов маскировки 90
3.2.1 Подготовка блока кода к преобразованию алгоритмами маскировки .. 90
3.2.2 Алгоритм построения потокового графа 91
3.2.3 Реализация расширенных операций над потоковыми графами 97
3.3 Реализация алгоритмов контроля целостности 104
3.3.1 Представление расширения модели защиты 104
3.3.2 Особенности реализации функций контроля целостности 105
3.4 Оценка качества 106
Выводы 108
Глава 4. Построение комбинированных защит сложной структуры 109
4.1 Защиты сложной структуры 109
4.1.1 Архитектура защищаемой программы 109
4.1.2 Общие подходы к проектированию защит 111
4.2 Проблемы ограничения программной функциональности 116
4.3 Проектирование системы маскировки кода 119
Выводы 122
Заключение 124
Библиографический список 126
- Требования к современным программным защитам
- Расширение операций над потоковыми графами
- Подготовка блока кода к преобразованию алгоритмами маскировки
- Проблемы ограничения программной функциональности
Введение к работе
Актуальность темы. В настоящее время можно выделить три области применения защиты исполняемого кода. Первой следует считать защиту от копирования. К настоящему моменту разработано и успешно используется довольно большое количество систем защиты от копирования и практически все они взломаны. Анализ причин уязвимости показывает недостаточную защищённость программных блоков контроля легальности запускаемой копии, то есть соответствующие фрагменты исполняемого кода легко доступны для модификации.
Наряду с защитой от копирования, где блоки безопасности исполняемого кода входят в состав более сложной структуры, существует защита отдельных фрагментов программного кода от анализа. Подходы к решению здесь используются те же самые и отсюда те же проблемы.
И последнее, это защита программ, распространяемых по сети Internet, в которых существуют два пути возможной работы: бесплатная ограниченная версия и платная полнофункциональная. Существующие системы для контроля легальности пути исполнения кода, следует признать малоэффективными.
Использование существующих средств защиты исполняемого кода в большинстве случаев не гарантирует успешного противодействия угрозам. Это обусловлено либо сложностью их эксплуатации, либо внешним характером установки защитной системы, либо реализацией защиты по фрагментированному принципу. Анализ используемых сегодня защит показал, что наиболее перспективным направлением следует считать построение комбинированных защит, то есть тех, где элементы защиты встраиваются в программный код до компиляции (прекомпиляция) и уже после компиляции исполняемый код подвергается дополнительным преобразованиям (посткомпиляция).
Из сказанного следует, что разработка комплексной комбинированной защиты с предусмотренной системой маскировки и контроля целостности кода, а также с возможностью использования в задачах проверки легитимности за-
пуска программ, распространяемых по сети Internet, является актуальной научной задачей.
Диссертационная работа соответствует научному направлению ЛГТУ «Разработка теории проектирования информационных систем»
Цель и задачи исследования. Целью диссертационной работы является разработка математического и программного обеспечения для построения комбинированной защиты исполняемого кода на прекомпилируемом уровне с по-сткомпилируемой обработкой кода, с учетом систем ее маскировки и контроля целостности.
Исходя из данной цели, определены следующие основные задачи:
разработка модели функционирования комбинированной защиты, обладающей большим резервом для модификации и отличающейся жесткой привязкой к механизму исполнения программного кода;
разработка алгоритмов дополнительной маскировки для программных блоков защиты, ориентированных на прекомпилируе-мый характер установки и обладающих большей гибкостью настройки под конкретный программный код;
разработка алгоритма контроля целостности фрагментов кода в рамках комплексной системы защиты, с возможностью выбора любого программного фрагмента;
разработка программного обеспечения, реализующего установку защитного комплекса и его маскировку в массиве исполняемых кодов;
разработка модификации данной защиты для контроля легитимности программ, распространяемых по сети Internet.
Методы исследования. В работе использованы методы теории автоматов, теории графов, теории построения интерпретаторов и компиляторов, модульного и структурного программирования, а также вычислительные эксперименты.
Научная новизна. В диссертации получены следующие результаты, характеризующиеся научной новизной:
конечно-автоматная модель функционирования защиты исполняемого кода, отличающаяся возможностью работы с произвольными фрагментами программного кода и обеспечивающая представление защит сложных структур;
алгоритм маскировки фрагментов программного кода, отличающийся использованием расширения множества допустимых операций над потоковыми графами и обеспечивающий прекомпилируемый характер системы маскировки;
метод контроля целостности кода, отличающийся возможностью работы с произвольными фрагментами программного кода, жесткой привязкой к логике работы всей системы защиты и затрудняющий анализ исполняемого кода с использованием средств отладки;
метод защиты легитимного пути выполнения программы, позволяющий задавать в рамках одной программной системы несколько вариантов её исполнения, ставящий в зависимость надёжность защиты только от использованной системы шифрования.
Практическая ценность результатов диссертационной работы. Разработаны два программных комплекса, в которых реализованы предлагаемые методы и модели.
Первый комплекс «Система проектирования и построения прекомпили-руемых защит сложной структуры с посткомпилируемой обработкой исполняемого кода» реализует предложенную модель функционирования защиты и обеспечивает построение системы противодействия угрозам безопасности программного комплекса за счёт генерации блоков кода, встраиваемых в защищаемую программу, и последующего шифрования защищаемого фрагмента после её компиляции. Он основан на маркерной технологии и предусматривает возможность использования для построения системы ограничения функциональности программного обеспечения за счёт шифрования отдельных фрагментов и замены их на дублирующие.
Во втором программном комплексе «Система прекомпилируемой маскировки фрагментов исполняемого кода» реализованы предложенные принципы маскировки кода, основанные на расширенных операциях над потоковыми графами.
Реализация и внедрение результатов работы. «Система проектирования и построения прекомпилируемых защит сложной структуры с посткомпи-лируемой обработкой исполняемого кода» внедрена в отдел по борьбе с компьютерными преступлениями УВД Липецкой области и используется для защиты разрабатываемого ими программного обеспечения.
Программный комплекс «Система прекомпилируемой маскировки фрагментов исполняемого кода» и система ограничения функциональности программ внедрены в отделе компьютерного обеспечения МУЛ «Регистраци-онно-вычислительного центра г. Липецка», где используются при создании защиты разрабатываемой там программной автоматизированной системы, предполагающей применение как на самом предприятии, так и у сторонних заказчиков.
Результаты диссертационной работы используются в учебном процессе ЛГТУ при изучении студентами специальности 230401 «Прикладная математика» дисциплин «Безопасность компьютерных систем» и «Системное и прикладное программное обеспечение».
Апробация работы. Теоретические и практические результаты, полученные в процессе исследования, обсуждались на межвузовской научно-технической конференции «Новые технологии в научных исследованиях, проектировании, управлении, производстве» (Воронеж, 2001), на VII международной открытой научной конференции «Современные проблемы информатизации в технике и технологиях» (Воронеж, 2002), на IX международной открытой научной конференции «Современные проблемы информатизации в системах моделирования, программирования и телекоммуникациях» (Воронеж, 2004), на научных семинарах кафедры прикладной математики ЛГТУ.
Публикации. По теме диссертации опубликовано 6 научных работ. Структура и объем работы. Диссертация состоит из введения, четырёх глав и заключения, библиографического списка из 103 наименований. Основная часть работы изложена на 133 страницах машинописного текста, содержит 49 рисунков и 2 таблицы.
Требования к современным программным защитам
Условно говоря, процесс функционирования защищенного программного комплекса можно представить в виде замкнутой системы с четырьмя участниками и единой средой взаимодействия (рис. 1.8).
Под средой взаимодействия здесь понимается область необходимых контактов, обеспечивающих в рамках определённых правил функционирование двусторонних цепочек между разработчиками программ, программных защит, групп тестеров и пользователей (в число последних входит и некоторое количество злоумышленников, которые, являясь деструктивным и нежелательным элементом системы, тем не менее, неизменно присутствуют среди пользователей, и, важно отметить, что с точки зрения безопасности, каждого пользователя следует рассматривать как потенциального злоумышленника).
Среды взаимодействия можно разбить на четыре части по областям контроля типов взаимодействия, описываемые показателями применимости защиты.
Наиболее слабо контролируемой средой следует рассматривать законодательную. Ни один из описанных субъектов системы не в состоянии оказать весомое влияния на властные структуры, определяющие правила или законы её функционирования. Ярким примером следует считать катастрофическую ситуацию с правами на интеллектуальную собственность как в России, так и за рубежом. Несмотря на кажущуюся развитой законодательную систему Запада, она всё равно не в состоянии бороться с «пиратами», привнося в их жизнь лишь некоторые ограничения. Отсюда очевидно, что наиболее важными с точки зрения нашей системы, являются остальные три среды взаимодействия.
Рассмотрим основные показатели применимости этих типов взаимодействия (показатель применимости можно рассматривать как параметры, определяющие уровень или даже саму возможность взаимодействия между субъектами системы);
Экономические. Показатели этого типа фактически определяют решение разработчика программы защищать или нет его продукт. Здесь важными элементами является соотношение потерь от пиратства и общего объёма прибыли, потерь от пиратства и стоимости защиты и её внедрения, соотношение стоимости программы и защиты. Так, например, при условии, что защита одной копии программы гораздо дороже самой программы видится экономически не выгодной, что естественно ведёт к потере пользователя защиты.
Технические. Данная группа показателей обеспечивает техническую сторону вопроса взаимодействия, прежде всего, между производителем программы и создателем защиты, что в дальнейшем определяет комфортность работы с программой для конечного пользователя и направления деятельности тестовых групп. Соответствие системы защиты функциональным требованиям производителя программы и его требованиям по стойкости, системные требования программы и системные требования системы защиты, объём дискового пространства, занимаемого программой и защитой, функциональная направленность программы, наличие и тип защиты аналогичных продуктов конкурентов, - всё это оказывает влияние на окончательную форму реализации защищенного комплекса.
Организационные. Показатели этого типа очень часто отодвигаются разработчиками программ на второй план, что фактически сказывается на уровне защищённости. Каждый параметр определяет степень требуемой для программы защиты, проводя прямые зависимости между определёнными характеристиками защищаемой программы и пределом эффективной функциональности. Распространённость и популярность программы, условия её распространения и использования, уникальность и наличие угроз, вероятность превращения пользователя в злоумышленника, роль документации и поддержки при использовании программы - дают близкую к реальной картину уровня востребованности данного типа защиты.
Рассмотренные показатели применимости позволяют последовательно сформировать требования к защите конкретной программы, но решить проблему оценки и выбора необходимой системы из множества других они не могут. Помочь с решением этой задачи должны специально выделенные критерии.
Оказавшись перед проблемой выбора, предварительно необходимо произвести оценку всех возможных выбираемых объектов, для чего традиционно используется набор стандартных параметров. Оценка в пошаговом режиме каждого параметра или критерия, ведёт к построению довольно наглядной структуры, существенно облегчающей необходимый выбор, и позволяет на ранних этапах отсеивать откровенно неудачные или неподходящие варианты.
Для оценки систем защиты можно выделить следующие критерии:
Защита как таковая. Критерий определяет, собственно, предназначение защиты и качество её конкретной реализации (под качеством понимается, прежде всего, наличие логических ошибок или недоработок).
Стойкость к исследованию или взлому. Название данного критерия, возможно, несёт не совсем корректный характер. Каким-либо способом вряд ли можно точно оценить именно стойкость всей структуры защиты, потому мерой стойкости в данном конкретном случае служит соотношение применяемых стандартных и новых нестандартных механизмов, что, естественно, довольно условно. Всё же определить эффективность этих новых механизмов может только время и внимание злоумышленников.
Отказоустойчивость (надёжность). Критерий носит чисто эмпирический характер и получается на основе анализа некоего эксплуатационного периода. Очевидно, что каждый из перечисленных параметров, входящих в этот комбинированный критерий, даёт достаточно разностороннюю, хотя и косвенную оценку различных причини возникновения отказов (время наработки на отказ, вероятность отказа программы защиты, частота ложных срабатываний).
Расширение операций над потоковыми графами
Стандартный набор операций над графами совершенно не подходит в случае потоковых графов и, кроме того, не решает задачу существенного ус ложнения структуры исходной программы как прообраза графа. Для решения поставленной задачи расширим множество допустимых операций над потоко выми графами, исходя из логики функционирования программных систем. Специальные операции над потоковым графом включают в себя добавление узлов, разбиение цикла, добавление предикатных узлов, разбиение предикатных узлов, добавление дуг. Добавление узла к графу G = (V, R) заключается в добавлении либо одного узла v , не оказывающего влияния на внутреннюю логику потокового графа либо множества из п узлов V ={v },..., v №} при условии, что суммарное действие этих узлов не оказывает никакого влияния на внутреннюю логику графа G=(V, R) Как видно из рис. 2.12 самостоятельно данная операция не приносит серьёзного структурного усложнения кода, но чрезвычайно удобна для создания более разреженной структуры программного кода, что позволяет увеличить степень несвязности событий. Разбиение цикла в графе G = (V, R), есть последовательное добавление региона Rgv (G) ={V\R h где V = (v h v b..., v J,R4(v i, V2},{ V2, v 3},...,{ v n-i, vy,/v A v i}}, предикатным узлом v которого служит условие программного цикла 0«ВДУ ) = {{{У},{У ,УІ v/JWIv.M.t v }, , } },. / }}}) (2.4) где w = v „ в программном смысле, причём данное преобразование верно при условии корректного разбиения циклового предиката (см. рис. 2.13). Стоит отметить, что под корректностью разбиения циклового предиката (см. рис. 2.13) понимается такое разделение условий выполнения цикла, при котором не произойдёт изменения результатов работы программы.
Например, разбиение цикла формата Пока 1=1 до 7 Выполнять... можно считать корректным при условии, что получены два цикла Пока 1=1 до 3 Выполнять...и Пока 1=4 до 7 Выполнять... Разбиение, выводящее за пределы циклового отрезка (отрезка, на котором выполняется программный цикл), является ошибочным. Более сложные варианты циклов (циклы с пост- и предусловием) также могут подвергаться разбиению, но только с использованием комбинации из нескольких операций. Примером тому может служить цикл с предусловием Пока I 5 Выполнять.... Для корректной обработки данной ситуации требуется использовать операцию разбиения предикатного узла, либо операцию добавления узла. Очевидно, что самостоятельное добавление дуги приводит к созданию нового потокового графа, причём велика вероятность того, что соответствую щая этому графу программа стала неработоспособной или кардинально изме нила логику своей работы (фактически, добавление дуги эквивалентно добавлению безусловного перехода в программу). Для достижения наилучшего эффекта операция добавления дуг должна применяться одновременно с операциями добавления предикатных узлов и добавления узлов, и дуги должны соединять (а фактически - разбивать) пару регионов. Возможно расширение данной операции до добавления 3, 4 и т. д. дуг, при условии выполнения требова-ния к сохранности логики исходного алгоритма программы. Поэтому уместно говорить о добавлении дуг как о добавлении регионов Rgv (G) ={V ,R } и Rgv (G) ={V",R"} в граф G = (V, R) за счёт добавления пары дуг {v , w) и {v , w j, таким образом, чтобы они уравновешивали друг друга. Добавление предикатного узла v в потоковом графе G = (V, R) к узлу v" порождает граф
Подготовка блока кода к преобразованию алгоритмами маскировки
Очевидно, что описанная в предыдущей главе модель защиты в идеале должна быть реализована непосредственно на уровне разработки языка lipo id граммирования. Это привело бы к плотной увязке всей логики работы любой программы с защитой её кода. Кроме того, в случае инкапсуляции базовых эле ментов защиты, структурные компоненты которой описаны в предыдущей гла ве, логика работы модулей защиты была бы сокрыта от пользователя (програм миста), и процесс взлома программного обеспечения был бы эквивалентен дос кональному изучению и разбору функционирования компилятора. Также сле дует заметить, что подобный подход привёл бы к росту потенциала возможно стей сокрытия защищаемых фрагментов при решении злоумышленниками за дачи однозначного позиционирования этих фрагментов в общем массиве ис полняемого кода. К сожалению, на практике эту проблему пока решить невозможно по причинам колоссальных трудозатрат на разработку и отладку соответствующе го программного обеспечения, что под силу только крупным компаниям. Суще ствует менее трудоёмкий способ, а именно, реализация предлагаемой модели защиты в виде программной надстройки над компилятором языка программи рования. Реализованная на языке высокого уровня, надстройка служит проме жуточным звеном между исходным незащищённым кодом и процессом компи ляции, и между откомпилированным исполняемым кодом и защищенным и полняемым кодом. Фактически, речь идёт о разработке уже упоминавшейся в предыдущих главах прекомпилируемой системы с возможностью посткомпи-лируемой обработки кода. На основании всего вышесказанного было принято решение о разработ ке программного обеспечения, реализующего все структурные компоненты предлагаемого защитного комплекса. В данной главе описывается опробованная на практике реализация системы защиты, рассматривается оценка её качества. Учитывая прекомпилируемый характер разрабатываемой защиты с воз можностью посткомпилируемой обработки кода получаем довольно нетриви альную проблему выделения фрагментов кода.
С одной стороны требуется од нозначное выделение некоторого фрагмента для обработки прекомпилятором (на уровне исходного кода) плюс обязательно использование тех же самых ме ток для однозначного определения нуждающегося в обработке кода (на уровне исполняемого кода) сразу после компиляции. С другой стороны метки должны не нарушать общую функциональность защищаемой программы и не нести угрозу её безопасности. Угроза функциональности заключается в самой концепции исполняемо го кода, которая гласит, что всякий последовательный код в запускаемом файле несёт смысловую нагрузку. Отсюда необходимо так разместить метки, чтобы их присутствие находилось вне основного порядка следования машинных команд. С точки же зрения безопасности, каждая метка не должна как-то выде ляться из общего массива кодов, что потенциально грозит возможностью обна ружения защищенного фрагмента. Учитывая эти соображения, предлагается в качестве метки использовать n-байтное шестнадцатеричное число. Экспериментально было установлено, что достаточно 6-8 байтов для задания уникальной метки. Для решения проблемы нарушения функциональности предлагается каждую программную метку обходить с помощью безусловного перехода, получая фактически на выходе из компилятора некоторый блок кода, который не будет исполняться ни при каких условиях. С этой точки зрения возможны два состояния меток. В первом случае выделенные безусловными переходами метки играют роль операторных скобок9 защищаемого фрагмента исходного кода (рис. 3.1, А). Во втором же случае происходит замена двух коротких переходов на один длинный, что связано с приведением исходного кода к шифрованному виду.
В результате решается проблема исполнения зашифрованного блока кода, который создаётся на этапе посткомпилируемой обработки. Метки всё также служат операторными (или, что точнее, кодовыми скобками), а длинный безус ловный переход исключает данный блок из общей последовательности шагов выполнения исполняемого кода (рис. 3.1, В). Отсюда задача системы защиты состоит лишь в корректном управлении этими переходами. Предлагаемая модель защиты с учётом представленной технологии применения меток предполагает три типа схем размещения в программном коде, что делает возможным усложнение структуры защиты не только в результате использования предложенных двухуровневых и двухфазных моделей, но и в силу особенностей программной реализации (см. рис. 3.2).
Проблемы ограничения программной функциональности
Прежде чем переходить непосредственно к этапу проектирования защиты, рассмотрим ряд дополнений к имеющейся модели, которые могут повысить её эффективность. Как уже упоминалось в главе 1, наряду с разнообразными системами безопасности и контроля кода существуют методы, ориентированные не на защиту непосредственно кода, а на противодействие работе инструментария взломщика. Недостаточная эффективность данных методов не позволяет их считать полноценными самостоятельными защитными мерами, но в качестве вспомогательных они вполне применимы. Поэтому рассмотрим область (среду) функционирования программного комплекса. Программа ориентирована на исполнение в операционной системе Win dows 98, что говорит о мультизадачности и гарантированном выборе в качестве инструмента отладки продукта компании Compuware Corpoparation программы Softlce. Отсюда для противодействия системе отладки в качестве вспомогательного средства в код программы необходимо внести следующие операции: - учёт активных процессов системы; - анализ информации о загруженных модулях процесса; - расчёт размеров загруженных в процессы модулей. Указанные операции позволяют построить систему проверки системы на наличие в оперативной памяти управляющих блоков как программного отлад чика Softlce, так и аналогичных ему инструментов.
Если же посмотреть на про блему более широко, то в качестве вспомогательной (а возможно, что и основ ной) системы можно добавить API электронного ключа. Естественно, что это уже не будет мерой противодействия отладке, но зато будет повышать надёж ность аутентификации системы. Теперь следует рассмотреть проблему построения защиты с несколько иной стороны. Как уже неоднократно упоминалось в данной работе, многие ме тоды противодействия угрозам безопасности программного кода ориентирова ны в большей степени на борьбу непосредственно со злоумышленником человеком, а не с его инструментарием. Основной же упор делается на психо логические особенности и сложности восприятия человеком численных (би нарных) массивов данных, которыми собственно и представлен исполняемый файл. Предлагаемая в работе маскировка исполняемого кода на основе расширенных операций над потоковыми графами ориентирована так же и на эту кате- горию защитных мер. Но следует отметить, что повысить запутанность («нечитаемость») машинного кода возможно и не прибегая к дополнительным алгоритмам маскировки, используя лишь средства, предоставляемые непосредственно моделью защиты, и исходя из возможностей современных языков программирования
В данном случае речь идёт о формировании обманных фрагментов кода или фрагментов-обманок, под которыми понимаются блоки кода, имитирующие функционирование защиты (или потенциально уязвимого элемента программы), но без прямой необходимости в их использовании с точки зрения логики работы программного комплекса. Исходя из определения обманки, следует, что для повышения функциональной эффективности защиты необходимо размещать в коде дублирующие блоки критических фрагментов программы. И, кроме того, защищать с использованием предлагаемой модели на основе динамического шифрования, не нуждающиеся в защите блоки. Перечисленные меры заставят злоумышленника тратить время на анализ и попытки взлома не требующих его внимания фрагментов. Последняя рекомендация к проектированию и разработке программных защит, косвенно относится к системам отладки. Специфика устройства современных компиляторов с языков высокого уровня в машинные коды такова, что в результирующем коде сохраняются имена переменных, функций и процедур. Учитывая же сходство человеческого мышления, одним из этапов взлома программного кода состоит в поиске с помощью систем отладки имён, содержащих требуемые злоумышленнику слова. Например, используемое многими начинающими программистами слово Password для хранения паролей, было причиной серьёзной уязвимости в середине 90-х.
