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




reverse-engineering protection (10)

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

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

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

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

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

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

Спасибо


Вы должны прочитать «Тайное программное обеспечение» от Collberg и Nagra. Эта книга действительно полезна, чтобы помочь вам понять, как работают механизмы защиты программного обеспечения (такие как обфускация кода, водяные знаки, маркировка рождения и т. Д.).

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

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

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

Эти понятия действительно хорошо объяснены в упомянутой мной книге, которую стоит прочитать.


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


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

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

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


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


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

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


Это одни из самых суровых DRM, о которых я когда-либо слышал, ваши пользователи будут ненавидеть это.

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


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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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





commerce