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

Рассмотрим процесс защиты и профилирования тестового приложения, созданного в Visual Studio 2010 по шаблону MFC Application.

001 Методы выбора функций для защиты

В мастере лицензирования предусмотрены различные методы выбора защищаемых функций (т. е. тех функций, с которыми будет работать RIP CODE):


1. Не защищать функции
При выборе этой опции происходит отключение технологии RIP CODE. Соответственно, этот вариант следует выбирать лишь тогда, когда RIP CODE вызывает проблемы с работой защищенного приложения.
2. Автоматически
Данный вариант предлагается по умолчанию. В этом случае RIP CODE будет выбирать функции для защиты случайным образом, но в целях оптимизации производительности исключит все функции с циклами и рекурсиями.
Этот вариант рекомендуется использовать в случаях, когда защищенное приложение не вызывает проблем с производительностью.
Процент функций, защищенных технологией RIP CODE, зависит от положения ползунка Уровень защиты, и показывается во всплывающей подсказке. На Пользовательском уровне защиты процент можно регулировать вручную.
3. Вручную
Можно выбрать функции для защиты вручную. Это рекомендуется делать, если защищенное приложение демонстрирует невысокую производительность (по сравнению с исходной), и разработчик хорошо знаком с внутренней структурой приложения, а значит, сможет указать автозащите, какие функции лучше не защищать.

ВАЖНО!
При повторной компиляции приложения, и, соответственно, перегенерации MAP-файла, существующий файл описания защиты кода становится недействительным, и необходимо повторное проведение статического анализа и повторный выбор функций!
Если же процесс статического анализа проводится впервые (или защищаемый файл изменился), то необходимо выбрать пункт Запустить процесс статического анализа, предварительно убедившись, что в одной папке с защищаемым файлом находится соответствующий ему MAP-файл:

Когда профилирование запускается из среды мастера лицензирования, то изменение параметров в данном диалоговом окне будет недоступно. В случае, если мастер лицензирования не используется, то здесь необходимо указать непосредственно профилируемое приложение.
Аналогично, если профайлер запускается из мастера, то имя файла описания изменить нельзя – оно жестко привязано к проекту лицензии. В случае использования профайлера отдельно, здесь указывается имя выходного файла с настройками для опции RIP CODE.

Примечание
При помощи RIP CODE виртуализируется не тело функции целиком, а только определенные наборы инструкций. Каждый такой набор называется базовым блоком. В защищаемой функции может быть от одного базового блока до нескольких тысяч, в зависимости от ее размера. Если базовых блоков в функции не найдено, защите она не подлежит.

По нажатию на ОК происходит переход в основное окно работы профайлера, методика работы с которым описана далее:


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

Затем можно указать параметры командной строки, с которыми вызывается приложение, и задать файл для сохранения результатов работы профайлера:

По нажатию на кнопку Готово начнется статический анализ приложения (как ив варианте Вручную), и будет предложен первоначальный набор функций для защиты:

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

002 Методика работы с Native-профайлером

Главное окно профайлера предназначено для выбора функций, базовые блоки в которых будут защищаться при помощи RIP CODE:

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

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

• Сохранить текущие результаты профилирования и выйти из приложения
• Найти функцию в приложении по ее названию или его части
• Отфильтровать для показа только защищенные функции
• Вызвать меню настроек профайлера
• Запустить повторно процесс профилирования

Принципы выбора защищаемых функций
Общая рекомендация: если приложение после защиты работает медленно, необходимо найти функции, вызывающие проблемы с производительностью, и изменить параметры их защиты.
Кроме того, нужно:
1. Защищать функции, содержащие интеллектуальную собственность
2. Защищать функции, изменившиеся в данном релизе
3. Не защищать стандартные библиотечные функции, прилинкованные статически
4. Не защищать «медленные» базовые блоки в функциях, отмеченных символом улитки

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

• Смена шрифтов интерфейса занимает более 10 секунд, хотя до защиты она выполнялась за 1 - 2 секунды
• При создании новой папки в некоторых случаях приложение зависает или аварийно завершается
• В приложении окно состоит из нескольких панелей, и при изменении их размера оно надолго подвисает

Данные проблемы можно решить следующими методами:
1. Не защищать функции
Отключить RIP CODE, т.е. в главном окне мастера лицензирования выбрать пункт Не защищать функции. Данный метод наиболее радикален, он помогает преодолеть большинство проблем с производительностью, но снижает защищенность приложения.
Рекомендуется использовать, если в приложение встроена защита на Guardant API, или когда любые попытки использования RIP CODE вызывают проблемы.
2. Выбрать функции для защиты вручную
С помощью окна поиска найти функции смены шрифтов интерфейса..:

..и создания новой папки:

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