deflat 脚本学习【去除OLLVM混淆】

deflat脚本链接：
GitHub - cq674350529/deflat: use angr to deobfuscation

deflat 脚本测试

这里以
代码混淆与反混淆学习-第一弹
中的OLLVM 混淆样本为例进行去除。【LLVM-4.0】

控制流平坦前 控制流平坦后
image image

python deflat.py --file main-bcf --addr 0x401180

image

image

deflat.py 成功去除后效果：

image image

去混淆后，效果还算可以，能分析程序流程了。

deflat 脚本分析【angr】

利用符号执行去除控制流平坦化 - 博客 - 腾讯安全应急响应中心 (tencent.com)

angr documentation

利用angr符号执行去除控制流平坦化 - 0x401RevTrain-Tools (bluesadi.github.io)

image

  • 序言：函数的第一个执行的基本块
  • 主(子)分发器：控制程序跳转到下一个待执行的基本块
  • retn块：函数出口
  • 真实块：混淆前的基本块，程序真正执行工作的版块
  • 预处理器：跳转到主分发器

如第一弹中分析：OLLVM 的控制流平坦化是将程序的一般逻辑划分为很多个真实执行的块，然后通过分发器进行链接。其实就是一个Switch结构，每次执行完真实块后，进行预处理，再跳转到主分发器，继续分发，最终达到平坦化的效果。

显然，
去控制流平坦化
就是要找到真实块间的跳转逻辑，打破Switch结构束缚。

具体来说，有如下步骤：

  1. 静态分析CFG得到序言/入口块、主分发器、子分发器/无用块、真实块、预分发器和返回块。
  2. 利用符号执行恢复真实块的前后关系，重建控制流
  3. 根据第二步重建的控制流Patch程序，输出恢复后的可执行文件

静态分析

首先明确：
【以下结论针对OLLVM项目，其他大佬加料的OLLVM混淆还需要单独分析】

  1. 函数的开始地址为序言的地址
  2. 序言的后继为主分发器
  3. 后继为主分发器的块为预处理器
  4. 后继为预处理器的块为真实块
  5. 无后继的块为retn块
  6. 剩下的为无用块

angr 获取类似Ida的 CFG

image

获取真实块、主分发器、预处理器、序言、retn块和无用块

image

获取真实块的细节

image

angr 恢复真实块执行逻辑，重建控制流

利用angr 强大的符号执行功能，找到各真实块的连接逻辑。

image

这里对于两个分支的模拟执行，只需关注
cmov
指令，就可以分别对应得到eax、ecx，然后获得后续真实块。【局限性很大】

image

符号执行
symbolic_execution（）
函数，返回后继真实块。

image

Patch程序恢复执行逻辑

image

如此便完成了 deflat脚本的简单处理分析。

小结

分析下来，其实就是定位到所有真实块，然后
利用angr符号执行将真实块间的执行逻辑进行串联
。最后进行patch程序，重建控制流。

但显然存在一些问题，我们默认了如下规则:

  1. 函数的开始地址为序言的地址
  2. 序言的后继为主分发器
  3. 后继为主分发器的块为预处理器
  4. 后继为预处理器的块为真实块
  5. 无后继的块为retn块
  6. 剩下的为无用块

但是在实际去除控制流平坦化过程中，上面的默认思路已经被加混淆的开发者做了处理。

例如：

  • 后继为预处理器的块不一定是真实块；
  • 预处理器不一定存在；
  • 存在分支的真实块跳转的判断逻辑，不一定是
    cmov
    指令;
  • deflat脚本默认模拟执行最多两个分支，但真实情况可能不只两个分支；
  • 可能存在一个
    向前更新的数组，依据程序运行进行更新
    ，决定当前真实块的跳转【这导致
    angr对于该块的模拟执行
    得不到正确的跳转】
  • 程序在加混淆前，已经被添加了花指令或其他处理，
    程序CFG图
    已经被打破；
  • 某个块存在死循环，会使angr符号执行卡死……

