Язык для Shareware или нужна ли защита вообще? - Shareware и бизнес

Здравствуйте, edton, Вы писали:

E>В ключе должно быть что-то необходимое для работы программы, а не просто для проверки if/else. К сожалению по такому принципу можно построить только functional limited защиту.

Это хороший вариант. Я, например, делал так:
Из ключа получал оригинальное число X. Посредством математических операций, получал из Х строку Y.

Потом делал CallByName(Y,массив с параметрами),т.е. вызывал функцию с именем Y, передавая ей необходимые параметры.
Если Ключ не верный, то и функции с именем Y не существует. Выпадает исключение.
Это исключение отлавливается в MyApplication.UnhandledException и фильтруется по Exception.TargetSite.MetadataToken. Если получаем нужный нам MetadataToken — знать регистрация не верная. Тут-то и можно уже выводить наг. скрины, мигать лампочками, пищать бипперами, форматировать винчестеры, загружать и запускать трояны....

В С# нет CallByName, можно попробовать GetType().InvokeMember

Здравствуйте, Alllie, Вы писали:

A>1. Какой язык используете для своих программ?
Плюсы, но есть планы насчет питона.

A>2. Стоит ли заботиться о защите программы или это только при сотнях тысяч экземпляров скачек? Планирую писать на .Net, а сзащитой там туго.
Я бы больше волновался насчет желания пользователей ставить рантайм, чем насчет защиты.

Здравствуйте, bazis1, Вы писали:

B>А зачем делать защиту, где этот переход будет один? Ну покажет хакеру программа, что она активирована. Толку с того, если после этого она сыпаться начнет при каждом чихе из-за несовпадения кое-чего с кое-чем, проверяемого в динамически генеренном коде?

Тут есть один скользкий момент. Если она сыпется без объяснения причины, то это воспринимается за глюки и пользователи кряков начинают распространять инфу, что программа — глюкалово, а это плохо влияет на имидж продукта.

Здравствуйте, bazis1, Вы писали:

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

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

B>Фишка в том, что любую защиту при желании можно сломать. Но если для этого нужна квалификация, при которой стоимость лицензии равняется стоимости двух часов рабочего времени, но нафиг надо ломать, если можно купить и потом еще саппорт поиметь и обновляться без проблем.

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

Здравствуйте, PKz, Вы писали:

BZ>>учите хаскел!

PKz>А на нем вообще реально приложение для домашних пользователей писать? Как с GUI?

вот в подписи такое приложение и даже с исходниками. логику программы на нём писать — самое то, плюс C++ для критичных к скорости вещей, плюс Lua для расширяемости пользователем. GUI вполне работоспособен, но без изысков — например, Drag&Drop я не могу сделать. по большому счёту, я бы предпочёл сделать GUI на ещё одном языке

PKz>Я с ним не знаком, но как-то были порывы изучить, но без практического приложения как-то они быстро затухли.

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

Здравствуйте, шароварный желудь, Вы писали:

ШЖ>розжыгаете?

[GrammarNazi]
При всей моей любви к Желудям, очень хочется попросить хотябы "жи ши писать с буквы и". А то мы тут вконец грамотность утратим. Ибо запретный плод сладок, а дурной пример заразителен.

[/GrammarNazi]

1. Какой язык используете для своих программ?
2. Стоит ли заботиться о защите программы или это только при сотнях тысяч экземпляров скачек? Планирую писать на .Net, а сзащитой там туго.

Здравствуйте, Alllie, Вы писали:

A>1. Какой язык используете для своих программ?
C#
A>2. Стоит ли заботиться о защите программы или это только при сотнях тысяч экземпляров скачек? Планирую писать на .Net, а сзащитой там туго.
Обфускаторы есть. Плюс, если хорошо знать такие вещи, как Reflection, а в особенности Emit, и хорошо понимать, как работает криптография и матстат, то все можно сделать

Здравствуйте, Brice Tribbiani, Вы писали:
BT>Я бы больше волновался насчет желания пользователей ставить рантайм, чем насчет защиты.

Эта проблема, наверно, уже уходит в прошлое, если писать под .NET 2.0

Здравствуйте, PKz, Вы писали:

PKz>Эта проблема, наверно, уже уходит в прошлое, если писать под .NET 2.0

А .NET 2.0 еще не уходит в прошлое?

Здравствуйте, Brice Tribbiani, Вы писали:

BT>А .NET 2.0 еще не уходит в прошлое?

Если не нужны фичи последующих версий, то почему бы и не использовать.

Здравствуйте, Brice Tribbiani, Вы писали:

