这是一款很老的壳了(4.4直接用hook opt的dexdump无法dump出。)，花了不短的时间，终于搞定了，今天记录一下流程。

先反编译，发现smali中的方法体都是Nop了。继续看Java代码，找到很可疑加载dex的地方

OK，下面进入native层找答案

先过一下反调试，反调试代码在initarray

相关资料

loadLibrary的流程

调试init和init_array技巧(这个壳是在init_array初始化反调试的)

反调试在gnu_..._11中,通过bsdsignal反调试的

代码中是判断常量为-1的时候，直接bsd了，我改的方法是，直接改成比较-2.然后重新覆盖so，由于我的系统刷的是没有安装签名校验的。

另一个点是检测data/local/tmp下面是否有android_server 由于我名字之前就改掉了，后面调试的时候才知道有这个。

经过漫长的调试，最终定位关键代码

interface4函数

由于接下来的so是动态加载的，所以不能实时保存日志，所以强烈建议写一个ida脚本动态保存日志，方便我们继续分析

这个是我写的，idapython脚本，有用但是很丑,凑合着用,根本就是根据起始地址和结束地址，然后把中间的日志和地址对应，保存起来。

又是漫长的调试，进入下一个关键地方

可以看到到这边已经修复classdefdata了。

附一张修复前和修复后的图

修复前

修复后

下面就是要向6520792这个偏移地址写真正的classdefdata了

这里说下 dump后的dex不是标准的dex，所以要baksmali一下，然后再smali，就是标准的dex了

整体流程:

hook了4.4的opt函数，所以无法dump出dex

更改原来apk的classdef以及classdefdate，将真正的数据存到apk中，native层从apk中取真正的classdef替换老的。

然后后面的任务，是直接自动化脱一下，顺便提升一下自己写C的能力（我C语言太菜了）

首先，先确认hook的点，第一个要得到apk地址，第二个找到修复后的点.

OK，最终确认了方案，用inject+substrate

1、通过hook字符串比较函数，确定apk地址

2、通过最后的munmap函数，拿到修复后的点

我C代码写的太烂了，还请大家包涵。。

最终mycql.dex就是dump出的dex了

最后付一个样本

[课程]FART 脱壳王！加量不加价！FART作者讲授！