编译、反编译、反反编译

答案：「盗版」的行为，天天都在我们的周遭上演，所以今年五月由 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，而不将软体卖到客户手上，这才是上策。 

上一个：怎样在指定的table单元格处生成下拉列表
下一个：·源代码搜索引擎-Koders.com