我又来搞阿里的混淆了。网上已经有不少分析libsgmain的文章，不过大都是侧重流程原理或者具体算法的分析，很少有对他进行反混淆的。
我对反混淆这块更感兴趣，去年搞过阿里好几年前的一个crackme，这次尝试挑战一下他们较新的代码防护。
文章接下来的内容，我会先是介绍反混淆和还原VM所使用的工具，然后使用他们对Native代码反混淆，接着进行VM的还原及展示还原后的伪码。

使用工具介绍

Trace工具

• 支持不同追踪粒度：
  • 代码覆盖
  • 指令块
  • 指令
• 支持记录内存访问内容
• 支持保存CPU上下文
• 支持追踪系统调用

以上是一个粒度最小的trace所展现的信息，它包含了：

• 相对地址
• 绝对地址
• 汇编指令
• 读写的寄存器及内容
• 访问内存地址及内容
• 地址所在模块
• 地址附近符号

二进制分析框架

• 完全使用Python实现，方便配合现有二进制分析平台进行分析。
• 内部使用SSA形式, 树型结构的IR。寄存器，栈变量均为SSA形式；内存也是SSA，即MemorySSA。
• 支持将Ghidra p-code转换成我们自己的IR。这个特性可以让分析框架支持大量指令集和指令。
• 内部有维护NON-SSA和SSA IR的对应关系。实现这个特性是为了方便反混淆，因为在修改CFG的时候维护IR的SSA形式非常困难，不如直接修改原始的NON-SSA的CFG，反混淆后再重建SSA IR简单。
• 常见的编译器分析：支配关系，控制依赖，活跃分析，别名分析，区域分析，循环分析，值集分析（VSA）。
• 常见的编译器优化：死代码消除，常量传播，常量折叠，稀疏常数条件传播(SCCP)。
• 反编译器（结构化分析）。

反混淆

这里选择去年某个版本的手淘，还原10401命令算法过程遇到的混淆，libsgmain版本为: 6.5.22，md5: 875d423e9df06024bfddeed4322a4de5，模块基址：0x7b3bd56000。

二进制代码反混淆

该版本的doCommandNative位于00013124，代码如下：

可以看到，X11是动态计算出来的，当进一步分析之后发现，这个地址还依赖一个静态变量，只使用静态分析难以分析出这个跳转目标。
这类间接跳转混淆可以很好阻止逆向工具的静态分析。有时静态分析难以解决的问题，使用动态分析则不是个问题。

通过trace我们可以清楚看到，br的跳转目标是0x000131ac。 对于这类混淆，我们只需要从trace中直接重建CFG即可完成反混淆。从trace中重建CFG算法跟直接从普通的二进制构建CFG差别不大。
我的实现算法主要参考了Binary Ninja的这篇博客Architecture Agnostic Function Detection In Binaries。
简单来说，先从Trace中创建ICFG，删除其中的Call，Ret边，图中的每一个弱连通分量就对应一个函数CFG。
有了函数CFG之后，就可以进行反编译了，下面我反混淆后的代码：

我在这里使用的是switch pc的方法，将"br x11"目标作为switch的一个case来表示这个间接跳转。

从上面伪码我们很容易看出阿里间接跳转的混淆模式：

识别并删除这类模式的跳转可以获得更干净的伪码：

我们也可以使用这个分析结果，对这个间接跳转进行patch来修复CFG，这样就可以使用熟悉静态工具进行下一步分析了。
这个函数其实是个非常好的反编译器测试用例，可以测试反编译器的：

• 除法，模运算的化简能力
• 函数调用参数，返回值识别准确性
• 反编译器优化能力
• 循环结构能力

不对反编译器进行干预的情况下，我测试了5个反编译器，他们分别是：IDA，Ghidra, Binary Ninja，Jeb，RetDec，只有Ghidra能正确反编译这个函数。对反编译有兴趣的朋友可以深入研究这个函数。

