Ключик к сердцу

Chingachguk/HI-TECH

Спецвыпуск: Хакер, номер #057, стр. 057-094-4

Это хороший, очень хороший ход разработчика защиты, но он становится уязвимым при одной плохой вещи: любой хакер, решившийся на покупку одного ключа (стоимость порядка $30), получит из него SecretKey и сможет расшифровывать любые программные продукты, защищенные этим ключом. Поэтому разработчики идут на различные хитрости в этом направлении: используют случайные запросы (данные для расшифровки выбираются случайным образом из достаточно большого списка, но при этом реверсер может исследовать код программы и найти весь список); запросы, сдвинутые во времени (допустим, в каждом следующем месяце программа обновляет данные для расшифровки и вроде бы рабочий крэк перестает работать); шифрование вводимых данных (допустим, шифрование записей базы данных или передача шифровального ключа SQL-серверу, поддерживающему защиту данных) и т.п. Словом, здесь используются все те же техники, которые можно встретить в "обычных" защитах или же вирусах. Однако следует отметить тот факт, что разработчики защит на основе аппаратных ключей отличаются особой паранойей в этой области: фактически их код стремится включить в себя максимальное число таких "фишек", благо user-код (код приложения win32, например) не ограничен по времени выполнения, в отличие от критичного кода драйвера, и, пока защита расшифрует свое тело раз пять-десять, пользователь может спокойно посидеть в интернете и т.п. По некоторым данным, аналогичные разработки "параноидальных" защитников для *nix-систем содержат ... существенно меньше таких приемов, и некоторые реверсеры вполне успешно сокращают время анализа защиты просто просматривая примеры реализации для этих систем.

HASP-ключ

Перейдем к следующему критичному участку защиты - обмену данными между prog.exe и драйвером защиты driver.sys. Почему обмен данными не может быть выполнен напрямую с ключом из prog.exe? По многим причинам, например по такой: времена DOS давно прошли, и выполнять машинные команды для общения с устройствами (ins/outs) из кода уровня приложения просто невозможно. К тому же в более-менее серьезной операционной системе весь обмен с внешними устройствами реализуется только в драйверах (уровни абстракции), и она не только запрещает обращение к устройствам из user-кода (NT-системы), но и часто предоставляет весьма удобный механизм перехвата таких обращений из user-кода (9x-системы), что может существенно облегчить работу реверсера.

Обмен данными между prog.exe и driver.sys также важно защищать от перехвата и исследования. Почему? Потому что если, например, число проверок наличия ключа в prog.exe 1000 штук, но все они реализуют обмен с ключом одинаковым способом, например через стандартный механизм из Win API DeviceIoControl, то гораздо легче перехватить такой единственный канал обмена вместо вырезания 1000 разбросанных по prog.exe подпрограмм проверки. Здесь защита наиболее уязвима (от перехвата обмена данными с ключом), но здесь же реверсер начинает отступать от "идеального взлома", заключающегося в полной очистке кода prog.exe от всякого присутствия защиты в нем.