Guardant ошибка получения числа компьютера
При работе с ключом защиты Guardant (не важно какой модели) разработчик использует соответствующие API, при этом от него скрыт сам механизм работы с устройством, не говоря уже о протоколе обмена. Он не имеет на руках валидного хэндла устройства, пользуясь только адресом шлюза (т.н. GuardantHandle) через который идет вся работа. В случае если в системе присутствует эмулятор ключа (особенно актуально для моделей до Guardant Stealth II включительно) используя данный шлюз разработчик не сможет определить, работает ли он с реальным физическим ключом, или его эмуляцией.
Задавшись в свое время вопросом: «как определить наличие физического ключа?», мне пришлось немного поштудировать великолепно поданный материал за авторством Павла Агурова в книге "Интерфейс USB. Практика использования и программирования". После чего потратить время на анализ вызовов API функций из трехмегабайтного объектника, линкуемого к приложению, в котором собственно и сокрыта вся «магия» работы с ключом.
В итоге появилось достаточно простое решение данной проблемы не требующее использования оригинальных Guardant API.
Единственный минус — все это жутко недокументированно и техническая поддержка компании Актив даже не будет рассматривать ваши вопросы, связанные с таким использованием ключей Guardant.
Ну и конечно, в какой-то момент весь данный код может попросту перестать работать из-за изменений в драйверах Guardant.
Но пока что, на 27 апреля 2013 года, весь данный материал актуален и его работоспособность проверена на драйверах от версии 5.31.78, до текущей актуальной 6.00.101.
- Через SetupDiGetClassDevsA() получим список всех присутствующих устройств.
- Проверим, имеет ли устройство отношение к ключам Guardant через проверку GUID устройства. (У Guardant данный параметр равен )
- Получим символьную ссылку на каждое устройство вызовом SetupDiGetDeviceRegistryPropertyA() с параметром SPDRP_PHYSICAL_DEVICE_OBJECT_NAME.
- Откроем устройство при помощи ZwOpenFile() (CreateFile() тут уже к сожалению не подойдет, т.к. будут затруднения при работе с символьными ссылками).
Начиная с Guardant Stealth III и выше, изменился протокол работы с ключом, как следствие поменялись константы IOCTL запросов и содержимое входящего и исходящего буфера. Для нормальной работы алгоритма желательно поддерживать возможности как старых, так и новых ключей, поэтому опишу различия:
Для начала константы IOCTL выглядят так:
Первая для ключей от Guardant Stealth I/II
Вторая для Guardant Stealth III и выше (Sign/Time/Flash/Code)
Отправляя первый запрос на устройство, мы будем ожидать что драйвер нам вернет следующий буфер:
В случае более новых ключей и с учетом того, что протокол изменился, отправка первого запроса уже нам ничего не даст. Точнее запрос конечно, будет выполнен, но буфер придет пустой (обниленый). Поэтому на новые ключи мы посылаем второй запрос, который вернет данные немного в другом формате:
Здесь уже возвращается блок в 512 байт содержащий более подробную информацию о ключе. К сожалению по некоторым причинам я не могу вам дать полное описание данной структуры, но необходимые для данной статьи поля я в ней оставил.
Общий код получения данных о установленных ключах выглядит так:
Данная процедура перебирает все ключи и заносит информацию о них в массив структур TDongleQueryRecord, после чего вы можете вывести эти данные пользователю, ну или использовать их каким либо образом непосредственно в вашем приложении.
Как видите все достаточно просто, но в объектных модулях Guardant API данный код помещен под достаточно серьезную стековую виртуальную машину и практически не доступен для анализа обычному разработчику. В принципе здесь нет ничего секретного, как видите при вызовах не используется даже шифрование передаваемых и получаемых буферов, но почему-то разработчики Guardant SDK не сочли нужным опубликовать данную информацию (правда я все-же смог получить разрешение на публикацию данного кода, т.к. в итоге тут не затронуты какие-то критические аспекты протокола обмена с ключом).
Но не будем отвлекаться, вы вероятно заметили в вышеприведенной процедуре вызов функции GetPnP_ParentPath(). Данная функция возвращает полный путь к устройству от рута. Выглядит ее реализация следующим образом:
Собственно (вы будете смеяться) детектирование эмулятора будет происходить именно на базе данной строки.
Обычно путь устройства выглядит следующим образом:
В нем как минимум будет присутствовать текст NTPNP_PCI или USBPDO.
Т.е. PCI шина или HCD хаб как минимум будут одним из предков.
Т.к. эмулятор является все-же виртуальным устройством, то путь к нему будет выглядеть примерно так:
Соответственно на базе данной информации можно реализовать простую функцию:
Ну и в завершение опишу еще несколько нюансов, которые можно будет увидеть в демопримере, прилагаемом к статье:
Этап 1: Удаление старой версии
Из-за особенностей взаимодействия системы и программного обеспечения ключей необходимо удалить предыдущую версию. Делается это следующим образом:
-
Поскольку вследствие ошибки стандартный метод доступа к инструменту «Установка и удаление программ» недоступен, необходимо воспользоваться следующим вариантом. Вызовите инструмент «Выполнить» нажатием клавиш Win+R, напишите команду appwiz.cpl и нажмите «ОК».
- grdcls.dll;
- grdctl32.dll;
- grddem32.exe;
- grddos.sys;
- grddrv.dll;
- grddrv32.cpl;
- grdvdd.dll;
Проделав эти действия, переходите к следующему этапу.
Этап 2: Загрузка и установка новейшей версии
После деинсталляции старой версии нужно скачать и установить новейший вариант служебного софта Guardant. Алгоритм действий выглядит так:
-
Перейдите на официальный сайт компании.
Если вы больше не используете Guardant, установленные таким образом драйвера можно без последствий удалить через пункт «Программы и компоненты».
Заключение
Отблагодарите автора, поделитесь статьей в социальных сетях.
При запуске Сервера-186 или Топаз-Офиса выдается ошибка "Ключ Guardant не обнаружен".
Запустить службу Guardant Dongle.
- Нажать клавишу Win+R и в появившемся окне набрать services.msc.
- В появившемся списке найти службу GLDS, кликнуть ПКМ и выбрать Запустить.
Скопировать файл gnclient из папки Топаз-Офис
Справка: обычно gnclient создается при первом запуске Сервера-186 или Топаз-Офис
-
Откройте файл gnclient.ini в любом текстовом редакторе.
Найдите параметр ip_name. Значение этого параметра должно быть равно имени или IP-адресу компьютера, на котором работает сервер ключей Guardant. Если это не так, необходимо указать правильное значение этого параметра и сохранить изменения.
ПРИЧИНА
Запустить службу Guardant Dongle.
- Нажать клавишу Win+R и в появившемся окне набрать services.msc.
- В появившемся списке найти службу GLDS, кликнуть ПКМ и выбрать Запустить.
Скопировать файл gnclient из папки Топаз-Офис
Справка: обычно gnclient создается при первом запуске Сервера-186 или Топаз-Офис
-
Откройте файл gnclient.ini в любом текстовом редакторе.
Найдите параметр ip_name. Значение этого параметра должно быть равно имени или IP-адресу компьютера, на котором работает сервер ключей Guardant. Если это не так, необходимо указать правильное значение этого параметра и сохранить изменения.
Описание ошибки с токеном Guardant
И так, есть виртуальная машина на Vmware, на ней стоит ПО Trassir, для которого по сети с устройства DIGI AnywhereUSB/14 подключен USB-ключ защиты Guardant. Обращается ответственный за сервер, с тем, что его сервис не работает. Зайдя по удаленному рабочему столу на виртуальную машину, я увидел, что в утилите AnywereUSB Hub Configuraion Utility USB-ключ Guardant с лицензиями Trassir подключен и имеет статус "Connection Successful to Remote Hub" и в утилите Remote USB Hub Viewer, он так же без проблем определялся, как токен Guardant.
Диспетчер устройств операционной системы Windows Server 2012 R2, показывал, что все работает правильно, ключ видится, и нет каких-либо предупреждений. Версии драйверов были последними для DIGI. Но служба Trassir не могла запуститься, о чем сигнализировало постоянное окно с ошибкой:
Пожалуйста проверьте, вставлен ли USB-ключ Guardant. Внимание начиная с версии 3.3 Trassir больше не поддерживается HASP-ключами. Если вы раньше использовали Trassir с ключом Alladin-HASP, то свяжитесь с DSSL для замены ключа безопасности.The description for Event ID 2 from source watchdog-service cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
payload dies unexpectedly, service stopped
7680
The description for Event ID 13 from source trassir cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
license problem
4884
Пожалуйста проверьте, вставлен ли USB-ключ Guardant.
Внимание: начиная с версии 3.3 Trassir больше не поддерживает HASP-ключи. Если вы раньше использовали Trassir с ключем Alladin HASP, то свяжитесь с DSSL для замены ключа безопасности
Алгоритм решения проблемы с определением ключа Guardant
Давайте составим алгоритм действий по которому вы должны пройтись, что избавиться от данной ошибки.
- Произведите отключение вашего ключа в AnywereUSB Hub Configuraion Utility, через кнопку "Disconnect"
- Необходимо выполнить обновление драйверов для подключения устройств по сети с AnywhereUSB/14, как это делать я уже подробно рассказывал в статье (Как обновить драйвера DIGI AnywhereUSB), так что останавливаться на этом не буду. После обновления, необходимо произвести перезагрузку.
- Если проблема "Пожалуйста проверьте, вставлен ли USB-ключ Guardant" сохраняется, то пробуем обновить драйвера для самого токена Guardant. Сделать это можно с официального сайта. Так как разработчиком Trassir является фирма dssl, идем на их сайт.
Архив весит 9 мегабайт, если вы по каким-то причинам не можете его скачать с сайта, то можете загрузить драйвера Guardant с mail облака.
Запускаем установочный файл, если у вас драйвера еще не установлены, то мастер установки "Драйверы Guardant x64" не будет вас просить об удалении и обновлении. Так как у меня присутствует более старая версия драйверов, то я выбираю пункт "Переустановить драйверы Guardant x64".
Начинается процесс инсталляции, он занимает менее минуты.
После установки, необходимо перезагрузить ваш сервер.
После загрузки операционной системы Windows Server 2012 R2, открываем утилиты Remote USB Hub Viewer и AnywereUSB Hub Configuraion Utility и проверяем статус подключения к DIGI AnywhereUSB/14. Так же проверьте диспетчер устройств, чтобы не было желтых предупреждений и ключ не виделся с кодом ошибки Code 28. Если ошибок нет ,то пробуем запускать Трассир, к сожалению он мне все так же выдавал ошибку "Пожалуйста проверьте, вставлен ли USB-ключ Guardant", идем дальше.
Откройте AnywereUSB Hub Configuraion Utility и убедитесь, что подключенный ключ в Hardware ID имеет четырех значный HEX номер после 0x. Далее я вам посоветую включить функцию Use Microsoft Device IDs.
Use Microsoft Device IDs - это альтернативный метод использования идентификаторов устройств Microsoft. Имя идентификатора состоит из трех частей:
- Имя драйвера шины
- Идентификатор продукта
- И уникальный серийный номер
Приведу пример расшифровки Use Microsoft Device IDs, предположим вы воткнули USB токен локально в сервер, в итоге идентификатор устройства будет такой: USB \ VID_1608 & PID_0214 \ A20299386, где USB это драйвер шины USB Microsoft, VID_1608 & PID_0214 идентификатор продукта и A20299386 будет серийным номером.
Если вы тот же ключ подключите по сети, то все будет выглядеть вот так: AWUSB \ VID_1608 & PID_0214 \ A20299386. Некоторые драйверы USB-класса ожидают увидеть имя драйвера шины как «USB», и в результате не будет работать если флажок "Использовать идентификаторы устройств Microsoft не установлен".
Для включения Use Microsoft Device IDs, выберите пункт меню File-Preferences.
В открывшемся окне Preferences, поставьте галку на пункте "Use Microsoft Device IDs". Чтобы изменения вступили в силу, вам потребуется сделать дисконект вашему USB токену и заново подключить. Мне в итоге это помогло и мой трассир сервер успешно запустился, не показывая мне эту надоедливую ошибку "Пожалуйста проверьте, вставлен ли USB-ключ Guardant"
Дополнительные методы
Например, на сайте базы знаний DIGI , есть рекомендация, чтобы отключить DEP в Windows (Data Execution Prevention). Еще можно добавить ваш ключ в качестве разрешенного устройства (permitted device).
Перед любыми манипуляциями с реестром Windows сделайте его резервную копию, автор ответственности не несет за ваши действия.Откройте AnywereUSB Hub Configuraion Utility и посмотрите HEX номер у VID (Vendor ID) and PID (Product ID) или Hardware ID. Перейдите в ветку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ionhubЩелкните по нему правым кликом и выберите "Создать-Мультистроковый параметр"
Щелкните по новому созданному параметру и задайте ему имя PermittedDevices, далее в его значении укажите Vid_1234&Pid_5678, где 1234 это Vendor ID и 5678 это Product ID. После чего перезагрузитесь.
Еще из методов обхода проблем с USB токенами подключенными по локальной сети, является отключение параллельного порта, если он не используется конечно. Делается это через BIOS. Даже если это виртуальная машина, то у нее то же есть BIOS, я вам рассказывал, как попасть в биос виртуальной машины. Надеюсь, данные методы помоги вам решить проблемы с подключением вашего ключа защиты Guardant.
Читайте также: