Спасибо, Станислав.

Пожалуйста, Владимир.

Станислав Петрушевский пишет:

Здравствуйте!

1. Ознакомьтесь, пожалуйста, с информацией об удалённом обновление ключа с помощью Guardant API
http://developer.guardant.ru/pages/view … Id=1278396

2. В GrdUtil должен быть открыт образ, в котором содержится соответствующий пароль удалённого обновления.

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

Здравствуйте, Владимир!

Спасибо Вам за хорошую идею, я передал Ваше пожелание разработчикам.
На текущий момент такую информацию мы предоставить не можем.
Все возможные варианты описаны выше, это GrdTRU и Guardant API.

Здравствуйте!

1. Ознакомьтесь, пожалуйста, с информацией об удалённом обновление ключа с помощью Guardant API
http://developer.guardant.ru/pages/view … Id=1278396

2. В GrdUtil должен быть открыт образ, в котором содержится соответствующий пароль удалённого обновления.

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

Здравствуйте, Станислав!

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

Другой момент связан с паролем удаленного обновления, который
в БД GrdUtil хранится вместе с образом. Этот пароль извлекается из последней прошивки
при удаленном обновлении. Если для каждого ключа пароль удаленного обновления свой,
приходится вручную следить, чтобы образ, который прошивается в ключ содержал корректный пароль,
иначе последующее TRU не выполняется.
(В этом случае помогает удаление последней прошивки из БД).
Проблем не возникает, если каждый следующий образ для ключа создавать
на базе последнего прошитого в ключ. Но в большинстве случаев образ создаётся на
основе другого образа-шаблона и пароль TRU приходится переносить вручную.

Здравствуйте!

1. Ознакомьтесь, пожалуйста, с информацией об удалённом обновление ключа с помощью Guardant API
http://developer.guardant.ru/pages/view … Id=1278396

2. В GrdUtil должен быть открыт образ, в котором содержится соответствующий пароль удалённого обновления.

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

Другой момент связан с паролем удаленного обновления, который
в БД GrdUtil хранится вместе с образом. Этот пароль извлекается из последней прошивки
при удаленном обновлении. Если для каждого ключа пароль удаленного обновления свой,
приходится вручную следить, чтобы образ, который прошивается в ключ содержал корректный пароль,
иначе последующее TRU не выполняется.
(В этом случае помогает удаление последней прошивки из БД).
Проблем не возникает, если каждый следующий образ для ключа создавать
на базе последнего прошитого в ключ. Но в большинстве случаев образ создаётся на
основе другого образа-шаблона и пароль TRU приходится переносить вручную.

Здравствуйте!

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

В качестве стандартных средств обновления, которые поставляются с SDK,
используются утилиты GrdUtil.exe и GrdTRU.exe.

В идеале, хотелось бы реализовать систему обновления, совместимую с
утилитой GrdTRU.exe. Однако, насколько удалось понять, в этой
утилите применяется особый формат обмена сообщениями (question, update, answer).
В документации информацию об этом найти не удалось.

Возможно ли получить информацию о формате указанных сообщений,
если она не является закрытой?

При разработке собственной утилиты обновления она должна содержать
внутри себя ключ private read.
Насколько опасна компрометация этого ключа?
Существуют ли какие-то рекомендации по хранению этого ключа в исполняемом файле?

С уважением, Владимир

Здравствуйте, Владимир!
Уточните, пожалуйста, чем Вас не устраивает штатная утилита обновления ключей Guardant?
Хочу сразу заметить, что компрометацию кодов доступа лучше не допускать.

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

В качестве стандартных средств обновления, которые поставляются с SDK,
используются утилиты GrdUtil.exe и GrdTRU.exe.

В идеале, хотелось бы реализовать систему обновления, совместимую с
утилитой GrdTRU.exe. Однако, насколько удалось понять, в этой
утилите применяется особый формат обмена сообщениями (question, update, answer).
В документации информацию об этом найти не удалось.

Возможно ли получить информацию о формате указанных сообщений,
если она не является закрытой?

При разработке собственной утилиты обновления она должна содержать
внутри себя ключ private read.
Насколько опасна компрометация этого ключа?
Существуют ли какие-то рекомендации по хранению этого ключа в исполняемом файле?

С уважением, Владимир