Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Guardant → Технологии защиты → Вопросы по Guardant API
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Для чего функция GrdSetFindMode() имеет параметр dwRemoteMode, если такой же параметр уже имеет функция GrdStartup()? К тому же, похоже, что в GrdSetFindMode() этот параметр обязан иметь то же самое значение, что и при вызове GrdStartup(), иначе будет ошибка GrdE_InvalidArgs.
Также непонятен смысл параметра dwInterfaces. Тип интерфейса (LPT, USB) уже задается предыдущим параметром dwModels.
Функция GrdSetFindMode() имеет параметр dwRemoteMode для построения сложных методов поиска ключа, к тому же, параметр dwRemoteMode не обязательно имеет одинаковое значение для обеих функций.
Смысл параметра dwInterfaces заключается в указании конкретного интерфейса, параметром dwModels задаётся конкретная модель ключа.
Эксперименты показывают, что в функцию GrdSetFindMode() можно передавать либо то же значение dwRemoteMode, что и в GrdStartup(), либо меньшее. То есть, функцией GrdSetFindMode() можно сузить область поиска ключа, либо оставить ее прежней. Расширить область поиска не получится. Верно?
Смысл параметра dwInterfaces заключается в указании конкретного интерфейса, параметром dwModels задаётся конкретная модель ключа.
Да, но модель ключа однозначно определяет интерфейс. Если посмотреть на список констант-моделей то видно, что на каждый вид ключа у вас по три модели: USB, LPT и любой.
И еще вопрос по функции GrdSetAccessCodes().
Обязательно ли каждый раз при вызове этой функции задавать значения dwPublic и dwPrivateRD? Или их достаточно указать один раз, а затем можно заменять нулями - и контейнер их будет помнить?
В документации про эти параметры сказано "Должен быть задан обязательно!". Обязательно задаваться каждый раз, или хотя бы один раз?
К примеру, такой код прекрасно работает:
nResult=GrdSetAccessCodes(hGrd, dwPublic, dwPrivateRD, 0, 0);
nResult=GrdLogin(hGrd, GrdLM_PerStation, GrdFMR_Local);
nResult=GrdRead(hGrd, 0, 1, &b0, 0);
nResult=GrdSetAccessCodes(hGrd, 0, 0, dwPrivateWR, 0); // dwPublic==0 and dwPrivateRD==0 !!!!
nResult=GrdWrite(hGrd, 0, 1, &b0, 0);Эксперименты показывают, что в функцию GrdSetFindMode() можно передавать либо то же значение dwRemoteMode, что и в GrdStartup(), либо меньшее. То есть, функцией GrdSetFindMode() можно сузить область поиска ключа, либо оставить ее прежней. Расширить область поиска не получится. Верно?
Да, совершенно верно.
Да, но модель ключа однозначно определяет интерфейс. Если посмотреть на список констант-моделей то видно, что на каждый вид ключа у вас по три модели: USB, LPT и любой.
В некоторых случаях может потребоваться при поиске ключа задать интерфейс отдельно, например если необходимо выполнять поиск любой модели USB-ключа (в таком случае удобнее будет указать параметр dwModels как GrdFMM_ALL, а параметр dwInterfaces как GrdFMI_USB) при этом если в будущем будут использоваться новые модели USB-ключей, то не будет необходимости менять параметры поиска.
Также можно отметить, что с выходом нашего нового SDK v6 появятся еще и софтовые ключи защиты, а в новом API для поиска будут добавлены соответствующие параметры функции GrdSetFindMode() в том числе и dwModels.
Обязательно ли каждый раз при вызове этой функции задавать значения dwPublic и dwPrivateRD? Или их достаточно указать один раз, а затем можно заменять нулями - и контейнер их будет помнить?
В документации про эти параметры сказано "Должен быть задан обязательно!". Обязательно задаваться каждый раз, или хотя бы один раз?
В рамках одного хэндла коды доступа достаточно указать один раз.
При необходимости вызвать GrdSetAccessCodes() повторно (до/переустановить коды доступа) можно задавать нули для тех кодов, изменять которые не требуется.
Еще вопрос.
Функция GrdWrite требует указателя на неконстантный буфер (void* pData, а не const void*). Почему так? Ведь, из здавых соображений, эта функция не должна менять содержимое буфера. Можно ли полагаться, что эта функция не попытается изменить содержимое буфера и просто кастить (const void*) в (void*)
Аналогичный вопрос относится и к многим другим функциям: GrdPI_Update(), GRD_API GrdTRU_SetKey()
Еще вопрос.
Функция GrdWrite требует указателя на неконстантный буфер (void* pData, а не const void*). Почему так? Ведь, из здавых соображений, эта функция не должна менять содержимое буфера. Можно ли полагаться, что эта функция не попытается изменить содержимое буфера и просто кастить (const void*) в (void*)
Аналогичный вопрос относится и к многим другим функциям: GrdPI_Update(), GRD_API GrdTRU_SetKey()
Так сделано для единообразия. Кастить, теоретически, можно.
Еще такой вопрос.
В справочнике Guardant API про функцию GrdLogin() сказано:
dwModuleLMS--номер модуля в таблице LMS, на котором будет регистрироваться копия приложения. Если LMS не используется, параметр должен быть равен 0xFFFFFFFF. Для локальных ключей этот параметр игнорируется
То есть, получается, я могу передать 0xFFFFFFFF и не использовать LMS. А что значит "не использовать LMS"?
С другой стороны, в Руководстве сказано, что
Для Guardant Sign Net / Time Net наличие таблицы лицензий обязательно, т. к. в ней хранится реальный сетевой ресурс ключа. Реальный ресурс ключа лежит в первой по счету записи LMS. За ним следуют записи с ресурсами модулей.
То есть, таблица лицензий должна присутствовать в сетевом ключе, даже если я не собираюсь использовать LMS? То есть, в Guardant Sign не нужно вставлять таблицу лицензий, а в Guardant Sign Net - нужно обязательно?
А как тогда определить, что найденный ключ - SignNet? По TGrdFindInfo::byMaxNetRes, по TGrdFindInfo::wType или по TGrdFindInfo::dwModel
То есть, таблица лицензий должна присутствовать в сетевом ключе, даже если я не собираюсь использовать LMS? То есть, в Guardant Sign не нужно вставлять таблицу лицензий, а в Guardant Sign Net - нужно обязательно?
А как тогда определить, что найденный ключ - SignNet? По TGrdFindInfo::byMaxNetRes, по TGrdFindInfo::wType или по TGrdFindInfo::dwModel
Да, таблица лицензий должна присутствовать в сетевом ключе, если Вы собираетесь использовать его, как сетевой. Как минимум она содержит общий ресурс ключа (максимальное число одновременно работающих пользователей). Дополнительно она может содержать модули LMS (каждый со своим ресурсом).
То есть, получается, я могу передать 0xFFFFFFFF и не использовать LMS. А что значит "не использовать LMS"?
Если передать функции GrdLogin() 0xFFFFFFFF, то логин по сети произойдет с захватом только одной лицензии из общего ресурса.
Если при логине указать номер модуля в таблице лицензий, то будет захвачена лицензия из этого модуля и из общего ресурса.
Таким образом, если защищаемое приложение не разбивается на отдельно лицензируемые модули, то в таблице лицензий будет достаточно общего ресурса, а при логине можно указывать 0xffffffff.
Большое спасибо за ответ.
Еще остался вопрос.
Итак, программа прошивки ключа должна в ключ "Sign Net" записывать таблицу лицензий, а в ключ "просто Sign" - не должна. Как правильно определить, что вставленный ключ является Sign Net?
a) TGrdFindInfo::byMaxNetRes > 1
б) (TGrdFindInfo::wType & GrdDT_LAN) !=0
в) TGrdFindInfo::dwModel ???
г) Как-то еще?
Большое спасибо за ответ.
Еще остался вопрос.
Итак, программа прошивки ключа должна в ключ "Sign Net" записывать таблицу лицензий, а в ключ "просто Sign" - не должна. Как правильно определить, что вставленный ключ является Sign Net?
a) TGrdFindInfo::byMaxNetRes > 1
б) (TGrdFindInfo::wType & GrdDT_LAN) !=0
в) TGrdFindInfo::dwModel ???
г) Как-то еще?
Тут стоит обращать внимание на поле wType структуры TGrdFindInfo (вариант "б").
Также если нет строгой необходимости определять модель ключа до того как будет выполнен GrdLogin, можно воспользоваться функцией GrdGetInfo где в качестве параметра dwInfoCode нужно указывать GrdGIL_Model и анализировать возвращаемое в буфер pInfoData значение.
А можно как-то узнать IP адрес сервера , на котором работает найденный ключ? То есть, до вызова GrdLogin().
Здравствуйте.
А можно как-то узнать IP адрес сервера , на котором работает найденный ключ? То есть, до вызова GrdLogin().
Нет, такой возможности не предусмотрено, и не совсем понятен практический смысл таковой.
Функция GrdFind() готова сообщить нам кучу информации о найденном ключе. Адрес сервера, на котором был найден ключ, как я понимаю, в этот момент также известен, но, к сожалению, в TGrdFindInfo не попадает.
Практический смысл.
Программа при старте находит какой-то ключ, и, глядя на содержимое TGrdFindInfo, понимает, что этот ключ нам заведомо не подходит. Ну, скажем, Id данного ключа запрещен настройками программы. И нет смысла тратить время на логин, чтение каких-то полей ключа, запуск алгоритмов, логаут. Просто идем искать следующий ключ...
Если подходящий ключ найдется и программа будет нормально работать, то все ОК. А если программа не запустится, то пользователь будет в недоумении: ключи воткнуты, а программа не работает. Чтобы помочь ему разобраться, программа готова предоставить ему отчет о найденных, но не использованных ключах. И было бы неплохо, если бы этот отчет содержал бы адрес сервера.
Чтобы помочь ему разобраться, программа готова предоставить ему отчет о найденных, но не использованных ключах. И было бы неплохо, если бы этот отчет содержал бы адрес сервера.
Несмотря на видимую логичность подобного сценария он весьма маловероятен: тут на одну ЛВС, одной организации, должно быть развернуто достаточно большое количество сетевых ключей Guardant и серверов Guardant Net. И даже в таком случае ключ конкретного разработчика будет "отделен" от других ключей кодами доступа. В итоге маловероятно то, что операции логина и последующих проверок ключа будут сильно сказываться на работу конкретного приложения, конкретного разработчика в такой ЛВС, а логирование IP-адресов "своих" серверов сетевых ключей можно организовать и при помощи функции GrdGetInfo.
У меня проблема c процедурой регистрации SP ключа,
GrdLogin() выдаёт ошибку DongleNotFound.
Делаю следующие действия:
Инициализирую API
Устанавливаю критерии поиска ключа (по ID)
Вызываю поиск GrdFind() (метод находит один ключ)
И регистрация GrdLogin который выдает ошибку DongleNotFound
Использую:
Комплект разработчика Guardant 6.2,
Win7
MVS 2010
Net 4.0
GuardantDotNetApi.dll 6.0
Мурад,
Скорее всего вы пропускаете функцию GrdSetAccessCodes с установкой кодов доступа. Вам по почте специалист сейчас ответит подробнее и уточнит какой из ваших аккаунтов вы используете, чтобы определить правильные коды доступа для этого ключа, и при необходимости переслать их вам.
С уважением,
Степин Андрей
Здравствуйте Техподдержка!
новую тему создавать не хочется - вопрос по переходу с Stealth II -> Time:
затык в элементарном куске кода (работает в Stealth ОК):
ret = GrdWrite (hGrd, 208, sPasswd.GetLength(), (void*)(LPCTSTR)sPasswd, NULL);
то же самое в Time не работает (не записывает пароль), хотя GrdE_OK == ret, в описании написано:
"При попытке записать данные в область памяти, на которую установлен запрет на запись, или за пределами адресуемой области памяти, будет возвращено GrdE_OK, однако ни один байт записан не будет. "
что я делаю не так? явно какой то затык
спасибо!
Здравствуйте, maratka.
Как Вы верно отметили:
При попытке записать данные в область памяти, на которую установлен запрет на запись, или за пределами адресуемой области памяти, будет возвращено GrdE_OK, однако ни один байт записан не будет.
Таким образом, в первую очередь нужно проверить не устанавливались ли аппаратные запреты, при прошивке ключа через GrdUtil, на той области памяти, куда производится запись?
Подробнее про аппаратные запреты можно прочитать в нашей документации, на стр. 69.
Если по указанным адресам установлены аппаратные запреты (например, записана защищенная ячейка), то обновление (запись) такой области памяти следует производить при помощи функции GrdPI_Update.
ключ совершенно новый неюзанный, устанавливаются ли на него заводские аппаратные запреты?
и если уж говорить по "Guardant API" то мне кажется что возвращать код ошибки GrdE_OK а в реальности не писать ни одного байта (фактически функция не отработала) считаю не совсем корректным)). я понимаю конечно - защита и т.д. но всё же....... имхо
ключ совершенно новый неюзанный, устанавливаются ли на него заводские аппаратные запреты?
До начала использования Guardant API любой новый ключ необходимо хотя бы раз прошить нужной Вам маской при помощи утилиты программирования ключей GrdUtil (также описана в документации, стр. 31). Именно Вам как разработчику должно быть известно и понятно - что и где (какие поля, с какими запретами) прошито в конкретном, используемом ключе.
Данные, которые записаны в памяти нового ключа на производстве, не предназначены для использования при защите и, как я и указал ранее, она (память ключа) должна быть инициализирована в GrdUtil нужными Вам данными.
спасибо за ответ!
Подниму старую тему.
Итак,
таблица лицензий должна присутствовать в сетевом ключе, если Вы собираетесь использовать его, как сетевой.
Относится ли это к сетевым ключам SP?
Если да, то как это практически реализовать?
Получается, нужно включать в дистрибутив два идентичных шаблона ключа - с таблицей лицензий и без нее. И пользователь, купивший сетевой SP, должен активировать первый шаблон, а пользователь с локальным SP - второй. Это сложно, можно и перепутать.
А можно ли в локальный ключ тоже вставить таблицу лицензий? Чтобы одинаково прошивать и локальные и сетевые ключи? Вопрос относится и к хардверным и к софтверным ключам.
Подниму старую тему.
Итак,
Алексей Перепелов пишет:таблица лицензий должна присутствовать в сетевом ключе, если Вы собираетесь использовать его, как сетевой.
Относится ли это к сетевым ключам SP?
Если да, то как это практически реализовать?
Получается, нужно включать в дистрибутив два идентичных шаблона ключа - с таблицей лицензий и без нее. И пользователь, купивший сетевой SP, должен активировать первый шаблон, а пользователь с локальным SP - второй. Это сложно, можно и перепутать.А можно ли в локальный ключ тоже вставить таблицу лицензий? Чтобы одинаково прошивать и локальные и сетевые ключи? Вопрос относится и к хардверным и к софтверным ключам.
Здравствуйте!
SP ключи управляются на портале sp.guardant.ru, там Вы можете несколько серийных номеров объединить в один сетевой, ресурс будет равен количеству серийных номеров. Шаблон уже активируется в соответствии с серийным номером. Прошивать сетевую лицензию в SP ключ не нужно.
Вы можете прошивать сетевой и локальный ключ Sign прошивать одной и той же маской с таблицей лицензией.
То есть, таблица лицензий обязательно должна быть только в следующих случаях:
1) В хардверных ключах SignNet, если они используются как сетевые.
2) В ключах StealthNet, если они используются как сетевые и используется LMS.
Во всех остальных случаях, в частности
1) Любые ключи, используемые как локальные
2) Сетевые и локальные софтверные ключи
3) Ключи StealthNet, если не используется LMS
таблица лицензий также может присутствовать, но не обязана.
Верно?
То есть, таблица лицензий обязательно должна быть только в следующих случаях:
1) В хардверных ключах SignNet, если они используются как сетевые.
2) В ключах StealthNet, если они используются как сетевые и используется LMS.Во всех остальных случаях, в частности
1) Любые ключи, используемые как локальные
2) Сетевые и локальные софтверные ключи
3) Ключи StealthNet, если не используется LMSтаблица лицензий также может присутствовать, но не обязана.
Верно?
В сетевых ключах NET и TIME NET при работе с сервером сетевых ключей обязательно записывать LMS в ключ.
Для сетевых ключей используемых локально таблицу лицензии не нужно записывать. Для локальных ключей Sign и Stealth II допустима запись таблицы лицензии.
Все операции с Guardant SP осуществляются через портал sp.guardant.ru
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Guardant → Технологии защиты → Вопросы по Guardant API