QC>Насколько это может повлиять на продажи?

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

QC>Поэтому возникла мысль немного усложнить защиту самостоятельно. Размазать число проверок по каждой кнопке. Создать много неидентичных функций проверок кода. Верно мыслю?

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

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

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

QC>Насколько это может повлиять на продажи?

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

QC>Поэтому возникла мысль немного усложнить защиту самостоятельно. Размазать число проверок по каждой кнопке. Создать много неидентичных функций проверок кода. Верно мыслю?

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

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

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

Предложу альтернативный вариант, к какому я пришел: можно в ключ встроить несоколько степеней проверки. А на первых порах проверять не все. По мере появления краков добавлять проверки при обновлении софта. В результате чего ключегенератор не надо менять в случае нахождения крака — обновил программу и старый крак больше не работает.

Плюсы этого решения: от не слишком настырных пользователей, ищущих краки, помогает, а настырные и так найдут крак, либо подождут, когда он появится, но будут пользоваться старой версией. Легко реализуемо и высокая устойчивость к багам. И такая штука защищает от корректного крака, правда, ненадолго.

Минусы этого решения: краки будут все равно. Пусть не сразу, но будут. Придется следить за ними и принимать решение, изменять ли проверку.