Вы не авторизованы. Пожалуйста, войдите или зарегистрируйтесь.
Форум Guardant → Технологии защиты → Новые Guardant Code. Обвновление при помощи TRU
Страницы 1
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Подходят к концу запасы ключей с процессором ARM, скоро прийдётся закупать партию с Cortex. Код под новую архитектуру я перекомпилирую, но возникает вопрос: как отличить поколение ключей у клиентов, для того, чтобы выполнять обновление соответствующей маской?
Здравствуйте, romik.
Отличить поколения ключей можно так:
1. По номеру модели в маркировке - "9" и "А" для новых моделей Code и Code Time соответственно (для старых моделей используются номера "7" и "8")
2. По номеру микропрограммы в утилите диагностики: для старых ключей номер имеет формат 1.0.0.х. Для новых 1.0.2.х.
Вопрос не об этом!
Например, у меня есть какое-то количество клиентов, у половины старые ключи, у второй половины новые. Клиент присылает запрос на обновление прошивки. Как я смогу узнать, какой модели у него ключ, чтобы сформировать обновление правильной маской?
Пока я вижу только один вариант - идентифицировать ключ по имени предыдущей маски, которая была в него записана. Получается, что нужно параллельно вести две одинаковые маски для старой и новой архитектуры, которые будут отличаться только ячейками загружаемого кода?
Да, такой вариант возможен.
Если Вы используете для обновления наши стандартные утилиты, то они выдают id, по которому можно установить в базе данных, какой конкретно ключ требуется обновить (когда произведен, версия прошивки и т. п.)
Ещё вариант - делать соответствующие пометки в базе данных.
Для обновления использую стандартные утилиты, но что-то не найду в них как по ID ключа клиента посмотреть информацию, о самом ключе.
Подразумевалось немного другое, а именно: в базе данных делаются любые необходимые пометки(например о поколении ключа), затем при необходимости обновления ключа, зная его ID, очень просто извлекать эти комментарии(пометки), следовательно определять поколение ключа.
Не совсем понятно, в чём конкретно заключается трудность запроса необходимой информации у пользователя из отчёта утилиты диагностики.
В дополнение всему вышесказанному, ознакомиться с инструкциями по миграции можно здесь: https://www.guardant.ru/download/manual … ode_NG.pdf
Варианты с пометками в базе, и утилитой диагностики понятны, но хотелось бы получить информацию без лишних действий со стороны клиента.
На практике ситуация выглядит так: я подготавливаю десяток ключей, прописывая их некой пустой начальной маской, иду на почту, и рассылаю ключи клиентам, не заботясь о том, кому какой ключ попадёт. Когда ключ приходит к клиенту, он формирует запрос на обновление. Дальше всё делается стандартными утилитами: нашел прошивку по числу-вопросу, зарегистрировал её на конкретного клиента, сформировал файл-обновление.
Без лишних действий со стороны пользователя можно попробовать следующий алгоритм:
Число-вопрос, помимо всего прочего, содержит ID обновляемого ключа. ID, по сути, содержит в себе точную дату производства ключа (потому и уникален). Так как новые ключи мы начали производить с определенного момента, то по ID можно косвенно понять, новый это ключ, или старый. ID, в частности, отображается утилитой GrdUtil при введении числа-вопроса в соответствующем поле диалога обновления.
Также можно оставлять комментарий (что ключ новый) у маски ключа при его программировании. В результате при загрузке маски по числу-вопросу будет видно, что ключ новый. Однако этот вариант не очень хорош тем, что придется именовать все маски для новых ключей.
Дополняя ответ моего коллеги, хочу отметить, что новые ключи Code начинаются с ID 2AE56697 , новые ключи Code Time с ID 2AEC5220 .
При генерации клиентского дампа обновления на стороне разработчика, утилита GrdUtil использует локальный ключ соответствующей модели. Вопрос: можно ли использовать локальный ключ старого поколения для генерации дампов к ключам нового поколения, и наоборот?
Нет, такая возможность не предусмотрена, не тестировалась и не будет тестироваться в дальнейшем. Но теоретически, в некоторых случаях, не исключаем, что такая схема может сработать.
Не совсем понимаю, с чем это связано. Уточню свой вопрос, под "старым" и "новым" поколением имелись ввиду ключи Code с процессорами ARM и Cortex соответственно.
Не совсем понимаю, с чем это связано. Уточню свой вопрос, под "старым" и "новым" поколением имелись ввиду ключи Code с процессорами ARM и Cortex соответственно.
Мы Вас поняли, про поколения ключей. Вообще говоря - теоретически все должно работать, т.к. кроме ячеек с загружаемым кодом - маски идентичны. При этом нужно иметь в виду, что при расшифровании числа вопроса и зашифровании числа ответа в ключ на стороне разработчика временно записывается некая специальная маска (формируемая на основе данных обновляемого ключа), и мы не можем гарантировать, что процесс пройдет успешно для различных поколений ключей в дальнейшем.
Мой коллега лишь хотел обратить внимание, что эту возможность мы не тестировали - и если она работает - то замечательно, если нет - увы. Можете попробовать самостоятельно (скорее всего Вы это уже сделали).
Пожелание разработчикам: если это возможно, сделать дополнительное API для формирования числа-вопроса, и обработки ответа от разработчика в формате, совместимом с утилитой GrdUtil. Чтобы на стороне клиента этот функционал можно было встраивать в свою программу, и не использовать GrdTRU, а на стороне разработчика пользоваться стандартной утилитой.
Страницы 1
Чтобы отправить ответ, нужно авторизоваться или зарегистрироваться
Форум Guardant → Технологии защиты → Новые Guardant Code. Обвновление при помощи TRU
