Новый сервер GUARDANT NET (Страница 2 из 3)

Итак, при программировании ключа Net II я должен занести реальный ресурс в 38SAM, а также создать таблицу лицензий с первой записью равной реальному ресурсу.
Но, в действительности, мы не пользуемся возможностью ограничить количество лицензий. То есть, я должен прочитать максимальное количество лицензий (19SAM) и занести его и в 38SAM и LMS. Правильно?
А для Stealth III Sign Net то же самое?

И как мне из клиентского приложения узнать реальное количество лицензий (с учетом возможных ограничений)? Из TGrdFindInfo::wRealNetRes? Это работает для всех версий ключей и для всех версий серверов?

А можно ли как-то узнать количество задействованных в данный момент лицензий?

Существует 3-4 поколений ключей, 2 поколения API, 2 поколения серверов. И в их декартовом произведении я несколько теряюсь. Документацию я читал и читаю, включая и прошлые версии. А спрашиваю то, что или неясно из документации, либо имеет противоречия, либо вызывает какие-то сомнения. К сожалению, последние ответы ясности не добавили, а, скорее, наоборот

Давайте разбираться.
Сейчаc меня интересует процесс программирования ключей Stealth I, Stealth II, Net II при помощи современного API. Есть давно работающий код вида:

nskRead()
nskRead()
nskInit()
nskWrite()
nskWrite()
nskWrite()
nskWrite()
nskProtect()

который просто заливает в ключ буфер с алгоритмами, программирует некоторые отдельные ячейки и все это защищает. Его нужно перевести на GrdXXX API, а также добавить для Net II таблицу лицензий для совместимости с сервером 6.2.

Насколько я помню, функция nskProtect() использовала адресацию в SAM-словах, независимо от настроек режима SAM/UAM

Нынешний ее аналог, GrdProtect(), судя по документации, теперь использует адресацию в SAM-байтах, также независимо от настроек SAM/UAM. Но почему-то есть одно исключение - dwTableLMS для Net II по прежнему использует адресацию в словах. Это действительно так, или это все-таки опечатка в руководстве?

Так, вроде, защищенные ячейки появились только в Stealth III. А раньше были только алгоритмы. LMS разве относится к алгоритмам?

В документации по GrdProtect() сказано

То есть, вроде как, dwNumFunc должна включать LMS, если это NET III, и не должна, если это NET II?

По поводу необходимости защиты LMS от чтения у меня тоже были сомнения. Тем более, разные версии GrdUtil имеют на этот счет различное мнение. Из ваших ответов я понял, что LMS должны быть защищена и от чтения, и от записи для всех типов ключей (II и III)

Берем GrdUtil от версии 6.2 (демо коды).

Создаем маску ключа Stealth I. По умолчанию в ней 4 алгоритма. Сохраняем Исходный код записи (он с сокращениями приведен ниже) .

Алгоритмы заканчиваются по адресу 78 УАМ, то есть 108 САМ. А в исходном коде мы видим:

GrdProtect(hGrd,  77,  77,  4,  0,  0, NULL)

В документации про параметры dwWrProt и dwRdProt сказано:

SAM-адрес первого байта, доступного для записи (в байтах). Адрес должен быть четным, в противном случае возвращается ошибка GrdE_InvalidArg

Почему нам предлагают поставить защиту до 77 адреса? Разве не 108 должно быть? Кстати, 77 еще и нечетное.

...
const unsigned char g_byDongleImage[] = {\
    0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1A, 0x20, \
    0x28, 0x2E, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
    0x00, 0x00, 0x00, 0x00, 0x04, 0x04, 0xD3, 0xF5, \
    0x4D, 0x48, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
    0x08, 0x20, 0x12, 0x79, 0x64, 0x73, 0x37, 0x16, \
    0xF4, 0x73, 0x06, 0x00, 0xFE, 0xFF, 0xFF, 0xFF, \
    0x04, 0x04, 0x91, 0xE2, 0x03, 0x5E, 0x00, 0x00, \
    0x00, 0x00, 0x00, 0x00, 0x08, 0x04, 0x78, 0x54, \
    0xA3, 0x22, 0x17, 0xE2, 0xFE, 0x61};

int main(int argc, char* argv[])
{
......................
    if(::GrdWrite(hGrd, GrdUAM_bNProg, sizeof(g_byDongleImage), (void*)g_byDongleImage, NULL) == GrdE_OK)
    {
        if(::GrdProtect(hGrd,  77,  77,  4,  0,  0, NULL) == GrdE_OK)
        {
            printf("Dongle image has been successfully written to the dongle");
        }
    }
......................
    
    return nLastError;
}

