В MS VS 2019 всё работает...

.Net 4.8

Выбираем на чём делать приложение для 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 и менять ключи у пользователей, ну, тогда надо думать ...

Лог:
05.12.2025 12:05:30 UTC+03:00 | GrdDongleSetLicense: код состояния = 23, сообщение = Некорректный аргумент функции
  серийный номер = L5FVwW-S7rUAH-VVfBST-77oePN-i7xXWb
  ID лицензии = 0x42787E37
  адрес = getlicense.guardant.ru
  порт = 443

Наш продукт использует ключи 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 поймать это отличие в памяти ключа?

Не появляется окно с сообщением об отсутствии аппаратного ключа, если запускать скрипт с командой "dotnet MyApp.dll" через *.desktop файл.
Если запускать напрямую в консоли, то выводит сообщение:

Key not found!
/usr/lib/dotnet/dotnet
./myapp-run: строка 3: 7952 Аварийный останов dotnet MyApp.dll

Так же, если извлечь ключ, то приложение просто крашится без окна с сообщением.

Как посоветуете организовать программу, что бы пользователь понимал, что требуется аппаратный ключ?

Страница разработчика ОС, где описана данная проблема:
https://wiki.astralinux.ru/pages/viewpa … =333812908
Согласно рекомендациям с вышеуказанной страницы, исключения можно избежать, если отключить контроль разрешения исполнения кода в программном стеке, добавить параметр ядра parsec.execstack со значением 1 в строку значений параметра GRUB_CMDLINE_LINUX_DEFAULT в конфигурационном файле /etc/default/grub (я это сделал через оконный менеджер).

В версии ядра 6.1.90-1-generic такой проблемы нет.

Будет ли возможность избегать необрабатываемого исключения в будущем, не прибегая к изменению загрузчика ОС?

Где посмотреть в чемпричина ?

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

Есть ли возможность прошивки сетевых USB ключей через командную строку под Linux? Дело в том, что сборка нашего продукта для каждого клиента ведется автоматически на серваке. Было бы здорово еще добавить создание через скрипт маски ключа для данного пользователя и запись ее в память ключа.