Сообщение Re: Кряки и их влияние на продажи от 28.10.2015 10:33
Изменено 28.10.2015 10:34 deleted2
QC>Насколько это может повлиять на продажи?
В моем случае ужесточение защиты не привело к видимому изменению продаж. Но в первые годы работало как маркетинговый инструмент распространения программы по широким массам. Т.е. работало по принципу сарафана и рекламных баннеров — пользователи взломанных программ писали о программах на форумах, блогах и т.п., делали обзоры. Правда, одновременно и распространяли краки. Это дало некий эффект знания на слуху у других потенциальных пользователей.
QC>Поэтому возникла мысль немного усложнить защиту самостоятельно. Размазать число проверок по каждой кнопке. Создать много неидентичных функций проверок кода. Верно мыслю?
Верно, если проверка будет делаться в разное время и будет выдавать вердикт нелинейно, чтобы кракер даже не понял, что что-то пропустил. Иначе он просто несколько раз прогонит программу и найдет все места проверок.
Это приведет к тому, что крак не будет работать и пользователю будет сложно найти работающий крак, так что он просто попытки поиска бросит. Правда, существуют специальные сайты, где пользователи краков следят за этим и пинают кракописателей. Так что, насколько это оправданно, сложно сказать. Есть и плюсы и минусы.
У меня, кстати, половина всех найденных багов была связана именно с тем, что техническая сложность проверки ключа сказывалась на разработке. Все в памяти ужержать я лично не смог, что приводило иногда к багам.
В моем случае ужесточение защиты не привело к видимому изменению продаж. Но в первые годы работало как маркетинговый инструмент распространения программы по широким массам. Т.е. работало по принципу сарафана и рекламных баннеров — пользователи взломанных программ писали о программах на форумах, блогах и т.п., делали обзоры. Правда, одновременно и распространяли краки. Это дало некий эффект знания на слуху у других потенциальных пользователей.
QC>Поэтому возникла мысль немного усложнить защиту самостоятельно. Размазать число проверок по каждой кнопке. Создать много неидентичных функций проверок кода. Верно мыслю?
Верно, если проверка будет делаться в разное время и будет выдавать вердикт нелинейно, чтобы кракер даже не понял, что что-то пропустил. Иначе он просто несколько раз прогонит программу и найдет все места проверок.
Это приведет к тому, что крак не будет работать и пользователю будет сложно найти работающий крак, так что он просто попытки поиска бросит. Правда, существуют специальные сайты, где пользователи краков следят за этим и пинают кракописателей. Так что, насколько это оправданно, сложно сказать. Есть и плюсы и минусы.
У меня, кстати, половина всех найденных багов была связана именно с тем, что техническая сложность проверки ключа сказывалась на разработке. Все в памяти ужержать я лично не смог, что приводило иногда к багам.
QC>Насколько это может повлиять на продажи?
В моем случае ужесточение защиты не привело к видимому изменению продаж. Но в первые годы слабая кракоустойчивость работала как маркетинговый инструмент распространения программы по широким массам. Т.е. работало по принципу сарафана и рекламных баннеров — пользователи взломанных программ писали о программах на форумах, блогах и т.п., делали обзоры. Правда, одновременно и распространяли краки. Это дало некий эффект знания на слуху у других потенциальных пользователей.
QC>Поэтому возникла мысль немного усложнить защиту самостоятельно. Размазать число проверок по каждой кнопке. Создать много неидентичных функций проверок кода. Верно мыслю?
Верно, если проверка будет делаться в разное время и будет выдавать вердикт нелинейно, чтобы кракер даже не понял, что что-то пропустил. Иначе он просто несколько раз прогонит программу и найдет все места проверок.
Это приведет к тому, что крак не будет работать и пользователю будет сложно найти работающий крак, так что он просто попытки поиска бросит. Правда, существуют специальные сайты, где пользователи краков следят за этим и пинают кракописателей. Так что, насколько это оправданно, сложно сказать. Есть и плюсы и минусы.
У меня, кстати, половина всех найденных багов была связана именно с тем, что техническая сложность проверки ключа сказывалась на разработке. Все в памяти ужержать я лично не смог, что приводило иногда к багам.
В моем случае ужесточение защиты не привело к видимому изменению продаж. Но в первые годы слабая кракоустойчивость работала как маркетинговый инструмент распространения программы по широким массам. Т.е. работало по принципу сарафана и рекламных баннеров — пользователи взломанных программ писали о программах на форумах, блогах и т.п., делали обзоры. Правда, одновременно и распространяли краки. Это дало некий эффект знания на слуху у других потенциальных пользователей.
QC>Поэтому возникла мысль немного усложнить защиту самостоятельно. Размазать число проверок по каждой кнопке. Создать много неидентичных функций проверок кода. Верно мыслю?
Верно, если проверка будет делаться в разное время и будет выдавать вердикт нелинейно, чтобы кракер даже не понял, что что-то пропустил. Иначе он просто несколько раз прогонит программу и найдет все места проверок.
Это приведет к тому, что крак не будет работать и пользователю будет сложно найти работающий крак, так что он просто попытки поиска бросит. Правда, существуют специальные сайты, где пользователи краков следят за этим и пинают кракописателей. Так что, насколько это оправданно, сложно сказать. Есть и плюсы и минусы.
У меня, кстати, половина всех найденных багов была связана именно с тем, что техническая сложность проверки ключа сказывалась на разработке. Все в памяти ужержать я лично не смог, что приводило иногда к багам.