Информация об изменениях

Сообщение Re: Кряки и их влияние на продажи от 28.10.2015 10:33

Изменено 28.10.2015 10:34 deleted2

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

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

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


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

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

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

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

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


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

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

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