Лицензионный ключ для приложения Java RCP на VMId - PullRequest
Новая
       25

Лицензионный ключ для приложения Java RCP на VMId

1 голос
/ 03 сентября 2011

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

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

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

В ожидании экспертного заключения,

Нэвин

1 Ответ

1 голос
/ 02 октября 2011

Если вы видите конструктор по умолчанию java.rmi.dgc.VMID 

public VMID() 
{
    addr = localAddr;
    uid = new UID();
}

, тогда вы обнаружите, что зависит от hash IP-адреса(который будет одинаковым для всех машин, использующих localhost или 127.0.0.1).Но (и это большой но), он также зависит от java.rmi.server.UID.

Теперь, согласно javadoc:

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

Теперь нет машины, которая доступнакоторый перезагружается менее чем за одну миллисекунду.Самые быстрые, которые я видел, это MS-DOS (не уверен в времени загрузки) и Google OS (в соответствии с их промоушеном занимает 3-4 секунды).

Итак, я буду чувствовать себя в безопасности, если это единственный фактор, но я все равно буду проверять фактор setting the system clock backward.

Если мне придется использовать вашпродукт на нескольких компьютерах, но платя только за один, тогда я бы установил его на ОС, работающую на VMPlayer или VirtualBox.Таким образом, я мог бы распространять несколько копий вашего инструмента.Вы проверяли этот сценарий.

Кроме того, на моей машине разработчика у меня обычно есть два разных JDK (последний для игры и второй для разработки для конкретного клиента).Известно, что классы VMID и UID ранее имели некоторые проблемы с несколькими JVM.Проверьте это: http://www.velocityreviews.com/forums/t131825-can-we-generate-unique-id-from-java.html.

Также взгляните на этот javadoc: http://fuseyism.com/classpath/doc/java/rmi/dgc/VMID.html

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

Итак, наконец, если вы уверены, что пользователь ваших продуктов не собирается использовать какую-либо технологию виртуализации (например, vmplayer и т. Д.), Нет проблем, связанных с несколькими JVM, и у них может не быть доступа к Интернету для однократной активации, а затем перейдите к нему.

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

...