Как предотвратить пиратство для java-приложения webstart

Question

У меня есть это приложение java swing, которое я намерен продавать через Интернет.На данный момент я склоняюсь к развертыванию приложения с использованием java webstart.Продукт будет лицензирован для использования пользователем программы только на одном компьютере одновременно.Я обеспокоен пиратством в этой модели.Я хотел бы установить некоторые функции безопасности для обеспечения соблюдения лицензионной модели.Цель состоит в том, чтобы, по крайней мере, затруднить лицензированному пользователю копирование установленного продукта, включая лицензионный ключ, нелицензированным пользователям.Вот варианты, которые я сейчас рассматриваю:

1. Заставьте пользователя проходить аутентификацию на материнском корабле с помощью имени пользователя / пароля при каждом запуске программы.

2. Просто установите лицензионный ключ где-нибудь (скрытый?) на КОМПЬЮТЕР пользователя после того, как он зарегистрируется и оплатит.Во время выполнения убедитесь, что установлен действительный лицензионный ключ.

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

Одна из проблем здесь заключается в том, что после установки этого приложения приложению не требуется во время выполнения связываться с материнским сервером, кроме проверки обновлений приложения с помощью java webstart.Все, что делает приложение, оно делает локально и отображает результаты пользователю с помощью swing.Таким образом, любое решение, связанное с материнским кораблем, в основном означало бы создание серверной инфраструктуры с единственной целью проверки лицензии.

Я предполагаю, что я ищу что-то основанное на Java, что было бы хотя бы в некоторой степени безопасным, простым в развертывании и не доставляло бы неудобств пользователю.Какой подход к обеспечению безопасности / лицензированию вы использовали?

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

Answer 1

Я бы сказал, что (2) - ваш лучший выбор.Вы уже отговорили себя от (1) и (3), которые могут вызвать проблемы, если пользователь, скажем, купит новую материнскую плату.(2) не будет большой защитой от пользователя, разбирающегося в компьютерах, но и не должно вызвать слишком много проблем.

Но, в конце концов, ничто из того, что вы можете сделать, не остановит решительного пользователя от пиратства вашего программного обеспечения.

Фактически, наиболее эффективная стратегия разработки антипиратского программного обеспечения является самой простой из всех:

1. У вас отличный долбаный продукт.
2. Назначьте за это справедливую цену.

-- Джефф Этвуд

Answer 2

ИМО, попытка обеспечить защиту от копирования на стороне клиента, вероятно, доставляет больше хлопот, чем того стоит.Вы потратите бесчисленное количество часов, пытаясь перехитрить своих клиентов (часы, которые вы могли бы вместо этого потратить на улучшение своего продукта), но в конце концов пираты всегда будут побеждать.

Однако у вас есть и другие варианты:

1. Иметь привлекательную ценовую модель и сделать ее действительно просто чтобы люди покупали ваш продукт.Если у вас достаточно низкий барьер для входа и вы относитесь к своему клиенту с уважением и доверием, а не с подозрением, вы сводите к минимуму риск пиратства.
2. Привяжите свой продукт к какому-нибудь онлайн-сервису.Отдайте клиента, но возьмите плату за услугу.Это то, что Blizzard делает с World of Warcraft, и это одна из немногих игр, в которой вообще нет проблем с пиратством (у них есть много других проблем, но это уже другая история).

Answer 3

Честно говоря, если программе действительно не нужны данные с сервера для функционирования (как заявил fred-o, что World of Warcraft нужны;и верно), то есть ничего вы можете сделать клиентскую часть, которая будет полностью защищена от ошибок.Все 3 идеи, которые у вас были, можно было легко обойти.Сервер / логин может быть немного сложнее, но я даже видел, как взломы заходили так далеко, что локально создавали фиктивный сервер входа, чтобы программа думала, что он проходит проверку подлинности.

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

Если вы реализуете функциональность на стороне клиента, она может быть достигнута независимо от того, что вы делаете.

Answer 4

Мой лучший выбор - внедрить простое решение, которое не облагает вас слишком большими налогами и не раздражает клиентов, чтобы предотвратить случайное пиратство.Еще что-нибудь более сложное, и это будет гонка вооружений.Тот, который слишком трудно победить.

Answer 5

Из ваших трех решений:

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

Во-вторых, защита от копирования невелика, если только местоположение не скрыто, а скрытое расположение сопряжено со своими трудностями (некоторым людям, например, не нравится устанавливать приложения, которые любят прятать вещи в разных местах), и в любом случае небезопасно.

Третий, скорее всего, будет работать до тех пор, пока пользователь не сделает что-то с компьютером, что изменит отпечаток пальца (я не знаю, что бы вы проверяли), или не захочет переместить приложение с одного компьютера на другой.Тогда у вас будет потенциально разгневанный пользователь.("Я заменил жесткий диск / перешел на другое подключение по локальной сети / произошел системный сбой / что угодно, и [удаленное ругательство] просто перестало работать!")

Таким образом, хотя номер 2, скорее всего, не вызовет проблем у пользователя, он не будет работать для большей части схемы защиты от копирования.Цифры 1 и 3 приведут к недовольству пользователей, доставят вам определенные проблемы и в любом случае не остановят решительных людей от копирования.

Answer 6

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

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

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

Answer 7

Рассмотрите возможность использования JNLP для создания в вашем приложении компонента с ограниченным временем - лицензионного модуля?- который должен регулярно обновляться через Интернет.Для доступа к обновленной версии требуется регистрация.Пусть

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

Answer 8

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

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

Итак:Я бы не стал пользоваться чем-то, что время от времени звонит домой.

(Что касается лицензионных ключей:если ключ работает только с определенным регистрационным именем, и если это имя отображается в каком-либо диалоговом окне "О программе", то я бы не стал беспокоиться о том, чтобы сделать его зависящим от оборудования.Конечно, несколько регистрационных имен и их ключи будут общими, но что-то более навороченное не стоит затраченных усилий.Если мой Mac подведет меня, то мне было бы не смешно видеть, как при восстановлении Time Machine в 1 клик на новом оборудовании ваше приложение не запускается.)