java代码混淆
仅做记录之⽤。
java代码可以反编译,因此有时候要保护⾃⼰的知识产权还真得费点⼼思,⼀般来说有三个思路:
1、将class⽂件加密,这个是最安全的,但也费事⼉,因为要重写classloader来解密class⽂件;
2、使⽤花指令,使得class⽂件不能反编译(利⽤反编译⼯具漏洞);安全性⼀般,还是有花指令破解器;
3、代码混淆,提⾼代码阅读成本;简单易操作,⼀般采⽤这种或者与其它⽅式结合;
我们项⽬中⽤到的即为代码混淆⼯具ProGuard,相关⽂章参考:
ProGuard是⼀个纯java编写的混淆⼯具,有客户端跟jar包两种使⽤⽅式。可以将程序打包为jar,然后⽤⼯具进⾏混淆,也可以在maven中导⼊ProGuard的插件,对代码进⾏混淆。本例中为对普通javaweb项⽬进⾏代码混淆。maven配置插件如下:
<!-- ProGuard混淆插件-->
<plugin>
<groupId>com.github.wvengen</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.0.11</version>
<executions>
<execution>
<!-- 混淆时刻,这⾥是打包的时候混淆-->
<phase>package</phase>
<goals>
<!-- 使⽤插件的什么功能,当然是混淆-->
<goal>proguard</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- 是否将⽣成的PG⽂件安装部署-->
<attach>true</attach>
<!-- 是否混淆-->
<obfuscate>true</obfuscate>
<!-- 指定⽣成⽂件分类 -->
<attachArtifactClassifier>pg</attachArtifactClassifier>
<options>
<!-- JDK⽬标版本1.8-->
<option>-target 1.8</option>
<!-- 不做收缩(删除注释、未被引⽤代码)-->
<option>-dontshrink</option>
<!-- 不做优化(变更代码实现逻辑)-->
<option>-dontoptimize</option>
<!-- 不路过⾮公⽤类⽂件及成员-->
<option>-dontskipnonpubliclibraryclasses</option>
<option>-dontskipnonpubliclibraryclassmembers</option>
<!--不⽤⼤⼩写混合类名机制-->
<option>-dontusemixedcaseclassnames</option>
java混淆工具<!-- 优化时允许访问并修改有修饰符的类和类的成员 -->
<option>-allowaccessmodification</option>
<!-- 确定统⼀的混淆类的成员名称来增加混淆-->
<option>-useuniqueclassmembernames</option>
<!-- 不混淆所有包名-->
<!--<option>-keeppackagenames</option>-->
<!-- 需要保持的属性:异常,注解等-->
<option>-keepattributes Exceptions,InnerClasses,Signature,Deprecated,SourceFile,LocalVariable*Table,*Annotation*,Synthetic,EnclosingMethod</option> <!-- 不混淆所有的set/get⽅法->
<!--<option>-keepclassmembers public class * {void set*(***);*** get*();}</option>-->
<!-- 不混淆包下的所有类名,且类中的⽅法也不混淆-->
<option>-keep x.bboss.SystemConfig { <methods>; }</option>
<option>-keep x.framework.** { *; }</option>
<option>-keep ller.** { <methods>; }</option>
<option>-keep x.xxx.dao.** { <methods>; }</option>
<option>-keep ption { <methods>; }</option>
<option>-keep del.** { <methods>; }</option>
</options>
<!--class 混淆后输出的jar包-->
<outjar>classes-autotest.jar</outjar>
<!-- 添加依赖,这⾥你可以按你的需要修改,这⾥测试只需要⼀个JRE的Runtime包就⾏了 -->
<libs>
<lib>${java.home}/lib/rt.jar</lib>
</libs>
<!-- 对什么东西进⾏加载,这⾥仅有classes成功,毕竟你也不可能对配置⽂件及JSP混淆吧-->
<injar>classes</injar>
<!-- 输出⽬录-->
<outputDirectory>${project.build.directory}</outputDirectory>
</configuration>
运⾏ mvn clean package -DskipTests
混淆后结果如图所⽰:
classes-pg.jar为混淆后的classes⽂件,⾥边包含完整的项⽬结构
混淆内容映射
参与混淆的类
混淆后反编译代码如下:
可以看到,部分包名跟类名已经被改为了简单字母,不再具有业务含义,⽽且变量名也进⾏了修改,增加了阅读代码难度。
运⾏服务,项⽬正常运⾏。
需要注意的问题:
1、因为有时候会配置不保持包名或类名,因此⼀些相关配置⽂件的内容需要改变,好在ProGuard不是随机⽣成类名,⽽是先按照原名称对相同包下类进⾏排序,混淆后的类名称依次为a.class,b.class,
那么问题来了,当包中超过26个类时,默认命名为A.class,B.class,C.class,在某些操作系统下,会不区分class⽂件名称的⼤⼩写,会导致错误(⽔平所限,未深⼊探究跟类加载相关);因此
<!--不⽤⼤⼩写混合类名机制-->
<option>-dontusemixedcaseclassnames</option>
配置极为关键,该配置会在超过26个类⽂件时,命名为aa.class,ab.class,ac.class,⽽不是原来的⼤写类名,从⽽避免错误。
2、打包部署问题。该配置⽂件打包出来的war中classes⽂件仍然为正常代码,需要⼿动解压,将classes-pg.jar中classes替换进去,在⼯程化管理的情况下,可以在jenkins中配置脚本,⾃动将混淆后的classes替换进war包:
#更改war包classes为混淆包的内容
cd /root/.jenkins/workspace/mytest_master/target
jar -xvf classes-pg.jar
rm -rf mytest
mkdir mytest
mv mytest.war mytest
cd mytest/
jar -xvf mytest.war
rm -rf WEB-INF/classes/com/
cp -rf com mytest/WEB-INF/classes/
cd mytest
jar -cvfM0 mytest.war ./
mv mytest.war ../
这样jenkins打出的就是混淆后的war包了,可以直接交给客户使⽤。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论