Вопросы все те же, но появились кое-какие соображения.
Думаю использовать таблицу лицензий, т.к. кроме защиты нужно ограничивать набор доступных модулей.
Также должна быть сетевая версия и локальная. Соответственно предполагается использовать сетевую и локальную версию ключа. В связи с этим еще один вопрос. Возможно ли с одним бинарником программы отгружать локальную или сетевую версию ключа и тем самым различать версию программы? Или нужно делать две версии бинарника, отдельно для локальной версии и отдельно для сетевой?
]]>Можно об этом подробнее?
Можно и поподробнее, но уже после новогодних праздников :)
]]>Guardant Code более чем приспособлен для решения таких конфликтных ситуаций, но даже на Sign, взяв за хранилище сессий защищенные ячейки (что менее надежно, чем работа с CODE) можно обеспечить более-менее грамотную защиту при наличии терминальных режимов работы.
Можно об этом подробнее?
]]>Прошу еще раз подтвердить, что несколько разных программ смогут одновременно работать с одним ключем каждая в своей сессии GrdLogin()-GrdLogout().
Ваша цитата SDK относится только к варианту автозащиты и для нее ответ - смогут.
Если работать с ключами "ручками", то так-же смогут, причем без всяких ограничений.
Если же вам потребуется именно аппаратная отсечка второго логина из сторонней терминальной сессии, то вам придется реализовать ее самому, не оглядываясь на утилиту автозащиты, ибо есть много нюансов.
К примеру что есть защита от терминала:
По сути это сеансовый ключ, которым шифруется траффик обмена с ключем (утрированно).
Допустим Вы связались с ключем из терминальной сессии А и работаете, после чего вы связываетесь с ключем из терминальной сессии Б, где для вас генерируется новый сессионный ключ (о котором знает железка) и о данном ключе ничего не известно приложению из сессии А. Но вот приходит время и код из сессии А обращается к ключу и ему приходит ошибка - неверный сессионный ключ GrdE_InvalidSessionKey.
Что мы можем сделать в данном случае?
Либо отвалится с ошибкой (сказав, что у нас это такая вот защита от повторного логина с терминальных сессиях).
Либо... просто перелогинится и продолжить работу с ключем, правда при этом новый ключ станет не валидный для сессии Б, но ПО запущенное в данной сессии (Б) так-же сможет перелогинится (при необходимости) и продолжить работу как будто ошибок и не было :)
В итоге получается такая вот чехарда с перегенирацией сессионных ключей, которую нужно как-то контролировать самостоятельно.
Заметьте, если у Вас не предусмотрен механизм релогина - его достаточно просто сможет реализовать взломщик вашего ПО (убрав отказ вашего кода на первую же ошибку GrdE_InvalidSessionKey).
Отсюда следует, что данный момент нужно тщательно продумать.
Guardant Code более чем приспособлен для решения таких конфликтных ситуаций, но даже на Sign, взяв за хранилище сессий защищенные ячейки (что менее надежно, чем работа с CODE) можно обеспечить более-менее грамотную защиту при наличии терминальных режимов работы.
]]>Технология, реализованная в ключах Guardant, позволяет обеспечивать работоспособность только одной копии запущенного приложения. Для этого электронный ключ при предпродажном программировании должен быть переведен в один из режимов ограничения количества сеансовых ключей:
Один сессионный ключ для автозащиты
Один сессионный ключ для API
Два сессионных ключа (по одному для автозащиты и API)
это опция, которую можно включить/выключить, или возможен только один из трех перечисленных вариантов?
Прошу еще раз подтвердить, что несколько разных программ смогут одновременно работать с одним ключем каждая в своей сессии GrdLogin()-GrdLogout().
]]>Защищаемое ПО представляет собой набор сервисов (службы Windows) и графическое приложение (ГУИ).
Предполагаю использовать ключ SIGN, но окончательного решения пока нет.
Первой мыслью было защитить только ГУИ, а сервисы оставить как есть. Но при дальнейшем рассмотрении возможных конфигураций работы ПО оказалось, что желательно защитить и сервисы тоже. Получается, что одним ключем нужно защитить несколько программ. Возможно ли это?
]]>