转载自http://hellohank.iteye.com/blog/2218668
综述(写在前面的废话)
Java从诞生以来,其基因就是开放精神,也正因此,其可以得到广泛爱好者的支持和奉献,最终很快发展壮大,以至于有今天之风光!但随着java的应用领域越来越广,特别是一些功能要发布到终端用户手中(如Android开发的app),有时候,公司为了商业技术的保密考虑,不希望这里面的一些核心代码能够被人破解(破解之后,甚至可以被简单改改就发布出去,说严重点,就可能会扰乱公司的正常软件的市场行为),这时候就要求这些java代码不能够被反编译。
这里要先说一下反编译的现象。因为java一直秉持着开放共享的理念,所以大家也都知道,我们一般共享一个自己写的jar包时,同时会共享一个对应的source包。但这些依然与反编译没有什么关系,但java的共享理念,不只是建议我们这样做,而且它自己也在底层上“强迫”我们这么做!在java写的.java文件后,使用javac编译成class文件,在编译的过程,不像C/C++或C#那样编译时进行加密或混淆,它是直接对其进行符号化、标记化的编译处理,于是,也产生了一个逆向工程的问题:可以根据class文件反向解析成原来的java文件!这就是反编译的由来。
但很多时候,有些公司出于如上述的原因考虑时,真的不希望自己写的代码被别人反编译,尤其是那些收费的app或桌面软件(甚至还有一些j2ee的wen项目)!这时候,防止反编译就成了必然!但前面也说过了,因为开放理念的原因,class是可以被反编译的,那现在有这样的需求之后,有哪些方式可以做到防止反编译呢?经过研究java源代码并进行了一些技术实现(结果发现,以前都有人想到过,所以在对应章节的时候,我会贴出一些写得比较细的文章,而我就简单阐述一下,也算偷个懒吧),我总共整理出以下这几种方式:
代码混淆
这种方式的做法正如其名,是把代码打乱,并掺入一些随机或特殊的字符,让代码的可读性大大降低,“曲线救国”似的达到所谓的加密。其实,其本质就是打乱代码的顺序、将各类符号(如类名、方法名、属性名)进行随机或乱命名,使其无意义,让人读代码时很累,进而让人乍一看,以为这些代码是加过密的!
由其实现方式上可知,其实现原理只是扰乱正常的代码可读性,并不是真正的加密,如果一个人的耐心很好,依然可以理出整个程序在做什么,更何况,一个应用中,其核心代码才是人们想去了解的,所以大大缩小了代码阅读的范围!
当然,这种方式的存在,而且还比较流行,其原因在于,基本能防范一些技术人员进行反编译(比如说我,让我破解一个混淆的代码,我宁愿自己重写一个了)!而且其实现较为简单,对项目的代码又无开发上的侵入性。目前业界也有较多这类工具,有商用的,也有免费的,目前比较流行的免费的是:proguard(我现象临时用的就是这个)。
上面说了,这种方式其实并不是真正加密代码,其实代码还是能够被人反编译(有人可能说,使用proguard中的optimize选项,可以从字节流层面更改代码,甚至可以让JD这些反编译软件可以无法得到内容。说得有点道理,但有两个问题:1、使用optimize对JDK及环境要求较高,容易造成混淆后的代码无法正常运行;2、这种方式其实还是混淆,JD反编译有点问题,可以有更强悍的工具,矛盾哲学在哪儿都是存在的^_^)。那如何能做到我的class代码无法被人反编译呢?那就需要我们下面的“加密class”!
加密class
在说加密class之前,我们要先了解一些java的基本概念,如:ClassLoader。做java的人已经或者以后会知道,java程序的运行,是类中的逻辑在JVM中运行,而类又是怎么加载到JVM中的呢(JVM内幕之类的,不在本文中阐述,所以点到为止)?答案是:ClassLoader。JVM在启动时是如何初始化整个环境的,有哪些ClassLoader及作用是什么,大家可以自己问度娘,也不在本文中讨论。
让我们从最常见的代码开始,揭开一下ClassLoader的一点点面纱!看下面的代码:
- public class Demo{
- public static void main(String[] args){
- System.out.println(“hello world!”);
- }
- }
上面这段代码,大家都认识。但我要问的是:如果我们使用javac对其进行编译,然后使用java使其运行(为什么不在Eclipse中使用Run as功能呢?因为Eclipse帮我们封闭,从而简化了太多东西,使我们忽略了太多的底层细节,只有从原始的操作上,我们才能看到本质),那么,它是怎么加载到JVM中的?答案是:通过AppClassLoader加载的(相关知识点可以参考:http://hxraid.iteye.com/blog/747625)!如果不相信的话,可以输出一下System.out.println(Thread.currentThrea().getContextLoader());看看。
那又有一个新的问题产生了:ClassLoader又是怎样加载class的呢?其实,AppClassLoader继承自java.lang.ClassLoader类,所以,基本操作都在这个类里面,让我们直接看下面这段核心代码吧:
看看这个方法中的逻辑,非常简单,先从内存中找,如果没有,则从父级或根先找,如果没找到,则再从自己的方法里面找!那findClass里面是什么样的呢?很不幸,这个方法是个抽象(abstract)的,也就是使用什么方式加载,由程序使用ClassLoader自己决定!这就给我们留下了巨大的“”!让我们看一下非常常见的一个ClassLoader的实现,那就是URLClassLoader(几乎所有的j2ee的web项目的容器使用的ClassLoader都是继承自它),让我们看一下它的findClass的实现:
这个方法里面的逻辑也很简单,从定义的ucp(就是各个jar包或class文件的具体路径)中读取指定的class文件的信息(如字节流之类),然后交给defineClass定义到JVM中,让我们继续看一下这个方法的核心部分:
看到这里,已经没有必要再往下面看了(再往下就是native方法了,这是一个重大伏笔哦),我们要做的手脚就在这里!
手脚怎么做呢?很简单,上面的代码逻辑告诉我们,ClassLoader只是拿到class文件中的内容byte[],然后交给JVM初始化!于是我们的逻辑就简单了:只要在交给JVM时是正确的class文件就行了,在这之前是什么样子无所谓!所以,我们的加密的整个逻辑就是:
- 在编译代码时(如使用ant或maven),使用插件将代码进行加密(加密方式自己选),将class文件里面的内容读取成byte[],然后进行加密后再写回到class文件(这时候class文件里面的内容不是标准的class,无法被反编译了)
- 在启动项目代码时,指定使用我们自定义的ClassLoader就行了,而自定义的部分,主要就是在这里做解密工作!
如此,搞定!以上的做法比较完整的阐述,可以仔细阅读一下这篇文章:http://www.ibm.com/developerworks/cn/java/l-secureclass/文章中的介绍。
通过这个方法貌似可以解决代码反编译的问题了!错!这里有一个巨大的坑!因为我们自定义的ClassLoader是不能加密的,要不然JVM不认识,就全歇菜了!如果我来反编译,呵呵,我只要反编译一下这个自定义的ClassLoader,然后把里面解密后的内容写到指定的文件中保存下来,再把这个加了逻辑的自定义ClassLoader放回去运行,你猜结果会怎样?没错,你会想死!因为你好不容易想出来的加密算法,结果人家根本不需要破解,直接就绕过去了!
现在,让我们总结一下这个方法的优缺点:实现方式简单有效,同时对代码几乎没有侵入性,不影响正常开发与发布。缺点也很明显,就是很容易被人破解!
当然啦,关于缺点问题,你也可以这么干:先对所有代码进行混淆、再进行加密,保证:1、不容易找到我们自定义的那个ClassLoader;2、就算找到了,破解了,代码可读性还是很差,让你看得吐血!(有一篇文章,我觉得写得不错,大家可以看一看:http://cjnetwork.iteye.com/blog/851544)
嗯,我觉得这个方法很好,我自己也差点被这个想法感动了,但是,作为一个严谨的程序员,我真的不愿意留下一个隐患在这里!所以,我继续思索!
高级加密class
前面我们说过有个伏笔来着,还记得吧?没错,就是那个native!native定义的方法是什么方法?就是我们传说中的JNI调用!前面介绍过的有一篇文章中提到过,其实jvm的真实身份并不是java,而是c++写的jvm.dll(windows版本下),java与dll文件的调用就是通过JNI实现的!于是,我们就可以这样想:JNI可以调用第三方语言的类库,那么,我们可不可以把解密与装载使用第三方语言写(如C++,因为它们生成的库是不好反编译的),这样它可以把解密出来的class内容直接调jvm.dll的加载接口进行初始化成class,再返回给我们的ClassLoader?这样,我们自定义的ClassLoader只要使用JNI调用这个第三方语言写的组件,整个解密过程,都在黑盒中进行,别人就无从破解了!
嗯,这个方法真的很不错的!但也有两个小问题:1.使用第三方语言写,得会第三方语言,我说的会,是指很溜!2.对于不同的操作系统,甚至同一操作系统不同的版本,都可能要有差异化的代码生成对应环境下的组件(如window下是exe,linux是so等)!如果你不在乎这两个问题,我觉得,这个方式真的挺不错的。但对于我来说,我的信条是,越复杂的方式越容易出错!我个人比较崇尚简洁的美,所以,这个方法我不会轻易使用!
对了,如果大家觉得这个方法还算可行的话,可以推荐一个我无意中看到的东西给大家看看(我都没有用过的):jinstall,还有一个叫:http://download.csdn.net/detail/yzjcnlpj/3296134
更改JVM
看到这个标题,我想你可能会震惊。是的,你没看错,做为一个程序员,是应该要具有怀疑一切、敢想敢做的信念。如果你有意留心的话,你会发现JVM版本在业界其实也有好几个版本的,如:Sun公司的、IBM的、Apache的、Google的……
所以,不要阻碍自己的想象力,现在没有这个能力,并不代表不可能。所以,我想到,如果我把jvm改了,在里面对加载的类进行解密,那不就可以了吗?我在设计构思过程中,突然发现:人老了就是容易糊涂!前面使用第三方语言实现解密的两个问题,正好也是更改JVM要面对的两个问题,而且还有一个更大的问题:这个JVM就得跟着这个项目到处走啊!有一个类似的思路是这样:
http://wenku.baidu.com/link?url=T0LOwOI5DDFRoFGJp_vzwq8x6OADAcnHcNBOFqij5jz7Rvt1wsjLe8Qa2sJFUBQha88A5csGqDH5yXIjWVV4i54x-iXtYpPSO9kJtQLhvNy
于是,我把构思与设计从头又想了想,终于……放弃了!
确定方案
前面可以说,我能想到的方式,我都想到了,都不能令我满意。于是我在想,有没有一个让我感觉代价又小,但却无隐患的方式呢?
这里,其实涉及到一个误区问题,就是为什么一定要把我们自定义的解密class的ClassLoader进行加密不让人看到呢?!其实,只要让别人无法窜改就可以了!如果能做到让别人就算看到了我们的源码,但他无法窜改我们自定义的这个ClassLoader,这和加密的效果其实是一样的了!那怎么做呢?
我们可以借鉴数字签名方式!其想法是:可以把解密并defineClass的功能委托给一个单独的类,这个类呢,我们使用一个私钥(私钥在公司管理的云端,不在系统发布的客户端)对其内容进行SHA256摘要,并将摘要记录在系统的某处,当我们自定义的ClassLoader在读取这个类时,先对其内容进行SHA256进行验证,看是不是被窜改过,如果被窜改,则系统拒绝工作!这样就可以了,核心代码简略如下:
- private Object decoderLoader = null;//注意这里的定义类型,是Object,不是DecoderLoader,因为这个类我们需要单独对其进行加载并校验
- ……
- if(decoderLoader == null){
- byte[] bs=FileUtils.readAsBytes(“具体DecoderLoader.class文件路径”);
- // 这里要对bs内容进行SHA256校验(需要带上私钥,私钥可以从服务器获取,也可以存储于系统的某个地方,反正每个用户可以不一样的私钥),如果校验不通过,抛出个异常,甚至可以直接System.exit(-1);
- DigestUtils.match("发布时生成好的签名",bs,"服务器获取的密钥");//验证是否一致,不一致就认为被窜改过,则直接抛出异常终止启动
- Class c = defineClass(具体DecoderLoader.class文件路径(/替换成.), bs, 0, bs.length, cs);
- decoderLoader = c.newInstance();
- }
- byte[] b = res.getBytes();//这里得到的是加密的class文件内容
- // 使用上面的decoderLoader利用反射进行解密操作,decoderLoader的解密方法只传入参数为:b,密钥。(为什么不直接定义DecoderLoader类,非要用反射?自己想想吧,这跟ClassLoader加载机制有关,就不阐述了)
- b = ReflectUtils.invoke(decoderLoader,”decode”,b,”密钥”);
- CodeSigner[] signers = res.getCodeSigners();
- CodeSource cs = new CodeSource(url, signers);
- return defineClass(name, b, 0, b.length, cs);
嗯,我很满意!
可是,当我看到自定义的ClassLoader里面的验证代码时,我又要感慨一下自己老了!这不还是绕回来了吗?!如果破解了自定义的ClassLoader,我还验证个毛啊,直接把类引用进来用就是了!毕竟,自定义的ClassLoader在加载时又没有校验!
等等!我们还是有回到初衷,我们到底要干什么?我们要加密我们的代码,防止被反编译,我们前面做到了,只是解密的问题却暴露出来了(更重要的是,人家可以绕过解密过程),所以,我们现在可以这样想:让他绕不过,不就行了吗?所以,我们上面使用一个单独类实现解密和defineClass一体功能的类。现在因为别人能看到自定义的ClassLoader源码,同时又能看到那个一体化功能的类,所以通过改写自定义的ClassLoader绕过校验、通过改写一体化功能的类保存解密后的内容到文件中,这样还是可以得到整个系统的源码!
整理了一下思路,我们发现,我们要处理的事情,其实已经很简单了:只要隐藏掉自定义的ClassLoader或一体化功能的类当中的任何一个,都可以达到目标!如何隐藏一个类?然后,我一个方法一个方法地去想:
从class文件格式做文章。我们先学一些这方面的知识吧:可以学习一下这个文章中的知识:http://chenzhou123520.iteye.com/blog/1596693。文章我还没看完,我突然发现,还是没有意义,因为代码混淆器就是干了这件事!——放弃!
借鉴数字签名的方式也在前面验证过不行!——放弃!
JNI方式是最好的方式!可是这种方式维护成本上有点高,我不喜欢!如果真没办法,那也用它是没办法的选择(相比改写JVM来说,它的代价是比较小的)!可是,真的可以吗?!java从1.5开始,提供一个代理(instrument)功能(大家一定见过在Eclipse中启动有些项目进,要加-javaagent参数吧?)!Instrument是干什么的呢?举个简单的例子吧:如果把JVM处理校验并生成class或运行class逻辑看成webapp项目中的Servlet功能的话,那instrument就相当于Filter,在JVM操作class之前,JVM会先执行instrument,在instrument里面,我们可以做任何事情,包括改写class(于是许多AOP框架就是这么干的,如AspectJ)和监控JVM的各类信息(很多监控软件就是这么干的,如有些性能监控工具等)等等。等你使用JNI辛辛苦苦解密出来,也隐藏了代码的解密方式,结果,JVM在这一步把你整个出卖了!
Instrument方式。上面说了JNI其实也不可靠了!那我们就从Instrument这里调用JNI不就行了吗?接下来总没有地方出卖它了吧?我只能说“别天真了”!因为Instrument的加载是通过在启动时加上一个参数:-javaagent:xxx,很不幸的是,这个参数可以跟多个代理(简单理解为多个具有代理功能的jar包),而这些代理的执行顺序就是这个参数后面写的顺序,如:-javaagent:a.jar,b.jar,这里加载了两个代理,它们的执行顺序就是a、b,如果想把顺序反过来,只要这样:-javaagent:b.jar,a.jar就行了,就跟webapp项目中web.xml中定义filter的顺序是一样一样的~
改写JVM方式。根据上面来看,我是几乎放弃了挣扎!所以,我想,嗯,还是改写JVM是最靠谱的!可是,JVM改写,要改写它运行instrument之后的地方,而且一旦改写,前面说的风险和代价是要承担的!
说到这儿,我想大家应该已经猜到了,反正我是不会为了防止人家破解我的java代码,还要搞这么大动静!只要意思一下,大概防一防就行了,能够达到“吓跑一大半,剩下的人要破解的话,花费的精力都可以自己写一个同样的系统”就行了!凡事要找个平衡嘛(或者说,有时候不需要追求完美,也是要有妥协的)!
最终的选择:就是上面那个混淆+自定义ClassLoader方式解密(然后在ClassLoader里面加一句类似“本是同根生,请君多自重”之类的话)。如果还不怕麻烦的话,再这个自定义的ClassLoader放到一个不起眼的第三方包中,增加查找的难度,仅此而已了~
最后要说一句:考虑到性能问题,我们只用来加解密核心代码即可。
总结
经过对java不断深入研究,以及多年来对java知识的积累,最重要的是,一种遇到困难时执着向前的精神,最终使得问题的解决越来越完善!虽然走过弯路,但每条弯路上都有许多收获,就像我曾经做得的分享里面说的:同一个现象,不同的视野将得到不同的结果!如何提升自己视野?就在于平时不断的自我追求和强烈的求知欲!
PS:这个总结,算是自夸一下,也算是给新入行的“菜鸟”们一个建议吧~