使用FART脱带有指令抽取功能的壳

前几天对某银行客户端做安全评估，该客户端经过加壳处理，传输数据也经过加密。最终对客户端进行脱壳，分析出了加密点和解密点，利用frida和burp最终完成整个评估工作。

1 脱壳

脱壳工具，我这里有两个，DexExtractor是基于dvm虚拟机，Fart基于art虚拟机。需要单独指出的是Fart可以用来对抗指令抽取的壳，可以将抽取的指令还原。具体使用方法参见{原创}FART：ART环境下基于主动调用的自动化脱壳方案-『Android安全』-看雪安全论坛。具体刷机过程本文直接省略掉。

1.1 配置fart文件

配置文件中为你想脱壳的客户端包名， 注意不要加换行符 。

com.aipao.hanmoveschool

1.2 启动应用

直接启动应用即可，需要等待一段时间。脱壳成功会在 /sdcard/fart/应用包名 下找到dex文件和对应的bin文件。如图：

图2  脱壳后文件

1.3 Jeb分析

直接通过jeb载入脱壳后的dex文件，定位到http请求的发起处方法 public static void c(Context arg5) 。可以看到具体的请求内容是 toString 的返回值。

图3  请求发起处

但是我们反编译深入查看 toString 函数，却发现都是直接返回 null 。这里我怀疑经过了指令抽取。

图4  jeb反编译结果

直接查看smali代码，发现除了一条const指令和ret指令外，全是空指令nop。

图5  经过指令抽取

2 修复指令

通过fart.py对dex进行指令修复，并且把修复结果重定向到repired.txt文件中。在repired.txt即可看到所有方法修复前以及修复后的指令。

python fart.py -d xxx_dexfile_execute.dex -i xxx_ins_execute_10445.bin >> repired.txt

通过分析解密后的指令，发现 toString 方法内部调用了 getMessage 方法。如图可以观测 getMessage 方法修复之后的逻辑。

图6  修复前

图7  修复后

同理可以从之前截图中的onSuccess方法中找到解密方法的位置。

图8  onSuccess

图9  修复后的解密函数

3 Frida Hook

由于客户端经过加壳处理，有双进程保护，所以frida attach无效，需要使用spawn的方式注入。

frida -U -f package_name -l xxx.js

脚本代码如下：

图10  脚本代码