Создание коммерческого программного обеспечения Java (DRM)

Question

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

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

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

Спасибо

Answer 1

Я работаю в компании, продающей защищенное программное обеспечение Java.

Я не буду комментировать схему аутентификации пользователя, но могу прокомментировать онлайн-проверку лицензии.

Не заставляйте его даже «работать в течение двух дней»: именно так я пиратую большую часть программного обеспечения ... Виртуальная машина настроена «вовремя» и внешне защищена, чтобы больше не «звонить домой» (то есть Только 30-дневная пробная версия (или двухдневная пробная версия) стала пожизненной пробной версией: разрешение только один раз связаться с сервером, чтобы получить пробный ключ), всегда обновляется с момента, когда программное обеспечение было установлено заново и после бинго. Почему я это делаю? Конечно, чтобы узнать, как лучше защитить наше приложение;) (хорошо, хорошо, я делаю это просто для удовольствия)

В нашем коммерческом программном обеспечении Java мы проверяем лицензию при каждом запуске.

У нас есть сотни клиентов, и никто никогда не жалел об этом. Ни разу. Мы генерируем уникальный класс при каждом запуске, который отличается при каждом запуске, который зависит как от того, что уникально для этого запуска на стороне клиента, так и от того, что было сгенерировано один раз на стороне сервера.

В дополнение к тому, что приложение связывается с вашим сервером при каждом запуске, это отличный способ сбора аналитики: соотношение загрузки к пробной версии, среднее количество запусков nb на пробную версию и т. Д. И это не так уж и плохо, чем использование JavaScript-трекера Urchin / Google на каждой веб-странице противно.

Просто дайте людям понять, что ваше программное обеспечение выполняет онлайн-проверку лицензии: мы установили огромный флажок, включающий или выключающий следующее: «Проверка онлайн-лицензии: OK / Failed». И это все. Люди знают, что есть чек. Если им не нравится это, они идут использовать продукты конкурента, и жизнь хороша.

Люди привыкли жить в проводном мире.

Как часто вы можете не получать доступ к GMail, потому что ваше интернет-соединение не работает? Как часто вы можете не получать доступ к FaceBook или SO, потому что ваше интернет-соединение не работает?

Суть в том, чтобы сделать как можно больше вычислений в зависимости от серверной стороны:

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

Никто не будет жаловаться. У вас будет 0,1% жалоб от вашего пользователя, и в любом случае вы не хотите, чтобы эти пользователи: именно они будут жаловаться на другие вещи и публиковать отрицательные отзывы о вашем приложении в Интернете. Вам лучше, чтобы они вообще не использовали ваше программное обеспечение и жаловались на тот факт, что для этого требуется постоянное подключение к Интернету (что составляет 99,99% от вашей целевой аудитории и, следовательно, они не будут заботиться о жалобе), а не на самом деле, чтобы они использовали его. приложение, и жаловаться на другие вещи, связанные с вашим приложением.

Что касается декомпиляции, то .class обычно можно декомпилировать обратно в .java, если только вы не используете обфускатор потока кода, который генерирует действительный байт-код, но который невозможно сгенерировать из файла .java (следовательно, невозможно вернуть верный файл .java).

Обфускатор строк помогает усложнить понимание.

Обфускатор исходного кода помогает усложнить понимание.

Обфускатор байт-кода, такой как бесплатный Proguard, усложняет (и производит более быстрый код, особенно заметный в мобильном мире), чтобы выяснить.

Если вы поставляете только Windows / Linux, то вы можете использовать конвертер Java-to-native, такой как Excelsior Jet (не бесплатный и довольно дорогой для стартапов, но он производит собственный код, из которого вы просто не можете найти .java файлы обратно).

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

Answer 2

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

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

Сообщение об этом здесь: все может быть взломано или скопировано. В конце концов, люди гораздо ярче, чем мы, занимаются этим (взлом iPhone, цифровое телевидение, игры и т. Д.), И никто не нашел серебряную пулю. Единственное, что вы можете сделать, это сделать труднее взломать ваше приложение (часто за счет удобства использования, простоты установки и сокращения углов для некоторых сценариев использования). Спрашивать себя, стоит ли это хлопот, это всегда хорошая отправная точка.

Answer 3

Не беспокойся.

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

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

Answer 4

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

Answer 5

Я понятия не имею, как защитить его от взлома и распространяется как варез.

Во-первых, вам лучше выбрать язык, кроме Java, если это вас беспокоит. Вот почему C ++ все еще жив и здоров в мире коммерческих приложений. Если вы не собираетесь использовать реальный компилятор Java для собственного exe-файла, я бы пересмотрел Java по соображениям защиты IP.

В этом отношении даже C ++ не невосприимчив к взлому, но защита IP от взлома - это две отдельные важные проблемы.

Answer 6

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

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

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

Answer 7

Я бы взглянул на обратную реакцию игры Spore, прежде чем выбрать схему лицензирования. Они звонили по телефону домой, и разрешали только очень много установок и т. Д. И т. Д. И т. П. Spore должен был стать их «приложением-убийцей», и ему действительно было трудно просто из-за лицензирования. Вы говорите, что готовы иметь меньше продаж, чем люди, использующие его бесплатно, но вы можете быть осторожны в том, что просите. Я действительно с нетерпением ждал споры (как и мои дети), но я никогда не покупал его из-за схемы DRM.

Независимо от того, что вы делаете, он будет взломан в очень короткие сроки, особенно если программа действительно чего-то стоит.

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

Answer 8

Перефразируя мистера Джеффа Этвуда, лучше сделать так, чтобы ваш клиент заплатил вам больше, чем взломать ваше приложение. Другими словами, я думаю, что вы атакуете не ту проблему. Сделайте покупку вашего продукта ОЧЕНЬ легкой, и тогда ваши клиенты не будут чувствовать, что им нужно приложить усилия для его взлома.

Answer 9

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

В вашем втором пункте:

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

Этот лимит в 2 (или X) дня, скорее всего, будет чрезвычайно просто обойти, его можно найти и исправить (всего несколько минут) (взломать).

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

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

Answer 10

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

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