编译、反编译、反反编译

类别:Java 点击:0 评论:0 推荐:
「盗版」的行为,天天都在我们的周遭上演,所以今年五月由 BSA(商业软体联盟)和法务部发起的「反盗版」活动,着实让大家风声鹤唳了好一阵子。但是,即使在这样诡谲的气氛之下,由大专院校学生为主的「反反盗版」活动,到也振振有词,轰轰烈烈地攻占媒体版面。有「盗版」,就有「反盗版」;有「反盗版」,就有「反反盗版」,这个世界就是这么一回事。

同样的道理,有「编译」(compile),就有「反编译」(decompile);有「反编译」,就有「反反编译」。对于 Java 和 .NET 这种虚拟机器的中间码来说,尤其明显。

Java 程式编译后的结果是 Java Bytecode,而 .NET 编译后的结果是 CIL(Common Intermediate Language),两者都具有下列的特性:

同为堆叠式(stack-based)指令集。
同为高阶物件导向机器语言。
和平台无关。
Code Validation
Symbolic Link
上述任何一点特色,都可以让程式变得更容易反编译,全部五点结合起来更是不得了。所以要反编译 Java 和 .NET 可以说是相当容易的。网路上就到处流传着 Java 的反编译器(decompiler),可以把编译后的档案反推出原始码,相信不久之后 .NET 也会遇到一样的问题。(至少,喜欢搞破坏的我就正尝试着写一个 .NET decompiler。)

试想,如果你将辛辛苦苦开发出来的 Java 和 .NET 程式交给别人(蔡学镛?),他只要透过反编译器,就可以推出原始码,你的智慧财产很可能会受到侵犯。

想要保护自己,你必须在 Java 或 .NET 软体出货前,进行反反编译,这个动作通常称为混淆(obfuscate)。被混淆过的程式码,依然遵照原来的档案格式和指令集,所以依然可以执行,执行结果也和混淆前一样。只是被混淆过的程式码变得更乱,更不容易被反编译成功。

有的 Java 开发工具(例如 JBuilder)有内附混淆器(obfuscator),或者你也可以购买功能更强大的混淆器。这些商业的混淆器通常只做三件事:
将每一个 method 内部用更乱的方式组织。
将 Java Constant Pool,或 .NET metadata 内可以消除的 Symbolic Data 消除(例如 private method 的名字)。
将 debug 资讯(例如 Java 的 LocalVariableTable 与 LineNumberTable)全部删除。
Obfuscator 的作用如果只是如同上述一般,只有 method 局部的作用,效果不大。欲大幅度地增加反编译的难度,必须搭配下列的方式:
Class 内的混淆:将 class 内的 method 互相混淆。
Class 之间的混淆:将 class 之间的关系混淆,例如将父类别和子类别合并或拆解等。
有一些学术论文有对上述两点做出研究,但成效仍然不大,而且必须手动调整,无法由软体自动处理。这方面值得大家投入更深入的研究。

混淆过的程式会遇到下面的问题:
通常效率会变差。
可能无法执行。我遇过这样的情况,有可能是混淆器的错,也有可能是 JVM 的错。
如果进行「Class 之间的混淆」,稍有不慎,就很可能会无法执行。例如:Java 程式中如果有用到 instanceof,或者 C# 程式中有用到 is,就要很小心的进行「Class 之间的混淆」,否则后果不堪设想。

混淆的目的有两个层次:
让程式无法被自动反编译:例如做出一些特殊的跳跃(goto),让程式区块(block)的关系无法被找出特定的 pattern。

让程式就算被反编译成功,也不容易被程式员阅读理解:想办法加入一些不易被识破的程式码来欺骗程式员。

Obfuscator 不是万灵丹,如果遇上了一个精通 obfuscating 技术的人,佐以 profiling 工具,原始码还是会落入他的手中。所以,使用 obfuscator 时,你必须有这样的心理准备:「防君子,不妨小人;防笨蛋,不防聪明人」。尽可能将软体放在 server 改为提供 service,而不将软体卖到客户手上,这才是上策。

本文地址:http://com.8s8s.com/it/it12109.htm