[原创]app加固分析狗尾续貂之dex vmp还原-Android安全-看雪安全社区

# 前言

oacia大佬的[APP加固dex解密流程分析](https://bbs.kanxue.com/thread-280609.htm)，已经基本把它翻个底朝天了，但众所周知要彻底攻破该加固，仍有dex vmp这最后一道堡垒横在面前。在此之前拜读过爱吃菠菜大佬的[某DEX_VMP安全分析与还原](https://bbs.kanxue.com/thread-270799.htm)以及Thehepta大佬的[vmp入门(一)：android dex vmp还原和安全性论述](https://bbs.kanxue.com/thread-281427.htm)，了解到dex vmp的原理是对dalvik指令进行了加密和置换，这里参照大佬们的方法对oacia大佬的样本复现了一遍，记录一下历程。

# 获取trace
既然是vmp，按照vmp常规的分析流程，必然要先拿到trace，以这次的经历来看，拿到trace就已经成功了一半了。参考了很多大佬的文章，大致有以下几种方法：ida trace、unidbg/AndroidNativeEmu、frida stalker、frida qbdi、Dobby Instrument、unicorn 虚拟CPU。

## ida trace
开始打算用maiyao的<a href="elink@d73K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0j5h3W2&6j5h3)9I4z5e0R3^5i4K6u0r3d9f1c8m8f1$3y4J5K9i4m8@1M7#2)9J5c8X3u0D9L8$3u0Q4x3V1k6E0j5i4y4@1k6i4u0Q4x3V1k6A6k6r3q4Q4y4h3k6@1M7X3q4U0k6g2)9J5k6i4m8&6">ida trace脚本</a>，但遇到以下问题：
1.ida附加上后每次执行到linker加载壳so加载到一半就退出了，单步发现是跑到rtld_db_dlactivity里的BRK指令会直接退出，但加载其他so时并没有这个问题（why?)。这里手动把它跳过了。
2.trace了一下JNI_Onload，结果发现每当进入mutex_lock就会卡死在那无限循环……这个没能解决，只好弃用。
## unidbg/AndroidNativeEmu
补java环境有点累，尤其是补到后面发现可能会有很多代理类，没坚持补下去……
## frida stalker
从oacia那篇文章来的肯定少不了尝试一下stalker，结果发现和ida相似的问题——每当进入mutex_lock就会卡死在那无限循环。
## frida qbdi
尝试用yang的<a href="elink@821K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6D9j5i4y4@1K9h3&6Y4i4K6u0V1P5h3q4F1k6#2)9J5c8X3k6J5K9h3c8S2i4K6u0V1M7h3u0V1K9g2)9J5k6s2c8J5j5h3y4W2M7R3`.`.">frida-qbdi-tracer</a>，但每当trace到一些跳转的时候就会崩溃，查阅资料发现qbdi好像确实存在这样的bug。
## Dobby Instrument（未尝试）
这个我是后面才看到的，感觉将来可以尝试一下，详见KerryS的[指令级工具Dobby源码阅读](https://bbs.kanxue.com/thread-273487.htm)。
## unicorn 虚拟CPU（未尝试）
爱吃菠菜那篇文章的中的方法，没完全搞明白，感觉大意应该是把unicorn作为一个so文件注入到app中，用frida hook住目标函数，当发生调用时把环境补给unicorn来trace。
## 小结
经过不断尝试，最终还是使用frida stalker，通过hook mutex_lock函数，在OnEnter中跳过stalker，再在OnLeave中恢复stalker的方法，在经过无数次崩溃之后，终于拿到了dex vmp的trace……

# 指令流分析
拿到trace指令流后，就可以着手分析了。可以看到，onCreate函数被注册到的地方，使用DebugSymbol.fromAddress没有打印出任何符号，应该是一块动态申请的内存区域：
 ![图片描述](upload/attach/202501/941380_QQQHT9PW9JKK59R.webp)
函数并不大，里面也基本全是位置无关代码，应该只是一个跳板，很快，便来到了主elf中的函数sub_137978。
## 跳转表修复（未完成）
sub_137978这个函数就大了，该函数内的指令流数量占了全部的99%，然而在ida F5中却不那么好分析，因为它全程用跳转表实现：
 ![ida F5](upload/attach/202501/941380_2C2HKKWEU7RMDSB.webp)
 ![汇编](upload/attach/202501/941380_779YJPD2X296D68.webp)
 ![图片描述](upload/attach/202501/941380_V5PQSRZ3XJ24VTW.webp)
 ![跳转表](upload/attach/202501/941380_PAVVGDNQD63PVXH.webp)
ida倒是具备跳转表修复的功能，在Edit->other->specify switch idiom中，可以参考<mark class="encrypted">3c2K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6o6K9r3W2F1j5f1&6#2K9$3g2Q4x3V1k6o6K9r3W2F1j5f1&6#2K9$3g2Q4x3X3g2Y4K9i4c8Z5N6h3u0Q4x3X3g2A6L8#2)9J5c8X3u0D9L8$3u0Q4x3V1k6E0j5h3W2F1i4K6u0r3x3U0l9J5x3g2)9J5c8U0l9^5i4K6u0r3f1%4m8W2j5$3W2X3P5g2)9J5k6s2y4%4K9i4c8U0K9q4)9J5k6s2y4@1j5i4c8W2L8h3g2F1N6q4)9J5k6r3W2F1i4K6u0V1d9f1c8m8i4K6u0V1f1s2u0G2i4K6u0r3K9h3&6V1k6i4S2Q4x3X3g2Z5N6r3#2D9</mark> （原博文已挂，这里的备份需要下载下来看）
我按照它的讲解修复了一下，不过效果也不是太好，估计是没搞清start of switch idiom和input register。
也尝试过用数据流分析来回溯跳转表，然后转化为bcond addr1、b addr2来修复，不过因为可能会涉及指令重排的问题，而且有的块的前驱没有分析出来会导致数据流中断，懒得再用迭代了……这里直接从trace中找到这些BR X8的后继，然后在ida中用idc.add_cref(ea, next_ea, idc.fl_JF)添加上引用，姑且在汇编分析了。
## 函数调用分析
不过，这么多指令应该从哪入手呢？先跟一下它的函数调用吧。在trace中搜索BL，先是几个比较短的函数，然后进入到一个有意思的函数sub_13B1D8：
 ![图片描述](upload/attach/202501/941380_76264BTDA6BANEY.webp)
看到这么大这么整齐的一个结构体，而之前又没有看到什么对a2的初始化，难道？我尝试将a2改为JNIEnv*，竟然整齐地对上了！再退回到result初始化的地方，看到result结构体的大小为0x728，和JNIEnv的大小0x748如此接近，那么很有可能是一个打乱顺序的JNIEnv。既然这么巧，先把这个结构体创建出来：
![图片描述](upload/attach/202501/941380_QY8MK6UP52KRDMJ.webp)
继续向下分析函数调用，在经过一系列短函数后，来到了函数sub_144EF0。
这个函数指令流数量占了90%以上，而其中再没有占比特别高的函数了，大概它就是虚拟机入口了，给它命名为vm_entry_sub_144EF0，接下来主要研究它。
## 虚拟机分析
和sub_137978一样，vm_entry_sub_144EF0同样是全程跳转表，怎么办呢？
根据上文提到的爱吃菠菜以及Thehepta的文章,可知dex vmp中会大量调用JNI函数，所以从它们入手是一个不错的选择。
### 从JNI调用入手
先看这条：
FindClass(androidx/appcompat/app/AppCompatActivity)libjiagu_64.so!0x19e654
我们来到0x19e654这个地址，将参数设为重排的JNIEnv，果然，这里确实是调用FindClass，这也印证了前面对JNI的猜测。查看其调用链为vm_entry_sub_144EF0->sub_160D7C->sub_19E508。
先看一下sub_160D7C：
 ![图片描述](upload/attach/202501/941380_2BSQ4X2P5XP5HQ9.webp)
有很多不同类型的CallXXMethod，这些显然是在解释函数调用指令，将该函数命名为call_method_sub_160D7C。
从call_method_sub_160D7C调用处向上回溯，我发现它经历了一系列的cmp w0, xx的比较和跳转，很像是在根据操作码来选择handler的流程。搜索一下
w0的来源，发现是来自sub_15FC34的返回值，其输入一部分是来自同一基本块内的sub_16CE0C，这两个函数都总共被执行了17次，均匀地分布在整个vm_entry_sub_144EF0的指令流中。
继续向上回溯，来到loc_153FC8，查看其引用，发现有多达254处，而联想到dalvik opcode为1字节，256种，因此这里多半就是虚拟机的dispatcher了。
再看一下oacia的未加固样本的OnCreate函数指令：
 ![图片描述](upload/attach/202501/941380_QHAK2KSM4F3A7CA.webp)
数一下，也是刚好17条。因此，sub_15FC34和sub_16CE0C应该就是解析字节码的函数了。
### 解密字节码
sub_16CE0C中多次用到异或运算，像是在解密字节码：
 ![图片描述](upload/attach/202501/941380_CSP39CUTP3ZNSX8.webp)
而sub_15FC34，如前所述其返回值是handler所对应的w0，不过没仔细研究其生成过程，像是从文件读取的：
 ![图片描述](upload/attach/202501/941380_YUZSSHYR4CNGKX7.webp)
回到call_method_sub_160D7C继续分析，又发现了两个和sub_16CE0C极其相似的函数，不过分别是从offset=2和4处开始解密，查看其返回值，分别为0x154b(5451)和0x21，根据dalvik的函数调用指令invoke的格式，其offset=2处的对应的是函数index，我们拿010editor来看一下method 5451：
 ![图片描述](upload/attach/202501/941380_Z6WSDQPW7D2EEMJ.webp)
恰好就是其实际调用的函数！
我们把这几个解密字节码的函数的所有返回值按序排列一下，和原字节码进行对比：
 ![](upload/attach/202501/941380_UWGYXBUFH46EGHD.webp)
可以看到，除了作为操作码的首字节及部分操作数外，其余均相同。而这些操作数不同的地方，其实也仅仅是因为dex内容发生改变而导致的index的不同，实际指向仍然是相同的。
### 还原操作码
那么接下来就是还原操作码苦力活了，不过也有迹可循，至少根据jni调用可以把method、field相关的指令还原，在资源中搜索操作数可以看看是不是对资源的引用，也可以像破解凯撒密码那样利用不同指令的统计特征及上下文相关性来推断。也有一些取巧的方法，比如自己构造一个容纳了尽量多类型指令的onCreate函数进行加固作为对照，即使它指令对照表发生改变，也可以根据其对应handler相似性来推断。
# 总结
综上所述，onCreate函数的关键流程包括：重排JNI、解密操作码、选择handler、解密操作数，其中操作码由于进行了置换，还需要通过各种方法进一步还原成dalvik操作码。
# 后记
整个数字加固研究下来，涉及到的大致包括ffi调用、frida反调试、elf动态解密加载、自实现linker解析与重定位、dex动态解密加载、dex vmp。但说实话，我花的时间最多的，虽然是dex vmp部分，但确是在如何获取完整的trace上，之后的分析反而没有花太多时间，可能因为像解密字节码关键函数没有用跳转表混淆掉吧，仍然可以用ida f5分析，而且操作数没有做其他的变换，另外就是有大佬们经典文章的加持。
不过仍有一些问题悬而未决，比如字节码的来源，又是如何被加载到内存中的？interpreter_wrap_int64_t、interpreter_wrap_float等这几个函数是什么原理？ida调试为什么单单壳so在运行到rtld_db_dlactivity里BRK时会退出而其他so不会？以后有机会再回过头来研究吧（逃）

# 参考文献
[APP加固dex解密流程分析](https://bbs.kanxue.com/thread-280609.htm)，oacia
<a href="elink@d56K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0j5h3W2&6j5h3)9I4z5e0R3^5i4K6u0r3d9f1c8m8f1$3y4J5K9i4m8@1M7#2)9J5c8X3u0D9L8$3u0Q4x3V1k6E0j5i4y4@1k6i4u0Q4x3V1k6A6k6r3q4Q4y4h3k6@1M7X3q4U0k6g2)9J5k6i4m8&6">ida trace脚本</a>，my1988
<a href="elink@67eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6D9j5i4y4@1K9h3&6Y4i4K6u0V1P5h3q4F1k6#2)9J5c8X3k6J5K9h3c8S2i4K6u0V1M7h3u0V1K9g2)9J5k6s2c8J5j5h3y4W2M7R3`.`.">frida-qbdi-tracer</a>，Imyang
[某DEX_VMP安全分析与还原](https://bbs.kanxue.com/thread-270799.htm)，爱吃菠菜
[vmp入门(一)：android dex vmp还原和安全性论述](https://bbs.kanxue.com/thread-281427.htm)，Thehepta
[Dalvik解释器源码到VMP分析](https://bbs.kanxue.com/thread-226214.htm)，glider
[从0开发你自己的Trace后端分析工具: (1) 概述](https://bbs.kanxue.com/thread-281555.htm)，FANGG3
[指令级工具Dobby源码阅读](https://bbs.kanxue.com/thread-273487.htm)，KerryS

登录后可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

#逆向分析 #脱壳反混淆

最新回复 (15)
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 707 粉丝 7 关注私信	mb_ldbucrik 2 楼感谢分享 2025-1-12 17:47 0
软件君子雪币： 537 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 68 粉丝 3 关注私信	软件君子 3 楼好帖不知道能扛多久看来还原vmp还是容纳了尽量多类型指令的onCreate函数进行加固作为对照这个方案比较靠谱另外大佬对过签有研究吗 2025-1-12 19:35 0
night star 雪币： 469 活跃值： (1316) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 18 粉丝 15 关注私信	night star 4 楼软件君子好帖不知道能扛多久看来还原vmp还是容纳了尽量多类型指令的onCreate函数进行加固作为对照这个方案比较靠谱另外大佬对过签有研究吗用seccomp重定向？我记得珍惜any大佬有个帖子讲这个 2025-1-12 20:24 0
软件君子雪币： 537 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 68 粉丝 3 关注私信	软件君子 5 楼 night star 用seccomp重定向？我记得珍惜any大佬有个帖子讲这个好的佬那篇帖子我看过我去试试能不能过掉 2025-1-12 20:30 0
龙飞雪雪币： 720 活跃值： (7137) 能力值： ( LV3，RANK：30 ) 在线值：发帖 1 回帖 267 粉丝 3 关注私信	龙飞雪 6 楼学习了。 2025-1-13 11:18 0
万里星河雪币： 273 活跃值： (2409) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 603 粉丝 8 关注私信	万里星河 7 楼大佬谦虚了这哪里是狗尾续貂明明就是画龙点睛锦上添花。基于类似破解凯撒密码的统计学特征进行opcode还原的思路很有启发性。对于字节码解密函数的定位其实还可以用frida监控内存读写的方式得到。另外hook所有的jni函数监控其字段读写函数调用解析参数返回值在指定vmp函数进入时记录这些信息指定vmp函数离开时输出这些信息可以快捷精准地分析指定的vmp函数 2025-1-14 00:05 1
墨穹呢雪币： 4770 活跃值： (8232) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 231 粉丝 18 关注私信	墨穹呢 8 楼感谢分享 2025-1-14 11:37 0
万里星河雪币： 273 活跃值： (2409) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 603 粉丝 8 关注私信	万里星河 9 楼软件君子好的佬那篇帖子我看过我去试试能不能过掉活捉一个B站up 2025-1-14 17:39 0
night star 雪币： 469 活跃值： (1316) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 18 粉丝 15 关注私信	night star 10 楼万里星河大佬谦虚了这哪里是狗尾续貂明明就是画龙点睛锦上添花。基于类似破解凯撒密码的统计学特征进行opcode还原的思路很有启发性。对于字节码解密函数的定位其实还可以用frida监控内存读写的方式得到。 ... 是你呀，指出sofixer符号解析问题的大佬话说“frida监控内存读写”，应该是先定位到字节码区域，对它进行监控吧？我是先找的解密函数 2025-1-14 20:02 0
万里星河雪币： 273 活跃值： (2409) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 603 粉丝 8 关注私信	万里星河 11 楼 night star 是你呀，指出sofixer符号解析问题的大佬[em_065] 话说“frida监控内存读写”，应该是先定位到字节码区域，对它进行监控吧？我是先找的解密函数[em_055] 是的需要先定位到字节码区域 2025-1-15 10:30 0
海带雪币： 427 活跃值： (2150) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 83 粉丝 11 关注私信	海带 12 楼赞 2025-3-1 13:36 0
海带雪币： 427 活跃值： (2150) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 83 粉丝 11 关注私信	海带 13 楼 111 最后于 2025-3-13 11:04 被海带编辑，原因： 2025-3-11 15:24 0
好好好好尼玛雪币： 0 活跃值： (645) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 8 粉丝 1 关注私信	好好好好尼玛 14 楼 interpreter_wrap_int64_t、interpreter_wrap_float 是混淆过的，开始是一个解密，然后进入一个简单的 VMP 实现，根据解密的字节码通过ffi调用目标函数。 2025-7-30 09:57 0
好好好好尼玛雪币： 0 活跃值： (645) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 8 粉丝 1 关注私信	好好好好尼玛 15 楼把整个指令流trace的结果发出来一份观摩观摩？？ 2025-7-30 09:59 0
ikunnn 雪币： 50 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 62 粉丝 0 关注私信	ikunnn 16 楼好好好好尼玛把整个指令流trace的结果发出来一份观摩观摩？？有个好问题怎么得到指令映射表，看jni调用真的可以吗 2025-11-16 23:18 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复