1

可以编写一个编译器,您不能从中对输入语言的语法和含义进行逆向工程。

即你能总是从编译器那里得到语言的规范吗?

假设我想从 ?? 对于某些语言,但我不希望阅读编译器的人能够阅读和理解?

我个人觉得编译器和语言规范是同构的,但从学术的角度来看,我对这是否错误很感兴趣。

4

5 回答 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 回答