在现代软件保护技术中，控制流混淆（Control Flow Obfuscation）是一种常见且有效的手段，用于增加逆向工程的难度。OLLVM 是基于 LLVM 编译器框架的一个扩展，它通过插入复杂的控制流混淆逻辑，使得生成的二进制代码难以被分析和理解。间接调用和控制流平坦化是 OLLVM 中最具代表性的混淆技术之一，它通过将程序的控制流打散并引入调度器逻辑，极大地增加了逆向工程的复杂性。

本篇笔记将从以下几个方面展开：

通过这些内容，希望能够帮助读者更好地理解 OLLVM 的工作原理，并掌握应对复杂混淆技术的分析方法，毕竟有谁能拒绝参加一场顶级玩家之间的攻防游戏呢？

下载网络上大佬开源的 ollvm 项目，goron 是我实际测试比较好用的版本，提供了额外的几种强度不错的混淆 Pass，选择 9.0 版本则是考虑到这个版本网络上可供学习的资料比较多，非常适合学习使用。

没有 clion的可以用命令行编译 clang，生成 release 编译配置文件

编译 release

将 ndk 中的 clang 加入环境变量

使用编译器打开 ollvm/llvm-project-9.0.1/llvm/CMakeLists.txt

编译器 file — settings — Build,Execution,Deployment — Cmake — Cmake options，配置 Cmake， 添加 Release 选项并设置 CMake options 如下

编译器主界面将工程切换为 clang 并将模式切换为 Release 模式，最后点击运行开始编译

使用 VSCode 打开 ollvm/llvm-project-9.0.1

新建文件夹 .vscode

创建文件 .vscode/launch.json

创建文件 .vscode/tasks.json

运行和调试 --> 启动

将 clang 添加到临时环境变量中

测试编译

交叉编译 arm64 需要先安装 gcc-aarch64 和 g++-aarch64

交叉编译 arm64

Ollvm 编译 X86 版本的可执行文件

Ollvm 编Arm64 版本的可执行文件

下载 android-ndk-r21e

将之前编译的 ollvm 中的 lib 和 bin 文件夹拷贝到 ndk 文件夹中

在 android studio 工程中 local.properties 中自定义 ndk 路径

在 CMakeLists.txt 中添加编译时使用的 ollvm 命令

c

在 LLVM 编译过程中，首先需要将 .c 文件通过前端编译器（如 Clang）转换为 LLVM IR（中间表示）。

ll

LLVM Assembly 文件是一种类似于汇编语言的中间表示。它是一种人类可读的文本格式，用于表示 LLVM IR。这种格式在跨平台上具有一定的可移植性。

bc

LLVM Bitcode 文件是一种中间表示的二进制格式，具有跨平台和跨编译器的特性。.bc 文件包含了经过前端编译器生成的 LLVM IR，但已经被编译成了一种更加紧凑的二进制形式。

s

汇编语言文件 .s 文件是汇编语言程序的源代码文件，包含了目标机器的汇编指令。在 LLVM 编译过程的最后阶段，LLVM IR 会被转换为特定目标机器的汇编代码，存储在 .s 文件中。这种格式通常不跨平台，因为汇编指令是特定于目标体系结构的。

生成 ll 文件

ll 文件也是可以执行的（需要在clion中先将 lli 编译出来）

生成 bc 文件（需要在clion中先将 llvm-as 编译出来）

生成 s 文件 （需要在clion中先将 llc 编译出来）

s 文件生成可执行文件

bc 文件生成可执行文件

ll 文件生成可执行文件

这部分除了理解 IR 汇编的基本语法，还必须理解 IR 语言中代码块的概念，这样我们才能理解 OLLVM 中最难的控制流平坦化的技术原理

C 代码

IR 汇编

C 代码

IR 汇编

C 代码

IR 汇编

C 代码

IR 汇编

