Где я могу хранить (и управлять) информацию о лицензии на приложение?

Ответ 1

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

Где

Если они удаляют файл данных лицензии, тогда перезапуск? Не запускайте приложение, если файл не существует, и создайте его с установленным действием при первом запуске.

Теперь у вас возникает вторая проблема: что делать, если они удаляют и переустанавливают приложение? Второй шаг - переместить этот файл в папку данных приложения (например Environment.SpecialFolder.CommonApplicationData). Это немного более безопасно (поскольку данные приложения не удаляются при удалении), но все же их можно вручную найти и удалить. Если приложение будет установлено пользователями с низкими привилегиями, вы не можете сделать это (вы не можете скрыть лицензию где-нибудь в реестре).

Теперь это игра между вами и крекеры. Они победят, всегда. Вы только усложняете жизнь законных пользователей, поэтому читайте cum grano salis. Где вы можете хранить данные лицензии:

• Реестр. Pro: легко сделать. Минусы: легко взламываются, а для пользователей с низкими привилегиями он действителен только для одного пользователя за раз. Раздел реестра (в базе для каждого пользователя) может быть как-то скрыт, если он имеет \0 в своем имени. Взгляните на этот хороший пост.
• Файл. Pro: легко сделать и IMO немного безопаснее, чем реестр. Минусы: легко взломать (но вы можете скрыть это больше, см. Позже).
• Само приложение (добавление данных в ваш исполняемый файл, несколько слов об этом на этот пост). Pro: сложнее обнаружить. Минусы: антивирус может увидеть это как... вирус и обновление приложения могут также удалить лицензию (конечно, если вы не справитесь с этой ситуацией должным образом), это сделает ваш код и развертывание более сложными.

Как скрыть лицензию в файле?
Если вы собираетесь с файлом (неважно, где он находится), вы можете подумать о том, чтобы сделать жизнь крекеров (немного) более сложной. Мне приходят в голову два решения:

• Альтернативные потоки данных. Файл прикрепляется к другому файлу, и они не будут видеть его только при поиске в проводнике Windows. Конечно, есть утилиты для управления ими, но, по крайней мере, они должны явно искать его.

• Скрыть его внутри данных приложения (растровое изображение, например, используя steganography). Они просто не знают данные лицензии, что более безопасно? Проблема в том, что они могут легко декомпилировать вашу программу на С#, чтобы увидеть, что вы делаете (см. Параграф о Обтекание кода).

Возможно, многие другие (фантазия здесь - наш мастер), но не забывайте... крекеры найдут его (если они действительно захотят), поэтому вам нужно сбалансировать свои усилия.

Как

Сохраняя свою лицензионную схему, вы теперь находитесь на мертвом пути. Решение, которое вы должны предпринять, заключается в том, что риск, который они используют, дольше, чем разрешено, выше, чем риск того, что они перестанут использовать ваше приложение из-за защиты от расточки.

Validation
Если вы можете предположить, что у них есть сетевое подключение, вы можете проверить лицензию в режиме онлайн (только при первом запуске своего приложения) с использованием некоторого уникального идентификатора (даже если это касается Windows 8, вы можете взглянуть на этот пост здесь на SO). Проверка на стороне сервера может быть довольно сложной (если вы хотите сделать это правильно), в этот пост объясняется пример потока программы для управления этим в правильном путь.

Обфускация данных/шифрование
Ваш файл/данные лицензии теперь находится в безопасном месте. Вряд ли взломщики найдут его. Теперь вам нужен еще один шаг: обфускация. Если ваши данные лицензии находятся в обычном тексте, как только они нашли ваш файл, его слишком легко изменить. У вас есть некоторые опции (упорядоченные по повышенной безопасности и сложности):

• Обфускайте свои файлы. Если они не могут понять, что внутри файла с помощью простого текстового редактора (или даже шестнадцатеричного редактора), им потребуется больше времени и усилий, чтобы взломать его. Например, вы можете сжать их: см. Эту статью о обфускации файла XML с сжатием. Обратите внимание, что также простая кодировка base64 будет запутывать ваши текстовые файлы.
• Зашифруйте их с помощью симметричного алгоритма. Даже очень простой будет работать хорошо, здесь вы просто пытаетесь скрыть данные. См. этот постдля примера. Я не вижу причины предпочесть этот метод для более простой обфускации.
• Зашифровать их с помощью асимметричного алгоритма. Этот вид шифрования является большим шагом в сложности и безопасности, и он будет (очень) полезен, только если маркер лицензии предоставляется сервером/внешним объектом. В этом случае он будет запутывать лицензию, подписанную с ее закрытым ключом. Клиентское приложение будет проверять подпись с открытым ключом, и даже если взломщик найдет этот файл (и декомпилирует ваш код для чтения открытого ключа), они все равно не смогут его изменить, потому что у них нет закрытого ключа.

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

Обфускация кода
Если вы не используете подписывание лицензии с асимметричным шифрованием, то последним шагом является обфускация вашего кода. Независимо от того, что вы сделаете, они смогут увидеть ваш код, проверить ваш алгоритм и обходным путем. Настолько печально, что вы развертываете инструкцию! Обфускация с помощью обфускатора, если вы хотите, но я настоятельно рекомендую вам перевести вашу лицензионную проверку в менее очевидное место.

