Лекции. Введение. Защита программного обеспечения от несанкционированного использования с помощью программноаппаратных средств
 Скачать 4.72 Mb.
|
Модульная архитектура технических средств защиты ПО от несанкционированного использованияВ общем случае, система защиты от несанкционированного использования представляет собой комплекс средств, предназначенный для затруднения (а в идеале - предотвращения) нелегального копирования (исполнения) защищаемого программного модуля, с которым она ассоциирована. Особенностью технических мер защиты ПО от несанкционированного использования является выделение (или введение) некоторого идентифицирующего элемента из среды окружения защищаемой программы, имеющего уникальные физические характеристики, на которые настраивается система защиты. Основными требованиями к системе защиты ПО от несанкционированного использования являются следующие [Error: Reference source not found]: система защиты должна выявлять факт несанкционированного запуска программы; система защиты должна реагировать на факт несанкционированного запуска программы; система защиты должна противостоять возможным атакам злоумышленников, направленных на нейтрализацию системы защиты. На рисунке представлена иерархия модулей системы защиты ПО от несанкционированного использования, а также направления взаимодействия данных модулей. Схема показывает, что система защиты ПО от несанкционированного использования состоит из двух основных частей: подсистемы внедрения механизмов системы защиты; внедряемого защитного кода. Последний блок, в свою очередь, состоит из двух подсистем: 1. подсистемы реализации защитных функций и 2. подсистемы противодействия нейтрализации защитных механизмов Рис. 1. Модульная архитектура системы защиты ПО от несанкционированного использования П  одсистема реализации защитных функций на структурном уровне также является составной и включает в себя три модуля: 1. блок установки характеристик среды, 2. блок сравнения характеристик среды и 3. блок ответной реакцииПодсистема противодействия нейтрализации защитных механизмов предназначена для борьбы с возможными попытками нейтрализации системы защиты от несанкционированного использования и/или ее дискредитации. Блок установки характеристик среды отвечает за получение характеристик, идентифицирующих вычислительную среду (серийный номер, ключ, конфигурация аппаратуры, элементы электронного ключа и т.д.). Выходные данные этого блока являются входными данными для блока сравнения характеристик среды. Блок сравнения характеристик среды устанавливает факт легальности запуска защищаемой программы, сравнивая текущие значения параметров среды с эталонными. Блок ответной реакции реализует ответные действия системы защиты на попытки несанкционированного исполнения защищаемой программы. Любая система защиты ПО от несанкционированного использования функционирует по следующему обобщенному алгоритму, отражающему взаимодействие перечисленных подсистем и модулей. 1. Разработчик программы внедряет защитные механизмы в защищаемую программу. 2. В защитные механизмы закладываются эталонные характеристики среды, которые идентифицируют конкретную копию программы, и относительно которых будет проверяться легальность запуска. 3. При каждом запуске программы выполняются следующие действия: снимаются текущие характеристики среды; текущие характеристики сравниваются с эталонными; если сравнение характеристик дало положительный результат, то ПО запускается (либо продолжает работать); если сравнение характеристик дало отрицательный результат, то запускается блок ответной реакции. Рассмотрим более подробно функциональное назначение каждой из подсистем и модулей. Функционирование подсистем и модулей системы защиты ПО от несанкционированного использованияПодсистема внедрения управляющих механизмов Системы защиты ПО от несанкционированного использования по способу ассоциации (внедрения) защитного механизма можно подразделить на два типа : 1) встроенные системы (внедряются при создании ПО); 2) пристыковочные системы (подключаются к уже готовому ПО). Во встроенных защитах подсистема внедрения защитных механизмов отсутствует. Встраивание защиты производится непосредственно разработчиком в процессе создания ПО. При этом разработчик может применять либо собственные разработки элементов защиты, либо готовый набор модулей. В качестве примеров подобных защит можно привести использование разработчиком API функций электронных ключей HASP для защиты своего программного продукта. Пристыковочные защиты внедряются в уже готовый исполняемый код, как правило, по вирусному принципу, преобразуя код программы. При запуске защищенного ПО, произведя необходимые проверки, код защиты восстанавливает оригинальное начало файла и передает на него управление, после чего программа начинает нормальную работу, не подозревая о том, что она была изменена. В качестве примера подобной защиты можно привести использование модуля пакетной обработки защищаемых файлов HASP Envelope для электронных ключей HASP, позволяющего в автоматическом режиме защитить исполняемый код. У каждого вида защит есть свои преимущества и недостатки. При использовании встроенных систем разработчику более просто реализовать любую реакцию системы защиты ПО на несанкционированный запуск, которую невозможно реализовать в пристыковочных системах. Например, при обнаружении несанкционированного запуска можно запускать программу в демонстрационном режиме. Это позволяет разработчику продвигать более гибкую маркетинговую политику на рынке ПО. Во встроенных системах защиты разработчик может опрашивать идентифицирующий элемент где угодно, когда угодно и столько раз, сколько нужно. Это сложнее реализовать в пристыковочных системах, где реализуется фиксированный алгоритм. В то же время, процедура ассоциации встроенных систем защиты требует от разработчика больших затрат времени и усилий и в любом случае не может быть автоматизирована. К тому же, для удобства пользователей встроенная защита, предоставляемая сторонними разработчиками, строится на основе библиотечных функций. При этом разработчики в сопроводительной документации детально описывают интерфейс библиотечных функций с вызывающей программой, вследствие чего его однозначно можно считать известным злоумышленнику, а значит, потенциальная стойкость системы защиты снижается. Реализация встроенной системы защиты приводит к значительному увеличению финансовых и временных затрат на создание конечного программного продукта при часто невысокой степени надежности полученной защиты. Следует отметить, что использование встроенных систем защиты требует доступа к исходным текстам защищаемого ПО. К преимуществам защит пристыковочного типа относятся: простота тиражирования программных систем защиты; простота технологии применения - защита поставляется в виде законченного продукта, которым нужно обработать защищаемую программу; возможность включения в пристыковочные защиты элементов защиты ПО от изучения с помощью отладчиков и дизассемблеров. Эти элементы очень сложно реализовывать во встроенных системах; использование пристыковочных защит не требует наличия исходных текстов программы. Основным недостатком пристыковочных защит является то, что многие из них могут быть нейтрализованы с помощью специальных средств в автоматическом режиме в момент, когда защитная часть уже отработала и начал выполняться защищаемый код. Считается, что защита пристыковочного типа подходит для защиты небольших узкоспециализированных программных пакетов, для которых стоимость нейтрализации защиты на порядок больше цены копии. В общем случае, для большей стойкости к взлому рекомендуется защищать программный продукт как с помощью встроенных, так и с помощью пристыковочных защит. Вначале разработчик реализует защиту встроенными методами, а затем, после компиляции продукта защищает исполняемый код с помощью защиты пристыковочного типа. Подсистема противодействия нейтрализации защитных механизмов Организация противодействия нейтрализации защитных механизмов в первую очередь связана с противодействием анализу злоумышленником логики и принципов действия защитных механизмов, а также с противодействием возможному вмешательству в их функционирование. Нейтрализация защитных механизмов может вестись по двум основным направлениям - статическому и динамическому. При статической нейтрализации защищаемая программа сначала дизассемблируется, по полученному коду изучается логика ее работы. При динамической нейтрализации изучение, реконструирование логики работы защитных механизмов и вмешательство в их работу осуществляется с помощью отладчиков, а необходимые изменения вносятся непосредственно в код программы. Блок ответной реакции Блок ответной реакции является одновременно самым простым и самым сложным при проектировании систем защиты ПО от несанкционированного использования. Достаточно часто злоумышленник атакует именно этот блок, отключая его, либо модифицируя так, чтобы ответная реакция на анализ идентификационного элемента была всегда положительна. Многие «пиратские» программы, снабжаемые достаточно короткой утилитой типа «crack.com», были взломаны крэкерами именно таким образом. Возможны ситуации, когда данный блок вообще отсутствует, либо выражен неявным образом (последний вариант в некоторых случаях предпочтителен с точки зрения безопасности). Например, информация, полученная от блока установки характеристик среды, может быть использована в качестве ключа для дешифровки кода программы. Если значения характеристик среды отличаются от эталонных, то при дешифровке получится «мусор», который при исполнении, как правило, «подвешивает» систему. Блок сравнения характеристик среды Данный блок, как и блок ответной реакции, достаточно часто подвергается атакам со стороны злоумышленников. Эти атаки направлены на модификацию данного блока таким образом, чтобы отключить блок ответной реакции, либо запускать его только по одной из ветвей (ветви, по которой идет исполнение в случае совпадения характеристик среды с эталонными). Для того чтобы систему защиты ПО от несанкционированного использования нельзя было нейтрализовать с помощью простейших приемов, блок сравнения значений характеристик среды должен отвечать ряду требований. 1. Установка значений характеристик среды функционирования защищаемой программы и сравнение значения характеристик с эталонными должны производиться многократно. 2. Сравнение текущих значений характеристик среды с эталонными должно производиться периодически в течение всего сеанса работы программы. Данные меры направлены против того, чтобы однократно проверенный в начале работы программы идентифицирующий элемент не мог бы быть использован для запуска других копий. 3. Значения, полученные от блока установки характеристик среды, хорошо использовать как ключ для дешифровки кода, для которого (перед передачей ему управления) подсчитывается контрольная сумма. 4. Получение результатов сравнения должно быть принудительно распределено в коде программы. Удачным приемом против потенциального злоумышленника считается преобразование значения на выходе блока установки характеристик среды в некоторую переменную, которая затем может быть использована, например, как аргумент для обращения к управляющей таблице при вычислении значения адреса перехода или вызова подпрограммы. Блок установки характеристик среды Блок установки характеристик среды определяет наличие идентифицирующего элемента, его текущие параметры и передает их значения блоку сравнения характеристик среды. В качестве идентифицирующего элемента, позволяющего отличать одну копию программного продукта от другой, могут выступать: серийный номер S/N; ключ; конфигурация аппаратуры; элементы электронного ключа, другие аппаратные устройства и т.д Наиболее уязвимым местом в блоке установки характеристик среды является не его код, а способ передачи и объем передаваемых данных. Например, если все характеристики идентифицирующего элемента преобразовываются для дальнейшего сравнения в однобайтовую переменную, появляется возможность нейтрализации системы защиты путем перебора возможных ее значений. Блок установки характеристик среды также очень часто атакуется злоумышленником. Однако, в данном случае цель анализа данного блока состоит не в отключении каких-либо модулей, а выяснение той идентифицирующей информации, которую «ждет» блок сравнения характеристик среды. Множество серийных номеров взломанных программных продуктов, ходящих в Интернет, является результатом атак на блок установки характеристик среды. Для защиты от подобных атак эталонные характеристики среды не должны никогда в явном виде присутствовать в коде программы, данные характеристики должны закрываться, например, с использованием криптографически стойких функций хэширования. |