android代码混淆恢复(详解代码混淆技术)-昊阳知识网

0、引言

Android代码混淆，老生常谈了，不过大部分Android仔对它的认识可能还处于这样的阶段(比如：写这篇文章前的我)：

1、日常开发Debug包时不用混淆，正式发布Release包前开启代码混淆；2、混淆好处① → 类、方法、变量名变成短且无意义的名字，提高反编译后代码的阅读成本；3、混淆好处② → 删除无用的类、方法与属性，缩减了APK包的大小；4、混淆好处③ → 对字节码进行优化，移除无用指令，应用运行更快；5、怎么混淆 → 主项目的 build.gradle 设置 minifyEnabled true，proguard-rules.pro 加入混淆规则；6、混淆规则哪里来 → 网上搜索通用混淆模板复制粘贴，项目依赖到的第三方库官方文档复制粘贴；

大都止步于此，好一点的还知道下 ProGuard 听过 R8，了解混淆配置语法，会自定义混淆规则。

会上面这些，日常开发已经很够用了，但是现在IT行业这么 “卷”，面试时，面试官问下：

混淆具体做了啥？有看过混淆源码吗？说下底层原理…

也说得过去吧 (手动狗头保命~)

所以本节稍微深入点探索下Android中的代码混淆~

1、日常使用

Tips：照惯例，写下简单例子演示日常使用，走走过场，只对混淆原理感兴趣的可以跳过这Part~

1. 混淆前后的APK对比

新建项目，引下Kotlin相关依赖，协程等 (app层级的build.gradle)：

dependencies{implementationfileTree(dir:”libs”,include:[“*.jar”])implementation”org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version”implementation’androidx.core:core-ktx:1.3.0’implementation’androidx.appcompat:appcompat:1.1.0’implementation’androidx.constraintlayout:constraintlayout:1.1.3’implementation’org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.7’implementation’org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.7′}

新建MainActivity.kt，请求URL，加载内容：

