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

Chingachguk/HI-TECH

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

(chingachguk@newmail.ru)

Все об аппаратных ключах защиты

Существует множество аппаратных ключей защиты. По заявлениям производителей, "c помощью ключей HASP защищено более 2/3 коммерческих программ, разработанных и продаваемых на территории СНГ и стран Балтии". Тем не менее, и этот способ защиты имеет ряд существенных недостатков, которыми можно воспользоваться.

Гонка вооружений

Итак, dongle (ключ) - компонента многих защит, которая используется, как правило, для защиты от незаконного использования программ, но также может (по утверждениям разработчиков) использоваться для авторизации/защиты баз данных и т.п. Втыкается в LPT-порт (это уже в прошлом) или в USB. Для нормальной работы может потребоваться установка дополнительных драйверов, не связанных с комплексом защиты. В общем и целом dongle представляет собой часть алгоритма защиты, вынесенную в аппаратную область, проще говоря - в "железо". Сейчас объясню почему. Разработчики защит уже давно приметили, что уровень исследования исполняемых кодов защищенных программ страшно возрос (его неуклонный рост начался еще во времена написания первых DOS-вирусов и крэков) и невозможно дать гарантий на то, что взломщик не сможет полностью изучить код защиты. Полное исследование проведено, исходный код программы фактически имеется перед глазами – крэка при таких делах не напишет только ангел небесный. Разработчики защит изощрялись и порождали на свет все новые и новые приемы, призванные помешать взломщику: антиотладочные процедуры, расшифровываемый при запуске код и многие другие техники. Но и в далеком прошлом, и сейчас на исследование кода защиты требуется намного меньше времени, чем на написание хорошей защиты.

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

{ "Прячем" настоящий пароль, чтобы его не нашли по F4 в far/total/etc }

Str(123,Key1);

Str(691,Key2);

MyBestPassword:=Key1+Key2+... { И другой подобный код ... }

if MyBestPassword <> UserPassword then ...

Однако время обнаружения такой процедуры ничтожно мало, например десять минут. Реверсер установит после ввода абстрактного ключа активации breakpoint на доступ к нему из любого кода и, разумеется, тут же увидит использование введенной информации и критичный код. Конечно, разработчик защиты может пойти дальше. Допустим, он попытается вырвать основной вид оружия из рук реверсера - отладчик SoftIce, которым тот может выполнить вышеописанные действия:

// Открываем устройство "NTICE", если это удалось, то отладчик SoftIce

// установлен в системе

if ( open("\\\\.\\NTICE"...) >= 0 )

{

printf("\n Unload SoftIce ! Program aborted !");

ExitProcess(...);

}

Такой код, будучи размещенным в начале программы, прервет ее выполнение еще до ввода ключа, и реверсер не сможет выполнить анализ кода. Но действительно ли не сможет? Такую попытку защиты легко отследить еще перед запуском исследуемой программы, установив в отладчике слежение за открытием файлов: