某DEX_VMP安全分析与还原

本文为看雪论坛精华文章

看雪论坛作者ID：爱吃菠菜

一

思路整理

还原VMP需要哪些铺垫?

(1)定位VMP字节码

(2)分割VMP字节码

(3)还原成SMALI

(1)为什么要找VMP字节码的位置？

因为如果目标方法的字节码地址,都找不到,还原也就没法展开了。

(2)为什么要分割VMP字节码?

如果要反汇编成smali，起码要知道这条smali对应的字节码一共几个字节。在确定一条指令占几个字节后，还要知道这几个字节中，谁是操作码，谁是操作数。

(3)还原为SMALI

 有了前两步铺垫,最终我们可以解读一条完整的smali的含义。

二

某安卓VMP入口特征(2021.8月样本)

跳板方法

进入native后的参数处理逻辑。

 为了处理不同类型的返回值, 定义了多个jni方法。

 对应jni函数入口指令情况。

三

定位VMP字节码

逻辑

根据上述逻辑,则一定存在函数F,向F输入index可得到对应codeitem_addr
F(index) == codeitem_addr。

我们看一下这个函数,从index到codeitem_addr的过程
(0x2dce->0xcac85880)。

如何在十几万数量级的汇编中定位到这段代码的?

通过Trace记录REG信息，用到了两个关键数值,0x2dce(index)与0xcac85880(codeitems)，标记两个数值出现的中间区间即可。

展开上面的定位方式的两个前提条件:

我们已经有了关键数据0x2dce，但还需要知道另一个提前条件，
即codeitem是0xcac85880，所以这个信息是从哪得知的？
这里是本章的关键。

如何分析出codeitem的地址是0xcac85880?

(1) 已知明文

(2) 沙箱日志获取切入点

(3) JNI参数回溯

(4) 内存访问统计

(1)已知明文

目标APP内很多的onCreate()方法，其内部普遍调用了，
NBSTraceEngine.startTracing();以及super.onCreate()

我们选一个被vmp保护了的onCreate()作为分析目标， ZxWebViewActivity.onCreate()

(2) 沙箱日志获取切入点

① ZxWebViewActivity.onCreate内必定存在NBSTraceEngine.startTracing();以及super.onCreate()

② startTracing为静态方法，会被编译器编译为invoke-static

③ super.onCreate()为超类调用，会被编译器编译为invoke-super

④我们猜测vmp对invoke-static模拟实现借助了JNI函数，
所以我们触发ZxWebViewActivity.onCreate()执行，截取其调用序列，效果如下：

 大致逻辑为：

(3) JNI参数startTracing来源回溯

我们在trace中找到这条GetStaticMethodID()的出现位置，
然后作为起点向上展开回溯,希望找到其参数”startTracing”的最早出处，
如果有自动化的脚本和条件可进行污点分析，由于逻辑不是很复杂，这里人工回溯完成。

具体过程省略……

在trace中对参数”startTracing”来源进行一番回溯，最终发现了一个起到决定性作用的偏移值0x000081de。可以简单理解成，它以base+0x000081de的形式确立的参数”startTracing”。

结论：

如果0x000081de是那个起到决定性意义的数值，那么毫无疑问0x000081de来自codeitem。

在trace中找到0x81de的出现位置，

发现它来自于内存位置0xcac858a8。

(4) 内存访问统计

0x81de来自0xcac858a8，由于这个地址可能是codeitem，
因此我们检索一下，trace中对这片内存区域的访问情况。

0xcac858a8取前5个高位，忽略后3个地位，即检索对0xcac85???的访问。

找到19条指令，而对0xcac85???的访问，最早的第一条指令，出现在编号5691的位置，对应的内存地址为0xcac85890，说明这里是ZxWebViewActivity.onCreate()第一条字节码。

由于codeitem第一条字节码之前0x10个字节还存在一些固定内容，
所以0xcac85890-0x10取得codeitem地址0xcac85880，
即codeitem的地址是0xcac85880。

四

分割VMP字节码

现在已经有了某厂vmp codeitems全部内容，但是还没法反汇编成smali，

因为还不知道，第一条指令一共占几个字节，第二条指令一共占几个字节，
依次......

dalvik指令是不等长，反汇编成smali的话，起码要知道这条smali对应的字节码一共几个字节。在知道了每条指令占几个字节后，还要知道这几个字节中，谁是操作码,谁是操作数。

通过观察codeitem的内存段的读取情况,可以达到这个目的。

如何快速区分出操作码和操作数?

一般opcode后面会有一个EOR解密指令，以及一串类似定位handle的CMP指令操作，而operand没有，这就为区分opcode和operand提供了特征依据。

opcode解密逻辑？

由eor指令向上回key出现的位置,
即可确定key的来源,
以及解密逻辑.
大致逻辑:
off1 = sub( codeitem当前指令地址, codeitem基址 )
off2 = lsl( off1, 1)
key = load( base + off2 )
de_opcode = xor(en_opcode, key)

五

VMP字节码还原为SMALI

1、标准dalvik指令反汇编过程

2、VMP指令反汇编过程

由于使用了已知明文条件作为切入点，已知分析目标ZxWebViewActivity.onCreate()中，必定会调用startTracing()方法，
即必定存在invoke-static {v0}, method@00da6f // ...startTracing

又通过上面的分析得知关键值81de出现在这条invoke-static中，且充当操作数的角色,那么按照我们按照标准invoke-static反汇编规则进行解析，就可以得到结论。

VMP指令由标准指令基础上修改而来,有哪些异同？

3、还原VMP所有指令需要什么？

4、没有opcode对照表时如何展开还原?

(1)接口猜测法

method相关的invoke系列指令，可以通过JNI执行情况猜测。
Field相关的get set系列指令，也可以通过JNI执行情况猜测。

(2)参数推导法

方法调用前，会先准备参数，通常是声明类型的指令，可以很大程度缩小猜测的候选指令范围。

(3)标准dalvik指令格式的信息利用

由于vmp指令是由dalvik标准指令略微修改/变异而来，只做了较小的改动，仍然保留了BIT位分布特征这样信息。在做还原时，可以利用这些信息,一定程度缩小候选范围。

https://source.android.com/devices/tech/dalvik/instruction-formats
https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions

六

攻击面总结

1、分析路径

2、攻击面总结 && 启示

(1) 被VMP的方法内部存在已知明文指令。

(2) VMP的实现高度依赖JNI函数，通过HOOK拿到其调用信息，是非常有效的切入点与突破口。

(3) codeitems的连续性,集中存储的特性，通过内存访问统计最终被发现。

(4)某vmp指令由标准dalvik指令基础上略改而来，整体仍然保留了很多可用信息。

七

深入VMP还原的一些问题

略。

八

调试与工具总结

核心问题：

获取程序完整的执行&&数据信息 (trace)。

目前公开的主流的获取trace的方案：

① GDB调试

② FridaStalker编译执行

③ 脱机unicorn模拟执行

主流的获取trace的方案的弊端和缺陷：

① IDA / GDB
速度极慢，且会遭遇反调试。

② FridaStalker
不支持arm指令的thumb模式，且BUG多，遭遇vmp.so中的花指令时，基本无法正常使用。

③ PC上脱机unicorn模拟执行
vmp.so中存在大量jni call和system call，需要手动实现它们，unicorn才能完成运行。

基于以上问题的尝试：

实现原始APP进程环境 && 原始context中，通过unicorn构造虚拟化CPU，执行目标function，获得trace，无已知检测和对抗手段，简单过anti。

基于trace进行离线分析：

① trace形态可视化
文本 / json / 数据库 / EXCEL可视化表格 / 动态CFG图

② 基本的分析
地址含义解析 调用符号识别

③ 程序分析

污点分析 相似性分析等

看雪ID：爱吃菠菜

https://bbs.pediy.com/user-home-760871.htm

*本文由看雪论坛 爱吃菠菜 原创，转载请注明来自看雪社区

# 往期推荐

球分享

球点赞

球在看

点击“阅读原文”，了解更多！