（看到这个 一 感觉肯定没好事发生）
众所周知，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啦，什么什么的，都可以按照这个思想来反编译。
那么通用的，也是最简单的解密方法也出来了，酱酱酱酱-----
那就是：请听下回分解。（去尼玛，还下回分解，明明是想偷懒好不好，鬼知道你下回又是什么时候写了，看看你上一篇认真写的文章是什么时候发布的，喂，别走啊~）