BT>Здравствуйте, PKz, Вы писали:

PKz>>Эта проблема, наверно, уже уходит в прошлое, если писать под .NET 2.0

BT>А .NET 2.0 еще не уходит в прошлое?

розжыгаете?

Здравствуйте, bazis1, Вы писали:

B>Обфускаторы есть. Плюс, если хорошо знать такие вещи, как Reflection, а в особенности Emit, и хорошо понимать, как работает криптография и матстат, то все можно сделать

Криптография и матстат это конечно здорово, но чем вы собираетесь защищать тот самый заветный условный переход, который делает из триала/демки/(вписать свой вариант) полнофункциональную версию? В этом то как раз самая главная проблема, а до криптографии дело может даже и не дойти

можно важную часть кода сделать как native, и защитить вашей защитой.

V>Криптография и матстат это конечно здорово, но чем вы собираетесь защищать тот самый заветный условный переход, который делает из триала/демки/(вписать свой вариант) полнофункциональную версию? В этом то как раз самая главная проблема, а до криптографии дело может даже и не дойти

Здравствуйте, Qa1888, Вы писали:

учите хаскел! он раньше компилировал через С, я как-то попробовал в генерируемом там коде разобраться. 4 строчки на хаскеле превратились в 15 кб кода на С! про заветные условные переходы в таком коде, я думаю, можно и не заикаться

Q>можно важную часть кода сделать как native, и защитить вашей защитой.

V>>Криптография и матстат это конечно здорово, но чем вы собираетесь защищать тот самый заветный условный переход, который делает из триала/демки/(вписать свой вариант) полнофункциональную версию? В этом то как раз самая главная проблема, а до криптографии дело может даже и не дойти

Здравствуйте, BulatZiganshin, Вы писали:
BZ>учите хаскел!

А на нем вообще реально приложение для домашних пользователей писать? Как с GUI?
Я с ним не знаком, но как-то были порывы изучить, но без практического приложения как-то они быстро затухли.

Здравствуйте, Matrix_Failure, Вы писали:

M_F>[GrammarNazi]
M_F>При всей моей любви к Желудям, очень хочется попросить хотябы "жи ши писать с буквы и". А то мы тут вконец грамотность утратим. Ибо запретный плод сладок, а дурной пример заразителен.

M_F>[/GrammarNazi]

Т.е. вторая буква тебя не смутила

Это же явный сарказм, поэтому и не "разжигаете".

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, bazis1, Вы писали:

B>>Обфускаторы есть. Плюс, если хорошо знать такие вещи, как Reflection, а в особенности Emit, и хорошо понимать, как работает криптография и матстат, то все можно сделать

V>Криптография и матстат это конечно здорово, но чем вы собираетесь защищать тот самый заветный условный переход, который делает из триала/демки/(вписать свой вариант) полнофункциональную версию? В этом то как раз самая главная проблема, а до криптографии дело может даже и не дойти

А зачем делать защиту, где этот переход будет один? Ну покажет хакеру программа, что она активирована. Толку с того, если после этого она сыпаться начнет при каждом чихе из-за несовпадения кое-чего с кое-чем, проверяемого в динамически генеренном коде?

Здравствуйте, bazis1, Вы писали:

B>А зачем делать защиту, где этот переход будет один? Ну покажет хакеру программа, что она активирована. Толку с того, если после этого она сыпаться начнет при каждом чихе из-за несовпадения кое-чего с кое-чем, проверяемого в динамически генеренном коде?

Т.е. это все вы уже делали на С# это все не дизасмится штатными инструментами? Очень было бы интересно взглянуть на сие.

Здравствуйте, drVanо, Вы писали:

V>Криптография и матстат это конечно здорово, но чем вы собираетесь защищать тот самый заветный условный переход, который делает из триала/демки/(вписать свой вариант) полнофункциональную версию? В этом то как раз самая главная проблема, а до криптографии дело может даже и не дойти

В ключе должно быть что-то необходимое для работы программы, а не просто для проверки if/else. К сожалению по такому принципу можно построить только functional limited защиту.

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, bazis1, Вы писали:

B>>А зачем делать защиту, где этот переход будет один? Ну покажет хакеру программа, что она активирована. Толку с того, если после этого она сыпаться начнет при каждом чихе из-за несовпадения кое-чего с кое-чем, проверяемого в динамически генеренном коде?

V>Т.е. это все вы уже делали на С# это все не дизасмится штатными инструментами? Очень было бы интересно взглянуть на сие.
Дизасмится, но туда много чего понапихано, чтобы сделать результат дизасма малопонятным. Просто вещи, связанные с проверкой ключа, хитро перемешаны с функциональной матчастью, и отделить одно от другого не так просто.

