CSDN博客

img 蔡学镛

蔡学镛:编译、反编译、反反编译

发表于2002/8/16 10:30:00  2528人阅读

「盗版」的行为,天天都在我们的周遭上演,所以今年五月由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之间的混淆」,否则后果不堪设想。

混淆的目的有两个层次:

1.         
让程序无法被自动反编译:例如做出一些特殊的跳跃(goto),让程序区块
(block)的关系无法被找出特定的pattern。

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

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

0 0

相关博文

我的热门文章

img
取 消
img