可以编写一个编译器，您不能从中对输入语言的语法和含义进行逆向工程。
即你能总是从编译器那里得到语言的规范吗？
假设我想从 ?? 对于某些语言，但我不希望阅读编译器的人能够阅读和理解？
我个人觉得编译器和语言规范是同构的，但从学术的角度来看，我对这是否错误很感兴趣。
问问题
166 次
5 回答
1
我认为编译器总是揭示它编译的语言的规范（我知道这是超级手动）。
然而，可能没有算法可以这样做（即它是不可判定的），因为例如该算法需要找出编译器将在哪些程序上停止。
于 2010-12-17T17:56:00.547 回答
1
假设您说他们只能访问二进制文件：
简短的回答：如果一个人足够关心，就不会。
长答案：如果一个人如此倾向于并且有很多空闲时间，总是有可能将编译器分解到字节级别并完全映射它。从那里，您可以找出逻辑树，并重建语言。
这会很痛苦，但这与“我能不能制定一种算法来防止专用用户破解 cd-key 验证”属于同一类别。
现在，如果您从未真正将编译器交给一个人（想象某种代理系统？），那么可以合理地说，用户将不得不花费非常非常长的时间来暴力破解语言规范，如果他可以的话永远产生可以完全锻炼它的东西。
如果您暗示他们可以访问源代码：
不。你可以混淆它，但编译器仍然必须构造相同的逻辑树，无论多么难以阅读。
可能有一些深奥的方法可以做到这一点..如果您以某种加密的二进制形式单独提供语言树...并且没有提供编译器的源代码..并且您的用户不会厌倦 NSA 类型。
于 2010-12-17T18:01:03.337 回答
0
不，它们不一样。但是编译器不可避免地会理解输入语言的语法，并且（希望）非常精确地遵循语言规范。因此，理解编译器就意味着理解那些。
当然，编译器源代码可能会被严重混淆，以至于没有人会费心去阅读它并提取语法和语言规则。当然，这也伤害了开发人员（祝你好运！）。
此外，如果我想了解有关该语言的一些信息（不是关于它是如何实现的，而是它是如何在更抽象的层面上定义的），阅读编译器的源代码将是我的最后选择——我会前往规范或其他一些权威来源（官方文档等），因为即使编译器的代码非常容易理解，它也会更容易。
于 2010-12-17T18:07:33.517 回答
0
我的直觉是，您可以通过检查编译器的输出来确定编译器的语义行为。但是如果没有文档或访问编译器源，您将无法获得实际的语法。如果您有源代码，这将变得微不足道，所以我假设您没有编译器的源代码，只需将其作为工具访问即可。
于 2010-12-17T18:26:14.647 回答
0
一般来说，如果代码中有关于语义的信息（并且在任何解释器或编译器中总是定义了操作语义），那么总是可以提取该信息。唯一的问题是这种逆向工程的复杂性。因此，您需要一种混淆语言和混淆编译器。
以 Malbolge“反编译器”为例。
于 2010-12-18T14:04:21.017 回答