Не виден ключ из-под VM (guest Linux host Win8)

Страницы: 1 2 След.
RSS
Не виден ключ из-под VM (guest Linux host Win8), ключ виден в lsusb, но исполняемый файл после envelop пишет, что ключ не найден
 
Гостевая система Ubuntu 14.04, хост-система  Win8.1. Под VM в Linux настроена работа Envelope, и  исполняемый файл успешно обрабатывается (мастер-ключ и ключ разработчика, соответственно, в виртуалке видны). Пользовательский ключ также виден и при lsusb, и в центре по адресу localhost:1947/_int_/devices.html . При обработке envelop-ом был указан файл

Код
./linuxenv -c:./envconfig.cfgx
в котором в разделе <VENDOR_CODE> был скопирован через буфер обмена код из файла в Win8 (визуально совпадает), где envelop тоже нормально запускается (файл указан параметром в GUI).

Но при попытке запустить защищённое приложение выдаётся:

Код
Sentinel LDK Protection System: Please note that this program is only protected with a demo 

Код
Sentinel protection key.Sentinel LDK Protection System: Sentinel key not found (H0007)
1. В чём может быть дело?

2. Также не понятно, почему написано про "demo Sentinel protection key". Envelop просил ключ разработчика и без него не запускался.
Возможно, я не прописал все параметры при работе из Linux, в котором нет наглядного GUI. Где можно посмотреть подробную инструкцию по настройке envelop  в Linux, и под Virtual Box в том числе?
 
Добрый день, Виталий.

Судя по всему Вы в *.cfgx вставили Vendor code не от своей боевой серии разработчика, а от серии DEMOMA, отсюда и предупреждение "Please note that this program is only protected with a demo", а также тот факт что уже защищённое ПО не видит пользовательского ключа Вашей серии разработчика.

В любом случае, рекомендую ознакомиться с документацией из нашего SDK - файлы:
  • Sentinel LDK for Linux_Getting Started.html
  • Envelope for Linux User Guide.pdf
Они есть в дистрибутиве нашего SDK и на ПК, в директории с установленным SDK.
 
Envelope for Linux User Guide.pdf читал, и вендор-код тоже мой. Но после полной перезагрузки  host-машины заработало.

Похоже, проблема была в VirtualBox и отчасти в ключах: и ключ разработчика и ключ пользователя Sentinel имеют одинаковые VendorID, ProductID, Revision и т.д. -- видимо, это совершенно сбивает с толку VM. Если не вытащить физически ключ разработчика и вставить ключ пользователя, то, несмотря на то, что в ACC оба ключа видны, вставленный вторым остаётся для VM недоступным. Более того, попытки принудительно отключать после этого и переподключать устройства с одинаковыми идентификаторами приводят к известной ошибке https://www.virtualbox.org/ticket/10309 в разных её вариациях, упоминаемых в интернете регулярно уже лет 5. После этого usb-ключи сменить невозможно, они не видны, а упомянутая ошибка VM остаётся до перезагрузки host-системы.

После перезагрузки host-OS, был сразу вставлен ключ пользователя, и обработанная с помощью envelop программа его увидела и нормально заработала.

Возможно, в случае, если бы поля ключей различались, такой проблемы бы не было. Попробуйте уведомить об этом разработчика. Мне пришлось потратить на выяснение этих тонкостей немало времени.
 
Проблема в данном случае (по всей видимости) не в наших ключах, а в самой среде виртуализации и в её алгоритмах при работе с USB устройствами.
VendorID - числовой идентификатор серии разработчика  он и должен быть одинаковым, в противном случае это были бы уже ключи разных серий разработчика.
ProductID - не совсем уверен что верно понимаю, что Вы под этим подразумеваете. В рамках идеологии нашей системы защиты, ProductID - это идентификатор продукта с набором лицензий, записываемых в пользовательские ключи. В ключах разработчика это понятие отсутствует.
Revision - опять же не совсем уверен что верно понимаю, что Вы под этим подразумеваете. Если Вы говорите о Firmware или Hardware то опять же эти параметры версии микропрошивки и железа ключа просто не могут быть разными для всех ключей, так как это технологически не возможно.  

Напомню, что у нас есть список официально поддерживаемых сред виртуализации (доступен в документации к используемой у Вас версии нашего SDK) и их версий, и если используемая у Вас среда виртуализации или её версия в этот список не входит, тогда нет ничего удивительного что оно у Вас как-то не так работает, ведь оно и не тестировалось на совместимость.
 