这里只给出笔者认为比较重要的代码片段，其中注释多为 AI 分析（让 AI 辅助我们理解复杂的工程是个很棒的主意），也包含少量的笔者在分析时插入的日志 LOG，笔者总结的经验就是在分析的时候多插入LOG，在关键代码前后多打印对应的 IR 汇编，对比前后的区别，将下面的任意一个 Pass 分析透彻后，熟悉了 LLVM 操作 IR 汇编的函数，接下来的源码分析会越来越得心应手。

核心功能：加密函数调用地址，将 bl lable 指令转变为 blr reg ，抵抗反编译器的静态分析

核心功能：加密块间的调用地址，将 b lable 指令转变为 br reg，抵抗反编译器的静态分析

核心功能：控制流平坦化，OLLVM 中最核心的保护手段，将函数中的所有代码块编号放到一个巨大的 while switch case 中进行分发执行，抵抗反编译器的静态分析

Unicorn 是一个模拟 CPU 执行的框架，Unicorn 在 OLLVM 反混淆中的作用为计算 BR 寄存器的值以及控制流平坦化中作为 SWITCH ID 的寄存器的值，这里附上一段笔者学习 Unicorn 的代码，希望可以帮助大家理解 Unicorn 的用法。

flare-emu 的核心功能是通过 Unicorn 的仿真能力，为 IDA 二进制分析提供强大的动态仿真支持。它支持多种架构（包括 x86、x86_64、ARM 和 ARM64），并提供了五种主要的仿真接口，以及一系列相关的辅助和实用函数。

项目地址：b7aK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0j5h3&6V1K9h3q4F1N6q4)9J5c8X3k6D9j5i4u0W2i4K6u0V1k6h3#2#2i4K6u0W2k6$3W2@1

C 代码

编译三种混淆的二进制文件

IDA 打开 main_icall 中的 main 函数可以发现函数 add5 的跳转已经被加密

这里我们可以发现原本的 BL 指令被替换成了 BLR 指令，这里我们只需要利用 flare_emu模拟执行一下函数，利用 iterate 方法强行执行到目标地址就可以获取目标寄存器的值了，在最后将 BLR 指令改回 BL 指令就可以了

根据观察，函数跳转的地址通过模拟执行还是比较好计算出来的，这里我的思路如下：

使用 flare_emu 的 iterate 方法，从指定的地址范围开始模拟执行

targetCallBack 回调中记录每个间接调用指令的目标地址

修复间接调用

IDA 已经可以解析出函数 add 的地址

IDA 打开 main_indbr 中的 add5 函数可以发现函数主体无法被解析

这里我们可以发现原本的 BL 指令被替换成了 BLR 指令，不过这里就不能像 icall 那样粗暴的直接计算地址了，因为这里可能会涉及到多个分支的问题。

通过观察我发现一般只有两个分支，所以我这里的还原思路如下：

使用 flare_emu 的 emulateFrom 方法，从函数起始地址模拟执行到 BR 指令：

在模拟过程中，通过 my_instruction_hook 拦截指令，记录 CSEL 或 CSET 指令的地址，需要注意有两个分支。

根据 CSEL 或 CSET 指令的类型，修复为条件跳转指令

IDA 已经可以解析出函数 add5 的函数主体

IDA 打开 main_indbr 中的 add5 函数可以发现函数逻辑难以理解

控制流平坦化作为 ollvm 中最重要的 Pass，也是最难以还原的，我这里的还原思路如下：

IDA 已经可以解析出函数 add5 的函数逻辑

通过本次学习和实践，笔者对 OLLVM 的编译、使用以及其混淆技术有了更深入的理解。具体来说：

这次学习让笔者认识到，面对复杂的混淆技术，工具的选择和分析思路的清晰性至关重要。同时也证明了混淆技术虽然强大，但并非不可破解。希望本篇笔记能够为其他研究 OLLVM 的同学提供一些参考和帮助。

细品sec2023安卓赛题

llvm学习笔记——llvm基础

初窺ARM平坦化還原

自实现一个LLVM Pass以及OLLVM简单的魔改

从源码视角分析Arkari间接跳转混淆

OLLVM控制流平坦化混淆还原

ARM64 目前主流的反混淆技术的初窥

ollvm_assets.zip

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！