Предположим имеется некое web приложение, написанное на Java!
Подскажите, каким образом можно защитить его от несанционирования
копирования, реализовать trial версию (чтоб через месяц без активации
перестало работать), ограничить количество лицензий по подключению
пользователей.
Кто как решает этот вопрос?

Здравствуйте, Бердник Антон, Вы писали:

БА>Предположим имеется некое web приложение, написанное на Java!
БА>Подскажите, каким образом можно защитить его от несанционирования
БА>копирования, реализовать trial версию (чтоб через месяц без активации
БА>перестало работать), ограничить количество лицензий по подключению
БА>пользователей.
БА>Кто как решает этот вопрос?

Текстовый ключ на RSA или USB ключ, плюс скремблирование по самое ни-гу-гу. И это всеравно не панацея.

Здравствуйте, Бердник Антон, Вы писали:

БА>Предположим имеется некое web приложение, написанное на Java!
БА>Подскажите, каким образом можно защитить его от несанционирования
БА>копирования, реализовать trial версию (чтоб через месяц без активации
БА>перестало работать), ограничить количество лицензий по подключению
БА>пользователей.
БА>Кто как решает этот вопрос?

Как насчет хостить это приложение у себя?

Здравствуйте, Бердник Антон, Вы писали:

БА>Предположим имеется некое web приложение, написанное на Java!
БА>Подскажите, каким образом можно защитить его от несанционирования
БА>копирования, реализовать trial версию (чтоб через месяц без активации
БА>перестало работать), ограничить количество лицензий по подключению
БА>пользователей.
БА>Кто как решает этот вопрос?

IMHO нативная либа + JNI + HASP должны как-то решить вопрос.

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

T>IMHO нативная либа + JNI + HASP должны как-то решить вопрос.
Нативная либа просто выкусывается. Единственное что может затруднить этот процесс — распаковка либы из какогонить спрятанного внутри jar архива, распаковка в хрен знает какую директорию и затем ее динамическая подгрузка, при этом вызов System.loadLibrary надо заврапить на Reflection и закодировать все строковые константы.

А что такое HASP?

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

A>Нативная либа просто выкусывается. Единственное что может затруднить этот процесс — распаковка либы из какогонить спрятанного внутри jar архива, распаковка в хрен знает какую директорию и затем ее динамическая подгрузка, при этом вызов System.loadLibrary надо заврапить на Reflection и закодировать все строковые константы.

Ну, так скажем, это тоже легко обходиться, сохранением исходого архива.

A>А что такое HASP?

Физический ключ, подключается к LPT чаще всего.

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

По поводу количества подключений --- легко делается лиснером и статическим счетчиком.

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

M>Ну, так скажем, это тоже легко обходиться, сохранением исходого архива.

Ну я так сделал — пока мне нереально это обойти самому даже. Даже зная где и что лежит.
Там так. DLLка зазипена и зарыта. Строки енкодятся и в явном виде не храняться. Передподгрузкой либы она распаковывается на диск, проверяется ее md5 хеш, загружается через специальный ClassLoader. Все критически отлавливаемые места вызовов системных методов (как System.loadLibrary) врапятся в соответствующие враперы, где строки также заенкодены и в явном виде не лежат, через эти врапперы и через Reflection делается вызов на System.loadLibrary.

M>Физический ключ, подключается к LPT чаще всего.

Ясно. Я меня такой на USB

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

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

M>>Ну, так скажем, это тоже легко обходиться, сохранением исходого архива.

A>Ну я так сделал — пока мне нереально это обойти самому даже. Даже зная где и что лежит.
A>Там так. DLLка зазипена и зарыта. Строки енкодятся и в явном виде не храняться. Передподгрузкой либы она распаковывается на диск, проверяется ее md5 хеш, загружается через специальный ClassLoader. Все критически отлавливаемые места вызовов системных методов (как System.loadLibrary) врапятся в соответствующие враперы, где строки также заенкодены и в явном виде не лежат, через эти врапперы и через Reflection делается вызов на System.loadLibrary.

А есть ли примеры или исходники этого способа? Вопрос мне тоже интересен!

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

usa>А есть ли примеры или исходники этого способа? Вопрос мне тоже интересен!

Открытых нет. NDA.
Могу рассказать как сделать подобную. Хотя вроде и так все понятно

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

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

usa>>А есть ли примеры или исходники этого способа? Вопрос мне тоже интересен!

A>Открытых нет. NDA.
A>Могу рассказать как сделать подобную. Хотя вроде и так все понятно
Да вроде понятно, но как обычно копать прийдется хорошо

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

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

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

