Лицензирование премиального контента в приложении java (desktop)

Замечу, что уже есть некоторые вопросы о том, как защитить лицензионные коммерческие приложения Java, перечисленные ниже, и хотя я согласен с общим консенсусом в отношении того, что вся такая защита неизбежно будет избита достаточно решительных пиратов, я все еще возражаю, что некоторая защита лучше, чем никто, пока это не вызывает раздражения законных пользователей.Лицензирование премиального контента в приложении java (desktop)

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

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

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

Благодаря

источник

2014-01-19 barneypitt

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

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

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

Имейте в виду, что java относительно легко декомпилировать, и кто-то может прийти и заменить всю вашу лицензионную логику на if(true).

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

источник

2014-01-19 11:59:44

Что касается декомпиляции и изменения логики лицензирования, логика аутентификации будет серверной, поэтому, независимо от изменений в клиентской логике, банку будет когда-либо обслуживаться только пользователь, прошедший проверку подлинности. Поскольку дополнительная функциональность находится в банке, никакое изменение на стороне клиента не может «включать» без банки. – barneypitt

@barneypitt, пока вы не разделите банку со своим другом и не удалите логику, подтверждающую ее использование! –

Я понимаю, что вы имеете в виду. Моя предпосылка заключалась в том, что взломщик никогда не сможет получить доступ к (незашифрованному) файлу jar, в первую очередь, поскольку незашифрованные классы будут когда-либо существовать в ОЗУ приложения. Но тогда я полагаю, что какое-то умное обнюхивание памяти могло бы восстановить банку? – barneypitt

Для взлома сетевого трафика между вашим приложением и вашим сервером взломщик может использовать такой инструмент, как Wireshark. Таким образом, он мог либо скопировать JAR непосредственно из потока данных, либо посмотреть, с какого URL он загружает программу и запрашивать этот URL вручную для получения JAR.

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

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

источник

2014-01-19 12:08:37 Philipp

Я предполагаю, что я мог бы зашифровать банку на основе запрашивающего MAC-адреса, но я думаю, что будет достаточно простой способ подделать ваш MAC-адрес. Другая мысль заключалась в том, что сервер мог отказаться от аутентификации заданного запроса, если кто-то еще в настоящее время подключен к сети с этими учетными данными - то есть только один одновременный пользователь на набор учетных данных. – barneypitt

@barneypitt Оба не имеют значения, когда взломщик эмулирует ваш сервер своим. – Philipp

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

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

Все данные были очень полезными.

источник

2014-01-23 14:23:51 barneypitt

Лицензирование премиального контента в приложении java (desktop)

ответ

Смежные вопросы