java源程序加密解决方案(基于Classloader解密)

源程序加密解决方案

1. 概述：
Java源程序的加密，有如下两种：
1使用混淆器对源码进行混淆，降低反编译工具的作用
2基于classloader的自定义加密、解密运行

1.1. 混淆器加密
1.2. 自定义classloader加密
1.2.1. 原理
原理：java虚拟机的动态加载机制，为classloader加密方案提供了理论基础。在jvm装载运行程序，初始的时候，只装在了必要的类，如java.lang.String等，而应用程序的类并没有一次性装入内存。Jvm解释执行应用程序的过程中，如果发现有未装载的类，则会调用装载正在执行的那个类的classloader来装载，这个过程是一层一层向上，直到顶层的classloader。Jvm启动的时候会装入ExtClassloader，而ExtClassloader又会装载AppClassloader，例如：

Class Hello{

	Public static void main(String[] args){
		System.out.println(“hello”);
		HelloMethod.sayHello();
}
}
Class HelloMethod{

	Public static void sayHello(){
		System.out.println(“hello in static HelloMethod”);

}
}

有上面两个类的定义，在执行Hello类的main方法的时候，首先会委托装载Hello类的classloader来装载HelloMethod类，即jvm会委托AppClassloader来装载，但是在AppClassloader的实现的时候，会首先委托装载AppClassloader的classloader来装载，如果上层的classloader无法装载，才会由AppClassloader来装载HelloMethod类。这种模式叫做双亲委托模式。在jvm的所有classloader中都是如此，首先由父classloader加载，失败由自身加载。

Java虚拟机的这种特性，使得我们可以自定义一个classloader，然后由这个classloader来装载应用程序的启动类，然后在启动应用程序，那么当应用程序中有未装载的类的时候，java徐机器逐层向上请求classloader装载新类，那么首先被请求的就是装在应用程序的classloader，即我们自定义的classloader，我们完全可以首先调用自己的加载方法来加载类，如果加载不成功，可以请求父classloader来加载，因为来请求加载的类是完全有可能是系统的类。







在我们使用自定义的classloader的时候，装载自己的程序，那么就可以对装入的字节码进行一定的操作，比如解密。在调用自定义的装载器classloader的时候，首先是要装入被加密之后的文件，通常情况下仍旧已.class为扩展名，在调用defineClass之前对装入的数据解密。
1.2.2. Classloader的两个重要方法
protected Class defineClass(String name, byte[] classData, int offset, int length);
最原子的操作，在调用自定义的classloader加载新类的时候，首先根据自定义规则找到加载的类所存放的位置，然后将数据一byte[]类型读入，进行解密运算时候，调用该方法，以生成一个Class。这是一个比较核心的方法，这个方法是被抽象的Classloader定义为protected访问标记的，只有继承了Classloader这个类才能使用。

Class loadClass(String name, boolean resolve);
Java虚拟机，在装载新类，递归向上查找并调用的方法，在自定义classloader中需要重写，就是判断是否能够自己装载，如果能则自己装载，否则交由系统装载。
2. 源程序加密解决方案

2.1. 自定义classloader加密
加密和解密要是对应的，即使用加密之后的数据，经过解密是需要能够得到原来的数据。

2.1.1. 加密应用程序
为了简单，在这里才用一种简单的加密方法，把得到的需要加密的数据，以字节取，每一个字节加1，对应的解密就是每一个减1。
还是以Hello、HelloMethod类为例子，

BufferedInputStream bis = new BufferedInputStream(new FileInputSteam(“d:/workbench/ciphertool/bin/com/aatest/Hello.class”));
byte[] data = new byte[bis.avialable()];
bis.read(data);
bis.close();
for(int I = 0; I < data.length; i++){
	data[i] =(byte)( data[i] + 1);
}
BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream(“d:/workbench/ciphertool/bin/com/aatest/Hello.class”));
bos.write(data);
bos.close();

将加密对象取出，加密，然后存盘。
2.1.2. 解密运行应用程序
在自定义的classloader接收到加载新类请求的时候，首先读入加密之后的文件，然后解密，最后调用defineClass(name, classData, offset, length)生成类，返回出去。


拦截新类加载请求

package com.cjnetwork.ciphertool.core;

import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.jar.JarEntry;
import java.util.jar.JarFile;

import com.cjnetwork.ciphertool.util.CipherUtil;

public class CjClassloader extends ClassLoader {

	String classpath;
	
	Map<String, Class> loadedClassPool = new HashMap<String, Class>();

