首页 > 学院 > 开发设计 > 正文

Java 编译、反编译、反反编译

2019-11-18 12:05:58
字体:
来源:转载
供稿:网友

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

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表