某DEX_VMP安全分析与还原
2022-1-16 18:7:55 Author: mp.weixin.qq.com(查看原文) 阅读量:42 收藏


本文为看雪论坛精华文章

看雪论坛作者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}, [email protected] // ...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

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

# 往期推荐

1.怎样制作一个防止重打包的APK【反脱壳反HOOK】

2.CVE-2019-9081 Laravel5.7 反序列化 RCE复现

3.某火热区块链游戏(mir4)的一次通信协议分析

4.从分析一个赌球APP中入门安卓逆向、开发、协议分析

5.常见的几种DLL注入技术

6.侠盗猎车 — 玩转固定码

球分享

球点赞

球在看

点击“阅读原文”,了解更多!


文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458419160&idx=1&sn=b9a8ccb8aed7a0593b317232d7706564&chksm=b18f4f5286f8c644851572449ce61667edb89bcc24f1d7dff2620709e6a8bca975b91b77198d#rd
如有侵权请联系:admin#unsafe.sh