Android Apk 反编译与混淆
反编译工具
目前反编译工具有四类
1、apktool 主要用于资源文件的获取
2、dex2jar 将apk中的dex文件编译成jar文件
3、jd-gui 查看反编译后的jar中的class
4、jadx 直接查看资源与代码
apktool:如果APK未加固，解压后可以看到APK里面的一些资源文件，比如我们看中了某个APP的一些UI控件，或者想分析AndroidManifest里面的启动是怎样的，或者游戏apk包需要改icon和名称，直接用apktool解压就行了。
网上随便找一个apktool版本，尽量高一点的，我们反编译可以用这种方式。在当前目录，存在一个apktool和一个apk，并且在当前目录打开cmd文件，输入java -jar apktool_2.4.0.jar d app-debug.apk -o dir，最后可以得到一个dir文件，资源什么的都出来了。对于仅仅只需要反编译需求。
指令很多，我通常用我自己的一套反编译方法，有反编译，回编译。
反编译：需要当前目录的apk,apktool.jar,apktool.bat,执行命令后就会得到一个test的文件夹，注意配置好jdk环境变量啥的。
xdqxz.keystore是你的签名文件，里面包含签名密码和alias
Test.apk是要反编译的目标apk
apktool是你要反编译工具的版本，名称就改成apktool
apktool.bat里面的东西为下图
@echo off
set PATH=%CD%;%PATH%;
java -jar "%~dp0\apktool.jar" %1 %2 %3 %4 %5 %6 %7 %8 %9
Test文件夹就是你反编译之后的文件夹
回编译
比如我改了游戏apk里面的icon等等之后，想让他重新变为新的apk
我先把Test文件夹改成huanxiang这个名字，其实改成什么名字都一样，到时候执行命令的时候要同步变化即可
apk解压后的文件变成APK，但这仅仅是没签名的APK
apktool b huanxiang -o new_huanxiang_unsign.apk
要变成签名的apk执行命令jarsigner -verbose -keystore xdqxz.keystore -storepass 123456 -keypass 123456 -signedjar new_huanxiang_signed.apk new_huanxiang_unsign.apk android.keystore -sigalg SHA1withRSA -digestalg SHA1
dex2jar是将apk中的dex文件编译成jar文件
如果我们有个apk，想看编译apk里面dex文件的源码，可以用这个工具。
下载dex2jar工具，在工具当前目录打开cmd文件，如果目标文件叫app-debug.apk
执行命令d2j-dex2jar.bat app-debug.apk -o app-debug.jar就可以在当前目录得到一个app-debug.jar的jar包
然后用jdu工具去查看这个jar包里面的东西就可以了。直接把jar拖进去就可以看
jadx
这个工具的作用就是直接可以查看apk里面的代码，双击jadx工具选择对应的apk就会出现目录结构。
混淆
Proguard是一个代码优化和混淆工具。
能够提供对Java类文件的压缩、优化、混淆，和预校验。压缩的步骤是检测并移除未使用的类、字段、方法和属性。优化的步骤是分析和优化方法的字节码。混淆的步骤是使用短的毫无意义的名称重命名剩余的类、字段和方法。压缩、优化、混淆使得代码更小，更高效。
开启proguard
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
我们常用的混淆方法其实可以有个模板在AS里面能找到
可以拿以上图左参考，混淆的规则还是挺多的，讲几个最常用，用的最多最有效的吧。
我们代码里面很多没有在程序里面使用过调用过的类，打包出去的时候可以混淆过滤掉，可以在根目录的proguard-rules.pro文件里面添加-dontoptimize属性，一般来说这个属性都要添加。
另外用的最多的混淆的三个地方就是：
-keep 指定类和类成员（变量和方法）不被混淆。
-keep class com.dongnao.proxy.guard.test.Bug
（保护了类名）
-keep class com.dongnao.proxy.guard.test.Bug{
public static void *();
}
（保护了 public static void的没有参数的函数）
-keep class com.dongnao.proxy.guard.test.Bug{
*；
}
(保护所有)
-keepclassmembers 指定类成员不被混淆(就是-keep的缩小版，不管类名了)。
-keepclassmembers
class com.dongnao.proxy.guard.test.Bug
（都被混淆了）
-keepclasseswithmembers 指定类和类成员不被混淆，前提是指定的类成员存在。
-keepclasseswithmembers class com.dongnao.proxy.guard.test.Bug
(保护类名，但是没指定成员，所以函数名被混淆)
-keepclasseswithmembers class com.dongnao.proxy.guard.test.Bug{
native <methods>;
}
全被混淆了。注意 前提是指定的类成员存在 因为不存在native函数，所以这条语句等于无效，
然后混淆后的apk通过jadx来查看，就会看到类名变成了a/b/c这样的。那如果我们集成了类似友盟、bugly等异常上报功能，那么我们怎么知道这个异常到底出现在哪里？
我们在Activity中主动写一个bug
然后生成一个debug的apk
运行产生这样的日志:
这个日志有两个问题：
1、 我们不知道是哪个类报告出的。
2、 不知道这个类是哪一行报出的。
混淆后的代码错误栈恢复方法(outputs/mapping/debug/mapping.txt文件中保存了混淆前后的对应关系)
1.把错误信息保存到文件
2.使用工具 sdk/tools/groguard/bin/retrace.bat先配置 -keepattributes SourceFile,LineNumberTable再执行 retrace.bat -verbose mappint文件 bug文件
第一个问题很显然是由于我们的代码进行了混淆。
在开启混淆后，我们生成apk会产生
dump.txt
说明 APK 中所有类文件的内部结构。
这个文件内容非常多，可读性也并不高
mapping.txt
提供原始与混淆过的类、方法和字段名称之间的转换。
seeds.txt
列出未进行混淆的类和成员。我们保护的zip没有被混淆
usage.txt
列出从 APK 移除的代码。可以在这个文件中查看是不是有我们不想被移除的类
最重要的当然就是我们的mapping文件了。通过这个文件我们就能定位到:
出现错误的函数是Bug类中的test函数。
我们现在比较简单，所以一下子就能定位到错误函数，如果函数层级较深，光靠自己比对来查找难度就比较大了。所以sdk中提供了一个工具在tools/proguard/bin中。
我们把logcat里面保存的错误堆栈复制到一个文件中：
然后执行retrace 脚本（在 Windows 上为 retrace.bat；在 Mac/Linux 上为 retrace.sh）
retrace.bat|retrace.sh [-verbose] mapping.txt [<stacktrace_file>]
现在错误日志一句mapping还原了。
所以我们每次在发布版本之后都需要保留这个mapping文件。所以一般异常上报平台都会提供mapping上传然后帮助我们分析。
第一个问题解决的，第二个问题是行数显示的是Unknow Source
如果希望出现具体行数,我们需要在配置文件中加入
抛出异常时保留代码行号，在异常分析中可以方便定位
-keepattributes SourceFile,LineNumberTable
另外还可以配合
-renamesourcefileattribute AAA
使用字符串"AAA"来替代真正的类，避免泄漏更多的信息
虽然我们的代码经过了混淆，但是实际上，对于有耐心有条件的人来说，还是能够从混淆过后的代码中看到蛛丝马迹。
dex2jar: java
https://sourceforge.net/projects/dex2jar/
反编译后生成了一个jar
然后使用jd-gui打开：
http://jd.benow.ca/
直接跳到了，更加方便。
所以只要花功夫，混淆完全能够被完整的解读出来。当然并不是说混淆就没用。混淆之后解读难度更大了。
proguard移除无用代码还能缩小apk大小。
