几点预防Python包被反编译的建议

要知道，独立的可执行文件决不会让应用代码变得安全，从这样的可执行文件中反编译嵌入代码虽然不易，但确是可行的。更重要的是，这种反编译的结果（如果使用适当的工具）可能与原始源代码非常相似。

基于这一事实，对于泄露应用代码会对组织带来危害的闭源项目来说，独立的 Python 可执行文件并不是一个可行的解决方案。因此，如果仅复制应用的源代码就可以复制你的整个业务，那么你应该考虑使用其他方法来分发应用，比如，仅提供软件作为服务可能是更好的选择。

使反编译更难

目前，并没有可靠的方法能够保护应用不被可用的工具反编译，但是仍有一些方法可以使这个过程变得更加困难。

更加困难并不意味着被反编译的可能性更小，对于某些人来说，最吸引人的挑战正是最难的那些，并且挑战的最终奖励是非常大的，就是你设法保护的代码。

通常来说，反编译过程包括以下几个步骤：

1. 从独立可执行文件中提取项目字节码的二进制表示；
2. 将二进制表示映射到特定 Python 版本的字节码。
3. 将字节码转换成 AST。
4. 从 AST 直接重新创建源代码。

虽然无法阻止开发者对独立可执行文件进行这种逆向工程，但是这里给出一些想法，可以阻止反编译过程或者使其结果变得没有价值，比如：

• 运行时删除所有可用的代码元数据（文档字符串），从而稍微降低最终结果的可读性；
• 修改 CPython 解释器使用的字节码，这样从二进制转换成字节码、随后再转换成 AST 需要花费更多精力；
• 用复杂的方式修改 CPython 源代码版本，这样即使得到了应用的反编译源代码，没有对修改过的 CPython 库反编译也是没有用的；
• 在将源代码打包成可执行文件之前，对源代码使用混淆脚本，这将会使反编译后的源代码变得没有价值。

需要注意的是，这些解决方案都会使开发过程变得更加困难，其中的某些想法要求开发者对 Python 运行有非常深入的理解，而且每一个想法都有许多陷阱和缺点。

大多数情况下，这些方案只是将反编译的过程推迟了而已，一旦你的把戏被识破，所有额外的努力都将变成时间和资源的浪费。

要想不让闭源代码泄露到应用之外，唯一可靠的方法是就是不以任何形式将其直接发送给用户，只有你的组织其他方面的安全性都做得很好时，这种方法才有效。