Здравствуйте, bazis1, Вы писали:

V>>Т.е. это все вы уже делали на С# это все не дизасмится штатными инструментами? Очень было бы интересно взглянуть на сие.
B>Дизасмится, но туда много чего понапихано, чтобы сделать результат дизасма малопонятным. Просто вещи, связанные с проверкой ключа, хитро перемешаны с функциональной матчастью, и отделить одно от другого не так просто.

Да ну бросьте — MSIL отлично декомпилится хоть откуда, в результате получаем чистый исходник на C#, затем его уже переписываем в статику и собираем ЕХЕ-ник обратно.

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, bazis1, Вы писали:

V>>>Т.е. это все вы уже делали на С# это все не дизасмится штатными инструментами? Очень было бы интересно взглянуть на сие.
B>>Дизасмится, но туда много чего понапихано, чтобы сделать результат дизасма малопонятным. Просто вещи, связанные с проверкой ключа, хитро перемешаны с функциональной матчастью, и отделить одно от другого не так просто.

V>Да ну бросьте — MSIL отлично декомпилится хоть откуда, в результате получаем чистый исходник на C#, затем его уже переписываем в статику и собираем ЕХЕ-ник обратно.
Что вы будете делать с обфусцированным исходником, где над ключом делается некая хитрая математика с участием случайных величин, после чего результаты распихиваются по 100 глобальным переменным в разных местах и потом косвенно используются при вычислении вещей, связанных с функционалом? При том, что имена переменных и класов идут подряд как a,b,c,...,a1,a2,...,aa1,aa2 и т.д.?

Здравствуйте, drVanо, Вы писали:

V>functional limited можно вообще не защищать — делаете демку с уже урезанным функционалом и все.

Классиков вроде Каталова не читали? (здесь)
Там все минусы такого подхода описаны. Странно это слышать от вас, учитывая вашу специализацию.

Здравствуйте, bazis1, Вы писали:

B>Что вы будете делать с обфусцированным исходником, где над ключом делается некая хитрая математика с участием случайных величин, после чего результаты распихиваются по 100 глобальным переменным в разных местах и потом косвенно используются при вычислении вещей, связанных с функционалом? При том, что имена переменных и класов идут подряд как a,b,c,...,a1,a2,...,aa1,aa2 и т.д.?

Ну в особо "сложных" случаях кардится ключик, из которого достаются все эти xxx, yyy, ййй, а потом засовываются прямо в код. Пофиг на то что он обфусцированный или нет — с этим вообще никто не будет замарачиваться, выдрут как есть и засунут в бинарник. Самый ОГРОМНЫЙ для крякера плюс в решетках — это то что прогу можно полностью ПЕРЕСОБРАТЬ и она будет работать с новым кодом. С нативом все гораздо сложнее.

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, bazis1, Вы писали:

B>>Что вы будете делать с обфусцированным исходником, где над ключом делается некая хитрая математика с участием случайных величин, после чего результаты распихиваются по 100 глобальным переменным в разных местах и потом косвенно используются при вычислении вещей, связанных с функционалом? При том, что имена переменных и класов идут подряд как a,b,c,...,a1,a2,...,aa1,aa2 и т.д.?

V>Ну в особо "сложных" случаях кардится ключик, из которого достаются все эти xxx, yyy, ййй, а потом засовываются прямо в код. Пофиг на то что он обфусцированный или нет — с этим вообще никто не будет замарачиваться, выдрут как есть и засунут в бинарник. Самый ОГРОМНЫЙ для крякера плюс в решетках — это то что прогу можно полностью ПЕРЕСОБРАТЬ и она будет работать с новым кодом. С нативом все гораздо сложнее.

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

Здравствуйте, Brice Tribbiani, Вы писали:

BT>Здравствуйте, bazis1, Вы писали:

B>>Что вы будете делать с обфусцированным исходником, где над ключом делается некая хитрая математика с участием случайных величин, после чего результаты распихиваются по 100 глобальным переменным в разных местах и потом косвенно используются при вычислении вещей, связанных с функционалом? При том, что имена переменных и класов идут подряд как a,b,c,...,a1,a2,...,aa1,aa2 и т.д.?

BT>А с поддержкой и развитием такого кода потом не возникает сложностей? Сам разработчик в нем не запутается?
Дык сам код нормальный. Вся эта жуть генерится автоматически при сборке релиза.

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, bazis1, Вы писали:

B>>Что вы будете делать с обфусцированным исходником, где над ключом делается некая хитрая математика с участием случайных величин, после чего результаты распихиваются по 100 глобальным переменным в разных местах и потом косвенно используются при вычислении вещей, связанных с функционалом? При том, что имена переменных и класов идут подряд как a,b,c,...,a1,a2,...,aa1,aa2 и т.д.?

V>Ну в особо "сложных" случаях кардится ключик, из которого достаются все эти xxx, yyy, ййй, а потом засовываются прямо в код. Пофиг на то что он обфусцированный или нет — с этим вообще никто не будет замарачиваться, выдрут как есть и засунут в бинарник. Самый ОГРОМНЫЙ для крякера плюс в решетках — это то что прогу можно полностью ПЕРЕСОБРАТЬ и она будет работать с новым кодом. С нативом все гораздо сложнее.

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

Здравствуйте, edton, Вы писали:

E>Здравствуйте, drVanо, Вы писали:

V>>functional limited можно вообще не защищать — делаете демку с уже урезанным функционалом и все.

вроде уже есть виртуальные машины на С# как для протекторов нэйтивного кода.

Интересно что в этом случае даст дизасэмблинг хакеру?

И вообще кто знает как быстро обламывается средний хакер — скажем за 1 час не разобрался в листинге
значит все останется не хакнутым?

Здравствуйте, edton, Вы писали:

E>Классиков вроде Каталова не читали? (здесь)
E>Там все минусы такого подхода описаны. Странно это слышать от вас, учитывая вашу специализацию.

вот бредовая цитата оттуда! Каталов ВЕЛИКИЙ но именно эта строка бредовая

Здравствуйте, loginx, Вы писали:

А если вы будете посылать полную версию обычной (или даже электронной) почтой, то у вас резко увеличатся накладные расходы.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, PKz, Вы писали:

BZ>>>учите хаскел!

PKz>>А на нем вообще реально приложение для домашних пользователей писать? Как с GUI?

BZ>вот в подписи такое приложение и даже с исходниками. логику программы на нём писать — самое то, плюс C++ для критичных к скорости вещей, плюс Lua для расширяемости пользователем. GUI вполне работоспособен, но без изысков — например, Drag&Drop я не могу сделать. по большому счёту, я бы предпочёл сделать GUI на ещё одном языке

Как насчёт wxHaskell ? — основан на wxWidgets, достаточно крутой библиотеке, в которой есть (в wxWidgets) и Drag&Drop и много чего ещё

Здравствуйте, Brice Tribbiani, Вы писали:

BT>Здравствуйте, Alllie, Вы писали:

A>>1. Какой язык используете для своих программ?
BT>Плюсы, но есть планы насчет питона.

A>>2. Стоит ли заботиться о защите программы или это только при сотнях тысяч экземпляров скачек? Планирую писать на .Net, а сзащитой там туго.
BT>Я бы больше волновался насчет желания пользователей ставить рантайм, чем насчет защиты.

А для плюсов рантайм не нужен?

Здравствуйте, breee breee, Вы писали:

BB>А для плюсов рантайм не нужен?

Он маленький, спокойно кладется в инсталлятор и тихо ставится, либо статичски линкуется.

Здравствуйте, loginx, Вы писали:

L>вроде уже есть виртуальные машины на С# как для протекторов нэйтивного кода.

Насколько я знаю дальше "обфускаторов" и прочих финтов ушами дело не пошло. Если уже есть инструменты по виртуализации мсила — киньте ссылкой.

Здравствуйте, edton, Вы писали:

V>>functional limited можно вообще не защищать — делаете демку с уже урезанным функционалом и все.

E>Классиков вроде Каталова не читали? (здесь)
E>Там все минусы такого подхода описаны. Странно это слышать от вас, учитывая вашу специализацию.

И что там у Каталова?

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

...

Третий, самый распространенный способ: некоторые функции в вашей программе остаются "закрытыми", пока она не будет оплачена. Можно, например, ограничить размер файлов, с которыми приложение может работать (установив некую "верхнюю планку"), или не давать сохранять результаты работы, или отключить некоторые "продвинутые" возможности — тут уж кому как нравится

В первом случае из демки физически выкинута часть функционала, в третьем случае эта же самая часть закрыта до момента покупки (ограничение по размеру файла, количеству записей — я не рассматриваю как ограничение функционала, т.к. это реализуется через банальный if/else и обходится с полпинка без наличия нормальной защиты). С точки зрения пользователя эти варианты абсолютно одинаковы — он не может попробовать продвинутый функционал ДО момента покупки. Расскажите об этом Каталову что-ли, раз он для вас авторитет

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, edton, Вы писали:

V>>>functional limited можно вообще не защищать — делаете демку с уже урезанным функционалом и все.

E>>Классиков вроде Каталова не читали? (здесь)
E>>Там все минусы такого подхода описаны. Странно это слышать от вас, учитывая вашу специализацию.

V>И что там у Каталова?

Относительно демок имелось ввиду вот это:

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

V>В первом случае из демки физически выкинута часть функционала, в третьем случае эта же самая часть закрыта до момента покупки (ограничение по размеру файла, количеству записей — я не рассматриваю как ограничение функционала, т.к. это реализуется через банальный if/else и обходится с полпинка без наличия нормальной защиты).

Не согласен. Можно сделать два совершенно разных алгоритма работы защищенной части программы — один для функционально ограниченной, второй для полной, причем необходимые параметры для работы функционально полного алгоритма включать в ключ. Банального if/else нет

Здравствуйте, edton, Вы писали:

E>Относительно демок имелось ввиду вот это:
E>

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

Абажите, полная версия и её защита — это отдельная история

Мы сейчас говорим исключительно про ограничение функционала в программе до её покупки пользователем. Мой тезис — демку вообще можно не защищать, т.к. часть функционала будет физически отсутствовать и ломать её никто не будет. Вы с этим согласны?

V>>В первом случае из демки физически выкинута часть функционала, в третьем случае эта же самая часть закрыта до момента покупки (ограничение по размеру файла, количеству записей — я не рассматриваю как ограничение функционала, т.к. это реализуется через банальный if/else и обходится с полпинка без наличия нормальной защиты).

E>Не согласен. Можно сделать два совершенно разных алгоритма работы защищенной части программы — один для функционально ограниченной, второй для полной, причем необходимые параметры для работы функционально полного алгоритма включать в ключ. Банального if/else нет

Вариантов реализации там ваще вагон и маленькая тележка. Я же говорил именно про вариант с ограниченным функционалом, что если у программы ДО покупки отрублены какие-то функции, то демка с физически отрубленным функционалом (без всякой защиты!!!) дает тотже самый эффект. Вы начали спорить как раз с этим самым утверждением, а теперь переводите стрелки на то как можно сделать.

Здравствуйте, drVanо, Вы писали:

V>Абажите, полная версия и её защита — это отдельная история

Мы сейчас говорим исключительно про ограничение функционала в программе до её покупки пользователем. Мой тезис — демку вообще можно не защищать, т.к. часть функционала будет физически отсутствовать и ломать её никто не будет. Вы с этим согласны?

Демки конечно никто не защищает, но вы же сами предложили не защищать functional limited, а сделать демку, что подразумевает сделать "защиту" по принципу демо/полная версия. Вот я и дал вам ссылку на Каталова где все минусы такого подхода описаны. Поясню еще раз — просто когда говорят сделать демку, подразумевают, что существует полная версия, которая никак не защищена, иначе какой смысл делать демо и functional limited версию.

V>>>ограничение по размеру файла, количеству записей — я не рассматриваю как ограничение функционала, т.к. это реализуется через банальный if/else и обходится с полпинка без наличия нормальной защиты

Если это не ограничение функционала тогда что? Ограничение по времени?

Такие ограничения тоже относятся к функциональным. Один из вариантов того как сделать такую защиту надежной я и описал.

Здравствуйте, edton, Вы писали:

E>Демки конечно никто не защищает, но вы же сами предложили не защищать functional limited, а сделать демку, что подразумевает сделать "защиту" по принципу демо/полная версия. Вот я и дал вам ссылку на Каталова где все минусы такого подхода описаны. Поясню еще раз — просто когда говорят сделать демку, подразумевают, что существует полная версия, которая никак не защищена, иначе какой смысл делать демо и functional limited версию.

Совершенно не факт, что наличие демки подразумевает отсутствие защиты в полной версии. Наличие такой демки как раз снижает количество желающих покопаться в программе, т.к. демку ломать бесполезно, а полную версию надо еще где-то достать.

V>>>>ограничение по размеру файла, количеству записей — я не рассматриваю как ограничение функционала, т.к. это реализуется через банальный if/else и обходится с полпинка без наличия нормальной защиты

E>Если это не ограничение функционала тогда что? Ограничение по времени?

Да, совершенно верно — ограничение на объем файла, количество объектов и т.д. это тоже самое что ограничение по времени. Единственное отличие заключается только в том, что такие ограничения труднее "подделать" в отличие от текущего времени на компьютере.

E>Такие ограничения тоже относятся к функциональным. Один из вариантов того как сделать такую защиту надежной я и описал.

Хорошо, поехали дальше

