移植 OLLVM 到 LLVM18，修复控制流平坦化报错

原创 已于 2024-12-22 15:25:05 修改 · 646 阅读 · 9 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#llvm #c++ #c语言 #汇编 #android #linux #驱动开发

于 2024-12-21 23:17:36 首次发布

版权归作者所有，如有转发，请注明文章出处：https://cyrus-studio.github.io/blog/

前言

把 OLLVM 移植到 LLVM18 后，发现 -fla（控制流平坦化）并不能正常使用。

关于移植过程可以参考这篇文章 【移植 OLLVM 到 LLVM 18，C&C++代码混淆】

测试代码 fla.c

#include <stdlib.h>
int main(int argc, char** argv) {
  int a = atoi(argv[1]);
  if(a == 0)
    return 1;
  else
    return 10;
  return 0;
}

使用 clang 编译并启用 Control Flow Flattening（控制流平坦化）报错如下：

D:\Projects\llvm-project\build>clang -mllvm -fla fla.c -o fla.exe
[OLLVM] run.PipelineStartEPCallback
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: D:\\Projects\\llvm-project\\build\\bin\\clang.exe -cc1 -triple x86_64-pc-windows-msvc19.42.34433 -emit-obj -mrelax-all -mincremental-linker-compatible -dumpdir fla.exe- -disable-free -clear-ast-before-backend -main-file-name fla.c -mrelocation-model pic -pic-level 2 -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -fdebug-compilation-dir=D:\\Projects\\llvm-project\\build -fcoverage-compilation-dir=D:\\Projects\\llvm-project\\build -resource-dir D:\\Projects\\llvm-project\\build\\lib\\clang\\18 -internal-isystem D:\\Projects\\llvm-project\\build\\lib\\clang\\18\\include -internal-isystem D:\\App\\VisualStudio\\IDE\\VC\\Tools\\MSVC\\14.42.34433\\include -internal-isystem D:\\App\\VisualStudio\\IDE\\VC\\Tools\\MSVC\\14.42.34433\\ATLMFC\\include -internal-isystem D:\\App\\VisualStudio\\IDE\\VC\\Auxiliary\\VS\\include -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.22621.0\\ucrt" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\\\include\\10.0.22621.0\\\\um" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\\\include\\10.0.22621.0\\\\shared" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\\\include\\10.0.22621.0\\\\winrt" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\10\\\\include\\10.0.22621.0\\\\cppwinrt" -internal-isystem D:\\App\\VisualStudio\\IDE\\VC\\Tools\\MSVC\\14.42.34433\\include -intern
最低0.47元/天 解锁文章
CYRUS STUDIO
关注
03-ollvm相关-Pass移植-将ollvm移植到llvm源码中
blind cat
02-07 952
移植ollvm OLLVM项目代码在 https://github.com/obfuscator-llvm/obfuscator github中，ollvm是基于llvm4.0进行开发的，下图中 initial LLVM and Clang4.0是llvm原始的代码，其他的都是ollvm修改的代码，我们需要把这些修改的代码，复制到自己llvm项目中。 需要修改的内容如下 ollvm4.0 llvm-project-9.0.1 1 obfuscator/include/llvm/Trans
04-在llvm源码之外移植ollvm
blind cat
02-07 406
. |-- CMakeLists.txt `-- ollvm |-- CMakeLists.txt |-- include | `-- llvm | |-- CryptoUtils.h | `-- Transforms | `-- Obfuscation | |-- BogusControlFlow.h | |-- Flattening.h
【教程】ollvm移植到最新的llvm10.0.1或更高版本
键盘的起始页
10-10 1848
环境： ubuntu 14 一、准备 1、下载 最新版本的llvm并解压 https://releases.llvm.org/ 2、下载最新的 ollvm 并解压 https://github.com/obfuscator-llvm/obfuscator 3、上诉两步完成后，下载Obfuscation.sh 放到llvm-project-10.0.1 ---------------------------- ../ollvm4.0/obfuscator ./llvm-project-10.
OLLVM 移植 LLVM18 踩坑：一步步调试修复控制流平坦化
09-09 939
把 OLLVM 移植到 LLVM18 后，发现 -fla（控制流平坦化）不能正常使用。OLLVM 移植 LLVM 18 实战，轻松实现 C&C++ 代码混淆测试代码 fla.cif(a == 0)return 1;return 0;从报错信息来看，Flattening.cpp 的第 101 行代码在运行时发生了异常，具体错误类型是 访问权限冲突 (0xC0000005)，通常意味着代码尝试访问了无效或空的内存指针。
06-将ollvm移植到NDK
blind cat
02-07 926
1、将ollvm移植到llvm源码中 2、将llvm编译：Release版本 3、下载androidNDK，将编译的Relase版本的bin，lib，include目录复制到androidNDK的android-ndk/toolchains/llvm/prebuilt/linux-86_64/目录下，并合并 4、android studio项目，在Gradle Scripts目录下的local.properties文件中添加ndk.dir=步骤3中配置的ndk路径 5、在cpp目录下的CMakeLists.
02-ollvm相关Pass移植-使用大佬配置好的
blind cat
02-07 472
快捷：直接用leadroyal大佬打包好的 参考链接 ： https://www.leadroyal.cn/?p=659 git clone https://github.com/LeadroyaL/llvm-pass-tutorial.git clion 打开项目，修改一下顶层的CMakeLists.txt cmake_minimum_required(VERSION 3.4) project(llvm-pass-tutorial) # 设置一下 LLVM_DIR ，就是自己编译的llvm的生成目录 s
别让 so 裸奔！移植 OLLVM 到 NDK 并集成到 Android Studio
最新发布
09-09 1795
在 Android 应用安全中，Native 层 so 库往往是最容易被逆向分析的目标。无论是游戏的核心逻辑，还是 App 的关键算法，一旦 so 被反编译，核心代码就可能暴露无遗。传统的 Java 层混淆工具（如 ProGuard、R8）对 C/C++ 代码无能为力，因此NDK 层代码的保护成了安全加固中的难点。在编译阶段对 so 进行混淆处理，让逆向难度大幅提升。LLVM 生态中有一个安全扩展 ——，它在编译流程里插入了混淆 Pass，能对 C/C++ 代码做控制流平坦化、虚假控制流、指令替换。
LLVM源码基础的高级混淆器发布
1. 控制流平坦化（Control Flow Flattening）：通过将程序的控制流扁平化，使得原本清晰的分支逻辑变得混乱，难以追踪。 2. 寄存器分配变换（Register Allocation Transformation）：通过改变变量所用寄存器的分配...
Hikari_LLVM19
08-14
Hikari 是一个基于 LLVM 的代码混淆工具，它在 OLLVM（Obfuscator-LLVM）的基础上进行了改进和扩展，增加了更多的混淆功能，如变量混淆、虚假控制流、平坦化以及字符串加密等[^1]。Hikari 通常用于对程序进行代码...
Android应用开发中的盲化技术实现
而高级混淆策略则包括控制流平坦化、插入无效指令、反射调用替换直接调用、多态代码生成等技术，使反编译后的代码结构混乱、逻辑断裂。“blinded_Android_App”可能采用了类似LLVM的中间表示（IR）级混淆框架，在...
ollvm 编译
weixin_30341735的博客
05-23 639
ollvm 的编译相对 llvm 更简单， 1：下载ollvm代码，去 https://github.com/obfuscator-llvm/obfuscator/tree/llvm-4.0 下载，并且解压到本地。 2：安装VS 2017. 3：使用cmake-gui 3.13.0 x64 来重新打包工程，打包成vs 2017的工程。 4：使用vs2017 直...
Obfuscation.sh,ollvm移植到LLVM10.0.1以及更高版本的脚本
10-10
Obfuscation.sh,Obfuscation移植到LLVM10.0.1以及更高版本的脚本，使用方法：https://blog.youkuaiyun.com/tabactivity/article/details/108995746
初识ollvm控制流平坦化
weixin_42545308的博客
10-26 1150
app：B站， 版本：随便搞了个最新版 目标：分析sign算法 1. 算法定位 B站的java层定位并不难找，直接搜索大法即可定位到生成sign的native函数。 新的改变 我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写博客： 全新的界面设计 ，将会带来全新的写作体验； 在创作中心设置你喜爱的代码高亮样式，Markdown 将代码片显示选择的高亮样式 进行展示； 增加了 图片拖拽 功能，你可以将本地的图片直接拖拽到编
deflat 脚本学习【去除OLLVM混淆】#
qq_41146932的博客
08-03 1348
就这道题而言，deflat 脚本中angr 对局部的模拟执行显然无法获取真实块间的执行顺序，重建控制流显然也无从谈起。当然静态查找各个控制流平坦化的功能块效果还是可以的。那么如何通过angr,有序的、联系上文地进行模拟执行，获取真实块的执行逻辑，显然是关键点！
LLVM 插桩 LLVM IR LandingPadInst Invoke 指令
shimly123456的博客
04-16 405
总结一下，就是说，如果有 LandingPadInst 指令，那么它必须是一个基本块的第一个非phi指令。根据 CHATGPT4。
3、ollvm移植
ahjxly的专栏
12-13 275
clang -mllvm -bcf -mllvm -bcf_prob=40 hello_ollvm_bcf.c -o hello_ollvm_bcf 混淆百分比。clang -mllvm -fla -emit-llvm -S hello_ollvm_bcf.c -o hello_ollvm_fla.ll 生成ll文件。clang -mllvm -sub -mllvm -sub_loop=3 hello_ollvm.c -o hello_ollvm_sub2，替换3次。
编译 LLVM 源码，使用 Clion 调试 clang
11-24 2127
LLVM IR（Intermediate Representation）：一种类似汇编的中间表示语言，是 LLVM 的核心抽象。在 Android NDK 中，LLVM/Clang 是默认的编译器。LLVM 是一个开源的编译器基础架构，最初由 Chris Lattner 于 2000 年在伊利诺伊大学开发，后来成为一个广泛应用于编译器和程序分析的项目。LLVM IR 优化和代码生成：LLVM 对中间表示进行优化，并生成适合 Android 设备（如 ARM、ARM64、x86、x86_64）的机器码。
LLVM编译安装
wyg_031113的专栏
09-03 1140
LLVM编译安装。
LLVM系列（1）： 在微软Visual Studio下编译LLVM
追赶时代的博客
01-14 1663
llvm安装 vs环境
AST操作在还原控制流平坦化时有哪些常见陷阱？
06-15
<think>我们正在讨论使用AST（抽象语法树）操作来还原控制流平坦化（ControlFlowFlattening）时可能遇到的常见问题和陷阱。控制流平坦化是一种代码混淆技术，它通过打破代码块之间的自然顺序关系，将它们转换为一个大的switch结构或状态机结构，从而增加逆向工程的难度。还原这种混淆的关键在于识别基本块之间的真实控制流关系，并重构出原始的控制流图。常见陷阱及问题：1.**状态变量分析不准确**：控制流平坦化通常引入一个或多个状态变量（或称为分发器变量），这些变量控制着基本块的执行顺序。如果状态变量的分析不准确（例如未能正确识别状态变量的类型、取值范围或更新逻辑），可能导致还原后的控制流图错误。2.**无法识别所有基本块**：在构建AST时，可能由于混淆技术的干扰（如插入无效代码、代码分裂等），导致某些基本块没有被正确识别或提取。这会导致还原的控制流图不完整。3.**循环结构还原困难**：原始代码中的循环结构在平坦化后通常被转换为线性序列，并通过状态变量跳转模拟循环。还原时，需要将分散的循环块重新组合，并正确识别循环条件和循环体。如果循环结构嵌套或存在多个出口，还原将更加复杂。4.**条件分支处理错误**：原始的条件分支（如if-else）在平坦化后被分解为多个独立的基本块，并通过状态变量跳转。还原时需要正确识别条件判断的原始逻辑，并重建条件分支结构。如果条件表达式被混淆（如使用复杂的逻辑运算），则可能难以还原。5.**不可达代码的干扰**：混淆器可能插入一些永远不会执行到的代码（死代码），这些代码在AST中也会被解析。如果在还原过程中没有过滤掉这些代码，它们可能会干扰控制流的重建。6.**异常处理与函数调用**：如果平坦化的代码中包含异常处理（如try-catch）或函数调用，这些结构在还原时可能被破坏。因为函数调用可能改变状态变量的值，而异常处理会引入额外的控制流路径。7.**性能问题**：对大型代码进行AST遍历和重构可能非常耗时，尤其是在处理深度混淆的代码时。如果算法设计不当，可能导致内存溢出或运行时间过长。8.**多级混淆**：代码可能经过多层混淆（例如先进行控制流平坦化，再进行常量加密、字符串加密等），这会使还原过程更加困难。AST操作需要按照正确的顺序解除这些混淆，否则可能无法完全还原。9.**平台和语言特性的差异**：不同编程语言（如C++、Java、Python）的AST结构不同，而不同混淆工具的实现也有差异。还原工具需要针对特定的语言和混淆工具进行适配，否则可能无法正确处理某些语法结构。10.**还原后的代码可读性**：即使成功还原了控制流，生成的代码可能仍然难以阅读（例如变量名被混淆，代码结构不清晰）。因此，还原后通常还需要进行变量重命名、死代码消除等优化。为了有效应对这些陷阱，建议：-使用成熟的AST解析库（如Python的ast、Clang的AST等）来确保语法解析的准确性。-结合数据流分析来跟踪状态变量的变化，提高状态分析的准确性。-采用逐步还原的策略，先处理简单的部分，再逐步解决复杂结构。-使用图形化工具可视化控制流图，帮助理解还原过程。§§相关问题§§1.如何准确识别控制流平坦化中的状态变量？2.在还原控制流平坦化时，如何处理循环结构的还原？3.有哪些工具或库可以辅助进行AST操作以还原控制流平坦化？4.控制流平坦化与其他混淆技术（如虚假控制流）结合时，如何有效还原？5.还原控制流平坦化后，如何进一步优化代码的可读性？</think>### AST操作还原控制流平坦化的常见陷阱 控制流平坦化是一种代码混淆技术，通过将原始控制流拆解为状态机结构（通常用`switch-case`实现），增加逆向分析难度。使用**抽象语法树（AST）** 还原时需注意以下陷阱： --- #### 1. **状态变量识别错误** - **问题**：混淆后的代码依赖**状态变量**（如`int state`）驱动跳转，若分析工具未能准确追踪该变量的数据流，会导致还原失败。 - **案例**：状态变量可能被多重赋值或加密，例如： ```c state = (input * 0xDEADBEEF) % 10; // 非线性运算干扰分析 ``` - **解决**：结合数据流分析（如常量传播、污点分析）精确跟踪状态变量变化[^1]。 --- #### 2. **基本块合并失效** - **问题**：平坦化将原始代码拆分为独立**基本块**（Basic Block），还原需合并相关块。但以下情况会导致合并错误： - **虚假控制流**：混淆器插入永不执行的条件分支（如`if(false){...}`）。 - **间接跳转**：通过函数指针或`goto`动态跳转，AST静态分析难以解析。 - **解决**：动态执行（如符号执行）辅助验证控制流可行性[^2]。 --- #### 3. **循环结构还原困难** - **问题**：原始循环被拆解为多个离散状态，AST操作可能： - 将循环误识别为顺序结构； - 无法重建循环边界条件（如混淆后的`for`→`switch`嵌套）。 - **案例**： ```c while(i<10){...} // 原始代码 // 平坦化后变为： switch(state){ case 0: if(i<10) state=1; else state=2; ... } ``` - **解决**：识别循环模式（如状态变量回退到前驱块）。 --- #### 4. **上下文信息丢失** - **问题**：AST操作可能忽略**环境依赖**： - 全局变量或寄存器值影响状态跳转； - 外部函数调用修改关键状态（如`state = rand()`）。 - **后果**：还原后的控制流缺少外部依赖逻辑，无法执行。 - **解决**：构建跨函数调用图（Call Graph）追踪副作用。 --- #### 5. **性能与复杂度瓶颈** - **问题**：深度混淆的代码生成**超大规模AST**，导致： - 内存溢出（百万级节点）； - 分析算法指数级耗时（如路径爆炸）。 - **优化**： 1. 分阶段处理：先简化AST（删除死代码），再还原控制流； 2. 启发式剪枝：忽略概率极低的路径。 --- #### 6. **平台与编译器差异** - **问题**：不同编译器（GCC/Clang/MSVC）生成AST结构差异大，例如： - Clang为`switch`生成`CompoundStmt`嵌套层； - GCC可能插入隐式内存屏障。 - **陷阱**：通用还原工具需适配多种IR（中间表示）。 --- ### 关键缓解策略 1. **混合分析**：结合静态（AST）与动态（符号执行/DSE）验证； 2. **模式匹配**：预定义平坦化模板（如OLLVM模式）加速识别； 3. **增量还原**：优先处理确定性路径，逐步扩展至模糊路径； 4. **可视化辅助**：生成控制流图（CFG）人工验证关键节点。 > 示例工具链： > - **静态分析**：Clang AST + LLVM Pass > - **动态分析**：Angr/KLEE符号执行引擎 > - **可视化**：GraphViz生成CFG
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值