	public CjClassloader(String classpath) {
		this.classpath = classpath;
	}

	
	@SuppressWarnings("unchecked")
	@Override
	public synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
		Class claz = null;
		if (loadedClassPool.containsKey(name)) {
			claz = this.loadedClassPool.get(name);
		} else {

			try {
				if (claz == null) {
					claz = super.loadClass(name, false);
					if (claz != null) {
						System.out.println("系统加载成功：" + name);
					}
				}
			} catch (ClassNotFoundException e) {
				System.out.println("系统无法加载：" + name);
			}
			
			try {
				if (claz == null) {
					claz = loadByCjClassLoader(name);
					if (claz != null) {
						System.out.println("自定义加载成功：" + name);
					}
				}
			} catch (Exception e) {
				System.out.println("自定义无法加载：" + name);
			}

			if (claz != null) {
				this.loadedClassPool.put(name, claz);
			}

		}
		if (resolve) {
			resolveClass(claz);
		}
		return claz;
	}

	/**
	 * 
	 * 解密加载
	 * 
	 * 
	 * @param name
	 * @return
	 */
	@SuppressWarnings("unchecked")
	private Class loadByCjClassLoader(String name) {
		Class claz = null;
		try {
			byte[] rawData = loadClassData(name);
			if (rawData != null) {
				byte[] classData = decrypt(getReverseCypher(this.cjcipher.getKeycode()), rawData);
				classData = CipherUtil.filter(classData, this.cjcipher);
				
				claz = defineClass(name, classData, 0, classData.length);
			}
		} catch (Exception e) {
			claz = null;
		}
		return claz;
	}

}

最主要的是集成Classloader，并重写Class loadClass(String name, Boolean resolve)方法，在这个方法中，可以根据需要自己加载需要的文件，并解析生成Class。


解密并返回Class

BufferedInputStream bis = new BufferedInputStream(new FileInputSteam(“d:/workbench/ciphertool/bin/com/aatest/Hello.class”));
byte[] data = new byte[bis.avialable()];
bis.read(data);
bis.close();
for(int I = 0; I < data.length; i++){
	data[i] =(byte)( data[i] - 1);
}
Class claz = defineClass(“Hello”, data, 0, data.length);

2.2. 加密自定义classloader
采用以上的方法，就可以将应用程序加密，使得被加密的程序不能被反编译，因为加密之后的class文件已经不是jvm定义的标准class文件，只能通过解密运行程序解密，才能运行。

如果只做到这一步，对于java源程序加密还没有完成。虽然应用程序无法直接反编译，但是自定义的classloader是没有被加密的，它自身是可以被反编译的。理论上，如果得到真正的class文件（即jvm标准的class文件），是可以反编译的java文件，在这里，假设得到class文件就得到了java文件。
如果攻击者将自定义的classloader反编译，得到源码，则攻击者可以再自定义解密运行的同事，将得到的应用程序的字节码存储到本地，那么，攻击者就相当于是跳过了源程序加密解密。例如攻击者在代码Class claz = defineClass(name, classData, offset, length);这句代码前，将classData存储到本地，即攻击者可以再解密运行应用程序的同时，将应用程序的字节码保存，就达到了破解应用程序源代码的效果。

为了描述方便，实例化一个 自定义的classloader，叫做CjClassLoader
这一个漏洞在于，CjClassLoader没有加密，攻击者可以在其中嵌入导出应用程序代码，那么，要解决这个问题，加密CjClassLoader就成了保护应用程序源代码的关键。
试想，如果加密、解密运行程序中，没有CjClassLoader.class文件，或是CjClassLoader.class文件本身也是经过加密的，CjClassLoader类的获得也是通过自己书写的方法动态获取，那么攻击者无法获取到CjClassLoader.class文件，相当于无法获取到CjClassLoader.java文件，那么也就无法再其中加入到处应用程序类文件的代码，那么被加密的应用程序可以认为是安全的。
假设将CjClassLoader.class加密后生成CjClassLoaderEncryptor0.class，那么CjClassLoader是安全了，但理论上攻击者还是可以通过反编译CjClassLoaderEncryptor0来获取CjClassLoader的源码，那么保护CjClassLoaderEncryptor0又成了保护应用程序的关键，注意在CjClassLoaderEncryptor0中存在解密CjClassLoader的密钥，即将密钥硬编码到CjClassLoaderEncryptor0中，这样做是为了防止攻击者直接获取密钥，直接破解最里面一层的加密，至于什么是最里面一层，请继续看后文。
那么如何CjClassLoaderEncryptor0.class的安全性呢，我们同样采取加密的方式，即将CjClassLoaderEncryptor0.class加密，生成CjClassLoaderEncryptor1.class，在解密运行的时候首先动态的生成CjClassLoaderEncryptor1.class，在由CjClassLoaderEncryptor1所定义的类动态的装入CjClassLoaderEncryptor0.class，并且解密生成CjClassLoader，最后使用CjClassLoader装入应用程序，运行。整体上的思路如下：

