Защита программного пакета

← →
MetalFan © (2005-01-19 15:16) [200]

> я вижу ветка плавно перерастает в соревнование ломателей
> :)

а что, прикольно понаблюдать!

← →
Беспечный_Ангел © (2005-01-19 18:45) [201]

> if RegEd.Text <> "17D61E26B05B07A03F74C73E"
> фантастика))))))))))))))))))))))))))

Гы))))) Может, перечитать ветку с начала? ))))

← →
Беспечный_Ангел © (2005-01-19 18:55) [202]

> if RegEd.Text <> "17D61E26B05B07A03F74C73E"
> фантастика))))))))))))))))))))))))))

Гы))))) Может, перечитать ветку с начала? ))))

← →
Strech (2005-01-20 03:36) [203]

Возвращаясь к проблеме защиты, определяемся, что именно следует защищать:
1. Инсталяшку от копирования;
2. Распространение серийника;
3. Работу инсталяшки при вводе серийника;
4. Копирование уже установленной программы, точнее ее работу на другой машине.
Теперь по порядку.
Защищать что либо от копирования по-моему бесполезное занятие, все равно скопируют. А денег на такую защиту уйдет много. Поэтому п.1 не рассматриваю. Или вы хотите распространять дистрибутивы на самодельной флешке, на которой виден только один файл setup.exe, а остальное спрятано?.. уверяю – и это скопируют
Если серийник статичный, как в примере выше, смысла в нем нет, ибо тот, кому лень ломать дистрибутив найдет его в сети. Следовательно он должен генерироваться на основе данных пользователя (фамилия или данные железа на которое устанавливается прога). Т.е. при установке пользователь получает некоторый первичный ключ, на основании которого он получает от производителя вторую часть ключа. Слабое место здесь в том, что хоть вторую часть ключа генерит производитель и это скрыто от пользователя, но та же процедура должна быть зашита в дистрибутив для проверки. Стало быть это место и нужно защищать шифрованием и т.д. Иначе вскоре появится кей-генератор.
На мой взгляд, самое слабое место - это проверка серийника. Большинство программ именно в этом месте и ломаются. Вот над этим местом давайте и думать дальше.
Есть вариант, когда серийник при вводе не проверяется, а проверяется он при запуске установленной программы. Это вычеркивает из нашей проблемы 3-й пункт, при этом 1-й пункт становится тоже нестрашен. При таком подходе вся проблема защиты сливается в один пункт (4). Вроде как проблем становится меньше, поэтому некоторые производители так и поступают.
Итак, самое слабое место - это момент проверки серийника. Так что давайте думать, как это место защищать...

← →
Strech (2005-01-20 04:02) [204]

Абсолютной защиты не бывает. Если что-то можно сделать, это можно и сломать. Нам остается лишь затруднить этот взлом.
Как выяснилось выше по ветке, какой бы сложный механизм шифрования мы не использовали, в конечном итоге все сводится к условному переходу в зависимости от результата проверки. Вывод: условного перехода быть не должно, это затруднит работу крэкера.
Итак, мы имеем:
П1 – процедура которая должна выполнится при успешной проверке серийника и П2 – в случае неуспешного. Ввод серийника должен сгенерировать нам некоторую маску Mask. В любом месте программы (а таких мест может быть много) мы вставляем безусловный переход по адресу равному комбинации некоторого числа Adr1 и маски Mask. При этом такая комбинация должна давать нам либо адрес П1 либо адрес П2. Это всё, осталось только зашифровать процедуру генерации маски.

← →
DDDeN (2005-01-20 04:20) [205]

Есть вариант, использовать в заголовке ехе-файла свой загрузчик, а тело всего ехе-файла зашифровать. Вчера нашел древний журнал "Монитор" (не знаю какой номер), там описан примерный алгоритм того, что надо делать.

Есть еще предложение, при вводе серийника проверять не самой прогой, а запустить какую-нить другую прогу, которая под прикрытием первой проверит серийник.

← →
nicesc (2005-01-20 06:21) [206]

DDDeN
"Есть еще предложение, при вводе серийника проверять не самой прогой, а запустить какую-нить другую прогу, которая под прикрытием первой проверит серийник."
Всё это обходится на раз-два

← →
DDDeN (2005-01-20 09:36) [207]

Ну, вообщем, хорошо пообщались...
Думаю, что тема себя исчерпала.

Защита программного пакета Найти похожие ветки