Общие советы по созданию защиты Shareware-программ

Вопросы защиты программ от незаконного копирования и использования встают сейчас всё чаще и чаще. В основном, это, конечно же, связано с ростом популярности коммерческих программ (aka shareware). Пару раз подобные вопросы проскакивали и в форуме.

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

Но всё же стоит подумать не о примитивной (как у большинства сегодняшних shareware-программ), а о достойной защите. Надеюсь, мои советы наставят вас на путь истины :-). Итак, приступим.

№1. Используйте ассемблер (хотя, думаю, не всем это понравится). Функции API и компоненты VCL использовать надо как можно меньше. Дизассемблеры способны распознавать вызовы стандартных функций, и хакер получит возможность создать на них точку останова, то есть заблокировать их вызов.

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

№3. Не храните регистрационный код в одном месте на компьютере пользователя, тем более открыто. Лучше записать его сразу в несколько мест, предварительно зашифровав разными методами шифрования. Это собьёт хакера с толку.

№4. Не проверяйте код сразу после его ввода. Это очевидно. Хорошо сделать функцию-приманку.

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

№6. Не делайте всего лишь одну проверку кода на правильность. Минимум - три, каждая из которых проверяет код по разным алгоритмам или шаблонам. Одну из них желательно всячески афишировать, а остальные тщательно замаскировать, чтобы взломщик и не подозревал о них. Кроме того, не делайте эти проверки в функции. Достаточно заблокировать их вызовы и все ваши старания будут напрасными. И ещё. Не давайте настоящим функциям проверки осмысленные имена, типа CodeCheck или IsValidCode.

№7. Как можно больше отвлекающих маневров! Поместите API-функции в цикл и отвлекайте ими хакера. Больше ненужных проверок и расчётов. Пусть программа что-нибудь усиленно шифрует и, в конце концов, возвращает значение, но каждый раз одно и то же. Проверяйте это значение с эталоном и, если оно не совпадает с ним (а такого ведь и быть не может), вырубайте программу. Взломщик обратит на этот код большее внимание, и это отвлечёт его от реальных проверок.

№8. Защищайте программу контрольными суммами (CRC). Это обезопасит вас не только от всевозможных патчей, но и от троянских коней.

№9. Пользуйтесь архиваторами, такими как ASPack или PEPack. Хакер хотя бы потратит время на их разархивирование. Ещё лучше написать свой собственный архиватор с оригинальным способом архивации.

№10. Никогда не выводите сообщения о том, что нарушена защита. По крайней мере, сделайте это спустя пару запусков.

№11. После того, как введён пароль и нажата кнопка OK, сделайте паузу на несколько секунд. Это не даст возможности подобрать регистрационный код перебором.

№12. Сообщения типа "Незарегистрированная версия" создавайте динамически и не храните их статически в программе. Поиск по этим фразам сразу выдаст место проверки. Можете хранить их по частям или в зашифрованном виде. А вообще лучше такие сообщения не выводить вообще. Это ведь только стимулирует хакера.

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

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

Чао.

Krott.