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

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

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

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

Спасибо

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bytecode obfuscator, как и бесплатный Proguard, делает его более сложным (и создает более быстрый код, особенно заметный в мобильном мире), чтобы выяснить.

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

В этом отношении даже С++ не является непроницаемым для взлома, но IP-прокоррекция против взлома - две отдельные важные проблемы.

Ответ 6

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

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

Ответ 7

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

В вашей второй точке:

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

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

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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