Коммерческая программа

[Polotenchik]

Я понимаю, что идеальной защиты нет и не будет, но все же каким образом можно превратить программу в платную? Хотелось бы, что бы программа та работала, но была ограничена в некоторых возможностях. Т.е например не работала пару кнопок. Желательно, что бы программа брала ID железа, который желающий приобрести продукт отсылал его мне, в ответ получал ключ и после этого все становилось доступным.

Может подскажете для этого дела какой-нибудь хороший компонент или подкините иные идеи?!

Нашел вот такое: http://www.delphilab.ru/content/view/282/72/ Там с примером с генератором ключей, как думаете нормальный компонент?

Так же интересует последний комментарий от туда:

Скажите, а вся концепция заключается в формате матрицы: S-S-C-S-C-C-S-S-C-S-S-C-S-C-C-C-S-C-S-S

Т.е тупа выставить свою последовательность и тем самым получаешь свой генератор ключей, я все правильно понял?

Заранее спасибо за любую помощь!

[Lemo]

http://delphiexpert.ru/view_download.php?id=123 Советую разобраться

[russian-stalker]

Алгоритм можно любой, хоть такой:

asm
push username
xor username,1234
add pass,username
pop username
end;

Чтобы отловить дебаггер(не всякий, но всё же) можно использовать WinAPI функцию IsDebuggerPresent.
Где то так:

if debuggerpresent then
close;

СофтАйс это не отловит, но всё же многие дебаггеры отловит.
Так же прочитайте это: http://wasm.ru/article.php?article=1017001
Для обмена ключём используйте сокеты.

[DeKot]

Идеально в этом случае работает демо-версия. Это версия . где возможности программы показаны, но отсутствует какое либо важное функциональное значение.
Например программа обработки каких либо файлов может открыть(прочитать, сохранить и т.п.) только три (цифра для примера) файла, что явно не достаточно для серъезной обработки.
Или в демо версии заложена работа только с минимальными цифровыми данными (на уровне byte) , что не позволяет решать нормальные задачи (без чисел на уровне integer).
Важен баланс между востребованностью Вашей программы и степенью защищенности.
Идеальной защиты от взлома нет, на любом уровне!

[mosq]

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

[Luke]

Советую распространять демку вручную, а полную версию высылать на мыло после оплаты, ибо все защиты обходятся на раз два.

Если все же будете писать сами - то незабудьте про эмуляцию винапи ф-ций, самоконтроль, шифровку тела (никогда в памяти файл не должен лежать целиком), антиотладку (например через контроль fs:[0]). Вобщем всего не упомянуть=)

p.S>Прием на закуску, разместите проверку ключа в любой неиспользуемой винапи ф-ции, реверсера это очень порадует=)))

[JTG]

Компоненты - сразу нет. Без написания дров можно:

- самый простой способ - выполнять важные действия в обработчике исключения: try <ложный_защитный_механизм> except <настоящий> end; умышленно создавая ошибки в ложном механизме, это во-первых элементарно реализуется и уводит крякера в лес, не вызывая лишних подозрений, а во-вторых если он поймёт, что защита не там, то трассировать из-под юзермодного отладчика цепочку SEH всё-равно не самое приятное дело, особенно если сделать несколько обработчиков - On E: EЧётотамException do ... Потом крякеру это надоест, и он либо потеряет интерес к программе, либо возьмёт ядерный отладчик.

- "раствориться" в программе - напихать защитного кода в system.pas и перекомпилить его - много народу банально переступит "стандартный" дельфийский run-time код. В sysutils заныкать кусок защиты в часто используемых функциях типа IntToStr.

- использовать в защите классы с кучей наследников и виртуальными методами. Получим много-много функций, вызываемых по косвенным адресам (mov edx, ... / call edx)

- проверять целостность кода в памяти и на диске, причём сделать несколько перекрывающихся участков так, чтобы одна процедура CheckCRC1 проверяла кусок кода, включающий в себя процедуру CheckCRC2, а та - CheckCRC3 и так пока не надоест.

- сделать свою виртуальную машину: 10-20 команд, add, sub, mul, div, or, xor... и интерпретатор к ним. Как вариант - сделать кусок защиты отдельным модулем на перле/питоне или лучше форте, скомпиленным в exe.

- попытаться не дать себя сдампить - заныкать точку входа в TLS-директорию и там же проинициализировать некие важные данные, и использовать одни и те же переменные/указатели под них далее в программе. Чисто на делфи такого сделать не выйдет.

"if ... then close;" никогда не делать, не хранить строки в открытом виде, требовать перезапуск для проверки ключа

Может всё-таки проще использовать протектор?

[Luke]

Как только протектор становится популярным (хорошим) его тут же ломают=)

[JTG]

Да, кстати, компонент из первого поста я уже где-то когда-то видел
http://programmersforum.ru/showpost....32&postcount=8

[Simply-Art]

Сообщение от Luke

Как только протектор становится популярным (хорошим) его тут же ломают=)

Брать открытый протектор и морфить его до неузнаваемости, запарятся искать распаковщик