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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- ключ;

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

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

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

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

Электронные ключи HASP

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

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

Рис. 8.2. Внешний вид электронных ключей HASP

Базовой основой ключей HASP является специализированная заказная микросхема (ASIC – Application Specific Integrated Circuit), имеющая уникальный для каждого ключа алгоритм работы. В процессе своего исполнения защищенная программа опрашивает подключенный к ПК HASP. Если HASP возвращает правильные ответы, работает по требуемому алгоритму и обладает требуемыми эталонными характеристиками, то программа выполняется нормально. В противном случае реализуется определенная реакция на несанкционированное использование: запуск в демонстрационном режиме, блокировка отдельных функций, отказ в запуске и т.д.

Семейство электронных ключей HASP включает в себя следующие модели:

1. HASP4.

2. MemoHASP.

3. TimeHASP.

4. NetHASP.

HASP4 Standard

Данный тип ключей является простейшей модификацией электронных ключей HASP. Основным элементом их защиты является аппаратно реализованная в них на ASIC микросхеме функция шифрования и связанная с ней функция отклика f(x), принимающая на вход 32-битный аргумент и формирующая на выходе четыре 32-битных значения.

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

1. проверку наличия HASP Standard;

2. проверку соответствия выходов, формируемых функцией отклика f(x) для различных x, эталонным;

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

С любым электронным ключом HASP связана его серия, идентифицирующая защищаемое программное обеспечение (например, IXGGR, RAOMG). Каждая из серий обладает своей уникальной функцией шифрования данных, что вносит уникальность в алгоритм защиты каждого защищаемого продукта.

Данный тип ключей HASP является наиболее хорошим решением для защиты недорогих программ. Стоимость данных ключей составляет порядка 14$.

MemoHASP

Ключи MemoHASP имеют в своем составе все компоненты HASP Standard. Базовым отличием данного типа ключей от HASP4 Standard является наличие встроенной в них энергонезависимой памяти (EEPROM), доступной для чтения и записи во время выполнения защищенной программы. Каждому из данных типов ключей также присваивается свой уникальный 32-битовый идентификационный номер ID, который позволяет идентифицировать конкретного пользователя продукта.

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

HASP4 M1 – 112 байт EEPROM, возможность одновременной защиты до 16 программ, ориентировочная стоимость 20$.

HASP4 M4 – 496 байт EEPROM, возможность одновременной защиты до 112 программ, ориентировочная стоимость 29$.

Кроме подходов к защите ПО, свойственных HASP Standard, с помощью MemoHASP могут быть реализованы, например, следующие подходы к защите:

4. Хранение в энергонезависимой памяти MemoHASP конфиденциальной информации – ключей шифрования, части исполняемого кода и т.д.

5. Хранение в энергонезависимой памяти информации о модулях защищенного ПО, к которым пользователь имеет доступ и о тех, к которым не имеет (в зависимости от заплаченной суммы за приобретение ПО).

6. Хранение в энергонезависимой памяти информации о количестве запусков ПО, либо об оставшемся количестве запусков. Данный подход актуален при создании демонстрационных версий ПО, работа с которыми ограничена количеством запусков.

TimeHASP

Кроме функций MemoHASP, данные ключи обладают встроенными часами реального времени с автономным питанием от литиевой батарейки (отражающие время и дату). Используя часы реального времени производитель может защищать свое ПО по времени использования и на основании этого строить гибкую маркетинговую политику - сдачу программ в аренду, лизинг ПО и периодический сбор платы за его использование и т.д. Стоимость данных ключей составляет порядка 33$.

NetHASP

Данные ключи имеют в своем составе все компоненты MemoHASP и предназначены для защиты ПО в сетевых средах. Один ключ, установленный на любом компьютере сети, способен защитить ПО от тиражирования, а также ограничить количество рабочих мест (лицензий), на которых ПО используется одновременно. Ключ может работать на выделенном либо невыделенном сервере, либо любой станции. Он поддерживает различные протоколы – IPX/SPX, NetBIOS, NetBEUI, TCP/IP.

Существует несколько моделей ключей HASP4 Net, которые позволяют лицензировать программы для 5, 10, 20, 50, 100 и для неограниченного количества пользователей. Все они могут защищать до 112 различных программ (или модулей программы). Номер модели определяет максимальное число рабочих мест для любой из этих программ. Например, HASP4 Net-5 защищает до 112 программ, и каждая программа может лицензироваться на количество рабочих мест от нуля до пяти (например, три).

