Автор: Владимир Каталов

Эту статейку написал скорее всего Владимир Каталов на тему защиты shareware-программ, но я думаю что она будет полезна не только программистам, но и крэкерам тоже.

При хорошем знании ассемблера очень просто обойти защиту типа имя пользователя-регкод: когда пользователь вводит свое имя и регистрационный код, программа генерирует "правильный" код и сравнивает его с тем, который он ввел, поэтому "перехватить" этот код (просто считать его из памяти) не составлет особого труда. В большинстве случаев достаточно просто поставить breakpoint на функцию lstrcmp -- и все дела... Упаковка программы, анти-дебаггерные и анти-дизассемблерные "примочки" помогают слабо.

А вот метод фиксированного ключа может быть реализован достаточно неплохо. Хранить "правильные" ключи в программе совсем не обязательно - можно подчинить их некоторым правилам; что-то подобное делает Microsoft со своими CD-keys, но у них все слишком просто. Алгоритм проверки может быть длинным и запутанным, так что его дизассемблирование (и "разборка", что же он делает) причинит немало головной боли. Именно первый метод я и применил для защиты своей программы (Advanced Disk Catalog - старые версии), но и он был "сломан" (хотя, как мне написал ломавший его хакер, подборка всего двух правильных ключей отняла у него много времени). Тогда мне в голову пришла идея: а что, если ключи хранить внутри программы, но зашифрованными? Я "сгенерил" некоторое количество ключей (абсолютно случайным образом), зашифровал их (по отдельности) 128-битным ключом по алгоритму RSA и прошил в программу в виде ресурса. Когда пользователь вводит ключ, он шифруется по тому же алгоритму и сравнивается с правильными. Так как система с открытым ключом не позволяет произвести обратное преобразование, базируясь только на открытом ключе (а закрытого нет даже у меня - расшифровывать-то не надо), то подобрать ключи невозможно даже теоретически.

Есть, впрочем, еще одна проблема: хакер (или "крэкер", если угодно) может заменить 'je' на 'jne' (или что-то в этом роде) там, где происходит последняя проверка, и функция "IsValidKey(...)" будет всегда возвращать TRUE. Останется лишь написать маленький patch... Чтобы защититься и от этого, я вычисляю CRC своего exe-файла и сравниваю его с правильный, прошитым тоже внутри программы (естественно, при вычислении эта часть файла -- где лежит правильный CRC -- исключается; а "прошивается" он после компиляции). Кстати, это еще и защита от вирусов. Вообще-то, проверку CRC тоже можно локализовать и "запатчить", но это уже немного сложнее, особенно если программа вызывает функции чтения/записи и для других целей. Кроме того, не стоит в случае несовпадения CRC сразу об этом сообщать, иначе можно будет поставить hardware breakpoint и найти место, где он вычисляется. И последнее. Если хочется защитить программы совсем уж "круто", томожно несколько функций в своей программе (те, которые должны вызываться только в зарегистрированной версии), зашифровать по тому же алгоритму с открытым ключом. При этом, естественно, часть серийного номера (отсылаемого зарегистрировавшимся) надо сделать "статическим", т.е. неизменным для всех пользователей. На основе этой части после регистрации генерируется полный закрытый ключ, который далее используется для расшифровки указанных функций. Таким образом, даже если будет написан patch, позволяющий "зарегистрироваться" с любым (произвольным) кодом, расшифровка пройдет неправильно, и вместо нормального кода будет выполняться "мусор".

Этот способ я применил в другой своей программе (Advanced ZIP Password Recovery), и ее пока не вскрыли. Всего наилучшего !

Комментарий от Bad_guy: действительно, если некоторые нужные функции зашифрованы, расшифровать их практически невозможно, и я бы сказал, что для защиты программы этого метода с лихвой достаточно, но никогда не надо забывать, что есть такой способ взлома как кража правильного кода (хотя такой метод противоречит крэкерской этике, да и не крэкерство это вовсе). На мой же взгляд программа - это сейф, содержимое которого вам известно, и прежде чем начинать взламывать этот сейф надо подумать: так ли вам нужно его содержимое ? Автор вот говорит - никто не взломает Advanced ZIP Password Recovery, ну и пускай спит спокойно, а я пока поищу бесплатный аналог (если припрёт).