usa>>>А есть ли примеры или исходники этого способа? Вопрос мне тоже интересен!

A>>Открытых нет. NDA.
A>>Могу рассказать как сделать подобную. Хотя вроде и так все понятно
usa>Да вроде понятно, но как обычно копать прийдется хорошо
Единственная засада тут — это динамическая загрузка DLL. Решается путем создания своего ClassLoader и имплементации в нем метода findLibrary

Здравсвуйте, aefimov!
> Ну я так сделал — пока мне нереально это обойти самому даже. Даже зная
> где и что лежит.
> Там так. DLLка зазипена и зарыта. Строки енкодятся и в явном виде не
> храняться. Передподгрузкой либы она распаковывается на диск, проверяется
> ее md5 хеш, загружается через специальный ClassLoader. Все критически
> отлавливаемые места вызовов системных методов (как System.loadLibrary)
> врапятся в соответствующие враперы, где строки также заенкодены и в
> явном виде не лежат, через эти врапперы и через Reflection делается
> вызов на System.loadLibrary.
Боюсь вас разочаровать, но данный метод далек от надежности. Допустим
крекер хочет взломать эту защиту.

Известно: приложение использует аппаратный ключ -> грузит нативную
библиотеку для связи с драйвером ключа. Не найдя явного вызова
#loadLibrary в коде, запускаем приложние под java и native отладчиками
одновременно. Ставим точку останова на kernel32.dll#LoadLibrary() и
смотрим какие библиотеки загружаются. Когда в качестве параметра
появляется ваша dll, исправляем контекст так, чтобы загрузка не удалась.

При помощи java-debug-ера ловим исключение и смотрим стек вызовов. Точка
загрузки библиотеки известна. Если распаковка идет рядом, то мы уже и
нашли место хранения библиотеки. Кроме то, в этом месте мы можем просто
поправить ClassLoader, чтобы он всегда загружал нашу dll, вместо
распакованной. Упс...

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

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

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

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

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

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

Понятно что сломать можно все. В моем случае, я просто пытаюсь этот процесс максимально осложнить.
Да, ксати, поправить Java код не получится. Ибо он декомпилиться в некомпилируемый код. Можно поправить bytecode, но нужно знать где и как.
Расчет у меня идет именно на то, что просто плюнут с этим возится.

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

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

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

C>Что-то я вот не понял, а почему не зашифровать код части приложения (необходимой для работы), а ключ хранить отдельно. Без ключа можно дешифровать и дизассемблировать до старости, все без толку.
C>В этом случае все упрется в копирование аппаратного ключа.

Потому-что просто заменяется это место на другое, которое слушает ключ и дампит рассшифрованную информацию. Т.е. это ламается легко с Eval ключами.

C>Что-то я вот не понял, а почему не зашифровать код части приложения (необходимой для работы), а ключ хранить отдельно. Без ключа можно дешифровать и дизассемблировать до старости, все без толку.
C>В этом случае все упрется в копирование аппаратного ключа.

Потому что чтобы программа исполнялась, её придётся расшифровать.
Для этого придётся где-то получить этот ключ.
Вот надо взять одну легальную версию и поставить бряк сразу за тем местом где получили ключ.
После этого этот ключ можно посмотреть и захардкодить прям там же и нигде больше не получать.

aefimov wrote:
> С запиванием куска в ключ весчь хорошая, конечно, только смысла в ней
> ноль. Если вы выкусили этот ключ, то кусок как-бы уже не нужен особо.
>

Вы не совсем поняли. В ключ не пишется код, он там на ключе и
выполняется. Например это сделано в Guardant-ах.

> Понятно что сломать можно все. В моем случае, я просто пытаюсь этот
> процесс максимально осложнить.
> Да, ксати, поправить Java код не получится. Ибо он декомпилиться в
> некомпилируемый код. Можно поправить bytecode, но нужно знать где и как.

Это малость

> Расчет у меня идет именно на то, что просто плюнут с этим возится.

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

Теперь прикинем: продукт серийный, стоит он, например, 150$ (я исхожу из
предположения, что цена ключа составляет малую долю). Это около 2-х дней
работы квалифицированного программера. Сломать описанную защиту можно. Я
бы даже сказал, что на это уйдет часа 4 максимум. То есть кому будет
нужно, сломать, он сломает.

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

