MagicLock vs SOURCEdefender——设备绑定授权 vs 加密加载

SOURCEdefender 用 AES 加密 Python 源文件，并在 import 时透明解密——对*"别人能不能读到我的 .py 文件？"*这个问题，它给出了一个干净、简单的回答。它把源码加密做得真正容易，这一点值得肯定；它的限时脚本对演示场景也是个不错的设计。MagicLock 和 SOURCEdefender 是这份清单上最可直接比较的两个工具，因为两者都是加密而非混淆——差别在于加密之后发生什么。

SOURCEdefender 做得好的地方

• 直截了当的 .pye 文件 AES 加密加透明 import——配置极少，概念极少。
• 用于到期演示的限时脚本。
• 简单的订阅制和小巧的 API 面——一个下午就能上手。

两个工具各自回答的问题不同

加密一个文件，保护的是它的保密性。但发布出去的软件还有第二个问题：**哪些机器被允许把那份密文重新变回一个运行中的程序？**一个在加载器所到之处都能解密的文件，保护的是"读"，不是"运行"。

MagicLock 把每个产物绑定到已授权的设备上：激活会登记一台机器的指纹，只有在那里解密才会成功——每次运行都通过一个五步闸门（真实性、有效性、设备、能力、新鲜度）完全离线校验。把产物复制到其它任何地方，它保持密文。

并排对比

基于截至下方日期的公开文档——最新能力请以 sourcedefender.co.uk 为准。

什么时候 SOURCEdefender 可能更合适

• 你只需要保密性——让源码在传输与静置时不可读——授权不在范围内，或已在别处解决。
• 相比设备控制，你更看重把概念数量压到最少。

什么时候 MagicLock 更合适

• 你需要控制代码在哪里运行，而不只是能否被读——由加密强制执行的按席位授权。
• 你交付的模型或数据资产需要和代码一样的按设备保护。
• 你希望发出去之后还能采取行动——在门户里停用、恢复或永久拒绝某个特定产物。
• 你想为最难对付的目标准备一个编译档位。

两个工具都做加密；MagicLock 的前提是：对商业软件而言，谁能运行它才是真正要紧的问题。免费试用 48 小时——从这里开始。