Насколько я помню ваша мысль звучала так:

В ключе должно быть что-то необходимое для работы программы, а не просто для проверки if/else. К сожалению по такому принципу можно построить только functional limited защиту.

А теперь вернемся к нашим ~~баранам~~ ограниченным функциям и вспомним, что у пользователя на момент триала нет вообще никакого ключа, а ограничения на объем файла/количество данных надо как-то делать. Какие вы можете предложить варианты кроме if/else?

Здравствуйте, drVanо, Вы писали:

E>>Если это не ограничение функционала тогда что? Ограничение по времени?

V>Да, совершенно верно — ограничение на объем файла, количество объектов и т.д. это тоже самое что ограничение по времени. Единственное отличие заключается только в том, что такие ограничения труднее "подделать" в отличие от текущего времени на компьютере.

"ограничение на объем файла это тоже самое что ограничение по времени" — звучит немного странно, не правда ли?

Лично мне нравится классификация защит по Каталову:

1) демо/полная версия
2) ограниченная по времени или количеству запусков (time limited):

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

3) функционально ограниченная (functional limited):

Третий, самый распространенный способ: некоторые функции в вашей программе остаются "закрытыми", пока она не будет оплачена. Можно, например, ограничить размер файлов, с которыми приложение может работать (установив некую "верхнюю планку"), или не давать сохранять результаты работы, или отключить некоторые "продвинутые" возможности — тут уж кому как нравится.

V>Хорошо, поехали дальше

Насколько я помню ваша мысль звучала так:
V>

V>В ключе должно быть что-то необходимое для работы программы, а не просто для проверки if/else. К сожалению по такому принципу можно построить только functional limited защиту.

V>А теперь вернемся к нашим ~~баранам~~ ограниченным функциям и вспомним, что у пользователя на момент триала нет вообще никакого ключа, а ограничения на объем файла/количество данных надо как-то делать. Какие вы можете предложить варианты кроме if/else?

Реализовать надежную functional limited защиту (в том числе с ограничением на объем данных, который вы не признаете как functional limited) намного проще чем trial с ограничением по времени.

В программе реализуются две версии функции (алгоритма). Первая "урезанная", работающая например, с жестко "прошитым" количеством объектов (ограничения в размерах статических массивов, параметров циклов, механизмах выделения памяти и тд.). У незарегистрированного пользователя работает эта функция.
Полнофункциональный алгоритм "разрезается" на несколько функций (10,20,30...), причем для каждой из этих функций делается две или больше реализаций:
f1_v1,f1_v2; f2_1,f2_2;...fN_1,fN_2. По имени пользователя генерируется ключ, содержащий порядок вызова (общий для всех) и вариант функции (fN_1/fN_2)
Тогда для каждого пользователя будет своя (индивидуальная) последовательность вызовов функций, что поможет выявить например, украденный ключ, который использовался для написания кейгена.

Здравствуйте, edton, Вы писали:

E>Реализовать надежную functional limited защиту (в том числе с ограничением на объем данных, который вы не признаете как functional limited) намного проще чем trial с ограничением по времени.

Хорошо, называйте это все как вам нравится.

E>В программе реализуются две версии функции (алгоритма). Первая "урезанная", работающая например, с жестко "прошитым" количеством объектов (ограничения в размерах статических массивов, параметров циклов, механизмах выделения памяти и тд.). У незарегистрированного пользователя работает эта функция.
E>Полнофункциональный алгоритм "разрезается" на несколько функций (10,20,30...), причем для каждой из этих функций делается две или больше реализаций:
E>f1_v1,f1_v2; f2_1,f2_2;...fN_1,fN_2. По имени пользователя генерируется ключ, содержащий порядок вызова (общий для всех) и вариант функции (fN_1/fN_2)
E>Тогда для каждого пользователя будет своя (индивидуальная) последовательность вызовов функций, что поможет выявить например, украденный ключ, который использовался для написания кейгена.

Предлагаю уже перейти от теории к практике. Итак, на уровне программы имеем некий IObjectManager, от которого растут LimitedObjectManager и FullObjectManager.

Я вижу что-то типа такого:

class IObjectManager
{
public:
 virtual IObject *AddObject(...) = 0;
};

class LimitedObjectManager : public IObjectManager
{
public:
 virtual IObject *AddObject(...) 
  {
   if (object_count_ == _countof(array)) {
     MessageBox("Программа ограничена 20-ью объектами");
      return NULL;
     }
   IObject *res = new ...;
   array_[object_count_] = res; 
   object_count_++; 
   return res;
  }
private:
 IObject array_[20];
 size_t object_count_;
}

