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

17

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

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

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

Спасибо

    
задан Fluffy 17.03.2010 в 23:40
источник
  • superuser.com/questions/14224/how-to-explain-drm-cannot-work/... –  RCIX 27.05.2010 в 01:53
  • Не могли бы вы изменить заголовок вопроса, чтобы отразить, что это касается DRM / обеспечения безопасности вашего приложения от взлома? –  Kissaki 17.10.2010 в 19:47

14 ответов

16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ответ дан SyntaxT3rr0r 18.03.2010 в 00:30
источник
  • @WizardOfOdds - Что происходит, когда компания хочет запустить ваше программное обеспечение в сети, не подключенной к Интернету? Я могу думать о нескольких отраслях, где это, вероятно, произойдет, поэтому, я думаю, это сводится к тому, кем может быть ваша пользовательская база? –  Binary Nerd 18.03.2010 в 01:17
  • @Binary Nerd: очень немногие отрасли, которые имеют такую ​​потребность, имеют как внутреннюю сеть, так и интернет-сеть. Я приведу вам пример, который я знаю очень хорошо: Broadcom была такой компанией: у чип-инженеров было по крайней мере два компьютера, одна рабочая станция Unx для запуска чип-дизайна (с высокой степенью секретности) и другого компьютера (Windows, Linux, Mac ), который был в Интернете. Подумайте об этом: сегодня очень мало компаний, где люди используют компьютерное программное обеспечение, но его пользователи не могут отправлять электронные письма. Торговые секреты? Две сети или жить в каменном веке и быть опережающими конкурентами. –  SyntaxT3rr0r 18.03.2010 в 03:21
  • @Binary Nerd: в дополнение к этому, рассматривая исходный вопрос, который говорит о сервере, и он обеспокоен «warez», кажется довольно очевидным, что OP не после тех немногих компаний в мире, которые произойдут с использовать компьютеры, но не разрешать своим компьютерам доступ к Интернету ... Теперь я не оспариваю, что могут быть несколько исключительных случаев, когда это не сработает. Но в настоящее время большинство людей, МСП и крупные компании используют ежедневные Webapps, такие как GMail и т. Д. Мы живем в мире, подключенном к Интернету, и если это изменится в один прекрасный день, у нас будут большие проблемы, чем у антипиратства;) –  SyntaxT3rr0r 18.03.2010 в 03:27
  • @WizardOfOdds - Спасибо за ответ. Я просто хотел сказать, что @roddik должен учитывать ситуации, когда внешнее сетевое соединение может быть недоступным. –  Binary Nerd 18.03.2010 в 04:09
  • @Webinator: -1. это плохая рекомендация, поскольку она наказывает только законных пользователей (как и любого DRM). Если хакер хочет этого достаточно, он сделает что-то вроде имитации вашего сервера и упростит взломать ваше программное обеспечение. Просто вы ничего не можете с этим поделать. @roddik: Лучше всего свести к минимуму ограничения, чтобы как можно меньше пользователей ощущали необходимость кражи вашего программного обеспечения. –  RCIX 27.05.2010 в 01:47
Показать остальные комментарии
10

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

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

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

    
ответ дан lorenzog 18.03.2010 в 00:11
источник
  • Я читал ваше сообщение и представлял себе, что одинокий разработчик программного обеспечения сутулился над баром-табуретом с лагером в руке ... (нюхает) ... (нюхать) НИКТО не хочет пиратствовать в моем программном обеспечении! (sniff) ... :-) –  Drew 19.03.2010 в 03:53
6

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

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

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

    
ответ дан Zak 18.03.2010 в 00:14
источник
  • Я согласен. В конечном итоге речь идет о балансировании удобства пользователя и сложности drm. Не прилагайте слишком много усилий, чтобы сделать его «действительно безопасным». В какой-то момент, делая его более безопасным, также уменьшится удобство пользователя. –  Kissaki 17.10.2010 в 19:46
3

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

    
ответ дан zellio 17.03.2010 в 23:48
источник
  • Какой процент населения, способного покупать программу в Интернете, предположите, что в наши дни не существует постоянного соединения? –  Fluffy 18.03.2010 в 12:42
  • Все, кто путешествует. Является ли это фактором, очевидно, зависит от типа вашего приложения. –  Lars 18.03.2010 в 20:05
2
  

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

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

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

    
ответ дан codenheim 17.03.2010 в 23:50
источник
  • Что? C ++ жив и здоров, потому что сложнее пиратский машинный код, чем байт-код? Извините, но ... это действительно неразумное заявление. –  asveikau 17.10.2010 в 21:44
1

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

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

    
ответ дан Tomislav Nakic-Alfirevic 17.03.2010 в 23:48
источник
1

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

    
ответ дан mR_fr0g 18.03.2010 в 00:15
источник
  • Это труднее всего для пользователей расстаться со своими деньгами, и я ничего не могу сделать, чтобы исправить это. –  Fluffy 18.03.2010 в 12:48
1

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

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

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

    
ответ дан digitaljoel 18.03.2010 в 00:16
источник
  • Я определенно с нетерпением ждал споры, и было ли это треснуло или нет, не имеет значения. Суть комментария заключалась в том, что навязчивый, сложный DRM стоил реальной продажи от кого-то, кто действительно хотел использовать программное обеспечение. Я не использую взломанное программное обеспечение. Просто потому, что я его не покупал, это не значит, что я не ожидал этого, это означает, что я принял решение не получать его на основе дерьма, которую издательская компания размещала в игре, которая, как я полагала, была бы забавной для меня и для детей. –  digitaljoel 18.03.2010 в 17:34
1

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

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

  

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

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

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

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

    
ответ дан Rickard von Essen 18.03.2010 в 00:15
источник
1

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

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

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

    
ответ дан Lars 18.03.2010 в 00:43
источник
0

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

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

    
ответ дан defectivehalt 18.03.2010 в 00:01
источник
0

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

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

    
ответ дан Marcus Adams 18.03.2010 в 00:46
источник
0

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

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

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

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

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

    
ответ дан tchufa 18.03.2010 в 00:56
источник
0

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

ответ дан Eric 29.03.2010 в 03:26
источник
  • +1, вы ударяете ноготь по голове. Небольшая заметка (что вы должны указывать людям, когда они рекомендуют DRM): superuser.com/questions/14224/how-to-explain-drm-cannot-work/... –  RCIX 27.05.2010 в 01:51