Программная часть
Усложним программу. Запутаем алгоритм. Избавим от комментариев. Снимем порчу с винчестера и сглаз с монитора. /Группа программистов-экстрасенсов/
Программная часть защитного комплекса состоит из драйвера аппаратного ключа и модуля, встраиваемого в прикладную программу.
1. Драйвер ключа. Так как ни одна уважающая себя операционная система не позволит прикладной программе напрямую общаться с портами ввода/вывода, требуется наличие драйвера, выполняющегося в режиме ядра ОС. Это условие является обязательным для всех клонов Unix, Novell Netware, MS Windows NT.
Задача драйвера – обеспечить самый низкий уровень обмена данными между ключом и прикладной программой. Для ключей, подключаемых к COM- и LPT-портам, драйвер отвечает за формирование синхронизирующих и информационных сигналов на выходах соответствующих разъемов и за расшифровку последовательного кода, получаемого от аппаратного ключа. Кроме того, для PIC- и ASIC-ключей драйвер формирует инициирующую последовательность (данные, приняв которые, ключ начинает обрабатывать все последующие данные по заданному алгоритму).
2. Встраиваемый модуль. Как уже было сказано выше, для ключей на основе FLASH-памяти защита заключается в считывания из ключа некоторых данных и/или участков программного кода. Для PIC- и ASIC-ключей защита строится по принципиально другому методу. На этапе программирования ключа (или производства ASIC-чипа) в него записывается микропрограмма, реализующая некоторую функцию y = F(x1,x2,…xn), где x1…xn – входные параметры, а y – выходной параметр. Обычно один или несколько параметров x1…xn представляют собой случайные числа (для затруднения определения вида функции F), один из параметров – уникальный номер ключа (“серийный номер”), еще один - идентификатор защищаемого программного обеспечения, и т.п.
После обработки ключом входных параметров он формирует и выдает в компьютер выходное значение y. Это значение передается в модуль, интегрированный в прикладную программу, где над этим значением и параметрами x1…xn производится преобразование вида y’ = f(y,x1,x2…xn).
Результирующим значением y’ могут быть константы, необходимые для работы программы, участки программного кода, адреса подпрограмм и т.п. При этом необходимое условие - невозможность восстановления функции F(x1,x2…xn) по функции f(y,x1,x2…xn), которую довольно легко получить, реассемблировав участок прикладной программы, отвечающий за проверку данных, полученных от ключа.
При наличии в ключе энергонезависимой памяти и/или таймеров можно добавить их текущие значения в качестве аргументов функции F(x1,x2…xn), что расширяет возможности построения систем защиты.
3. Реализация. Конечно, разработчики электронных ключей пытаются как можно больше усложнить жизнь хакерам, которые будут взламывать их защиту. Для этого применяются: - защита от реассемблирования (условные и безусловные переходы по содержимому регистров или ячеек памяти, после которых ставятся несколько байт, реассемблируемых в реальную команду процессора; “размывание” программного кода путем размещения его в разных местах программного модуля с выполнением безусловных или неочевидных условных переходов после каждой ассемблерной команды), - защита от трассировки (перехват INT1 и INT3, издевательства над регистрами SS/SP/ESP, работа в режиме запрещенных прерываний и т.п.), - защита от отладчиков (проверка их наличия через API-функции), - проверка изменения кода драйвера ключа или встраиваемого модуля (проверка контрольной суммы, проверка по контрольным точкам и т.п.).
Если система хащиты обнаруживает попытку взлома, работоспособность прикладной программы намеренно нарушается. Это может проявляться и как невозможность запуска прикладной программы, и как ее неправильное функционирование. В последнем случае взлом защищаемой программы становится еще труднее, т.к. не понятно, на каком этапе сработала защита.