CjClassLoader.class	——》	CjClassLoaderEncryptor0.class
CjClassLoaderEncryptor1.class	——》	CjClassLoaderEncryptor1.class
CjClassLoaderEncryptor2.class	——》	CjClassLoaderEncryptor2.class
CjClassLoaderEncryptor3.class	——》	CjClassLoaderEncryptor3.class
。。。。。。
CjClassLoaderEncryptorN.class	——》	CjClassLoaderEncryptorN.class

这样的一级一级加密，我们称CjClassLoaderEncryptorN.class为最外层，成CjClassLoaderEncryptor0.class为最里层。除去最外层没有加密，里面的每一层都是加密之后的数据，都是不能直接为jvm所识别的字节码，都是需要通过后一级的解密程序解密之后才能为jvm所识别。

系统装在CjClassLoaderEncryptorN.class，生成CjClassLoaderEncryptorN类，使用反射机制，调用CjClassLoaderEncryptorN类中的方法，这个方法可以动态的装入CjClassLoaderEncryptor(N-1).class，并利用CjClassLoaderEncryptorN中的密钥，解密CjClassLoaderEncryptor(N – 1)，然后生成CjClassLoaderEncryptor（ N – 1）类，最后调用CjClassLoaderEncryptor(N – 1)中的方法。而CjClassLoaderEncryptor（ N – 1）类中的方法，可以动态装入CjClassLoaderEncryptor(N- 2).class文件，并利用CjClassLoaderEncryptor（N – 1）中的密钥，解密CjClassLoaderEncryptor（N – 2），然后生成CjClassLoaderEncryptor(N – 2)类，最后调用方法，被调用的方法可以动态的装入CjClassLoaderEncryptor(N – 3).class。。。。。。。。

CjClassLoaderEncryptorN  (密钥N，动态装入，解密，方法调用)  CjClassLoaderEncryptor(N–1)
CjClassLoaderEncryptor(N-1) (密钥N-1，动态装入，解密，方法调用) CjClassLoaderEncryptor(N–2)
CjClassLoaderEncryptor(N-2) (密钥N-2，动态装入，解密，方法调用) CjClassLoaderEncryptor(N-3)
......
CjClassLoaderEncryptor1  (密钥1，动态装入，解密，方法调用)  CjClassLoaderEncryptor0
CjClassLoaderEncryptor0  (密钥0，动态装入，解密，方法调用)  CjClassLoader

最后使用CjClassLoader解密装载应用程序。


通过这样一个过程的加密CjClassLoader，可以达到保护加密程序本身的目的，这种保护在理论上是可破，但在实际操作中将会变得困难，因为密钥是通过硬编码的方式存储在下一层的封装器中，即CjClassLoaderEncryptor(N-1).class的密钥是放在CjClassLoaderEncryptorN.class中，如果存在CjClassLoaderEncryptor1000.class，那么加密过程将会变得非常复杂。

当然动态生成CjClassLoaderEncryptorN.class的工作，虽然内置了应编码（解密CjClassLoaderEncryptor(N-1)的密钥），但是这样一个过程，是不需要手动实现，利用程序自动生成即可。目前，这个版本的实现中是采用了动态生成CjClassLoaderEncryptorN.java文件，然后调用javac 命令，编译生成class文件。

请记住，这个过程是理论上不安全的，但如果需要加密的应用程序非常的重要，那么可以将加密、解密运行自身的CjClassLoader加密次数增加，以达到更加安全的目的。
2.3. 隐藏自定义classloader
通过上述加密CjClassLoader的方案，可以使得CjClassLoader变得相对安全，但似乎还是有一个问题，即解密运行程序本身的main方法中，会动态的装入CjClassLoaderEncryptorN，然后通过层层调用，最终获取到CjClassLoader类，然后使用CjClassLoader解密装载应用程序，这段代码是没有加密的，攻击者可以不考虑CjClassLoaderEncryptorN开始的层层调用，只需要在最终获取的CjClassLoader解密应用程序之前，将CjClassLoader本地化，即可以获得未经加密的CjClassLoader，这样，就不安全了。
解决这个问题，可以将这段代码中动态获取CjClassLoader类，修改为动态获取CjClassLoader中的Class loadClass(String name, Boolean resovle)方法，然后直接使用获取到的方法，开始加载应用程序。


如此，攻击者就没有办法直接获取到解密之后的CjClassLoader，保护了加密、解密程序。