这也导致了，这个
deflat脚本的普适性较低
，除了能够处理OLLVM官方项目做的混淆，对加了其他PASS或者处理的混淆，基本用不了。

所以对于去除不了的OLLVM混淆，我们需要
根据程序的实际混淆效果，对deflat脚本进行修改
，再进行去混淆。

【这也要求对deflat 脚本比较熟悉，可以更快上手】

失败的花指令控制流平坦化尝试

使用
代码混淆与反混淆学习-第一弹
中加了花指令的程序，进行OLLVM控制流平坦化混淆，看看效果。

源代码如下：

image

# clang 执行内联汇编加 -fasm-blocks 或者 -fms-extensions 或者 -masm=intel

clang -mllvm -fla -mllvm -split -mllvm -split_num=3 main-call-加花.cpp -lm -fasm-blocks -o main-call-加花

# 需要对源代码作一些修改

存在较大的问题，我的OLLVM 环境是在Ubuntu上搭建的，对于上述内联汇编加的花指令无法编译通过！

【或许可以在
Windows 上移植OLLVM，进行编译（好像挺难的）
】

image

可以看到，花指令用到的标签、$ 出现报错。

【最终也没解决编译问题，或许本就不可以，ollvm 不具备这样的处理能力，也可能是我代码的问题，
如果博客前的你有任何想法，欢迎与我交流
】

TSCTF-J 2022-upx_revenge实战分析

TSCTF-J 2022 WP

对
upx_revenge
题目进行分析。

image

首先直接使用deflat 脚本。

python deflat.py --file upx_revenge_test --addr 0x4016D0

image

发现没有找到retn 块。

处理多个retn块

回到ida 查看cfg 图发现原因：存在其他的退出块。

image

这里需要改进deflat 脚本，使其存在很多retn块。

# 其他位置的retn_node，对应改为list处理
if supergraph.out_degree(node) == 0:
            retn_node.append(node)

image

成功运行，但是去除效果不行。

去除后CFG图
image

多个comv的处理

很明显看出，程序的真实块间的逻辑串联失败，也就是重建控制流失败。

image

产生原因

image
image

显然，这里存在2个分支，因为有两个
cmov
【相同判断】，并且call 函数，对分支跳转是有作用的，这里var_CC是顺序执行，动态更新的。

【deflat 脚本只处理了执行有一个
cmov
指令的情况，且hook了call函数】

【由于var_CC是顺序执行，动态更新也可以看出，deflat 脚本的模拟执行思路已经无法对真实块的后继进行确定了】

但这里做个测试，不hook call 看是什么效果。

image

可以知道，取消hook call 对真实块后继的查找毫无影响，这是因为deflat中的模拟执行，只是基于
comv
处的模拟。对前文并无任何关联。

显然，该deflat脚本的无法处理了。【】

总结

angr

就
upx_revenge
这道题而言，

deflat 脚本中angr 对局部的模拟执行显然无法获取真实块间的执行顺序，重建控制流显然也无从谈起。当然静态查找各个控制流平坦化的功能块效果还是可以的。

那么如何通过angr,有序的、联系上文地进行模拟执行，获取真实块的执行逻辑，显然是关键点！

【??? 后续学习了，有思路再更新】

unicorn

[
原创]ARM64 OLLVM反混淆-Android安全-看雪论坛-安全社区|安全招聘|bbs.pediy.com (kanxue.com)

Unicorn反混淆：恢复被OLLVM保护的程序(一) - 简书 (jianshu.com)

使用unicorn 模拟执行框架获取真实块间的执行顺序，重建控制流。

【还没学过 unicorn 使用，，，】

ida

使用IDA microcode去除ollvm混淆(上) - 先知社区 (aliyun.com)

GitHub - PShocker/de-ollvm: IDA Python Script for anti ollvm

利用ida 现成的CFG 图，以及idc 脚本，动态运行程序，获取真实块的执行顺序，从而恢复控制流。

标签: none

添加新评论