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

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

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

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

Не беспокойтесь.

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

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

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

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

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

если на то пошло, даже c++ не поддаюсь трескать, но IP prorection и крекинг-это две отдельные, важные проблемы.

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

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

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

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

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

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

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

во втором пункте:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если бы у меня было достаточно очков репутации, я бы проголосовал за этот вопрос. Коммерческая защита программного обеспечения-это пустая трата времени, денег и усилий по многим причинам. Сконцентрируйтесь на создании программного обеспечения, которое стоит покупать. Если ваше программное обеспечение достаточно популярно, чтобы поддерживать широкий посев пиратов, вы, вероятно, достаточно успешны в тот момент, что вы даже не будете беспокоиться о пиратстве. В любом случае, crackers crack Software protection в основном для удовольствия. Чем сильнее ваша защита, тем лучше вызов. подарки и тем больше они хотят взломать его. Ваши лучшие усилия будут стоить Вам тысяч, занять месяцы и быть взломаны всего за несколько дней.