VendorID, ProductID, Revision это то, что всплывает, когда наводишь на устройство указатель мыши в разделе Devices->USB окна виртуальной машины. У некоторых устройств там же указан и серийный номер, но не у ключей. Если на основе этих полей VM строит идентификатор, то при совпадении полей могут быть коллизии. В любом случае, это только мои предположения.

VM = VirtualBox обновлена позавчера. Весь софт Sentinel тоже позавчера обновился и на hostOS Win 8.1 и на гостевой Ubuntu 14.04 под VM -- это всё входит в список поддерживаемого из Release Notes.pdf или http://www.safenet-inc.com/software-monetization/sentinel-ldk/#tab2 ( за исключением VirtualBox, которая уже 5й версии, а по ссылке тестировали только на 4й, но описанная проблема с USB-устройствами была и на 4й, то есть нет оснований считать, что во всём виновато обновление до 5й версии).

Как бы там ни было, всё работает, хотя, как я эмпирически выяснил, во избежание проблем с добавлением-удалением ключей и их видимостью надо быть очень осторожным, и не пытаться держать в VM активными сразу два устройства Sentinel.
 
"VendorID, ProductID, Revision" - понял о чём Вы говорите.

VendorID - идентификатор производителя ключей.
ProductID - числовой идентификатор устройства.
Revision - версия микропрошивки ключа.

Как видите это те из параметров которые явно не могут быть различными для всех ключей.
К тому же в VirtualBox у каждого устройства есть свой UUID, что как бы гарантирует их отличие друг от друга.
 
Цитата
Виталий пишет:
У некоторых устройств там же указан и серийный номер, но не у ключей
Соответственно, если бы ключи Sentinel полностью удовлетворяли спецификации USB, с уникальными серийными номерамИ, то скорее всего такого вопроса бы в принципе не возникло.

А поскольку практически у всех ключей (кроме самых дешевых) и так есть 32-битный Hardware HASP ID, то весь вопрос в прошивке. Если бы прошивка сообщали свой HASP ID (или его производную) в качестве USB serial number - то скорее всего проблема бы не возникла.

Можете зарегистрировать тикет для разработчиков прошивок, чтбы при наличии HASP ID заполнялось поле USB serial number ?
 
Цитата
Yury Goryachev пишет:
Как видите это те из параметров которые явно не могут быть различными для всех ключей.
Цитата
Yury Goryachev пишет:
ProductID - числовой идентификатор устройства.
Для вот вообще всех - не может. А для Master key / Developer key / client key вполне может. Может даже быть разным для разных видов коиентских ключей ( Basic, Pro, Net10, Net50, Net250+).
Опять же - вопрос исключительно к прошивке.
 
Цитата
Yury Goryachev пишет:
К тому же в VirtualBox у каждого устройства есть свой UUID, что как бы гарантирует их отличие друг от друга.
Чтобы назначит уникальный UUID первоначально у хоста должна быть возможность определить уникально само устройство. Если устройство полностью определяет USB Plug-n-play инфо, включая уникальный серийный номер, то по крайней мере принципиальных проблем нет.

Но вот в случае например клавиатур/мышек - экземпляры одной модели ничем не отличаются и смысла заполнять серийник действительно нету.

Насколько знаю, при отстуствии серийного номера :

* Linux идентифицирует устройство по набору VendorID / ProductID куда бы его не втыкать

* Windows идентифицирует устройство по набору VendorID / ProductID / Revision / USB controller

То есть если в компьютере есть два USB-контроллера - например интегрированный на материнке и отдельный на PCI-плате, или возможное использование USB-хабов, или (см. комментарии к тикету VB) USB1/USB2/USB3 (они для ОС считаются разными контроллерами, даже если один чип физически) - то Windows просто при переносе устройства из одного гнезда в другой будет считать его новым неизвестным устройством и ставить драйвера "с нуля".

А вот как себя ведет VirtualBox неизвестно...
Но явно в этой ситуации он не может идентифицировать устройства различно, если у них совпадает Plug-n-play USB id
 
Дмитрий, в том то и дело что не зная как работает VirtualBox  и мы и Вы можем лишь только гадать почему он имеет подобные проблемы.
Однако, например среда виртуализации VM Ware, к примеру, вполне нормально отличает ключи, и поддерживает подключение какого угодно количества ключей к одной и той же виртуалке единовременно. Это в свою очередь говорит в пользу теории, что проблема именно в механизмах Virtual  Box'а, а не нашего драйвера/прошивки/ключа.
Однако, повторюсь - это всё только догадки, за не имением информации, которой обладает Oracle (как разработчик Virtual Box).
Страницы: 1 2 След.
Читают тему (гостей: 1)