Работа с NetHASP осуществляется через менеджер лицензий.

Менеджер лицензий HASP4 Net - это программа-посредник, обеспечивающая связь защищённых приложений с сетевым ключом. При этом сам ключ может стоять на любом компьютере в сети - выделенном или невыделенном файл-сервере или на любой станции. Чтобы использовать в сети сервис NetHASP, нужно выбрать рабочую станцию, присоединить к ней ключ NetHASP и загрузить на ней менеджер лицензий NetHASP.

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

Когда защищённое приложение стартует на компьютере, подключенном к сети, оно обращается к менеджеру лицензий и запрашивает разрешение выполняться дальше (NetHASP LOGIN), для отключения от сервера используется процедура (NetHASP LOGOUT). При этом менеджер лицензий проверяет соблюдение ряда условий:

- наличие соответствующего ключа HASP4 Net на машине, где он загружен;

- наличие лицензии на выполнение данной программы;

- лимит рабочих мест для этой программы на данный момент не исчерпан.

Если результаты всех проверок положительны, менеджер лицензий даёт запросившей его программе разрешение на выполнение и заносит данные о ней в журнал доступа.

Менеджер лицензий ведёт журнал доступа, в котором отмечаются все подключившиеся приложения, выполнившие LOGIN. В журнале содержатся сведения о том, какая программа и на какой рабочей станции была запущена. Эти данные сохраняются в журнале до тех пор, пока программа не выполнит отключение (LOGOUT). При помощи журнала доступа менеджер лицензий отслеживает количество машин, на которых одновременно выполняется защищённая программа, и не допускает превышения максимального их числа, заданного разработчиком программы.

Цена на ключи NetHASP в зависимости от модели 37,5 – 260$.

Общая схема взаимодействия с электронным ключом HASP

Общую схему функционирования HASP можно представить в следующем виде:

Серия

ID

F(x) – функция шифрования

MEMO

TIME MEMO

Таймер

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

Доступ к функциям электронного ключа HASP возможен только при указании кодов доступа. Коды доступа представляют собой два целых 16-битовых числа. Они уникальны для каждой из серий HASP. Внутри серии данные коды определены однозначно. Не указав код, пользователь не сможет обеспечить себе доступ к функциям HASP. Таким образом выполняется противодействие эмуляции и копированию HASP.

В таблице 8.1. представлены основные элементы электронных ключей HASP и типы HASP, в которых данные элементы присутствуют.

Табл. 8.1. Элементы электронных ключей HASP

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

1. HASP API – с помощью API функций.

2. Пакетный режим (HASP Envelope).

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

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

При защите ПО более предпочтительно одновременное использование как первого, так и второго способа.

Система полного управления доступом в HASP (FAS)

Система полного управления доступом (Full Authorization System) в HASP позволяет производителю защитить несколько программ одним и тем же ключом HASP, определив условия, при которых может работать конкретная программа. Возможно ограничение использования программ посредством:

1. Задания количества запусков программы (MemoHASP, NetHASP). Эта возможность полезна при разработке демо-версий защищенных программ.

2. Задания допустимого срока работы программы (HASP4 Time). Эта возможность полезна при лизинге и аренде программ.

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

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

1. В первую очередь, проверяется, присоединен ли к компьютеру соответствующий ключ.

2. Если ответ положителен, память HASP проверяется на предмет того, занесена ли программа в список разрешенных к работе.

3. При положительном ответе выполняется серия проверок в зависимости от используемой модели HASP.

В случае MemoHASP, память ключа опрашивается на предмет превышения допустимого количества запусков программ. С каждым новым запуском число допустимых запусков уменьшается на 1. Как только это число станет=0, работа программ прекращается, и выдается сообщение об ошибке.

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

HASP API

Все функции API HASP (кроме NetHASP) вызываются через единую функцию hasp(), которая имеет следующий синтаксис

Hasp(Service,SeedCode,LptNum,Pass1,Pass2,Par1,Par2,Par3,Par4)

Для NetHASP та же функция имеет следующий формат