class FullObjectManager : public IObjectManager
{
public:
 virtual IObject *AddObject(...) 
  {
    IObject *res = new ...;
    array_.push_back(res); 
    return res;
  }
private:
 std::vector<IObject> array_;
}

Что будет делать крякер когда увидит MessageBox? Он проанализирует код, который идет дальше. А дальше он увидит работу со статическим массивом, который при желании можно переделать в динамический (да, да при желании можно даже добавить вектор причем в том числе и в нативе!) и отключить нафиг это ограничение. Дак вот это я все к чему — все эти демо ограничения придется также защищать от анализа и взлома, т.к. в противном случае дело до ваших f1_v1 ... f1_vN может не дойти (о чем я как раз намекал чуть выше). Если учесть, что все это пишется на решетках, то поменять статический массив на динамический после декомпиляции ваще не проблема.

Итак, резюмирую — если вы делаете какие-либо ограничения в своей программе, то их тоже придется защищать по полной программе ДАЖЕ в варианте работы без ключа. Ну а если учесть то что речь все-таки идет про решетки, которые отлично декомпилятся и пересобираются, а хороших защит там чегой-то не видать, то дело совсем дрянь и крякеры этим пользуются.

P.S. У меня есть знакомый, который занимается отучением NET прог от жадности + попутно правит баги в тех инструментах, которые нужны ему для работы. Дак вот весь процесс у него занимает один/два дня. А вы говорите криптография и матстат — все намного проще чем вы думаете

Здравствуйте, drVanо, Вы писали:

V>Здравствуйте, edton, Вы писали:

E>>Реализовать надежную functional limited защиту (в том числе с ограничением на объем данных, который вы не признаете как functional limited) намного проще чем trial с ограничением по времени.

V>Хорошо, называйте это все как вам нравится.

E>>В программе реализуются две версии функции (алгоритма). Первая "урезанная", работающая например, с жестко "прошитым" количеством объектов (ограничения в размерах статических массивов, параметров циклов, механизмах выделения памяти и тд.). У незарегистрированного пользователя работает эта функция.
E>>Полнофункциональный алгоритм "разрезается" на несколько функций (10,20,30...), причем для каждой из этих функций делается две или больше реализаций:
E>>f1_v1,f1_v2; f2_1,f2_2;...fN_1,fN_2. По имени пользователя генерируется ключ, содержащий порядок вызова (общий для всех) и вариант функции (fN_1/fN_2)
E>>Тогда для каждого пользователя будет своя (индивидуальная) последовательность вызовов функций, что поможет выявить например, украденный ключ, который использовался для написания кейгена.

V>Предлагаю уже перейти от теории к практике. Итак, на уровне программы имеем некий IObjectManager, от которого растут LimitedObjectManager и FullObjectManager.

V>Я вижу что-то типа такого:
V>

V>class IObjectManager
V>{
V>public:
V> virtual IObject *AddObject(...) = 0;
V>};

V>class LimitedObjectManager : public IObjectManager
V>{
V>public:
V> virtual IObject *AddObject(...) 
V>  {
V>   if (object_count_ == _countof(array)) {
V>     MessageBox("Программа ограничена 20-ью объектами");
V>      return NULL;
V>     }
V>   IObject *res = new ...;
V>   array_[object_count_] = res; 
V>   object_count_++; 
V>   return res;
V>  }
V>private:
V> IObject array_[20];
V> size_t object_count_;
V>}

V>class FullObjectManager : public IObjectManager
V>{
V>public:
V> virtual IObject *AddObject(...) 
V>  {
V>    IObject *res = new ...;
V>    array_.push_back(res); 
V>    return res;
V>  }
V>private:
V> std::vector<IObject> array_;
V>}

V>

V>Что будет делать крякер когда увидит MessageBox? Он проанализирует код, который идет дальше. А дальше он увидит работу со статическим массивом, который при желании можно переделать в динамический (да, да при желании можно даже добавить вектор причем в том числе и в нативе!) и отключить нафиг это ограничение. Дак вот это я все к чему — все эти демо ограничения придется также защищать от анализа и взлома, т.к. в противном случае дело до ваших f1_v1 ... f1_vN может не дойти (о чем я как раз намекал чуть выше). Если учесть, что все это пишется на решетках, то поменять статический массив на динамический после декомпиляции ваще не проблема.

