Здравствуйте!

Поделитесь пожалуйста, каким образом вы защищаете AX компоненты?

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

Очевидный недостаток этого метода — зачем покупать компонент, если в конечном приложении наг скрина все равно нет? Думаю, я теряю на этом пользователей. Выводить наг скрин в этом случае тоже нельзя, так как например при регистрации новой незарегистрированной версии компонента все приложения, сделанные с использованием зарегистрированной версии начнут показывать этот наг.

Мне интересно, как другие разработчики обходят этот момент?

В общем-то Майкрософт предусмотрели стандартный способ защиты AX компонентов, но насколько я могу судить, он достаточно легко ломается. А моя защита пока что очень хорошо себя зарекомендовала, поскольку использует некоторые приемы (например, частичное шифрование кода), недоступные при стандартном способе защиты.


Заранее благодарю за ответы.

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

VA>Здравствуйте!

VA>Поделитесь пожалуйста, каким образом вы защищаете AX компоненты?

VA>Я сейчас использую такой способ:
VA>Регистрационная утилита "патчит" компонент, прошивая туда шифрованный рег. код.
VA>Компонент при инициализации проверяет этот код, если его нет и компонент находится в режиме разработки, то выводится наг скрин. Если компонент не в среде разработки (выполняется из откомпилированного приложения), то наг не выводится.


А чем не подходит такой метод: AX имеет метод с именем, скажем, RegCode и принимающий параметр в виде BSTR, например. В лицензии к компоненту пишется, что для подавления нагскрина в результирующем приложении разработчик _обязан_ вызвать этот метод с полученным от вас ключом. Таким образом, разработчик сам вкомпилит выданный вами ключ в exe, а AX будет лишь проверять этот код.

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

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


F>А чем не подходит такой метод: AX имеет метод с именем, скажем, RegCode и принимающий параметр в виде BSTR, например. В лицензии к компоненту пишется, что для подавления нагскрина в результирующем приложении разработчик _обязан_ вызвать этот метод с полученным от вас ключом. Таким образом, разработчик сам вкомпилит выданный вами ключ в exe, а AX будет лишь проверять этот код.

F>Имхо, дешево и сердито, и нет проблем с "при регистрации новой незарегистрированной версии компонента все приложения, сделанные с использованием зарегистрированной версии начнут показывать этот наг".

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

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