Независимо от того, запутываете ли вы код или нет, дело в том, что ваша техника небезопасна и может быть побеждена. Схема лицензирования вашего продукта будет такой же надежной, как и ваша обфускация.
Вместо того, чтобы использовать RSA для шифрования уникального идентификатора или файла лицензии, рассмотрите возможность использования RSA для шифрования модуля, сборки или библиотеки классов с основными компонентами ядра или некоторыми ключевыми функциями, которые вы хотите использовать только в приобретенной полной версии. Таким образом, без надлежащей лицензии функции полной версии или логика ядра приложения просто отсутствуют, вместо того, чтобы вся ваша тяжелая работа была украдена с инструкцией JMP к точке входа вашей полной версии, «лицензионного» программного обеспечения.
По сути, наиболее простой из реализаций этой концепции было бы сделать «лицензию», которую вы получаете после покупки, и вставить в программу открытый ключ для расшифровки зашифрованных модулей / сборок. Однако вы не захотите этого делать, поскольку один человек может приобрести «лицензию», а затем раздать ее всем или опубликовать в своем блоге. По крайней мере, ключ, который расшифровывает функциональность полной версии, должен быть зашифрован с использованием другого ключа и включен в каждую копию программного обеспечения. Тогда «лицензия» будет открытым ключом, который расшифровывает реальный ключ, который выполняет дешифрование защищенного программного обеспечения. Таким образом, вы можете иметь несколько версий лицензии или изменить ее, если она будет размещена на всех популярных веб-сайтах сериалов.
Далее, «лицензия», которая шифрует лицензию, будет просто хеширована или симметрично зашифрована с помощью «уникального идентификатора» компьютера, который предоставляется серверу через некоторое время во время обработки платежа. Таким образом, только тот компьютер может генерировать правильную «парольную фразу», если хотите, которая может восстановить ключ для расшифровки ключа для дешифрования программы / dll / whathaveyou.
В идеале вы должны расшифровать модуль в защищенном пространстве памяти, которое не может быть прочитано другими приложениями и не выгружено на диск, затем запускается из памяти и перезаписывается, как только вы закончите с ним. Конечно, этот метод не является непогрешимым, и решительный инженер может потенциально получить дешифрованный модуль для перераспределения, но даже для этого кто-то должен был бы купить у вас юридическую лицензию где-то вдоль линии.
Другие идеи включают в себя сохранение основных функциональных возможностей или ключевых структур данных в виде скомпилированного машинного языка или промежуточного языка, в зашифрованном виде и на каком-либо сервере, который должен пройти проверку, чтобы получать эту информацию с сервера каждый раз, когда необходимо выполнить эту функцию, и расшифровывается непосредственно в защищенную память, из которой он выполняется, но такой уровень сложности вряд ли необходим и не обеспечивает значительной дополнительной безопасности для уровня сложности.
Надеюсь, я дал вам кое-что подумать. Имейте в виду, что контроль количества копий, которые делает пользователь, становится невозможным, если все это дешифровано и доступно для копирования пользователем, поэтому я рекомендую сохранять некоторые компоненты в зашифрованном виде, когда приложение не выполняется.