Hasp(Service,SeedCode,ProgNum,Pass1,Pass2,Par1,Par2,Par3,Par4)

Здесь,

Service – номер вызываемой функции (и соответствующей ей операции).

LptNum – номер параллельного порта, к которому подключен HASP (если 0, то драйвер его ищет автоматически, 1-LPT1, 2-LPT2, 3-LPT3,201-255-определенный ключ HASP для порта USB).

SeedCode – значение, посылаемое в функцию отклика f(x).

Pass,Pass2 – пароль для HASP. Он должен быть указан при доступе ко всем функциям, кроме функции проверки наличия HASP

Par1,Par2,Par3,Par4 – параметры, через которые передаются значения в HASP и через которые возвращаются.

Система удаленного обновления (RUS)

Система удаленного обновления (RUS) представляет собой утилиту, позволяющую безопасным образом удаленно обновить содержимое ключей HASP у пользователя без необходимости раскрытия паролей. Эта возможность позволяет отказаться от необходимости отправки разработчиком нового ключа HASP, когда покупатель желает обновить его содержимое.

Использование RUS позволяет, например, принять разработчиком ПО оплату от покупателя, после чего удаленно разблокировать запрет использования определенного модуля. Это позволяет использовать так называемую концепцию многоуровневого лицензирования.

Технология применения утилиты RUS включает в себя 2 этапа:

1. Создание утилиты RUS.

2. Обновление памяти ключей у пользователя.

С помощью утилиты RUS продавец создает 2 утилиты – утилиту продавца и утилиту пользователя.

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

Чтобы обновить память ключа HASP

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

2. Разработчик вводит идентификатор и обновляемые данные в утилиту Продавца.

3. Разработчик генерирует пароли RUS в утилите Продавца и передает их пользователю.

4. Пользователь вводит эти пароли в утилиту Пользователя и обновляет память своего ключа HASP.

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

Модель защиты структурным кодом (PCS)

Защита структурным кодом (Pattern Code Security – PCS) является средством, значительно повышающим защищенность приложения, защищаемого с помощью электронных ключей HASP.

PCS реализуется в процессе защиты с помощью HASP API. Использование PCS возможно лишь при наличии доступа к исходным текстам защищаемого приложения.

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

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

Шаблон – специальная статическая структура данных, определенная в приложении. Шаблон включает в себя сигнатуру, номер функции hasp() и параметры, необходимые для работы данной функции.

Каждый вызов процедуры hasp() автоматически обновляет все шаблоны в коде программы, их после выхода из функции можно проверить. Если динамически изменять в шаблонах значения входных переменных, то автоматически будут меняться и выходные. Аналогично, можно изменять и значения сервисов.

Преимуществами использования PCS являются:

1. скрывание обращения к HASP;

2. трассировка вызовов hasp() для шаблонов практически невозможна, так как их нет в исходном коде;

3. легче обнаруживается вмешательство извне (если процедуру отключили); если вызов hasp() будет удален, то шаблоны не обновятся, а это значит – кто-то вмешался в работу приложения;

4. PCS препятствует эмуляции процедуре hasp().

Рекомендации по наиболее надежной защите с помощью HASP

Электронные ключи HASP являются достаточно надежным аппаратным средством защиты ПО. Тем не менее, система защиты HASP надежна лишь настолько, насколько разработчик сделает ее таковой.

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

- заклеивание вызовов к защищающей приложение процедуре;

- заклеивание программы производителя ключа.

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

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

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

1. Использовать одновременно методы защиты с помощью оболочки и с помощью API. Они дополняют и усиливают друг друга.

2. Использовать больше вызовов hasp() и шаблонов PCS. Это создаст большие проблемы для взломщика в понимании схемы защиты и атаках на нее. Необходимо как можно больше рассеивать данные вызовы по всему приложению, чтобы затруднить анализ.

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

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

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

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

6. Использование функционирования программы в качестве ответа на отсутствие HASP. Можно использовать целый ряд реакций на неприсоединение нужного ключа. Наиболее простое – вывод сообщения «HASP not FOUND», однако это подсказывает, что делалась проверка ключа. Лучше запрограммировать другую реакцию, – например, отключить клавиатуру. После подсоединения ключа клавиатура включается.

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

Защита ПО от изучения

Не нашли, что искали? Воспользуйтесь поиском по сайту: