摘要:介绍混淆器会对文件进行压缩,优化,混淆以及校验。混淆器为了能够正确进行整个过程,会重新构建类之间的依赖。所有的其他类和类成员都会被抛弃掉在优化步骤,混淆器会进一步优化代码。除此之外,混淆器会提供一些建议是否保留一些出现的类和类成员。
文章转自我个人博客
本文前半部分对照 Proguard 文档 (Manul 中的 Introduce 部分)进行翻译同时加上个人的理解,如果有与原文不同,请以原文为主。后半部分是对几个步骤的验证。
混淆器(ProGuard)会对 Java class 文件进行 shrinker(压缩),optimizer(优化),obfuscator(混淆)以及preverifier(校验)。shrinker(压缩)这一步会找到并移除没用到的类,变量,方法,属性。optimization(优化)这一步,会分析并且优化方法的字节码。obfuscation(混淆)则会对 class,fields,methods替换成一些短的无意义的名字。第一步会把代码量变小,运行更加有效率,同时更加难以被逆向。在 Java Micro Edition 和 Java 6或者更高版本中,最后一步的检验过程,会向class文件中添加一些预校验的信息。
上述的每个步骤,都是可以选择的(可以进行也可以不进行)。例如,ProGuard 可以只进行preverify,从而更高效的运行。

首先,ProGuard(混淆器) 读入输入的 jars (也可以是 aars, wars, ears, zips, apks, 或者目录)。随后,开始进行 shrinker(压缩),optimizer(优化),obfuscator(混淆)以及preverifier(校验)。你可以选择性的让ProGuard(混淆器)进行多种类型的优化操作。ProGuard(混淆器)会把修改过的结果写入一个或者多个输出的 jars (也可以是 aars, wars, ears, zips, apks, 或者目录)中。
混淆器需要明确输入文件(Input jars)是jars包(也可以是 aars, wars, ears, zips, apks, 或者目录)。这些 libraries 本质上是你将会用来编译的代码。混淆器为了能够正确进行整个过程,会重新构建类之间的依赖。而依赖包(Library jars) 往往是不会被改变的,但你依旧需要把它们放在最终的App的环境中。
Entry points (入口点)在压缩步骤(shrinker),混淆器会从这些点(入口点)进入,并且递归寻找决定哪些类和哪些类成员会被使用。所有的其他类和类成员都会被抛弃掉
在优化步骤(optimizer),混淆器会进一步优化代码。在这些优化过程中,那些不是入口点的类和方法会变成private static或者final,不被用到的参数会被移除,一些方法会变成内敛方法
在混淆这一步(obfuscator),混淆器会重新命名那些不是入口点的类和类的成员。在这整个过程中,那些成为入口点的地方,依旧会为他们保留原来的名字
预验证阶段(preverifier)是唯一一个不需要知道入口点的阶段
反射对于反射和introspection 进行代码的自动处理时,都会存在一些特殊的问题。在混淆器进行处理时,代码中类和类成员都是被动态创建或者被动态调用的(通过对应类的名字,或者成员名字),这些地方都必须被定义成入口点。例如,Class.forName()这个构造器会在运行时指向任何的类。又比如,类的名字可能会从配置文件中读入,这通常很难去计算出是那些类需要被保留(通过原始的名字)。因此,你必须得在混淆器的配置中,通过简单相同的操作-keep来指定他们。
然而,混淆器已经能够帮你发现并处理以下的情况:
Class.forName("SomeClass") SomeClass.class SomeClass.class.getField("someField") SomeClass.class.getDeclaredField("someField") SomeClass.class.getMethod("someMethod", new Class[] {}) SomeClass.class.getMethod("someMethod", new Class[] { A.class }) SomeClass.class.getMethod("someMethod", new Class[] { A.class, B.class }) SomeClass.class.getDeclaredMethod("someMethod", new Class[] {}) SomeClass.class.getDeclaredMethod("someMethod", new Class[] { A.class }) SomeClass.class.getDeclaredMethod("someMethod", new Class[] { A.class, B.class }) AtomicIntegerFieldUpdater.newUpdater(SomeClass.class, "someField") AtomicLongFieldUpdater.newUpdater(SomeClass.class, "someField") AtomicReferenceFieldUpdater.newUpdater(SomeClass.class, SomeType.class, "someField")
类和类成员的名字会不一样,但是构造方法必然是相同的,由此,混淆器能够认出他们。被引用的类和类的成员在压缩(shrinking)阶段会被保留,同时,string 类型的参数也会在混淆时(obfuscation)被准确的修改。
除此之外,混淆器会提供一些建议:是否保留一些出现的类和类成员。举例,混淆器会标记(SomeClass)Class.forName(variable).newInstance()这样的构造器。因为这些方法可能会指向其他类,这些可能是类,也可能是接口,或者是继承自这些接口或者类的类。你需要在配置中做相应的处理。
为了能够得到正确的混淆结果,你应该对进行混淆的代码多少有所熟悉。当面临大量反射代码时,混淆代码需要进行大量的试验,并处理错误,特别是对于内部代码没有足够的信息的情况下。
以上是对官方文档首页的翻译内容。
该部分不是翻译内容,是根据ProGuard 的使用方法和文档首页,对上述三个步骤的具体验证。
由于大部分情况下,Android的混淆只需要考虑Obfuse这个步骤,因为很多第三方依赖包的混淆规则会把 shrink和optimize去掉(比如友盟)。所以先验证这一步。
下面的验证步骤,涉及三个类,java打包的命令(Java 环境),proguard.jar包(混淆器,进行整个混淆过程的jar包),proguard.pro文件(写入具体混淆的规则)和Intelij(用来查看class文件)等内容。
Obfuse 步骤验证这个步骤,如上所说,主要是对类,方法进行名字的修改,也是 Android 混淆中最重要的部分。为了验证这个过程,我做了下面的demo操作。
首先写了3个类:
package com.dove.home; class HelloWorld { public HelloWorld(){ System.out.println("Hello World"); } }
package com.dove.home; class HelloWorld2 { public HelloWorld2(){ System.out.println("Hello World2"); } }
package com.dove.home; class Main { public static void main(String[] args) { HelloWorld helloWorld = new HelloWorld(); } }
然后编译,打包
javac com/dove/home/Main.java javac com/dove/home/HelloWorld2.java javac com/dove/home/HelloWorld.java //注意在进行下面步骤的时候,我把 com/dove/home 下的 java源码删了 jar -cvf main_source.jar com

然后使用混淆器,混淆器其具体使用方法,主要是调用proguard.jar包,然后配置 proguard.pro文件进行具体的参数设置。
下面是我proguard.pro文件内容
# 源码文件 -injars main_source.jar # 混淆后输出文件 -outjars main_source_out.jar # java 核心 jar 不能混淆 -libraryjars/lib/rt.jar -libraryjars /lib/jce.jar # 全部不混淆,即三个class文件都会保持原样 -keep class com.dove.home.Main{*;} -keep class com.dove.home.HelloWorld{*;} -keep class com.dove.home.HelloWorld2{*;}
具体的混淆命令,同时参考下图(该步骤会生成混淆后的jar包)
java -jar proguard.jar @proguard.pro
注意:然后修改 proguard.pro 文件,内容如下
-injars main_source.jar # 注意输出包的名字改了 -outjars main_source_proguard_out.jar -libraryjars/lib/rt.jar -libraryjars /lib/jce.jar -keep class com.dove.home.Main{*;} # 删除了HelloWorld的 keep -keep class com.dove.home.HelloWorld2{*;}
同样运行上面的混淆命令,生成另一个混淆后的包
最后对三个包进行对比,通过代码逆向,进行验证,最快的方式是把生成的 jar 包,当做第三方依赖包直接导入Intellij 中(有decode的功能),如下图,三个包的区别

最初是的源码包和保留HelloWorld,HelloWorld2以及Main入口点的包是一样的,不同的是最后没有保留HelloWorld入口点的包,它的HelloWorld变成了a,而Main和HelloWorld2都正常没有被修改。
Optimize 步骤验证同样,修改 proguard.pro 文件,内容如下,然后运行混淆命令,生成新的 jar 包
-injars main_source.jar # 输出包名改了,方便对比 -outjars main_source_proguard_not_optimize_out.jar -libraryjars/lib/rt.jar -libraryjars /lib/jce.jar # 加上不进行优化的限制 -dontoptimize -keep class com.dove.home.Main{*;} -keep class com.dove.home.HelloWorld2{*;}
同上,导入IntelliJ,对比上一步中混淆后的 jar 包,发现名字没啥变化,但内容不一样了

首先是没有添加 -dontoptimize
package com.dove.home; final class a { public a() { System.out.println("Hello World"); } }
然后是添加了 -dontoptimize
package com.dove.home; class a { public a() { System.out.println("Hello World"); } }
如上述译文中所说,optimize 会进行代码优化,不是入口点的代码,会变成final,private等等,该步骤验证完毕。
Shrink 步骤验证修改 proguard.pro 文件,进行压缩,同时不对 HelloWorld,HelloWorld2进行入口点的保留
-injars main_source.jar -outjars main_source_proguard_shrink_out.jar -libraryjars/lib/rt.jar -libraryjars /lib/jce.jar -keep class com.dove.home.Main{*;} # 注意对比之前,删除了HelloWorld和HelloWorld2的 keep
修改 proguard.pro 文件,不进行压缩,同样不对 HelloWorld,HelloWorld2进行入口点的保留
-injars main_source.jar -outjars main_source_proguard_not_shrink_out.jar -libraryjars/lib/rt.jar -libraryjars /lib/jce.jar # 添加不进行压缩 -dontshrink -keep class com.dove.home.Main{*;}
其结果对比,添加了 -dontshrink标志

未添加 -dontshrink标志

此处消失的b其实就是HelloWorld2,而留下的a则是HelloWorld,原因很简单,因为Main里面持有了HelloWorld的引用,而HelloWorld2则从未被用到,所以就被抛弃了。
由此验证,shrink阶段,Proguard(混淆器)会把无用类文件等删除,一些被动态获取的类就需要注意了,需要进行-keep操作,使其成为入口点。
以上就是对混淆整个过程的验证。对于 Android 混淆,一些需要注意的东西,会在下一篇文章中记录。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/13086.html
摘要:因为同包名的情况下,混淆器是无法一个一个的进行混淆。所以最终的解决方案是,面对这种项目,还是在主中进行混淆吧。类似的处理库,等都是有反射代码的。最后,需要注意的是网上也会有大量现成的第三方类库的混淆规则。 文章转自我个人博客 Android 代码混淆(一) 中已经记录并走了混淆的整个流程,用命令行进行混淆的操作,并验证了三个过程,这篇文章会记录一下在 Android Studio 下混...
摘要:中调用的方法布局使用的构造函数等。检查混淆结果混淆过的包必须进行检查,避免因混淆引入的。将混淆过的包进行全方面测试,检查是否有产生。前者是提供的默认混淆文件,后者是开发者自定义混淆规则的地方。 本篇文章:自己在混淆的时候整理出比较全面的混淆方法,比较实用,自己走过的坑,淌出来的路。请大家不要再走回头路,可能只要我们代码加混淆,一点不对就会导致项目运行崩溃等后果,有许多人发现没有打包运行...
摘要:主要通过工具来提供代码混淆是什么是一个工具,用来混淆和优化代码。工作方式移除无效的代码,将代码中的类名函数名替换为晦涩难懂的名字。注意它只能混淆代码,工程中代码,资源文件图片,它是无法混淆的。 Android ADT主要通过ProGuard工具来提供代码混淆. 1. ProGuard是什么 ProGuard是一个工具,用来混淆和优化Java代码。 工作方式:移除无效的代码,...
摘要:前言是一个开源的代码混淆器。它可以混淆项目里面的代码,对的,你没看错,仅仅是代码。它是无法混淆代码,资源文件等。列出了原始的类,方法,和字段名与混淆后代码之间的映射。 1) 前言 ProGuard是一个开源的Java代码混淆器。它可以混淆Android项目里面的java代码,对的,你没看错,仅仅是java代码。它是无法混淆Native代码,资源文件drawable、xml等。 2)...
摘要:同时还可优化字节码,移除未使用的代码指令,以及用短名称混淆其余的类字段和方法。使用可以进一步的压缩代码还包括其他在字节码一级方法内和方法间执行分析的优化,可进一步减小大小和帮助提高其运行速度。ProGuard介绍 ProGuard是一个Java类文件压缩器,优化器,混淆器和预先文件验证器。 压缩步骤检测和删除未使用的类,字段,方法和属性。 优化步骤分析和优化方法的字节码。 混淆步骤使用短无意...
阅读 1990·2021-11-22 13:54
阅读 3277·2019-08-29 12:25
阅读 3314·2019-08-28 18:29
阅读 3419·2019-08-26 13:40
阅读 3170·2019-08-26 13:32
阅读 843·2019-08-26 11:44
阅读 2101·2019-08-23 17:04
阅读 2854·2019-08-23 17:02