Посмотрите хотя бы на 1С. Титанические усилия на защиту, судебное
приследование крэкеров. А что в итоге? Креки выходят почти с
регулярностью релизов. Все защищенные материалы кочуют по Сети. Более
того, в некоторых организациях, владеющих 1С официально, используют
креки, ибо HASP-ы не дружат с оборудованием. И уходить от нелицензионки
стали только тогда, когда за нее можно стало схлопотать по голове.

Почему гиганты софтосроения типа Adobe, Microsoft, Corel и др. не
создают сложных защит? У них то ресурсов предостаточно, чтобы создать
весьма сложные для взлома системы. Однако из лидеров рынка только у
Skype есть сколько-нибудь сложная защита. И она не защищает от
копирования, она препятствует reverse-engineering-у, защищает патенты.

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

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

G>aefimov wrote:
>> С запиванием куска в ключ весчь хорошая, конечно, только смысла в ней
>> ноль. Если вы выкусили этот ключ, то кусок как-бы уже не нужен особо.
>>

G>Вы не совсем поняли. В ключ не пишется код, он там на ключе и
G>выполняется. Например это сделано в Guardant-ах.

>> Понятно что сломать можно все. В моем случае, я просто пытаюсь этот
>> процесс максимально осложнить.
>> Да, ксати, поправить Java код не получится. Ибо он декомпилиться в
>> некомпилируемый код. Можно поправить bytecode, но нужно знать где и как.

G>Это малость

>> Расчет у меня идет именно на то, что просто плюнут с этим возится.

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

G>Теперь прикинем: продукт серийный, стоит он, например, 150$ (я исхожу из
G>предположения, что цена ключа составляет малую долю). Это около 2-х дней
G>работы квалифицированного программера. Сломать описанную защиту можно. Я
G>бы даже сказал, что на это уйдет часа 4 максимум. То есть кому будет
G>нужно, сломать, он сломает.

G>Вы же я так думаю, потратили ни один день на написание этой усилинной
G>системы безопасности, увеличили стоимость продукта (как минимум на
G>стоимость ключа) и получили дополнительные проблемы с саппортом, так как
G>аппаратные ключи штука капризная, да и увеличение сложности приложения
G>ни к чему хорошему не ведет. Эти усилия, потраченные на проработку
G>функционала, окупили бы потери на пиратке.

G>Посмотрите хотя бы на 1С. Титанические усилия на защиту, судебное
G>приследование крэкеров. А что в итоге? Креки выходят почти с
G>регулярностью релизов. Все защищенные материалы кочуют по Сети. Более
G>того, в некоторых организациях, владеющих 1С официально, используют
G>креки, ибо HASP-ы не дружат с оборудованием. И уходить от нелицензионки
G> стали только тогда, когда за нее можно стало схлопотать по голове.

G>Почему гиганты софтосроения типа Adobe, Microsoft, Corel и др. не
G>создают сложных защит? У них то ресурсов предостаточно, чтобы создать
G>весьма сложные для взлома системы. Однако из лидеров рынка только у
G>Skype есть сколько-нибудь сложная защита. И она не защищает от
G>копирования, она препятствует reverse-engineering-у, защищает патенты.

G>Я не говорю, что защищать софт не нужно. Нужно, но в меру. Традиционного
G> серийного номера и обфускации вполне достаточно. Рядовой пользователь
G>не сломает, и то ладно. Подойдите к своей системе критически. Вы уверены
G>что ваши усложнения того стоят?

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

G>Посмотрите хотя бы на 1С. Титанические усилия на защиту, судебное
G>приследование крэкеров. А что в итоге? Креки выходят почти с
G>регулярностью релизов. Все защищенные материалы кочуют по Сети. Более
G>того, в некоторых организациях, владеющих 1С официально, используют
G>креки, ибо HASP-ы не дружат с оборудованием. И уходить от нелицензионки
G> стали только тогда, когда за нее можно стало схлопотать по голове.

G>Почему гиганты софтосроения типа Adobe, Microsoft, Corel и др. не
G>создают сложных защит? У них то ресурсов предостаточно, чтобы создать
G>весьма сложные для взлома системы. Однако из лидеров рынка только у
G>Skype есть сколько-нибудь сложная защита. И она не защищает от
G>копирования, она препятствует reverse-engineering-у, защищает патенты.

G>Я не говорю, что защищать софт не нужно. Нужно, но в меру. Традиционного
G> серийного номера и обфускации вполне достаточно. Рядовой пользователь
G>не сломает, и то ладно. Подойдите к своей системе критически. Вы уверены
G>что ваши усложнения того стоят?

Почему тогда Cronos никто взломать не может если это так просто? У них
даже аппаратного HASP-а нет