Виталий Мирошниченко пишет:

Разобрался с некоторыми нюансами.
Экспериментально установил, что nsd не подходит :( Дамп прошивки вроде бы обрабатывается нормально, но при применении уже к клиентскому ключу (метод GrdTRU_ApplyAnswer) возвращает код ошибки GrdE_InvalidData (в случае применения безопасной перегрузки метода генерации) или код ошибки GrdE_InvalidArg (в случае применения перегрузки с указателями. Ошибка в обвёртке?). Разные комбинации параметров настройки и генерации ответа не привели к вменяемому результату.

Имею такую же проблему. GrdTRU_ApplyAnswer возвращает  GrdE_InvalidArg.
Удалось ли как-то решить эту проблему?

Ответ был направлен на ваш электронный адрес.

Разобрался с некоторыми нюансами.
Экспериментально установил, что nsd не подходит :( Дамп прошивки вроде бы обрабатывается нормально, но при применении уже к клиентскому ключу (метод GrdTRU_ApplyAnswer) возвращает код ошибки GrdE_InvalidData (в случае применения безопасной перегрузки метода генерации) или код ошибки GrdE_InvalidArg (в случае применения перегрузки с указателями. Ошибка в обвёртке?). Разные комбинации параметров настройки и генерации ответа не привели к вменяемому результату.

Имею такую же проблему. GrdTRU_ApplyAnswer возвращает  GrdE_InvalidArg.
Удалось ли как-то решить эту проблему?

Да :)

16 и 32 байта соответственно. Во всяком случае для Code и Code Time

В моём случае это GrdTRU_CryptMode_AES128SHA256

Увы так и не понял :(

Экспериментально установил, что nsd не подходит :( Дамп прошивки вроде бы обрабатывается нормально, но при применении уже к клиентскому ключу (метод GrdTRU_ApplyAnswer) возвращает код ошибки GrdE_InvalidData (в случае применения безопасной перегрузки метода генерации) или код ошибки GrdE_InvalidArg (в случае применения перегрузки с указателями. Ошибка в обвёртке?). Разные комбинации параметров настройки и генерации ответа не привели к вменяемому результату.

Собственно до сих пор не понятно. Но имею подозрение, что для полной прошивки нужно указывать 0.

Пока всё. Надеюсь что в понедельник кто-то мне ответит. Если будет какой-нибудь прогресс, я отпишусь в новом посте.

PS надеюсь мои попытки и эксперименты помогут кому-то в подобных задачах.

Я сейчас работаю над проектом, использующим ключи Guardant Code Time для защиты клиентского приложения. Была поставлена задача по написанию системы автоматической предпродажной подготовки ключей. Основное требование - независимость от Guardant SDK. То есть подготовка только что доставленного чистого ключа должна проходить исключительно средствами системы без участия Guardant SDK. Другими словами - исключительно средствами GuardantApi.

Следует так же указать, что система пишется на dotNet.

Возникло ряд вопросов связанных с методами GrdTRU_*:

1. Параметр pGSII64_Key128 метода GrdTRU_SetKey должен быть байтовым массивом длиной в 16 байт?

2. Какими должны быть длины байтового массива вопроса и хеша для метода GrdTRU_GenerateQuestionEx?

3. Для метода GrdTRU_DecryptQuestionEx какие необходимо указывать флаги режима (GrdTRU)?

4. Необходимо ли использовать метод GrdTRU_SetAnswerProperties или достаточно записать в ответ образ?

5. Собственно главный вопрос: данные для записи в ключа, которые передаются в метод GrdTRU_EncryptAnswerEx - это образ в формате файла nsd? Если нет, то возможно ли получить необходимую информацию из nsd-файла?

6. В параметрах метода GrdTRU_EncryptAnswerEx фигурирует некий стартовый адрес по которому будет произведена запись. Какое должно быть его значение в данном случае?

Вроде бы всё. Заранее спасибо за ответ.

PS пытаюсь во всём разобраться сам. Возникла проблема! Метод GrdTRU_DecryptQuestionEx возвращает результат NoService. Я завёл алгоритмы AES128 Decode и SHA256 на ключе разработчика, а так же точно указал их в параметрах метода а mode установил в GrdTRU.CryptMode_AES128SHA256. В чём я ошибся?