Question

到这里算是脱壳成功了，下面总结脱壳流程。

在脱壳的过程中，就一个目标：dump 出内存中的 dex 文件。但是在上面分析了加固流程之后，发现它做了这些事：把源程序 apk 加密处理放到了 assets 目录下的 ijiami.dat，也同时在 assets\ijm_lib 目录下添加两个 so 文件 libexec.so 和 libexecmain.so，这里两个 so 文件用来处理整个 apk 解密，动态加载等逻辑，但是用 IDA 查看得知，这两个 so 文件被加密处理了。

首先，添加自己的壳 Application 即 SuperApplication 类，这个类中的 attachContext 方法中，首先把 assets 目录中的两个 so 文件 copy 到应用的 files 目录下，然后使用 System.load 方法，加载这个 files 目录中的两个 so 文件。

然后，在给 dvmDexFileOpenPartial 下断点进行调试的时候，发现有反调试检测，因为无法给 JNI_OnLoad 下断点来去除反调试功能的 arm 指令，所以只能去修改内存数据，把 TracerPid 的值变成 0，骗过检测了。这里的思路就是给 fopen 和 fgets 这两个函数下断点，因为反调试的原理就是读取本进程的 status 文件，然后获取 TracerPid 那行内容即可，所以这里肯定用到了 fopen 和 fgets 函数，在使用 fgets 这个函数的时候，会读取每行内容，那么我们只要发现在读取到 TracerPid 那行内容的时候，去修改内存值，把 TracerPid 字段的值改成 0 即可。

有了上面的反调试思路之后，就开始进行操作了，但是在操作的过程中发现多次执行了 fopen 和 fgets 函数，而且需要修改多次 TracerPid 的值，原因很简单，因为是反调试检测，肯定是在子线程中轮询去检测这个值，会执行多次很正常，所以要修改多次 TracerPid 的值，骗过检测，直到当在主线程中，代码运行到了解密 dex 文件的时候，即到了 dvmDexFileOpenPartial 函数处的断点处为止。

最后修改多次 TracerPid 值，骗过检测，到了 dvmDexFileOpenPartial 这里，这时候，再执行 dump 脚本，把内存中的 dex 数据 dump 到本地即可。

通过上面的调试和破解流程其实不难发现，加密的流程是这样的：

1）fopen——/proc/self/cmdline.debug.atrace.app_cmdlines。

2）fgets——com.droider.crackme0201。

3）dvmLoadNativeCode——加载 libexec.so。

4）dvmLoadNativeCode——加载 libexecmain.so。

5）建立反调试线程（通过检查是否存在调试进程）。

6）调用 fopen——打开/proc/pid/status。

7）调用 fgets——读取调试进程 pid。

这里除了 dvmDexFileOpenPartial 函数，还有一个重要的函数 dvmLoadNativeCode，它是加载和初始化 so 的函数，感兴趣的读者可以去给这个函数下断点看看运行逻辑。

所以只需记住目的只有一个：到达 dvmDexFileOpenPartial 函数处，dump 出内存中的 dex 文件，就算是完成脱壳工作了。