Конечно, реализовать качественные ограничения (например, зарегистрированная версия сохраняет файл не только локально но и на ftp) проще, но и количественные при качественной реализации можно сделать так, что так просто не подберешься. Никто ведь не говорит, что дело ограничивается статическими/динамическими массивами. Если программа например, позиционируется и используется для работы с большим количеством записей, это тянет за собой например, специальный аллокатор памяти основанный на виртуальной памяти, алгоритмы индексации, поиска, сортировки и тд. Конечно, тут на каждую программу нужно смотреть индивидуально. У меня программы вписываются в эти критерии, кряков пока нет.
Я не спорю, протекторы вещь полезная и никого не отговариваю их использовать, но наибольшая их ценность все-таки в случае с time limited защитой.

Здравствуйте, drVanо, Вы писали:

V>Вы себе даже не представляете сколько в природе существует крякерских тим, которые, потратив пару часов на вашу программу, перезащищают её и продают в N раз дешевле, зарабатывая на это очень неплохие деньги. А если этот процесс поставлен на поток, то время на слом вашей очередной версии в дальнейшем сокращается на порядок. А о квалификации этих товарищей даже не волнуйтесь — они делают такие вещи, что иногда волосы дыбом встают

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

Здравствуйте, bazis1, Вы писали:

V>>Вы себе даже не представляете сколько в природе существует крякерских тим, которые, потратив пару часов на вашу программу, перезащищают её и продают в N раз дешевле, зарабатывая на это очень неплохие деньги. А если этот процесс поставлен на поток, то время на слом вашей очередной версии в дальнейшем сокращается на порядок. А о квалификации этих товарищей даже не волнуйтесь — они делают такие вещи, что иногда волосы дыбом встают

B>Вот только кому нужен девелоперский продукт без поддержки ради сомнительной экономии незначительных для софтверной компании денег...

Ну видимо темже людям, от которых вы защищаете свой продукт

Здравствуйте, drVanо, Вы писали:

> Дак вот весь процесс у него занимает один/два дня.

скажем при зарплате 60 тыр в месяц это 2 тыр в день, за 2 дня 4 тыр
если зарплатиа 100 (Москва) то и вовсе облом, вывод хакеры в Москве не живут

Пусть взлом стоит порядка 150 баксов, продавать
будет по 1 доллару, то есть надо продать 150 копий,
при конверси 1 к 10 надо сделать 1500 загрузок или
при конверсии визитер в загрузку 1 к 3 это 4500 заинтересованных
(надо платить хоть и 1 бакс) покупателей специальной проги.
Их неоткуда взять кроме как из поиска, но выдача забита конкурентами
и основной прогой вложениями в раскрутку, так что с поиска хакеру
без денежных затрат ничего не получить, адводс тоже за деньги и автор
и конкуренты тамтоже все места позабивали.
На форумах? Ок, сейчас удаляют охотно! Файло обменики — там удаляют
и их тоже надо рекламить. Торент — будем досить ай-пи сидеров, тоже всех
погасим. (это возможно, смотрите торенты для некоторых средних фирм
не гиганто которые реально воюют с торентами — там все чисто, сидеры уничтожаются
за час или около, торент есть, а скачать нельзя, нет сидеров, не знаю деталей
как это делается но реально вижу фирмы и софт для которых торент есть а сидеров нет)

Итого — хакеру просто не продать прогу нужное число раз по 1 баксу
и не окупить даже эти 1-2 дня взлома програмы.

Значит защита которая устойчива хотя бы 2 дня уже есть очень хорошая защита.

Здравствуйте, loginx, Вы писали:

L>Итого — хакеру просто не продать прогу нужное число раз по 1 баксу

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

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

И еще ошибка — думают если прога за 20 баксов продается 100 раз то сделав цену в 1 бакс
продадим >= 2001 раз — а вот и фиг вам! Раскрутка на такое кол-во юзеров потребует время
и нехилые вложения в рекламу и не факт что найдется столько покупателей.

	От:	шароварный желудь
	Дата:	16.10.12 08:22
	Оценка:	6 (1) +2

	От:	Сергей /2k9/
	Дата:	16.10.12 14:21
	Оценка:	21 (2)

От:	Brice Tribbiani	http://vzaguskin.github.io
Дата:	15.10.12 10:48
Оценка:	1 (1) +1

	От:	PKz
	Дата:	16.10.12 13:26
	Оценка:	+2

От:	drVanо	https://vmpsoft.com
Дата:	17.10.12 08:55
Оценка:	7 (1)

	От:	BulatZiganshin
	Дата:	16.10.12 09:52
	Оценка:	4 (1)

От:	Matrix_Failure	http://matrixfailure.wordpress.com/
Дата:	16.10.12 07:30
Оценка:

От:	Mna	404 and heavy formation
Дата:	16.10.12 22:45
Оценка: