一、背景
自己编译的模拟器，它可以在源码上打log，做到可控。并且，所有的行为都会经过模拟器，比如后面你的url请求
二、常用的思路
加固思路有以下几种：
反模拟器，一旦发现模拟器，就停止核心代码运行
代码虚拟化，自己写的代码先运行在自己写的虚拟机上，后续再运行到系统的虚拟机上
加密，核心代码是以压缩或者加密形式存在的，被分割成一段一段的，需要的时候，再把目标段加载到内存。加壳方案，分为壳dex和源dex，壳不加密，源加密
关于第 3 种加固方案的总体示意图如下：
最后为什么有个签名，因为加固过程会修改 APK，必然破坏了 APK ，因此需要重新签名。以上方案值得我们的思考的有几点：
壳dex 与 源 dex 可以随意拼凑吗？
壳 dex 怎么生成？
如何签名？
如果运行新的 apk（如何脱壳）？
四、Apk打包过程
简单说一下 APK 的打包过程，整体流程如下图所示：
几个重要的过程：
首先 aapt 工具将资源文件生成 R.java 文件
aidl 工具将 aidl 文件生成 Java 文件
将上述的 java 文件、项目自己的 java 文件，通过 Java compiler 一起生成 .class 文件
.class 文件通过 dx 工具生成 dex 文件
将 dex 文件和那些资源文件一起压缩生成 apk
签名
加壳
生成原始 apk ，然后解压到目录 unzip 中文件夹中，当然，要把之前的签名文件给剔除；之后，找到所 unzip 中所有的 dex 文件，进行加密。
接下来，将项目中的一个 lib 生成的 aar 转成 dex 文件， dx 工具可以将 jar 转成 dex，当然，这个 lib 有自己的 Application ，在正式使用的时候，上述 原始 apk 中的 Application 在最开始的时候要通过反射的方式调用这个 lib 的 Application ，让其形式上作为 App 的默认 Application ，以便后续的解密。
将加密的 dex 和 aar 转成的 dex 一起放入 unzip 中，这样 ，unzip 文件夹中有了 加密的 dex 和 lib 的dex ，以及原始 apk 中所有的 资源，这时候通过 zip 压缩，就能将 unzip 中所有的内容压缩起来，改名 apk （这个打包apk 的过程需要确认）
最后，对这个 apk 进行签名，就形成了正式的apk 。
脱壳
上述打包的 APK 最终需要安装使用，安装成功后，
我们的安装包都会安装在
/data/data/包名/files/fake_apk/
这种目录下，在壳的 Application （那个lib 中的 Application）的 attachBaseContext 的时候，我们可以将这个apk加载进来，然后过滤出所有加密的 dex 文件，之后解密，然后将这些解密后的文件存入到指定的目录，后续就使用这些已经解密的dex 。当然，我们不需要每次都去解密这个 dex ，将其存起来就好了，下次直接使用。
对称加密、非对称加密
看了，但是笔记略
后续要根据视频内容自己写一下整个的加壳、脱壳的过程
