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

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

Системы защиты программного обеспечения от несанкционированного использования по способу ассоциации (внедрения) защитного механизма можно подразделить на два типа [2,8]:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· ключ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-11