加密脚本以嵌入文本文件答案

【问题标题】：Encrypting Scripts for Embedding in Text Files加密脚本以嵌入文本文件
【发布时间】：2010-02-01 23:03:06
【问题描述】：

我正在开发一款使用脚本语言实现自动化的封闭源代码游戏。几乎所有的游戏逻辑都由脚本处理。脚本可以编译为字节码格式，但由于语言的性质，必须保留标识符。编译后的脚本可以使用二进制到文本的编码嵌入到其他基于文本的资源格式中。

我想在分发过程中对编译后的脚本进行加密以保护源代码，但是由于语言、字节码格式和二进制到文本的编码方案都是专有的，我是否需要担心加密？如果是这样，我应该简单地扰乱一些字节并收工，还是应该使用功能齐全的加密解决方案？加密不应过度增加可执行文件的大小，因为脚本可能很大并且加载时间很重要。

【问题讨论】：

看不到 C++ 内容 - 删除了 C++ 标签。
对不起。标签是习惯性添加的，因为实现语言是C++。
保护源到底是什么？为什么？您需要使用加密的想法从何而来？
我需要保护来源不被意图逆向工程或修改游戏玩法的人查看。

标签： encryption encoding scripting

【解决方案1】：

在 Windows 上，可执行文件的大小对加载时间没有影响，因为 exe 只是映射到内存中，然后根据需要进行分页。我无法想象为什么 *nix 也不是这样。

因此，如果脚本不需要与您的 .exe 分开更改，您可以将它们嵌入到 .exe 中，这会使用户即使找到它们也难以更改。我曾经写过一个小工具，它可以将数据文件转换为 .obj 文件，这使得将数据嵌入到我的 exe 中变得非常容易——结果证明，编写一个只包含数据的目标文件非常容易。

当然，如果您真的关心保护这些数据而不是您唯一的选择，但如果您只是想阻止随意的黑客攻击，那么让文件难以获取可能会很好够了。

【讨论】：

足够好就是足够好。我想对objcopy 进行一些幼稚的干扰和明智的使用是我的解决方案。顺便说一句，我指的是脚本可执行文件的大小，而不是游戏应用程序。 :)
@Jon：是的，我现在明白了。据我了解，强加密通常不会增加它加密的数据，而是将其大小向上舍入以匹配加密算法的块大小。

【解决方案2】：

您不应该假设人们无法阅读二进制专有格式。有很多人非常擅长在没有任何文档的情况下对协议进行逆向工程。

因此，如果您想确保源代码安全，则需要一些真正的安全措施。唯一的问题是，如果您加密文件，则需要向用户提供解密密钥才能玩游戏，而当您这样做时，有人弄清楚如何获取密钥只是时间问题并用它来解密所有文件。

所以基本上，不幸的是，您无能为力。您可以尝试混淆您的代码，但即使这样也无法阻止所有人。

【讨论】：

【解决方案3】：

您所说的不是加密，因为您将不得不随身携带解密密钥。这只是混淆。不管你多么想隐藏解密密钥，如果你的程序能找到它，那么用户也能找到。

因此，一旦您了解我们只是在谈论各种混淆方案，问题就是您需要多少混淆。可能专有的字节编译是比加密更高的障碍，我会称之为一天。任何想要跟踪逻辑的人都可以在上面放一个调试器，不管你是否加密。如果他们已经对您的运行时引擎进行了逆向工程以计算出字节码，那么他们已经在包含未加密数据的代码部分中。

也就是说，如果您发现文件中的标识符有问题，您可以在字节编译之前将它们机械地转换为随机字符串。

【讨论】：

【解决方案4】：

加密在这里不会给你带来太多好处。

基本上，无论您添加什么加密层，可执行文件本身都必须能够执行解密才能运行脚本。你锁了门，但你把钥匙留在了锁里。这是不可避免的。

加密的作用是它在一定程度上提高了谁可以访问数据的门槛。它需要一些拆卸技巧。只需将文件嵌入到可执行文件中，就已经过滤掉了临时的不太好的黑客。那些不被这种嵌入吓倒的人，也是那些能够沿着数据处理路径，找到解密逻辑，并随意抽取解密代码的人。一层加密也可能增加重要性的感觉：被加密的当然是值得的。因此，尝试太时髦的东西可能只会让你的情况变得更糟，而不是更好。

另一方面，将文件嵌入可执行二进制文件可能是个好主意。它将消除在运行时在文件系统上定位它们的需要（众所周知，在 Unix 系统上，在运行时定位东西比在 Windows 上要困难一些，因为硬链接：在 Windows 上，可执行文件可以很容易地获得它自己的路径，但是在 Unix 上，硬链接的存在意味着“该”可执行路径定义不明确）。

【讨论】：