apk提取加密素材_高效IO之Dex加密（三）

更多Android高级架构进阶视频免费学习请点击：

哔哩哔哩 ( ゜- ゜)つロ 乾杯~ Bilibili​space.bilibili.com

apk加固原理之dex加密

原理其实不复杂，加固其实就是加密dex文件，防止dex专程jar 被阅读。后面才是热部署解密dex；

一、加密和解密方案

既然我们已经弄清了apk是如何打包的，那么将加密流程加到整个打包流程就相对清晰了。如下图

什么?还是不懂呢？那来看看我们整个加密和解密方案呢？

我们的思路如下：

既然我们要加密，那么必然有解密，但是这个解密又必然是整个应用的一部分，但是连这部分都加密的话，那么系统就完全无法解析我们的应用，也就是完全无法安装了。所以我们需要将解密的部分提取出来单独作为一个module，且这个module是不能够被加密的。然后最好的解密时机就是首次启动应用的时候进行，所以Application自然成了我们负责解密的首选。那么是否意味着原apk中不能有这个module呢？答案是：错啦。原apk中同样要将这个解密module打包进去,否则原apk也无法编译通过啊。
我们都知道，系统在加载类的时候都是从我们apk的dex文件中加载的。ClassLoader会去维护一个这样的dex文件数组（这个在前面的热修复章节有介绍过）。而我们要做的就是将原apk中的dex都加密，然后将解密部分的代码单独编程成dex文件（我们称这样的dex为壳dex）连带着加密的dex一起加到新apk中。这样新apk安装后系统就能够找到我们应用启动的入口Application了，不至于由于加密导致系统找不到应用程序入口。而在这个程序入口中我们要做的就是解密被加密的dex文件，然后重新插入到ClassLoader维护的dex文件数组中（这里就涉及到大量的反射知识）。
三、加密实现
方案说了那么多，到底如何实现呢？实现后到底能不能像我们说的那样正常安装运行呢？撸代码来验证！

先来看看我们加密工程未运行前的结构图

再来看看工程运行后，工程结构的变化

可以看到运行后原apk被加密和解密模块被放到一起重新打包成了新的apk。这个过程代码如何实现呢？

1、既然要加密，必然要