|
|
ru.algorithms- RU.ALGORITHMS ---------------------------------------------------------------- From : Andrzej Novosiolov 2:5020/400 30 Jun 2001 12:12:04 To : Andrew Simontsev Subject : Re: Keygen -------------------------------------------------------------------------------- On Sat, 30 Jun 2001 09:32:18 +0400, Andrew Simontsev wrote: AN>> PS. То есть принцип такой: в кейгене вшит секретный ключ, в программе AN>> - открытый. > Может лучше наоборот? Идея алгоритмов с открытым ключом вроде бы и > состоит в том, чтобы не передавать тайный ключ, а хранить у себя (дабы злые > хакеры не перехватили)... Hу так ты ведь и будешь хранить кейген с секретным ключом у себя. Или я неправильно понял твою задумку? А пользователям раздавать программу, открытый ключ и зашифрованный файл лицензии (лучше назовём его так, чтобы не возникало терминологической путаницы с ключами шифрования). При желании можно пойти ещё дальше: для каждой зарегистрированной копии программы генерировать отдельную пару ключей, и затем при помощи этой пары генерировать заказанное количество пользовательских лицензий, привязанных к конкретной копии программы. AN>> Регистрационным ключом продукта является N-килобайтный файлик с AN>> регистрационными данными пользователя и имитовставкой, зашифрованный AN>> секретным ключом. > Что такое имитовставка? В ru.crypt объяснят :) Вкратце - сгенерированный по каким-то правилам набор данных, позволяющий после расшифровки файла удостовериться, что расшифровка прошла успешно (то есть на вход нам подали правильный файл, а не мусор). Простейший вариант - контрольная сумма данных, а вообще-то выбор "хороших" имитовставок - отдельная серьёзная задача. Таким образом, поскольку алгоритм шифрования можно считать устойчивым ко взлому, для взломщиков останется только два пути: несанкционированное копирование легальных копий программы с лицензиями (тут уж методы борьбы скорее организационные, чем программные) и взлом кода программы на предмет отвязки от ключа. От последнего с абсолютной надёжностью защититься нельзя, можно только затруднить взлом. В вопросах защиты от трассировки и дизассемблирования я не силён, но и при условии "беззащитности" кода можно испортить жизнь хакеру следующими спростыми приёмами: 1. Проверять ключ не один раз при старте программы, а многократно, в самых разных и неожиданных местах. 2. Использовать не одну процедуру проверки ключа, а написать их несколько, функционально идентичных, но с разным кодом, и в разные моменты вызывать разные процедуры. 3. Процедуры проверки ключа вызывать не явно, а через переменную-указатель, при этом значение указателя получать не прямо перед вызовом, а заблаговременно, вычисляя его за несколько шагов при помощи разнесённых по телу программы и времени выполнения запутанных процедур. 4. Процедура проверки ключа должна делать что-то большее, чем просто возвращать 0 или 1. Лучше зашить в файл лицензии какой-нибудь массив данных, нужный программе для работы, причём не в открытом виде, а требующий дополнительных преобразований перед использованием. Ещё лучше - несколько отдельных массивов, закодированных независимо и использующихся в разных частях программы. При кодировании использовать регистрационные данные пользователя (имя, фамилию etc.) 5. По возможности, обнаружив неправильный ключ, не вываливаться немедленно с криком "неправильный ключ", а некоторое время продолжать как бы нормальную работу, после чего сымитировать какой-нибудь естественно выглядящий фатальный глюк или баг. Hо обязательно без повреждения данных пользователя, обрушивания системы или отправки разоблачительного e-mailа автору. ... 2:463/1124.5@fidonet, ICQ 8481158, http://surf.to/andrzej --- ifmail v.2.15dev5 * Origin: SoftElegance (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.algorithms/20800e407c59.html, оценка из 5, голосов 10
|