最近针对公司框架进行关键业务代码进行加密处理，防止通过jd-gui等反编译工具能够轻松还原工程代码，相关混淆方案配置使用比较复杂且针对springboot项目问题较多，所以针对class文件加密再通过自定义的classloder进行解密加载，此方案并不是绝对安全，只是加大反编译的困难程度，防君子不防小人，整体加密保护流程图如下图所示
maven插件加密使用自定义maven插件对编译后指定的class文件进行加密，加密后的class文件拷贝到指定路径，这里是保存到resource/coreclass下，删除源class文件，加密使用的是简单的DES对称加密
注意事项1.加密后的文件也是class文件，为了防止在递归查找中重复加密，需要对已经加密后的class名称记录防止重复
2.在删除源文件时可能出现编译占用的情况，执行System.gc()后方可删除
3.针对自定义插件的列表形式的configuration节点可以使用List来映射
插件使用配置如图所示
自定义classloader创建CustomClassLoader继承自ClassLoader，重写findClass方法只处理装载加密后的class文件，其他class交有默认加载器处理，需要注意的是默认处理不能调用super.finclass方法，在idea调试没问题，打成jar包运行就会报加密的class中的依赖class无法加载（ClassNoDefException/ClassNotFoundException），这里使用的是当前线程的上下文的类加载器就没有问题（Thread.currentThread().getContextClassLoader()）
隐藏classloaderclassloader加密class文件处理方案的漏洞在于自定义类加载器是完全暴露的，只需进行分析解密流程就能获取到原始class文件，所以我们需要对classloder的内容进行隐藏
1.把classloader的源文件在编译期间进行删除（maven自定义插件实现）
2.将classloder的内容进行base64编码后拆分内容寻找多个系统启动注入点写入到loader.key文件中（拆分时写入的路径和文件名需要进行base64加密避免全局搜索），例如
3.通过GroovyClassLoader对classloder的内容（字符串）进行动态编译获取到对象，删除loader.key文件
pom文件增加动态编译依赖
获取文件内容进行编译代码如下（写入/读取注意utf-8处理防止乱码）
被保护class手动加壳因为相关需要加密的class文件都是通过customerclassloder加载的，获取不到显示的class类型，所以我们实际的业务类只能通过反射的方法进行调用，例如业务工具类LicenseUtil，加密后类为LicenseCoreUtil，我们在LicenseUtil的方法中需要反射调用，LicenseCoreUtil中的方法，例如
为了避免反射调用随着调用次数的增加损失较多的性能，使用了一个第三方的插件reflectasm，pom增加依赖
reflectasm使用了MethodAccess快速定位方法并在字节码层面进行调用，CoreLoader的代码如下
总结自定义classloder并不是一个完美的代码加密保护的解决方案，但就改造工作量与对项目的影响程度来说是最小的，只需要针对关键核心逻辑方法进行保护，不会对系统运行逻辑产生影响制造bug，理论上来说只要classloder的拆分越小，系统启动注入点隐藏的越多，那破解的成本就会越高，如果有不足之处还请见谅
到此这篇关于SpringBoot详细讲解通过自定义classloader加密保护class文件的文章就介绍到这了,更多相关SpringBoot自定义classloader内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
