(看到这个 一 感觉肯定没好事发生)
众所周知,Java是一个实时编译型的语言,其编译后的产物,class文件也是Bytecode,字节码。
很容易被反编译工具反编译,而传统的Java源代码保护方法基本都是采用混淆的方式,
但这样会带来很多麻烦,而且也不能真正保护class文件。
于是,市面上出现了很多采用jni技术定制classloader调用经过加密的class来动态解密,运行class文件的加密器。
所以加密后的文件,根本就不是合法的class文件,自然目前大部分Java反编译器都无法反编译啦,所以也在一定程度上保证Java程序不被轻易逆向。
于是呢,就有了这篇文章
首先来分析下
从上面说的可以看出,经加密过的类字节码 其实已经不是[Java字节码]文件了,那么这样奇葩的二进制文件是怎么被java虚拟机成功加载的呢?
其实就是————>通过Java虚拟机所提供的参数,来设定解密程序(启动的时候需要指定): -agentlib:classloader.dll
简单的来讲,这个agentlib相当于给Java虚拟机做了一个‘Plugin’(插件),Java虚拟机在把Class字节码读入内存的时候,就会先尝试把Class字节码先交给这个Plugin处理再交给系统本身的Classloader(类装载器)加载、执行。
所以嘛,确定了一点:Java虚拟机把读到”奇怪的字节码”交给之前提到的加密器提供的classloader.dll,然后这个dll文件再将这段“奇怪的字节码”解密,然后把解密后的Bytecode再交给Java虚拟机来进行下一步,Java虚拟机就可以正常使用系统的Classloader加载这个类了。当然这个加密器的任务也就结束了。
可以看到,无论加密方式多么屌炸天,都在最后一个环节,[解密]上薄弱了,因为你不管怎么样,都要交给系统的Classloader来加载,也就是说,系统必须认得,既然系统认得了,那么自然在内存中的信息就是你想要的啦。
所以照这个思路下去,任何只要带虚拟机的语言,什么c#啦,什么python啦,什么什么的,都可以按照这个思想来反编译。
那么通用的,也是最简单的解密方法也出来了,酱酱酱酱-----
那就是:请听下回分解。(去尼玛,还下回分解,明明是想偷懒好不好,鬼知道你下回又是什么时候写了,看看你上一篇认真写的文章是什么时候发布的,喂,别走啊~)
小虾米
O菊苣赛高!
ovear 回复给 小虾米
嗷嗷,小虾米菊苣的博客是神马~
小虾米
=。=难道有评论审核……
ovear 回复给 小虾米
呜呜,都是这破系统,我自己的留言都进垃圾箱里面。。
ovear 回复给 小虾米
呜呜,怪不得我博客没留言,哭哭
Siegfried
卧槽什么情况,我本来想去里区看巨人,搜acfunwiki居然跑到这边来了……
a站被你黑了么喂
居然是个精通程序而且喜欢科幻的技术宅么wwwww求指点求勾搭
ovear 回复给 Siegfried
0 0,什么情况,wiki.acfun.tv正常也。。怎么会跑到我这来0 0.TAT我的确喜欢科幻呢~不过技术宅不敢当啊。。同求勾搭 _(:з」∠)_~
siegfried 回复给 ovear
710585882快加我qq
你打acfunwiki.org试试看〉。〉真的不是你干的吗
ovear 回复给 siegfried
=。=真不是我干的。。一会我去瞄一眼
siegfried 回复给 ovear
_(:з」∠)_可恶居然还没加我qq
魔法少女千寻
可恶我一个也看不懂(怒摔键盘!
ovear 回复给 魔法少女千寻
千寻酱!
花舞花落泪
喂!O菊苣,你不能这样,,,难道要我把8G内存翻一遍么?
ovear 回复给 花舞花落泪
海棠菊苣!当然是有办法的啦~等我考完试就补完!
Kunr
O菊莴好。
ovear 回复给 Kunr
Kunr菊苣尼壕~