classMainActivity:AppCompatActivity(),CoroutineScopebyMainScope(){overridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)et_url.setText(“https://www.baidu.com”)bt_load.setOnClickListener{launch{tv_content.text=”开始加载请求…”tv_content.text=”加载完毕，网页内容如下：\n\n\n ${loadUrl(et_url.text.toString())}”}}}privatesuspendfunloadUrl(url:String)=withContext(Dispatchers.IO){varcontent=””(URL(url).openConnection()asHttpURLConnection).apply{requestMethod=”GET”content=dealResponse(inputStream)disconnect()}return@withContextcontent}privatefundealResponse(inputStream:InputStream):String{valreader=BufferedReader(InputStreamReader(inputStream))returnStringBuffer().apply{varstr=reader.readLine()while(null!=str){append(str)str=reader.readLine()}}.toString()}overridefunonDestroy(){super.onDestroy()cancel()}}

运行下康康：

app层级的build.gradle加下release的签名和编译配置：

signingConfigs{release{storeFilefile(‘test.jks’)storePassword’123456’keyAlias’test’keyPassword’123456′}}buildTypes{release{//启用代码压缩、优化及混淆minifyEnabledtrue//启用资源压缩，需配合minifyEnabled=true使用shrinkResourcestrue//指定混淆保留规则proguardFilesgetDefaultProguardFile(‘proguard-android-optimize.txt’),’proguard-rules.pro’//包签名signingConfigsigningConfigs.release}}

执行 gradle assemble 打下包，静待打包完毕，先康康Debug包：

23333，裸奔，把APK直接拖到反编译工具 jadx-gui 里，看代码无压力：

再康康Release包：

同样拖到jadx-gui里康康：

可读性明显降低~

2. 混淆后App Crash日志定位问题

不知道你有没有想过：混淆后的APK如果报错，日志信息会是怎样的呢？

单凭这里的b.b.a.a.onClick(Unknow Srouce:2)，似乎很难直接定位到错误代码的真实位置。

一种低效的解决方法：自行对照混淆后生成的 mapping.txt 文件，比如直接搜上面的b.b.a.a：

顺着往下看不难发现问题所在，但日常开发不建议用此法，这里好找只是因为示例代码简单，推荐另一种方法：

去混淆，如果你的应用有发布到Google Play的话，可以照着官方文档走：

对崩溃堆栈轨迹进行去混淆处理或符号化解析

没有上传到Google Play也没关系，直接用 android-sdk/tools/proguard/bin/proguardgui.bat：

去混淆前后对比：

可以的，日常使用就讲到这里，接着过一下混淆的详细规则。

2、混淆规则详解

1. 混淆设置参数-optimizationpasses5#代码混淆的压缩比例，值介于0-7，默认5-verbose#混淆时记录日志-dontoptimize#不优化输入的类文件-dontshrink#关闭压缩-dontpreverify#关闭预校验(作用于Java平台，Android不需要，去掉可加快混淆)-dontoptimize#关闭代码优化-dontobfuscate#关闭混淆-ignorewarnings#忽略警告-dontwarncom.squareup.okhttp.**#指定类不输出警告信息-dontusemixedcaseclassnames#混淆后类型都为小写-dontskipnonpubliclibraryclasses#不跳过非公共的库的类-printmappingmapping.txt#生成原类名与混淆后类名的映射文件mapping.txt-useuniqueclassmembernames#把混淆类中的方法名也混淆-allowaccessmodification#优化时允许访问并修改有修饰符的类及类的成员-renamesourcefileattributeSourceFile#将源码中有意义的类名转换成SourceFile，用于混淆具体崩溃代码-keepattributesSourceFile,LineNumberTable#保留行号-keepattributes*Annotation*,InnerClasses,Signature,EnclosingMethod#避免混淆注解、内部类、泛型、匿名类-optimizations!code/simplification/cast,!field/,!class/merging/#指定混淆时采用的算法2. 保持不被混淆的设置

语法组成：

[保持命令][类]{[成员]}

保持命令：

-keep#防止类和类成员被移除或被混淆；-keepnames#防止类和类成员被混淆；-keepclassmembers#防止类成员被移除或被混淆；-keepclassmembernames#防止类成员被混淆；-keepclasseswithmembers#防止拥有该成员的类和类成员被移除或被混淆；-keepclasseswithmembernames#防止拥有该成员的类和类成员被混淆；

类：

具体的类访问修饰符 → public、private、protected通配符(*) → 匹配任意长度字符，但不包含包名分隔符(.)通配符(**) → 匹配任意长度字符，且包含包名分隔符(.)extends → 匹配实现了某个父类的子类implements → 匹配实现了某接口的类$ → 内部类

成员：

匹配所有构造器 → <init>匹配所有域 → <field>匹配所有方法 → <methods>访问修饰符 → public、private、protected除了 * 和 ** 通配符外，还支持 *** 通配符，匹配任意参数类型… → 匹配任意长度的任意类型参数，如void test(…)可以匹配不同参数个数的test方法

常用自定义混淆规则范例：

#不混淆某个类的类名，及类中的内容-keepclasscn.coderpig.myapp.example.Test{*;}#不混淆指定包名下的类名，不包括子包下的类名-keepclasscn.coderpig.myapp*#不混淆指定包名下的类名，及类里的内容-keepclasscn.coderpig.myapp*{*;}#不混淆指定包名下的类名，包括子包下的类名-keepclasscn.coderpig.myapp**#不混淆某个类的子类-keeppublicclass*extendscn.coderpig.myapp.base.BaseFragment#不混淆实现了某个接口的类-keepclass*implementscn.coderpig.myapp.dao.DaoImp#不混淆类名中包含了”entity”的类，及类中内容-keepclass**.*entity*.**{*;}#不混淆内部类中的所有public内容-keepclasscn.coderpig.myapp.widget.CustomView$OnClickInterface{public*;}#不混淆指定类的所有方法-keepcn.coderpig.myapp.example.Test{public<methods>;}#不混淆指定类的所有字段-keepcn.coderpig.myapp.example.Test{public<fields>;}#不混淆指定类的所有构造方法-keepcn.coderpig.myapp.example.Test{public<init>;}#不混淆指定参数作为形参的方法-keepcn.coderpig.myapp.example.Test{public<methods>(java.lang.String);}#不混淆类的特定方法-keepcn.coderpig.myapp.example.Test{publictest(java.lang.String);}#不混淆native方法-keepclasseswithmembernamesclass*{native<methods>;}#不混淆枚举类-keepclassmembersenum*{publicstatic**[]values();publicstatic**valueOf(java.lang.String);}#不混淆资源类-keepclassmembersclass**.R$*{publicstatic<fields>;}#不混淆自定义控件-keeppublicclass*entendsandroid.view.View{***get*();voidset*(***);public<init>;}#不混淆实现了Serializable接口的类成员，此处只是演示，也可以直接*;-keepclassmembersclass*implementsjava.io.Serializable{staticfinallongserialVersionUID;privatestaticfinaljava.io.ObjectStreamField[]serialPersistentFields;privatevoidwriteObject(java.io.ObjectOutputStream);privatevoidreadObject(java.io.ObjectInputStream);java.lang.ObjectwriteReplace();java.lang.ObjectreadResolve();}#不混淆实现了parcelable接口的类成员-keepclass*implementsandroid.os.Parcelable{publicstaticfinalandroid.os.Parcelable$Creator*;}#注意事项：##① jni方法不可混淆，方法名需与native方法保持一致；#②反射用到的类不混淆，否则反射可能出问题；#③四大组件、Application子类、Framework层下的类、自定义的View默认不会被混淆，无需另外配置；#④ WebView的JS调用接口方法不可混淆；#⑤注解相关的类不混淆；#⑥ GSON、Fastjson等解析的Bean数据类不可混淆；#⑦枚举enum类中的values和valuesof这两个方法不可混淆(反射调用)；#⑧继承Parceable和Serializable等可序列化的类不可混淆；#⑨第三方库或SDK，请参考第三方提供的混淆规则，没提供的话，建议第三方包全部不混淆；3. 混淆规则的叠加

不知道你有没有想过：上面日常使用的创建的代码示例，proguard-rules.pro没有配置混淆规则，却混淆了？

① <module-dir>/proguard-rules.pro

不止主模块有proguard-rules.pro，子模块也可以有，因为规则是叠加的，故某个模块的配置都可能影响其它模块。

② proguard-android-optimize.txt

AGP编译时生成，其中包含了对大多数Android项目都有用的规则，并且启用 @Keep* 注解。

AGP提供的规则文件还有proguard-defaults.txt或proguard-android.txt，可通过 getDefaultProguardFile 进行设置，不过建议还是使用这个文件(多了些优化配置)。

③ <module-dir>/build/intermediates/proguard-rules/debug/aapt_rules.txt

自动生成，AAPT2会根据对应用清单中的类、布局及其他应用资源的引用，生成保留规则，如不混淆每个Activity。

④ AAR库 → <library-dir>/proguard.txt⑤ Jar库 → <library-dir>/META-INF/proguard/

如果想查看所有规则叠加后的混淆规则，可在主目录的 proguard-rules.pro 添加下述配置：

#输出所有规则叠加后的混淆规则-printconfiguration./build/outputs/mapping/full-config.txt4. 资源压缩

资源压缩其实分为两步：资源合并与资源移除，前者无论是否配置 shrinkResources true，AGP构建APK时都会执行，当存在两个或更多名称相同的资源才会进行资源合并，AGP会从重复项中选择优先级更高的文件，并只将此资源传递给AAPT2，以供在APK中分发。

级联优先顺序：

依赖项 → 主资源 → 渠道 → 构建类型

比如：重复资源存在于主资源及渠道中，Gradle会选择渠道中的资源；但如果重复资源在同一层次出现，如src/main/res/和src/main/res2中有重复资源，Gradle就会报资源合并错误。

说完资源合并，接着说下资源移除，开启资源压缩后，所有未被使用的资源默认会被移除，如果你想定义那些资源需要保留，可以在 res/raw/ 路径下创建一个xml文件，如 keep.xml，配置示例如下 (此文件不会打包到APK中，支持通配符*，此类文件可有多份)：

<?xmlversion=”1.0″encoding=”utf-8″?><resourcesxmlns:tools=”http://schemas.android.com/tools”<!–定义哪些资源要被保留–>tools:keep=”@layout/l_used*_c,@layout/l_used_a,@layout/l_used_b*”<!–定义哪些资源需要被移除–>tools:discard=”@layout/unused2″<!–开启严苟模式，可选值strict,safe，前者严格按照keep和discard指定的资源保留–><!–后者保守删除未引用资源，如代码中使用Resources.getIdentifier()引用的资源会保留–>tools:shrinkMode=”strict”/>

另外，还可以在build.gradle中添加 resConfigs 来移除不需要的备用资源文件，如只保留中文：

android{…defaultConfig{resConfigs”zh-rCN”//不用支持国际化只需打包中文资源}}3、从脱糖引出ProGuard、DX、D8、R8

我们都知道Java是跨平台的，一次编译，到处运行，同一套Java代码可以在Windows、Linux、Mac上运行，背后依赖于不同平台/版本的 JVM（Java虚拟机），Java代码编译后生成 .class 字节码文件，再由JVM翻译成特定平台的机器码，然后运行。

JVM的内部组成图如下：

类加载器：加载编译后的.class，链接、检测损坏的字节码，定位并初始化静态变量及静态代码；运行时数据：栈、堆、方法变量等；执行引擎：执行已经加载的代码、清理生成的所有垃圾(gc)；

运行程序时，Interpreter(解释器) 会将字节码解释为机器码然后运行，当发现有重复执行的代码时，会切换为 JIT编译器。JIT编译器会将重复的代码编译为本地机器码，当同样的方法被调用时，直接运行本地机器码，从而提高系统性能。

JVM的设计是面向无限电量/存储的设备，Android设备与之相比，太弱鸡了(电量、内存大小、存储等小的可怜)。

不能直接使用，于是Google自己设计了一套用于Android平台的Java虚拟机——Dalvik，支持已转换为 .dex (Dalvik Executable) 压缩格式的Java应用程序的运行。

与JVM字节码基于栈不同，Dalvik基于寄存器(变量都存储在寄存器中)，后者更加高效且需要更少的空间。

.java和.kt代码文件被Java、Kotlin编译器协作编译为.class，而后编译为.dex文件，最后打包到.apk文件中。

在Dalvik中，应用的每次运行都需要执行编译操作，而这段时间是计入程序的执行时间，所以程序的启动速度会有点慢，当然也有好处，应用安装速度快。

在Android 4.4.4后，Google开始引入 Dalvik 的替代品——ART，从JIT(Just In Time，即时编译) 到 AOT (Ahead-Of-Time，预编译)，应用在首次安装时用dex2oat将 dex 编译为 .oat 二进制文件。

除了应用安装会触发dex2oat编译外，OTA升级、系统启动(首次/非首次)、系统空闲时也可能会触发，具体要看对应系统的配置。

上面说过Android虚拟机采用基于寄存器的指令集(opcodes)，这样会存在一个问题，更高版本Java新引入的语法特性不能在上面直接使用。

为了让我们能使用上Java 8的特性，Google使用 Transformation 来增加了一步编译过程 → 脱糖(desugaring)。

当使用当前Android版本不支持的高版本jdk语法时，在编译期转换为其支持的低版本jdk语法。

脱糖实现的大概发展历程如下：

至此，相信你对ProGuard、DX、D8和R8在混淆过程中起的作用有了一个基础的认知~

4、用 ProGuard 还是 R8?

答：如果没有历史包袱，直接R8，毕竟兼容绝大部分的ProGuard规则，更快的编译速度，对Kotlin更友好。

还是简单描述下两者吧：

如果不想用R8，想用回ProGuard的话(可以但没必要)，可以在 gradle.properties 文件中添加下述配置禁用R8：

android.enableR8=falseandroid.enableR8.libraries=false

编译APK时可能会报错：

在 proguard-rules.pro 文件中加上 -ignorewarnings 即可解决。

另外，使用ProGuard或R8构建项目会在 build\outputs\mapping\release 输出下述文件：

mapping.txt → 原始与混淆过的类、方法、字段名称间的转换；seeds.txt → 未进行混淆的类与成员；usage.txt → APK中移除的代码；resources.txt → 资源优化记录文件，哪些资源引用了其他资源，哪些资源在使用，哪些资源被移除；

Tips：上述文件不一定都有，R8可以在 proguard-rules.pro 文件添加下述配置输出对应文件：

#输出mapping.txt文件-printmapping./build/outputs/mapping/mapping.txt#输出seeds.txt文件-printseeds./build/outputs/mapping/seeds.txt#输出usage.txt文件-printusage./build/outputs/mapping/usage.txt复制代码5、D8干了啥？

接着跟下源码，康康D8具体都做了啥，在上一节《补齐Android技能树——从AGP构建过程到APK打包过程》中我们摸清了APK的打包Task链，打包成Dex经历的Task有三个：

transformClassesWithDexBuilderForDebug → 将class打包成dextransformDexArchiveWithExternalLibsDexMergerForDebug → 打包第三库的dextransformDexArchiveWithDexMergerForDebug → 打包最终的dex

三个Task最终都是通过DX或D8来打dex，跟下第一个Task：DexArchiveBuilderTransform.transform()

这里拿到需要待脱糖的文件列表，接着往下就来到熟悉的：处理目录下的class 和 .jar里的class 了。

这里把待脱糖的文件列表传到 convertToDexArchive() 里了，跟下：

跟 launchProcessing() → dexArchiveBuilder.convert()

抽象类，跟下具体实现类 D8DexArchiveBuilder.convert()，

D8Command类是D8命令行配置类，就是将上面进行的这些配置转换成 d8打包命令而已：

命令行配置参数详解可以参见官方文档：d8，这里就不去刨d8的源码了，知道D8起做的作用是：脱糖将.class字节码转换成dex 就好。

6、R8又干了啥？

不知道，细心你的有没有发现，D8竟在r8的包里：

接着在 TaskManager.java 搜下D8，经过各种跳转，来到源头：createPostCompilationTasks()，可以看到在创建D8相关的Transform前还做了一些其他的操作~

① R8 – 执行前

从注释不难看出，这些Tasks就是用来把.class转dex文件的，还加了一些可选步骤如混淆、jacoco(代码覆盖率工具)，还创建了一个 TransformManager 实例，用来管理各种TransformManager。继续：

这里引起了我的好奇，可能创建脱糖Task？脱糖不是在D8里进行的吗？跟一下代码：

这里的DESUGAR，猜测是旧版本的D8兼容，AS 3.0引入的，而现在默认是D8，所以这里其实不会创建脱糖Task。继续：

获取外部扩展，合并Java资源，对合并算法感兴趣的可以点进去 MergeJavaResourcesTransform.transform() 看下，这里不展开讲~

继续往下走：

② R8 – Java代码压缩

再往下走，就碰到关键词R8了：

这里有下述三个maybe：

maybeCreateJavaCodeShrinkerTransform → Java代码压缩maybeCreateResourcesShrinkerTransform → 资源压缩maybeCreateDexSplitterTransform → dex分割

先看第一个：

//前面获取dex的文件列表、混淆列表等，初始化R8Transform实例时传入R8Transformtransform=newR8Transform(variantScope,userMainDexListFiles,userMainDexListProguardRules,inputProguardMapping,variantScope.getOutputProguardMappingFile());//处理混淆规则，callback用于在混淆后执行后续操作returnapplyProguardRules(variantScope,inputProguardMapping,variantScope.getOutputProguardMappingFile(),testedVariantData,transform,callback);

//Thisisa”normal”variantinanapp/library.applyProguardConfigForNonTest(transform,variantScope);

跟下此方法：

跟下 R8Transform.transform()，又是参数，最后调用下述方法：

最后在 r8Tool.kt 中定位到了此方法，核心代码如下：

//初始化了一个r8CommandBuilder实例valr8CommandBuilder=CompatProguardCommandBuilder(!useFullR8,D8DiagnosticsHandler(messageReceiver))//然后调用一系列方法，如混淆相关addMainDexRules()setMainDexListConsumer()addProguardConfigurationFiles()addProguardConfiguration()setProguardMapOutputPath()//配置相关：是否禁用缩小、摇树、脱糖、编译模式setDisableMinification(toolConfig.disableMinification)setDisableTreeShaking(toolConfig.disableTreeShaking)setDisableDesugaring(toolConfig.disableDesugaring)setMode(compilationMode)setProgramConsumer(programConsumer)…//初始化r8ProgramResourceProvider实例，用来给R8提供所有资源valr8ProgramResourceProvider=R8ProgramResourceProvider()//各种传参设置//最后调用R8.run()ClassFileProviderFactory(libraries).use{libClasspath->r8CommandBuilder.addLibraryResourceProvider(libClasspath.orderedProvider)R8.run(r8CommandBuilder.build())}

具体的逻辑，可以追溯到 R8.class → run()，做了这些事：

代码删除：通过语法树静态分析技术、发现并删除未使用的代码，如未实例化的Class等；代码优化：对运行时代码进行优化，删除死代码、未使用的参数，选择性内联、类合并等；代码混淆：优化标识符名字，减少代码量，会判断混淆规则中是否允许修改标识符名字；行号重新映射等。

短短333行的处理代码，逻辑复杂，恐怖如斯，感兴趣的自己看吧，我是啃不动了…

③ R8 – 资源压缩

接着跟下第二个 maybeCreateResourcesShrinkerTransform()：

跟下 ShrinkResourcesTransform.transform()，

跟下 SplitterRunnable.run()，看下具体是怎么压缩资源的，核心代码如下：

//①创建资源优化记录文件FilereportFile=null;if(params.mappingFile!=null){FilelogDir=params.mappingFile.getParentFile();if(logDir!=null){reportFile=newFile(logDir,”resources.txt”);}}//②分析资源及使用情况analyzer.analyze();//③重写.ap_文件(上面AAPT2生成的)，去掉没有用到的资源，实际上是没有删除本地资源的！analyzer.rewriteResourceZip(params.uncompressedResourceFile,params.compressedResourceFile);//③导出统计数据

解压AAPT生成的.ap_文件，然后判断是是否为未使用资源，是的话移除，感兴趣可以跟下 rewriteResourceZip()。

④ R8 – 调D8拆Dex

只有使用了 Multidex 才会走这里，跟下代码：

跟下 DexSplitterTransform.transform()

跟下 DexSplitterTool.Builder

跟下 DexSplitter.run()

跟下 DexSplitterHelper.run()

所以最后还是用的D8打Dex，总算把大概的过程过完了~

7、自定义混淆字典

之前在反编译人家的APP时看到标识符竟然不是abcd，而是中文和特殊字符，怎么做到的呢？其实不难，自定义一个混淆字典就好，在app的proguard-rules的同级目录创建一个文件，比如 dictionary，内容示例如下：

﹢﹣×÷…太长省略

接着在 proguard-rules 添加下述配置：

-obfuscationdictionary./dictionary-classobfuscationdictionary./dictionary-packageobfuscationdictionary./dictionary

再接着 gradle assemble 打下包，用jadx打开生成的Release APK康康：

23333，效果极佳，喜欢反编译别人APK的同学看到了，不会打我吧！

8、模块化混淆

混淆的开启由app模块控制，与子模块无关。

建议在app模块设置公共混淆规则，子模块设置专属混淆规则，子模块区分project和aar：

#Project类型，配置方法同app模块buildTypes{release{minifyEnabledfalseproguardFilesgetDefaultProguardFile(‘proguard-android.txt’),’proguard-rules.pro’}}#AAR类型android{defaultConfig{consumerProguardFiles’lib-proguard-rules.txt’}…}

当然，你想让混淆规则都由app模块控制也是可以的，移除模块时记得删掉对应的混淆就好~

小结

淦(gàn)，看源码到吐血，Gradle相关的东西真的是无底洞啊，学完一个又一个，还有著名的ASM字节码插桩，基于APK构建过程Task的HOOK的各种开源性能优化/检测工具等。

不过源码过完流程了解了心里有底，再看别人这些开源项目时就不会跟看天书一样了~