Все алгоритмы по умолчанию защищаются как от чтения так и от записи, поэтому их изучение модификация посторонним лицом невозможны. Даже если злоумышленники украли у Вас коды доступа к ключу, максимум, что они смогут сделать, это отформатировать ключ.  По сути - уничтожить лицензию.

Если же появляется новый не предусмотренный ранее модуль, вы можете добавить его через TRU. Наиболее легкий способ в этом случае - переписать с помощью TRU новый образ ключа целиком с новым алгоритмом. Причиной тому является необходимость модификации таблицы алгоритмов и защищенных ячеек (PIAT), где хранятся адреса алгоритмов для микропрограммы. Т.е. чтобы добавить алгоритм в рабочий ключ, нужно модифицировать несколько областей памяти. В случае же, когда алгоритмов становится больше определенного количества, таблица PIAT увеличивается в размерах, что приводит к смещению всех полей, следующих за ней. Все это делает частичное обновление алгоритмов крайне нетривиальной задачей. Увы удобством здесь пришлось пожертвовать для увеличения возможностей ключа, чьи ресурсы не так велики.

Поэтому моя рекомендация для Вашей схемы следующая: завести максимальное число алгоритмов заранее, установив неактивное состояние тем из них, которые отвечают за допмодули. По мере покупки пользователями  модулей активировать нужные алгоритмы. В случае TRU это будет просто перезапись байта состояния нужного алгоритма (нужно знать точный адрес). В обычном случае - вызов функции активации алгоритма на машине конечного пользователя. Первый способ безопаснее, второй - легче. Хотя, все зависит от инфраструктуры поддержки. Например, утилита программирования умеет прописывать уникальные пароли доступа к алгоритмам для каждого конкретного экземпляра ключа и хранить это все в базе данных (MS Access или SQL Server). В этом случае перехват вызова функции активации алгоритма у конечного пользователя будет бесполезен, т.к. пароль не сработает на других ключах.

С уважением, Алексей Лазарев

Насколько я понял я заранее прописываю в ключ пользователя все алгоритмы под каждый модуль и активирую их по мере необходимости? Ну а при выходе нового модуля я просто делаю TRU обновление?
Получается что ключ будет иметь все модули сразу, только неактивные, насколько это безопасно?

Т.е. получается что я могу используя Guardant API автоматизировать процесс запрос/ответ для TRU и создать собсвтенный сервис обновлений? Если так, то это здорово!

Ну я думаю, что приложение начинает некорректно работать, не просто if(!securitySignVerified) { Close(); }, конечно же используя аппаратные алгоритмы я буду проверять подпись и использовать результат проверки в приложении...

Наиболее надежным, на мой взгляд, способом лицензирования  на локальном ключе многомодульных приложений, является привязка конкретного модуля к своему собственному алгоритму, заранее прописанному в ключ при помощи утилиты программирования ключей. У каждого алгоритма есть сервисы активации и деактивации, которые позволяют включать или выключать соответствующий алгоритм по мере надобности. В ключах Code Time, помимо прочего можно задать время автоматической активации либо деактивации ключа.

Теперь по порядку:

>1. Насколько это безопасно и насколько можно сделать это безопасным?
В состав API входят функционал Trusted Remote Update (TRU), с помощью которого ключи могут обновляться по защищенному протоколу. Примеры использования также входят в состав комплекта разработчика. Если необходимо запустить именно online-сервис обновления, то на базе этой технологии это можно сделать.

>2. Насколько реально защитить .NET приложение той же цифровой подписью, скажем конечного .exe?
Здесь все зависит от способа проверки подписи.

>3. Вообще насколько стойкая эта защита с цифровыми подписями на каждый модуль?
Не думаю, что это вообще надежный способ защиты от копирования.

>4. Как работает обфускация Guardant с рефлексией, что нужно учитывать при написании модулей/приложения?
В автозащите для .Net есть возможность отключить символьную обфускацию для Public-интерфейсов. Кроме того, есть возможность отключать любой режим обфускации для любого метода, правда, это кропотливое занятие :)

C уважением,
Алексей Лазарев.

Структура программы
Есть защищаемое приложение написаное на .NET 4.0, а также есть дополнительные модули в виде .dll сборок, которые грузятся динамически(через System.Reflection). У разных пользователей может быть разный набор этих самых модулей. В любой момент пользователь может докупить модуль к приложению. Частота обновления модулей(выхода новых версий dll) - 1-2 месяца. Также и с самим приложением.
Предполагаемая защита
Первое что приходит в голову это использовать защищеные ячейки памяти ключа + загружаемый код и реализовать следующее:

• В ключ прописаны цифровые подписи для каждого модуля

• При загрузке каждого модуля проверяется существует ли такая подпись в ключе, если нет, то модуль не работает(или работает некорректно)

Задача защиты сделать невозможным добавление сторонних модулей(взятых у другого пользователя), а также защиты приложения от копирования.

Возникает ряд вопросов:
1. Необходимо реализовать онлайн обновление, для того, чтобы дописывать модули или обновлять существующие(со сменой версии, ясное дело поменяется ЭЦП). Допустим есть сервер, с которым приложение связывается и скачивает новые библиотеки, а потом с разрешения серверва пишет их в ключ. Насколько это безопасно и насколько можно сделать это безопасным?
2. Насколько реально защитить .NET приложение той же цифровой подписью, скажем конечного .exe?
3. Вообще насколько стойкая эта защита с цифровыми подписями на каждый модуль?
4. Как работает обфускация Guardant с рефлексией, что нужно учитывать при написании модулей/приложения?

Пока такие вопросы, думаю в этой теме буду задавать вопросы и дальше. Заранее спасибо за ответ! Также рад услышать рекомендации по защите подобного рода ПО.