【1】加固

一、为什么要加固

通过反编译apk可以获得dex文件和一些res文件，也可获得相应的java文件，从而也可以达到自定义apk，或者汉化等效果，甚至直接窃取相关机密代码。这对某些apk来说是不安全的，也侵犯了开发者的权益，所以有时会用到app加固技术。

二、加固方案

①免费的第三方加固方案

360加固等

②付费的第三方加固方案SDK

360加固等

③Java IO 流实现AES加密dex

后文【5】、【6】、【7】

【2】加固方案的实现方式

反模拟器
代码虚拟化
加密(dex)

在这里插入图片描述

【3】apk文件构造

Android上可直接运行的文件类型是apk文件，它其实是一种zip文件。就好比windows上的exe文件。exe文件在Windows上能直接运行，Android中能直接运行的就是apk
解压后得到：
反编译后的文件类型

META_INF目录下存放的是签名信息，用来保证apk包的完整性和系统的安全。生成一个apk包时，会对所有要打包的文件做一个校验计算，并把计算结果放在META-INF目录下。而在Android平台上安装apk包时，应用管理器会按照同样的算法对包里的文件做校验，如果校验结果与META-INF下的内容不一致，系统就不会安装这个apk。这就保证了apk包里的文件不能被随意替换。比如拿到一个apk 包后，如果想要替换里面的一幅图片，一段代码，或一段版权信息，想直接解压缩、替换再重新打包，基本是不可能的。如此一来就给病毒感染和恶意修改增加了难度，有助于保护系统的安全。
AndroidManifest.xml 是每个应用都必须定义和包含的，它描述了应用的名字、版本、权限、引用的库文件等等信息，如要把apk上传到Google Market上，也要对这个xml做一些配置。
classes.dex是java源码编译后生成的java字节码文件。但由于Android使用的dalvik虚拟机与标准的java虚拟机是不兼容的，dex文件与class文件相比，不论是文件结构还是opcode都不一样。目前常见的java反编译工具都不能处理dex文件。
res目录存放资源文件。
resources.arsc编译后的二进制资源文件。

【3】dex文件构造（分段dex文件加密需要）

dex文件构造

【4】apk打包流程分析

在这里插入图片描述

①打包资源文件，生成R.java文件
打包资源的工具是aapt（The Android Asset Packaing Tool）在这个过程中，项目中的AndroidManifest.xml文件和布局文件XML都会编译，然后生成相应的R.java，另外AndroidManifest.xml会被aapt编译成二进制。存放在APP的res目录下的资源，该类资源在APP打包前大多会被编译，变成二进制文件，并会为每个该类文件赋予一个resource id。对于该类资源的访问，应用层代码则是通过resource id进行访问的。Android应用在编译过程中aapt工具会对资源文件进行编译，并生成一个resource.arsc文件，resource.arsc文件相当于一个文件索引表，记录了很多跟资源相关的信息。
②处理aidl文件，生成相应的.Java文件
这一过程中使用到的工具是aidl（Android Interface Definition Language），即Android接口描述语言。aidl工具解析接口定义文件然后生成相应的.Java代码接口供程序调用。如果在项目没有使用到aidl文件，则可以跳过这一步。
③编译项目源代码，生成class文件项目中所有的.Java代码
包括R.java和.aidl文件，都会变Java编译器（javac）编译成.class文件，生成的class文件位于工程中的bin/classes目录下。
④转换所有的class文件
生成classes.dex文件dx工具生成可供Android系统Dalvik虚拟机执行的classes.dex文件。任何第三方的libraries和.class文件都会被转换成.dex文件。dx工具的主要工作是将Java字节码转成成Dalvik字节码、压缩常量池、消除冗余信息等。
⑤打包生成APK文件所有没有编译的资源
如images、assets目录下资源（该类文件是一些原始文件，APP打包时并不会对其进行编译，而是直接打包到APP中，对于这一类资源文件的访问，应用层代码需要通过文件名对其进行访问）；编译过的资源和.dex文件都会被apkbuilder工具打包到最终的.apk文件中。打包的工具apkbuilder位于 android-sdk/tools目录下。
⑥对APK文件进行签名
一旦APK文件生成，它必须被签名才能被安装在设备上。在开发过程中，主要用到的就是两种签名的keystore。一种是用于调试的debug.keystore，它主要用于调试，在Eclipse或者Android Studio中直接run以后跑在手机上的就是使用的debug.keystore。另一种就是用于发布正式版本的keystore。
⑦对签名后的APK文件进行对齐处理
如果你发布的apk是正式版的话，就必须对APK进行对齐处理，用到的工具是zipalign。对齐的主要过程是将APK包中所有的资源文件距离文件起始偏移为4字节整数倍，这样通过内存映射访问apk文件时的速度会更快。对齐的作用就是减少运行时内存的使用。

【5】项目构造（加密、解密）暂不涉及逻辑

项目中新建module-library，在这个library中application的attachBaseContext方法中实现dex解密逻辑，并且通过反射和类加载机制将解密后的dex动态添加到element数组中(可以参考微信热修复框架）
app从这个application启动

在这里插入图片描述

aar文件是什么？

aar文件相比apk文件没有签名文件，里面是jar包而不是dex文件，在这里作为壳dex

获取aar：

在这里插入图片描述

【6】加密流程

解压apk文件，过滤得到源dex文件（同时丢掉签名文件META_INF，后续打包后重新签名）
通过流操作将dex文件写到自定义目录下面
循环所有dex文件对其进行AES字节加密，最后修改dex文件名，以示区分（与未密过的dex文件）
将aar文件解密，获取jar包
通过jar2dex 将获取的jar转换为dex文件（壳dex）
将壳dex通过io输出到上面有加密后dex文件的目录下

至此已经得到了加固项目的整个dex文件，接下来要做的就是利用apktool和keystore进行打包签名。

打包、签名
得到加固后的apk文件
发布

【7】解密流程

在壳module-library的application里面的attachBaseContext里面写解密代码（商用项目中通常hookApplication，因为像我这样操作实际的项目就没有application了）
得到解密后的dex
参考微信Tinker，利用反射和Android类加载机制将解密后的dex动态插入到element数组中。