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

Подсистема внедрения управляющих механизмов

Системы защиты ПО от несанкционированного использования по способу ассоциации (внедрения) защитного механизма можно подразделить на два типа :

1) встроенные системы (внедряются при создании ПО);

2) пристыковочные системы (подключаются к уже готовому ПО).

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

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

У каждого вида защит есть свои преимущества и недостатки.

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

К преимуществам защит пристыковочного типа относятся:

• простота тиражирования программных систем защиты;

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

• возможность включения в пристыковочные защиты элементов защиты ПО от изучения с помощью отладчиков и дизассемблеров. Эти элементы очень сложно реализовывать во встроенных системах;

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

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

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

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

Подсистема противодействия нейтрализации защитных механизмов

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

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

Блок ответной реакции

Блок ответной реакции является одновременно самым простым и самым сложным при проектировании систем защиты ПО от несанкционированного использования. Достаточно часто злоумышленник атакует именно этот блок, отключая его, либо модифицируя так, чтобы ответная реакция на анализ идентификационного элемента была всегда положительна. Многие «пиратские» программы, снабжаемые достаточно короткой утилитой типа «crack.com», были взломаны крэкерами именно таким образом.

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

Блок сравнения характеристик среды

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

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

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

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

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

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

Блок установки характеристик среды

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

• серийный номер S/N;

• ключ;

• конфигурация аппаратуры;

• элементы электронного ключа, другие аппаратные устройства и т.д

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

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