加密嵌入文本文件的脚本
我正在开发一款使用脚本语言实现自动化的闭源游戏。几乎所有的游戏逻辑都是由脚本处理的。脚本可以编译为字节码格式，但由于语言的性质，必须保留标识符。编译后的脚本可以使用二进制到文本编码嵌入到其他基于文本的资源格式中。
我想在分发过程中对编译的脚本进行加密以保护源代码，但由于语言、字节码格式和二进制到文本的编码方案都是专有的，我是否需要担心加密？如果是这样，我应该简单地扰乱一些字节并结束，还是应该使用功能齐全的加密解决方案？加密不应过度增加可执行文件的大小，因为脚本可能很大并且加载时间很重要。
I'm working on a closed-source game that uses a scripting language for automation. Almost all of the game logic is handled by scripts. Scripts can be compiled to a bytecode format, but due to the nature of the language, identifiers must be preserved. Compiled scripts can be embedded in other text-based resource formats using a binary-to-text encoding.
I want to encrypt the compiled scripts to protect the source during distribution, but because the language, bytecode format, and binary-to-text encoding scheme are all proprietary, do I need to worry about encryption at all? If so, should I simply perturb some bytes and call it a day, or should I make use of a fully featured encryption solution? Encryption should not increase the size of the executable unduly, because scripts can be large and load times are important.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在 Windows 上，可执行文件的大小对加载时间没有影响，因为 exe 只是映射到内存中，然后根据需要进行分页。我无法想象为什么 *nix 也不是这样。
因此，如果脚本不需要与 .exe 分开更改，您可以将它们嵌入到 .exe 中，这将使用户很难更改它们，即使他们可以找到它们。我曾经编写过一个小工具，可以将数据文件转换为 .obj 文件，这使得将数据嵌入到我的 exe 中变得非常容易 - 事实证明，编写仅包含数据的目标文件非常容易。
当然，如果您确实关心保护这些数据，那么完全加密是您唯一的选择，但如果您只是想阻止随意的黑客攻击，那么让文件难以获取可能就足够了。
On Windows, the size of the executable has no impact on load times because the exe is just mapped into memory and then paged in as needed. I can't imagine why that would not be true for *nix as well.
So, if the scripts don't need to change separately from your .exe, you could imbed them into the .exe, that would make them difficult for users to change even if they could find them. I wrote a little tool once that turned data files into .obj files that made it really easy to imbed data into my exe - it turned out to be pretty easy to write an object file that contains only data.
Of course, if you really care about protecting this data than full encryption in your only choice, but if you are just trying to discourage casual hacking, making the files hard to get at might be good enough.
您不应该假设人们无法读取二进制专有格式。有很多人非常擅长在没有任何文档的情况下对协议进行逆向工程。
因此，如果您想保证源的安全，您需要一些真正的安全措施。唯一的问题是，如果您加密文件，您需要向用户提供解密密钥才能玩游戏，当您这样做时，有人知道如何获取密钥只是时间问题并用它来解密所有文件。
所以基本上，不幸的是你无能为力。您可以尝试混淆代码，但即使这样也无法阻止所有人。
You shouldn't assume that people can't read binary proprietary formats. There are many people who are very good at reverse-engineering protocols without any documentation.
So if you want to keep your source safe, you need some real security. The only problem is that if you encrypt the files, you'll need to give your users the decryption key in order to play the game, and when you do that then its only a matter of time before someone works out how to get the key and use it to decrypt all the files.
So basically, there's not much you can do unfortunately. You could try obfuscating your code, but even that's not going to stop everyone.
你所说的不会是加密，因为你必须附带解密密钥。这只是混淆视听。无论您如何尝试隐藏解密密钥，如果您的程序可以找到它，那么用户也可以。
因此，一旦您明白我们只是在讨论各种混淆方案，那么问题就是您需要多少混淆。专有的字节编译可能比加密的障碍更高，我就到此为止了。任何想要追踪逻辑的人都可以在上面放置一个调试器，无论你是否加密。如果他们已经对您的运行时引擎进行了逆向工程以计算出字节码，那么它们已经位于具有未加密数据的代码部分中。
也就是说，如果您发现文件中的标识符有问题，您可以在字节编译之前将它们机械地转换为随机字符串。
What you're talking about isn't going to be encryption, because you're going to have to ship the decryption key with it. It's just obfuscation. No matter how much you try to hide the decryption key, if your program can find it, so can the user.
So once you understand that we're just talking about various obfuscation schemes, the question is how much obfuscation you need. Likely the proprietary byte-compiling is a higher barrier than the encryption would be, and I'd call it a day. Anyone who wants to trace the logic can just put a debugger on it whether you encrypt or not. If they've already reverse-engineered your run-time engine to work out the byte-codes, then they're already in the portion of the code that has the unencrypted data.
That said, if you find the identifiers in the file to be problematic you can mechanically converts them to random strings prior to byte-compiling.
在这里，加密不会给你带来太多好处。
基本上，无论您添加什么加密层，可执行文件本身都必须能够执行解密才能运行脚本。你锁上了门，但你把钥匙留在锁里。这是不可避免的。
加密的作用是在一定程度上提高了访问数据的门槛。需要一定的拆解技巧。只需将文件嵌入到可执行文件中就可以过滤掉不熟练的黑客。那些不被这种嵌入吓倒的人，也是那些能够沿着数据处理路径，找到解密逻辑，并随意抽取解密代码的人。一层加密还可以增加重要性感：加密的东西当然是值得的。因此，尝试过于时髦的事情可能只会让你的情况变得更糟，而不是更好。
另一方面，将文件嵌入可执行二进制文件可能是一个好主意。它将消除在文件系统上运行时定位它们的需要（众所周知，在 Unix 系统上运行时定位比在 Windows 上更困难，因为存在硬链接：在 Windows 上，可执行文件可以轻松获得自己的路径，但是在 Unix 上，硬链接的存在意味着“该”可执行路径定义不明确）。
Encryption would not buy you much here.
Basically, whatever encryption layer you add, the executable itself must be able to perform the decryption in order to run the scripts. You lock the door, but you leave the key in the lock. This is unavoidable.
What encryption does is that it somewhat raises the bar on who may access the data. It requires some disassembly skills. Simply embedding the files in the executable will already filter out the casual not-very-good hacker. Those who are not deterred by such embedding are also those who will be able to follow the data processing path, find the decryption logic, and siphon out the decrypted code at will. A layer of encryption may also increase the feeling of importance: that which was encrypted is certainly worthwhile. Hence, trying too funky things may just make your situation worse, not better.
On the other hand, embedding the files in the executable binary is probably a good idea. It would remove the need to locate them at runtime on the filesystem (locating things at runtime is known to be somewhat more difficult on Unix systems than on Windows, because of hard links: on Windows, an executable can easily obtained its own path, but on Unix the presence of hard links means that "the" executable path is ill-defined).