Тема: Возможность обхода проверки сетевых лицензий

Добрый день.
Извините за кликбейтное название поста, но по сути вопрос именно в этом.
Наша компания рассматривает сценарии использования сетевых ключей от Guardant. Загрузил SLK, более менее разобрался, как использовать API для проверки лицензии в C/C++/Python. Также попросили посмотреть на легкость обхода лицензии. Возникла пара вопросов.
1) Тестовая конфигурация:
минимальное тестовое приложение на С, вызывает GrdFeatureLogin()
и GrdFeatureLogout().

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?

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

Re: Возможность обхода проверки сетевых лицензий

Добрый день,

Благодарим за ваше обращение.
Если использовать только Login\Logout в паре с программными ключами, то описанный кейс вполне ожидаемый и если коротко, то решается защитой приложения при помощи протектора Guardant Protection Studio (если тип приложения поддерживаемый нашим протектором) или же внедрением функций шифрования и подписи из нашего Guardant Licensing API.

Немного позже подготовим более раскрытый ответ по методам защиты от этого через API.

Re: Возможность обхода проверки сетевых лицензий

Александра, спасибо за ответ.
Действительно, Protection Studio не дает залогиниться в компонент с помощью простого replay пакетов.
Но мы предпочли бы использовать API.

Немного позже подготовим более раскрытый ответ по методам защиты от этого через API.

Буду признателен за обзор методов защиты через API.