(2012-12-20 11:40:55 отредактировано Luck)

Guardant SP и kmSN

Я правильно понимаю, что при использовании Guardant SP у всех пользователей будут ключи с одинаковыми серийными номерами kmSN (2uam/32sam)?

Можно ли как-то сделать их различными?


И более общая задача.
Можно ли сделать так, чтобы у каждого пользователя был свой уникальный ключ  Guardant SP (отличающийся не только по ID, а алгоритмами, защищенными ячейками)?

Можно ли создать (или модифицировать) шаблон Guardant SP программно?
Но, впрочем, даже если каждому пользователю выдавать свой персональный шаблон ключа, то кто им помешает установить какой-то другой шаблон? То есть,  можно ли сделать так, чтобы пользователь с помощью своего кода активации мог активировать только свой шаблон ключа?

Re: Guardant SP и kmSN

Здравствуйте, Luck.

Luck пишет:

Я правильно понимаю, что при использовании Guardant SP у всех пользователей будут ключи с одинаковыми серийными номерами kmSN (2uam/32sam)?

Нет, поле "Серийный №" (kmSN) для софтверных ключей имеет аналогичное железным ключам назначение (см. 1 часть руководства пользователя, стр. 45 - "Поля общего назначения") и значение в него записывается разработчиком при помощи утилиты программирования ключей (GrdUtil).

Luck пишет:

Можно ли как-то сделать их различными?

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

Luck пишет:

И более общая задача.
Можно ли сделать так, чтобы у каждого пользователя был свой уникальный ключ  Guardant SP (отличающийся не только по ID, а алгоритмами, защищенными ячейками)?

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

Luck пишет:

Можно ли создать (или модифицировать) шаблон Guardant SP программно?
Но, впрочем, даже если каждому пользователю выдавать свой персональный шаблон ключа, то кто им помешает установить какой-то другой шаблон? То есть,  можно ли сделать так, чтобы пользователь с помощью своего кода активации мог активировать только свой шаблон ключа?

В первую очередь тут нужно отметить то, что при активации нескольких шаблонов одним серийным номером SP-ключа, в системе всегда остается только один рабочий ключ, причем с данными из того шаблона, который был активирован последним.
Персонализировать же серийные номера можно в личном кабинете на сайте - sp.guardant.ru назначая каждому номеру свое имя продукта, и указывая номер такого продукта в шаблоне конкретного ключа (в поле "Номер программы").

Re: Guardant SP и kmSN

Антон Тихиенко пишет:

Нет, поле "Серийный №" (kmSN) для софтверных ключей имеет аналогичное железным ключам назначение (см. 1 часть руководства пользователя, стр. 45 - "Поля общего назначения") и значение в него записывается разработчиком при помощи утилиты программирования ключей (GrdUtil).
...
нужно просто записывать в каждый шаблон (та же маска, но для софтверного ключа) разное значение для данного поля.

При записи железных ключей с помощью GrdUtil kmSN автоматически инкрементировался. А еще железный ключ можно было писать с помощью самопальной утилиты, которая могла прописывать в kmSN инкрементируемое, либо случайное значение.

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

Антон Тихиенко пишет:

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

Опять, же это придется делать руками в утилите GrdUtil. Никакого АПИ, как я понимаю, нет (пока)

Так что, видимо придется сделать один шаблон софтверного ключа и поставлять его всем пользователям. Тогда у всех пользователей будут одинаковые kmSN, и вообще, ключи будут практически идентичными. Разными будут их ID. А что еще будет разным?

Кстати, ваша утилита умеет считывать из установленного софтверного ключа специфическую информацию типа "Имя разработчика", "Имя программы", "Дата активизации", а также Серийный номер (тот, который очень длинный). Как это сделать? Это записано в ключ по какому-то адресу, или нужна специальная АПИ функция?

Re: Guardant SP и kmSN

Софтверные ключи предназначены для защиты хорошо тиражируемых продуктов. Фактически, некоторые классы задач для этих ключей подходят плохо - такие как возможность иметь уникальный шаблон для каждого пользователя, и возможность активации шаблона единственно пригодным серийников. В таких случаях речь обычно об очень дорогом ПО и небольшом количестве пользователей, аппаратные ключи как правило с этой задачей справляются лучше.

Главный паттерн использования софтверных ключей таков: у вас есть некоторая продуктовая линейка, скажем из трех продуктов - "Продукт Стандарт", "Продукт Профессиональный", "Совершенно другой продукт". Каждому из них вы назначаете номер (0, 1, 2) на сервере активации. Далее для каждого продукта вы назначаете некоторое количество серийных номер, и создаете один универсальный шаблон. Для каждого продукта. Причем в шаблоне, прописываете номер этого продукта.

В результате, у вас будет один универсальный шаблон для продукта, и активировать его можно будет только серийными номерами назначенными данному продукту. Кстати, с помощью обычного Guardant API вы можете после активации (и появление ключа с уникальным ID) писать в ключ произвольную информацию - включая алгоритмы и прочее.

Теперь рассмотрим вашу задачу: для каждого клиента уникальный шаблон со своими алгоритмами, который можно активировать только одним серийником. Если вы делаете так, то для каждого шаблона у вас своя уникальная версия программы, умеющая работать только с ключом созданным на основе этого шаблона. Строго говоря, каждая копия программы у вас  уникальна и для каждой логично завести своой номер программы на сервере. Тогда у вас на  сервере будет например несколько сотен (или тысяч продуктов), для каждого из них будет создан свой уникальный шаблон, и если вы каждому продукту на сервере ассоциируете единственный серийник, то только  им можно будет активировать нужный шаблон.

Касательно API: непосредственно для создания и управления шаблонами (включая чтение специнформации) публичного API пока нет, и не могу сказать что оно в ближайших планах. В ближайшее время будет зарелизено API активации ключей. Кроме того, после активации ключа, его  можно полноценно использовать с Guardant API.

Re: Guardant SP и kmSN

Понятно. Спасибо

(2012-12-25 12:36:33 отредактировано Luck)

Re: Guardant SP и kmSN

AndreyStepin пишет:

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

Обнаружил, что вся специнформация лежит в открытом виде в файле, путь к которому можно узнать из реестра.
Там, начиная со смещения 070h лежат блоки открытого текста длиной 256 байт. То есть 070h, 170h, 270h .... Серийный номер (длинный) лежит по смещению C70h.
Информация хоть и открытая, но редактировать ее нельзя, целостность файла контролируется.
Осталось понять, как связать ID ключа с именем файла, если ключей GuardantSP несколько.  Подозреваю, что имя файла - это его ID в некой кодировке, типа Base64.

Правда, стремно пользоваться этими сведениями без одобрения разработчиков - нет гарантий, что при очередном релизе этот формат не поменяется.

Re: Guardant SP и kmSN

Luck пишет:

Осталось понять, как связать ID ключа с именем файла, если ключей GuardantSP несколько.  Подозреваю, что имя файла - это его ID в некой кодировке, типа Base64.

Действительно, расшифровав имя файла как base64 я получил 6 байт: 4 байта - это ID ключа, смысл двух других байт пока не ясен.

Re: Guardant SP и kmSN

Для просмотра списка ключей и информации в них есть утилита диагностики. В принципе, всю информацию кроме спецполей вы можете получить посредством Guardant API.

Разумеется, все что в явном виде не документировано, включая формат хранения и кодировки, а также не выпущенные официально API, - не рекомендуется нами к использованию. Только на свой страх и риск, т.к. в будущих версиях мы не гарантируем аналогичные форматы.

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