• Поместите весь свой код, связанный с лицензией, в отдельную DLL. Подпишите его (помните, что подписанные сборки могут быть декомпилированы и перекомпилированы для удаления подписи, есть даже инструменты, чтобы сделать это почти автоматически).
• Упакуйте его в исполняемые ресурсы (с не столь очевидным именем) и не развертывайте DLL.
• Обработать событие AppDomain.AssemblyResolve, когда ваша DLL понадобится во время выполнения, вы распакуете в памяти и вернете поток байт. Подробнее об этой технике см. этот пост Джеффри Рихтера.

Мне нравится этот метод, потому что они увидят, что есть проверка лицензии, но... они не найдут код лицензии. Конечно, любой хороший взломщик разрешит эту проблему за 10 минут, но вы будете (немного более) безопасны от случайных.

Выводы

Подводя итог немного, это список того, что вы можете сделать, чтобы обеспечить более сильную проверку лицензии (конечно, вы можете пропустить один или несколько шагов, но это снизит безопасность):

• Разделите код проверки лицензии на две сборки (один для выполнения проверки и управления лицензией, а другой для обеспечения открытого интерфейса для этого движка).
• Сильный знак всех ваших собраний.
• Вставьте свою сборку Engine Engine внутри вашей сборки лицензионного интерфейса (см. раздел Obfuscation кода).
• Создайте сервер лицензий, который будет управлять вашими лицензиями. Будьте осторожны, чтобы обеспечить безопасность, обеспечить безопасное соединение и безопасную аутентификацию (см. Раздел "Проверка" ).
• Сохраните файл лицензии локально в безопасном месте (см. раздел "Где" ) и зашифрован с помощью асимметричного алгоритма шифрования (см. раздел "Обтекание данных" ).
• Иногда проверяйте лицензию на своем сервере лицензий (см. раздел "Проверка" ).

Дополнение: Защитные ключи для защиты программного обеспечения
Небольшое дополнение к аппаратным ключам (программные защитные ключи). Они являются бесценным инструментом для защиты вашего программного обеспечения, но вы должны еще более тщательно разрабатывать свою защиту. Вы можете предположить, что аппаратное обеспечение очень безопасно, но слабыми точками являются его связь с компьютером и связь с вашим программным обеспечением.

Представьте, что вы просто храните лицензию в ключе, взломщик может использовать внешний USB (при условии, что ваш SPD является USB) для совместного использования одного и того же ключа с несколькими компьютерами. Вы также должны сохранить уникальный идентификатор оборудования в ключе, но в этом случае слабой точкой является соединение (аппаратное обеспечение может быть эмулировано программным драйвером). Это довольно простая трещина и ложное чувство безопасности ( "я использую Software Protection Dongle, мое программное обеспечение безопасно" ) сделает ваше приложение еще более уязвимым (потому что вы рискуете забыть другие основные меры защиты, чтобы упростить управление лицензиями).

Стоимость и преимущества для плохой разработанной защиты с использованием SPD должны заставить вас подумать о том, чтобы использовать обычный USB-накопитель. Это стоит 1 $вместо 15/20 $(или намного больше) для SPD, и у вас есть такой же уровень защиты от случайных взломщиков. Конечно, это не остановит серьезный взломщик, но также плохой дизайн SPD не остановит его.

Настоящая защита (при условии, что вы не работаете на устройстве с поддержкой DRM) является ключом, который также может выполнять ваш код, Если вы можете переместить некоторые основные алгоритмы (по крайней мере, для дешифрования жизненно важных и динамических файлов поддержки) в ключ, тогда для взлома вашего программного обеспечения им потребуется взломать аппаратное обеспечение. Для полупристойного ключа это очень сложная задача. Более тщательно вы разрабатываете этот и более код, который вы переходите в ключ, и больше вы будете в безопасности.

В любом случае вы должны сомневаться в маркетинговых кампаниях: защита программного обеспечения с помощью ключа не проще. Это может быть (намного) более безопасным, но это не так просто, как говорят продавцы. На мой взгляд, стоимость защиты плагинов n-play слишком высока по сравнению с ее преимуществами (преимущества = сколько это сделает жизнь крекеров более сложной).

Ответ 2

К сожалению, везде, где вы храните информацию о лицензии на клиентской машине, она открыта для злоупотребления (потому что это их машина!).

Единственный безопасный способ сделать это - проверить вашу программу с помощью удаленной службы, что, очевидно, требует больших накладных расходов.

Мой собственный подход заключается в том, что если клиенты воюют с их лицензионным ключом, тогда они должны ожидать проблем, и вы не обязаны помогать. Я бы удостоверился, что ваш ключ содержит информацию о запущенном компьютере (чтобы предотвратить простое копирование ключа), но в остальном это очень просто.

Когда я сам изучал лицензирование, я нашел философию, к которой я, как правило, придерживаюсь: вы оттесняете больше потенциальных клиентов с запутанными и сложными настройками лицензирования, чем вы теряете из-за пиратства.

Мое предложение состояло бы в том, чтобы вы отменили логику - вместо того, чтобы разрешить удаление лицензионного ключа для перезапуска бесплатной пробной версии, почему бы не заставить их иметь лицензионный ключ для разблокировки полного приложения?

Ответ 3

Если вы собираетесь писать в HKEY_CURRENT_USER, вам не понадобятся права администратора. с другой стороны, для записи в HKEY_LOCAL_MACHINE требуются права администратора.

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

RegistryKey key = Registry.CurrentUser.OpenSubKey(@"Software\YourAppPath", true);

если это не работает для вас, есть хитрость для записи в конец самого исполняемого файла, но это еще одна вещь.