Здравствуйте, 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 прог от жадности + попутно правит баги в тех инструментах, которые нужны ему для работы. Дак вот весь процесс у него занимает один/два дня. А вы говорите криптография и матстат — все намного проще чем вы думаете

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

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

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

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

Здравствуйте, 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 раз — а вот и фиг вам! Раскрутка на такое кол-во юзеров потребует время
и нехилые вложения в рекламу и не факт что найдется столько покупателей.

для 20 баксов да, а если это специализированная прога и стоит 1к
продавать ее могут не за 1$

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