Похоже, дело не только в функции (Исходный код записи). В статус-баре также указано 77/77.

Казалось бы, GrdProtect() всегда использует SAM, и не обращает внимание на режим, установленный GrdSetWorkMode()

PS
Не удалось залить картинку на ваш форум.

- независимо от формата и размера картинки

Продолжаем разговор...

Речь пойдет о ключах Sign и современном SDK 7.0

Создаем пустую маску Sign.

В статус-баре указано, что защиту нужно ставить на адрес 39. Смотрим Исходный Код Записи - там тоже GrdProtect(hGrd,  39,  39,  0,  0,  0, NULL). Но почему?
Левая колонке таблицы - это, как я понимаю, UAM-адрес. Мы видим, что свободная память начинается с 40uam, а 39uam - это последняя защищаемая ячейка. В документации сказано, что в функцию GrdProtect() нужно передать SAM адрес первой незащищенной ячейки, то есть, это должно быть 40uam+30=70sam.
Прошиваем ключ и смотрим байты 10uam и 12uam - там 70. То есть ключ прошивается правильно, а пользователю показывается чепуха!

Добавим какой-нибудь алгоритм.

Теперь статусбар предлагает нам установить защиту на 135, Исходный Код Записи - тоже 135. А левая колонка и документация подсказывают, что защищать нужно 136sam+30=166uam!
Прошиваем ключ - так и есть, там 166. На экране и с cpp-файле опять чушь, но ключ опять прошит верно!

Итак, в GrdUtil есть две ошибки:
1) На 1 байт - из-за путаницы: (первый незащищенный байт) <-> (последний защищенный)
2) На 30 байт - из за путаницы: SAM<->UAM
Итого, программа врет на 31 байт.

Попробуем теперь отключить защиту памяти.

Документация говорит нам, что в этом случае нужно в GrdProtect() передать 0. Статусбар согласем с документацией - там нули. Исходный Код Записи того же мнения - там тоже 0.
Прошиваем ключ - там 31! Теперь, наоборот, в ключ прошита ерунда, а на экране и в cpp все нормально!

Может, я чего-то не понимаю?

Хорошо, пусть статусбар показывает последний защищенный байт. А в какой адресации?

... в системе SAM. А реально там UAM-адрес, уменьшенный на 1.

А это я не понял. Согласно документации, защиту можно устанавить на четный адрес памяти, начиная с 44sam. То есть, если защита установлена на 44sam, то, фактически, она отсутствует. Но для отключения защиты документация рекомендует устанавливать 0. Так что, в третьем случае, защита должна быть установлена на 0, или на худой конец, на 44sam. А реально она ставится на 31 (нечетное число). Разве это правильно?

Еще столкнулись с такой проблемой.

После перехода на версию 7 программа, запущенная из ProgramFiles, перестала видеть ключ. Та же программа, запущенная из другой директории, ключ видит нормально.

По-видимому, причина в том, что программа пытается создать файл gnclient.ini рядом с собой. В ProgramFiles это запрещено и она обламывается. Это проявляется даже на сугубо локальных программах.

Какая АПИ функция создает gnclient.ini?

Как исправить эту ошибку?

Guardant API, из состава SDK 6.0, не "умело" генерировать конфигурационный файл "gnclient.ini".
Сейчас нужно пользоваться функцией GrdStartupEx для того, чтобы указать директорию, куда будет помещаться файл "gnclient.ini".

Спасибо. Замечания учтем.

Пару лет назад, очевидно, данный вопрос был не совсем корректно мной истолкован, однако, ошибок нет - реальный сетевой ресурс (wRealNetRes) это именно то число, которое записывается разработчиком при программировании электронного ключа и TGrdFindInfo::wRealNetRes работает корректно для всех ключей.

Таким образом значения реального сетевого ресурса (wRealNetRes) и максимального (byMaxNetRes), по желанию разработчика, могут отличаться друг от друга. С обновлением драйверов ничего не сломается.

Да, все верно.

wRealNetRes; // Текущий ресурс лицензий сетевого ключа. Задается разработчиком, должен быть <= byMaxNetRes

Здесь ошибка, исправление которой войдет в весеннее обновление Guardant SDK.

Тут не совсем понятно, в составе дистрибутива приложения, защищенного при помощи Guardant API 7 версии, поставляется "старый" конфигурационный файл gnclient.ini?