Выбираем на чём делать приложение для windows и linux  c GUI.
Без учёта защиты предпочтительно было бы на С#, .NET Core, Avalonia. Но!
У вас на сайте во многих местах написано

Например, тут https://dev.guardant.ru/display/KB/0023.

Положим, для Avalonia MVVM опционально, но рефлексия в .NET используется очень много где, сериализация, базы ...
Поискав по форуму немного вижу ссылок про .NET приложения c GUI, в основном проблемы которые неизвестно как были решены.

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

Вы уже давно поддерживаете .NET, какая то статистика у вас накопилась.  Что посоветуете?

const char* visibility =
"{ \"remoteMode\": 2, \
\"controlCenter\": \
{ \
\"hostName\": [ \"127.0.0.1\" ], \
\"connectionTimeout\" : 10 \
} \
}";

И приложение и ControlCenter работают на локальной машине с Ubuntu, на ней же установлена лицензия.

С помощью WireShark записал обмен с ControlCenter на порте 3189. После обмена HTTP  пакетами обмен переходит на WebSockets по grdnet-protocol. Записал payload двух пакетов, отправляемых ControlCenter приложению. Подменил  ControlCenter на сервер, который шлет эти ответы. Результаты для меня неожиданные —  GrdFeatureLogin и Logout успешно отрабатывают для любого feature ID.

Конфигурация не столь искусственна, как может показаться: мы планируем дать пользователю возможность настраивать IP адрес, на котором находится ControlCenter и возможность rehost лицензии.
Собственно, вопрос — это ожидаемое поведение? Если да, то как от него защититься? Усложнить анализ путем увеличения трафика (навтыкать много разных обращений к GCC через API)?

2. Работа через API предполагает использование статической или динамической библиотеки grdlic (как минимум в Linux исполнении).  При линковке нативного приложения я могу использовать статическую библиотеку, убрать символы и обфусцировать. В случае python wrapper предполагается  использовать именно динамическую библиотеку. Так ли я понимаю, что в случае динамической библиотеки нет никакой, предоставляемой guardant, защиты от ее подмены на stub?

Я ни в коей мере не являюсь специалистом по защите или взлому, так что мои вопросы могут показаться тривиальными и ответы очевидными. Тем не менее буду благодарен за ответы)

Во первых, у вас в разных местах на сайте либо не указан rust, либо указан только для linux (https://dev.guardant.ru/pages/viewpage. … d=71476159).

Предполагаю что утилита автозащиты приложение rust зашифрует, а дело просто в том что вы не предоставляете rust-овский крейт для доступа к Guardant API. Если так, не страшно. ИИ поможет его сделать из h файла.
Но хочу уточнить на всякий,  может быть существуют какие то принципиальные тонкости и защищать стоит только приложения на указанных у вас языках?

Второй момент. На форуме прочитал что технология SLK требует ключей выпущенных начиная с 2020 года. У наших пользователей много ваших ключей Sign и более ранних выпусков и мы собираемся предоставить и им доступ к будущему приложению.
Приложение будет и для win, и для linux. Ранее мы защищённые приложения для linux не делали. Как я понял, автоматическая защита может быть навешана под windows на linux - исполняемый файл или so ? Сборка приложения в linux, в том числе с использованием Guardant API, потом копирование в windows и навешивание автозащиты там. Если так, устраивает если это про SDK, т.к., если для защиты под linux потребуется переходить на SLK и менять ключи у пользователей, ну, тогда надо думать ...

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

С переводом в режим HID я разобрался, надо вызывать GrdProtect с параметром dwGlobalFlags=GrdGF_HID.

Не понятно, как и когда использовать функцию GrdSetDriverMode.
У меня всегда выдает ошибку 1 GrdE_DongleNotFound.
В примерах из SDK нигде не вызывается.
Проблема в том, что ключ Sign, а не Code? Хотелось бы пояснений на этот счет.

Второй вопрос по определению текущего режима ключа Guardant driver/HID.
Утилита grddiag.exe показывает "Глобальные флаги HID".
Как мне программно считать глобальные флаги?
В адресах GrdSAM_... или GrdUAM_... для GrdRead ничего похожего не нашел.

Если я руками в grdutil.exe переключаю Driver/HID в панели инструментов, то вижу, что в .nsd-файле меняется 4 байта со смещением 4 в Data. Как мне в runtime поймать это отличие в памяти ключа?

Обнаружил, что GrdCRC() выбрасывает исключение "Range Check Error" на некоторых данных.

• Перепрошить старые ключи Sign, Stealth II для нового приложения

• Сделать единую прошивку, подходящую для обоих приложений, чтоб SDK и SLK работали с одним и тем же физическим ключом

Я знаю, что могу получить оставшееся время жизни алгоритма через GrdPI_GetTimeLimit(). Но из нее я получу структуру TGrdSystemTime, которая вернет условно: 0 лет, 5 месяцев, 27 дней, 18 часов, 45 мину, 10 секунд...

Сам вопрос: как мне пересчитать эти данные в количество оставшихся дней? Имею ли я право просто перемножить года на 365, а месяцы на 30 и сложить? Или внутренний механизм отсчета времени ключа как-то учитывает кол-во дней в текущих месяцах и високосный год?

Надеюсь объяснился понятно, заранее спасибо!