Question

先用一个案例来看看加壳原理。首先自己弄一个 demo 程序，然后去某加壳网站上加固一下，得到加固之后的 apk，然后开始破解。

1.反编译 apk

解压 apk，看看大体的目录，得到 classes.dex 文件，然后用 dex2jar+jd-gui 得到 Java 源码，如图 24-1 所示。

图 24-1　反编译之后的源码

看到这里只有 Application 的壳，而且这个是加固之后的特点，都是这两个 Application 的。

使用 apktool 来反编译 apk，获取资源文件信息：

2.分析加密流程

加固程序把源程序进行加密操作然后隐藏到了一个地方，在之前一章中也说过了，隐藏的地方就那么几个：assets 目录、libs 目录、自己的 dex 文件。这里直接看 assets 目录，如图 24-2 所示。

图 24-2　assets 目录

多了这个文件，猜想这个可能就是处理之后的源 apk 了。在 AndroidManifest.xml 中看到了入口的 SuperApplication 类，下面来分析一下这个类：

这里一般都是在 attachBaseContext 方法中进行操作的，这里的时机比较早，首先会调用 loadLibs 方法进行加载 libs：

这里区分不同的平台，然后拷贝不同的 so 文件，继续看 copyLib 方法：

可以看到，从 assets 目录下把增加的两个 so 文件 libexec.so 和 libexecmain.so 拷贝到应用程序的 files 目录下，可以去看看 assets/ijm_lib 目录下的 so 文件，如图 24-3 所示。

图 24-3　so 文件目录

到这里 loadLibs 方法就执行完了，下面就开始调用 NativeApplication 的 load 方法进行加载数据，继续看 NativeApplication 类：

开始从应用程序的 files 目录中加载这两个 so 文件，load 方法也是一个 native 方法，继续看看这两个 so 文件内容。

首先用 IDA 打开 libexecmain.so 文件，如图 24-4 所示，但是发现，它里面并没有什么重要信息，连 JNI_OnLoad 函数都没有内容。

图 24-4　IDA 打开 libexecmainso 文件

继续查看 libexec.so 文件，如图 24-5 所示。

图 24-5　IDA 打开 libexec.so 文件

可惜的是，打开提示 so 文件格式错误，到这里就猜到了，这个 so 可能被加密处理了，ELF 格式改了，点击 Yes 继续强制打开之后，再使用 Ctrl+S 查看 so 的各个段信息，如图 24-6 所示。

现在确定，没办法分析 so 文件了，分析到这里，也知道了大体加密流程：

1）按照惯例把源 apk 进行加密处理存放在一个地方，通过分析猜想是 assets 目录下的 ijiami.dat 文件。

图 24-6　查看 so 中的段信息

2）添加壳 Application：SuperApplication 类在这个壳的 attachContext 方法中主要做了两件事：

·把 assets/ijm_lib 目录下的两个 so 文件 copy 到程序的 files 目录中。

·调用 NativeApplication 的 load 方法，在这个类中同时也把上面的两个 so 文件加载到内存中。

3）对 apk 的加密都是放在底层的两个 so 文件中操作的，通过 IDA 去分析这两个 so 文件之后，发现核心功能的 so 文件被加密了，IDA 打开是看不到具体信息了。

到这里知道加固之后的特点是：在程序的 assets 目录下多了一个 ijiami.dat 文件和两个 so 文件，同时这两个 so 文件被加密处理了，增加破解难度。