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

1、CjClassloader中，最后会调用方法Class defineClass(String name, byte[] classData, int offset, int length)来定义一个类，然后返回加载好的类给请求加载请求者，如果不隐藏CjClassloader，则攻击者在这里直接导出解密后的数据classData，即然后了你的程序加密方法，而不论你的算法有多安全。
2、des，是的，我在实现中使用了这个算法加密，但是这种对称密钥的算法，在解密应用程序的时候，是需要使用的，那么，这个密钥（确切的说是生成密钥的密码）是一定会给别人的。例如，你需要在你托管的机房运行你的应用程序，那么那个机房的服务器上是一定需要你的密钥，当然，如果说是在启动程序之后就删除密钥，这种情况除外。

无论你做多少层classloader无非就是增加破解的复杂度而已。
但只要是用java写的复杂度都不算高，如果需要应该考虑采用jni方式，在jni中解密，然后直接调用jnienv的defineClass来定义类。

但即便是这种方式也是可以破解的，不过是需要破解者对c也要熟悉

你的class是经过加密了的啊，只有你自定义的classloader可以解密加载啊，即使对方hijack你的classloader也不能读取你的class，因为他不知道密钥是什么。

所以关键点就在于密钥的安全性的问题了，密钥可以多级管理啊，比如银行里面的三级加密体系，如果要很安全，可以用加密机存储你的顶级密钥，如果一般的机房实现，可以把密钥导入到JVM里面或者web服务器的keystore里面啊，这样只有授权的虚拟机才能运行你的程序：）

如果CjClassloader（自定义classloader）只有一个，应用程序的class文件是经过加密的，别人是无法直接读取加密后的应用程序的class文件，但是CjClassloader本身没有加密，CjClassloader自身的不安全性，会使得能够在CjClassloader中加入代码，在CjClassloader使用自定义装入class文件，并获取数据，解密，然后使用解密后的数据定义类（Class），这里的解密后的数据是可以导出的。无论加密算法有多么安全，在CjClassloader中会出现应用程序的非加密数据，因此说是不安全的。
当然如果建立完整的密钥授权机制，即每次获取解密密钥之后，密钥并不存储在本地，那这样的方式，应用程序的安全性是依赖于建立的密钥授权机制（还要除去jvm本身支持的class dump方法这种特殊的情况）。

你的担心无非就是破解者知道了机房服务器的管理员权限，然后把你的classloader修改了然后把解密的内容打印出来。

但是这种情况的发生概率还是非常小的吧（替换class还重启服务器，跟中木马一样）。大部分情况是别人在发布或者传输过程中可以拿着你的class包，然后自己部署反编译，我上面说的这种一机一密的方式就可以防止这种情况的嘛。

至于class dump，那就是另外关于如何防止class dump的议题了吧，但我想任何一个生产服务器不可能开启这种在开发模式才允许的操作吧？

不，标准的Sun JDK在什么模式都支持class dump。而且还有好几组API支持这个操作，我前面只是给了其中一种的例子。

OH，那就是说Class文件加密然后Classloader层解密加载，不管做得多复杂都是徒劳的？ Runtime的class都能被dump出来了，难道只有代码混淆才是 真正有意义的？

这些技巧主要都是用来增加“普通人”的拆解难度的，并不是要“理论上杜绝拆解”。
虽然知道的话做起来不难，但真正知道如何做class dump的人也并不算多，对吧？

另外也有一些办法，例如说不让用户使用标准的JDK，而必须使用专用的launcher来启动应用（注意到java/java.exe其实就是一个launcher而已，并不是JVM本身）；在launcher里多做点手脚，就像保护一般的本地程序一样，例如说让调试器更难连接上来，这就足以使得HotSpot原本支持的class dump方式的一些接口不能直接用了。

学习了，马克一下。

“让调试器更难连接上来” 这个点需要学习一下...



另外忘了赞一下LZ的帖子，思路很清晰。（可惜没有投票权，不然投精了）

嗯例如说在Windows的话IsDebuggerPresent之类的能简单的扛一下，然后如果想办法把这类函数的调用藏起来又能再提高那么一点烦琐程度。总之…嗯就是想办法让拆解的人烦得不想去拆了那就成功了