到这里，我们已经完成间接跳转的反混淆。他之后还有流程平坦混淆等着我们。

流程平坦反混淆

传统的流程平坦反混淆可以参考我之前的帖子。我这次使用一种仅依赖编译器优化，不必区分混淆框架代码，真实代码块，真实代码块间的关系的反混淆方案：直接反编译trace。
其本质是对特定的输入展开混淆函数中的所有循环，对展开后的代码应用编译器优化去除混淆。考察下面trace代码片段：

在反编译器中反编译这个函数的某次trace，反编译器会自动识别以上常数条件，执行优化后的代码效果：

以上代码即是doCommandNative反混淆之后的最终代码，可以看到流程平坦混淆中对的状态变量的更新和测试均已经被优化掉，代码逻辑已经也比较清晰了。
另外一处包含循环的是LiteVM的加密解释器，这部分代码不便贴出，这里使用看雪培训ollvm8中的sub_fcb4函数的反混淆效果代替。
这个函数代码较长，放在文章最后。

VM还原

阿里的这个VM我猜测是使用LLVM后端实现的，并没有经过二进制->VM的转换，而是由源码->LLVM IR->LLVM LiteVM后端编译直接编译出LiteVM指令的二进制文件。
PC上VM防护大都是将编译好的二进制的指令集转换成自定义的指令集，它对应的还原方式也都是尝试将VM指令还原到原始指令。
对于阿里这种没有原始指令集的一类VM，貌似还没有相关的还原文章。
我采用的是最笨的方法，人肉分析LiteVM所有指令的编码和语义，将指令转成我们反编译器的IR，使用反编译器生成高级伪码。

LiteVM架构

LiteVM的整体架构如下：

LiteVM的寄存器：

它的一些特性：

• 64位寄存器结构虚拟机
• 固定4字节指令长度。指令集类似MIPS：条件跳转不使用条件码；只有少量opcode，更具体的功能通过funct码区分。
• 很多指令有32，64位两个版本。
• 很多指令有寄存器，立即数两个版本。
• 完备的FFI实现，可调用虚拟化模块外的虚拟化代码或者是本地代码。
• 具备条件执行能力。

LiteVM解释器实现

LiteVM的解释器入口位于0xdfe0c，代码结构如下：

LiteVM为了提升解释性能，避免每次执行指令都需要重新解码一次，会先将模块所有指令提前解码成以下结构：

同时使用一种叫Threaded Interpretation的解释器，解释器位于0xf1a24。
关于该解释器原理可以参考这篇文章Computed goto for efficient dispatch tables。
为了修复这个解释器的CFG，我使用类似对间接跳转的处理方法，把其他vm handlers的地址硬加到第一个间接跳转后面：

反编译后的代码结构如下：

LiteVM的handler表位于0x140ad0，handler都没有混淆，很是比较好分析的，有兴趣的朋友请自行分析。
我这里只分析两条函数调用相关的两个handler，以了解反编译器所需的调用约定信息。

使用trace快速定位到调用外部函数的实现

通过上面两个trace片段，我们基本可以确定VM使用以下指令跳转的外部函数：

0x000df720所在的函数是0xdf4e4，往上回溯定位到vm call的handler，按顺序分析调用链：

了解调用约定之后，我们就可以识别函数中使用的参数、栈上变量，函数调用参数。

LiteVM指令加密及混淆解释器实现

这是我分析10401指令遇到的最后一道防护，为了避免不必要的麻烦，这里不再详细分析他的实现。
他是vm handler表中最后一个handler，使用了前面遇到过的机器码混淆。他的CFG看起来是这样：

在IDA中反编译后大概有8000+行代码。

解释器实现框架大体是这样的：

如果要分析这个解释器，建议先完整分析未加密指令的编码和指令的语义，会事半功倍。

效果展示

下面几个是还原的VM函数，sub_538是执行10401命令第一个运行的函数

看雪培训ollvm9 sub_fcb4反混淆效果（更复杂了？）。