2.4. 隐藏加密、解密方法
在上述的实现中，CjClassLoader中加密、解密应用程序的方法是被放置于CipherUtil.class文件中，而这个文件是没有被加密的，攻击者是可以直接获取到应用程序加密和解密的方法的，这给应用程序带来了不安全性，是的攻击者不利用解密程序的繁琐解密过程，而自定调用CipherUtil.class中的方法，解密应用程序。

解决这个问题，可以将CipherUtil.class中的加密和解密方法封装到CjClassloader中，因为CjClassloader是没有办法直接得到，所以认为加密解密所用到的方法是安全的。最终在程序中调用的时候不是直接得到CjClassloader类，都是通过CjClassloaderEncrytorN的层层方法调用，而直接获取到需要使用的方法。例如，我们可以在CjClassloaderEncrytorN类中封装了一个Method getEncrytMethod()，如此的方法，这个方法会去调用CjClassloaderEncrytor(N-1)中的同名方法，如此一直调用，直到CjClassloaderEncrytor0.class中，在这个类中直接反射获得CjClassloader中的加密方法，当然这个是比较特殊的，因为在CjClassloaderEncrytor0中时候反射获取CjClassloader中方法的时候，这个反射是需要带参数的，但这个带参数获取也是简单的。


3. bug

异常堆栈过长
经过这种一层一层的CjClassLoader解密运行的源程序，其堆栈是很长的，如果应用程序中，出现异常，答应异常或日志记录将会变得很麻烦，会记录很多无用的堆栈信息。


备注：文中提到的应用程序，指需要被加密的程序。


欢迎评论。

代码混淆就不错。

你这里的代码混淆是指网络上已经有的一些混淆器，还是自己修改class文件

如果是网络上的混淆器，第一是不太清楚原理，第二是觉得效果不是很好

如果是自己修改class文件，那么需要对class文件结构非常熟悉。。

思路很好

我曾经也做过类似实践，把项目所有class文件经过一定的打乱处理，写入到图片里了。不过没想到再在classloader层面做一次保护。受教了，抽空试验一下。

另外，投票权被robbin给ban了，否则肯定给你投精华了，呵呵

我觉得重点是学到关于ClassLoader这个知识点

我记得代码混淆常用的技术就是将类名改掉……

自定义的classloader在深入java虚拟机中都有相关的讲解.

换句话说只要这样就绕开了这里说的保护手段了。
先开上-verbose或-XX:+TraceClassLoading跑一次，可以知道关心的类的全限定名是什么（如果加载的类使用了名字混淆那很容易看出来，没混淆的话则容易通过名字猜测类的作用）；然后用上面的办法写个合适的filter就能达到解的目的了。ClassLoader系加密感觉还是不算特别强，主要还是用来防君子。

程序员没有被别人破更多的是看这个程序有没有破的价值——足够有价值的话最容易吸引到相应水平的人来做这种事情。

另外，提到混淆，主要是两类吧：名字混淆，控制流混淆。名字混淆比较常见就不详细说了。控制流混淆的思路也很简单，主要是通过把字节码的某些模式转换为计算上等价、但Java语言无法直接表达的形式。
例如，Java源码里的循环在循环体末尾的地方，操作数栈应该是空的；如果故意在此处留一个值在操作数栈上，很多反编译器就要栽了。再举一例，Java语言里的try块的起始与结束边界处，操作数栈也应该是空的，同样可以用留一个值的方式让反编译器呛着。或者修改ExceptionTable让多个异常处理器（本来应该对于Java语言的catch或finally块）指向同一个位置，这也有效果。
另外很常见的是故意加些无用的swap或者goto之类的。虽说对反编译器有效果，但如果真的是关键代码的话，人肉解读也并不困难，只是烦琐而已——能做到“烦琐”当然也已经有阻吓作用了，还是回到那个问题——这程序到底有没有足够的价值去破。

话说回来，JVM的JIT编译器自身就有跟反编译器很类似的部分，如果把反编译器呛住了的话，同时也很可能会影响JIT编译器的效果，使得程序性能降低。这些都是值得权衡的地方。

当然也有别的混淆方式。例如说，.NET上微软有提供虚拟机指令混淆，就是把原本的MSIL指令的映射关系打乱，使得一般的工具无法直接分析被混淆后的程序。这种是在虚拟机里有钩子直接支持的。

关键点还是建立加密体系，而不是classloader体系。

我倒觉得没必要这么多级的classloader，定义一级classloader就可以了。你只要用对一种加密算法，你的cjClassloader逻辑和公钥可以公开，但是你的私钥不公开，这样不就可以达到加密的目的了吗？
当然也可以用对称加密，比如用最简单的des算法就可以了

classloader加密的方法，确实没有办法绕过jvm自身支持的class dump功能。暂时没有想到可以绕过这一点的加密源程序方案。