-
-
[原创]AntiOllvm 去除二进制文件Ollvm混淆并编译回二进制文件
-
2021-6-17 09:53
-
[AntiOllvm]
AntiOllvm去除二进制文件 Ollvm 混淆，并生成新的可执行二进制文件
其它方法介绍
- Ollvm 已经开源很久了，现在市面很多恶意软件都使用它，为了防止分析加壳加混淆基本是必备的。假如一个恶意软件使用某种算法加密了你的文件，并且采用了混淆，如果你要自己解密或者制作解密工具都离不开分析它的算法。而使用混淆后伪代码几乎不可查看，为此你要付出大量的时间和精力去分析。现在网上通用一点的方法有使用
unicorn模拟执行，还有使用trace功能跟踪运行过的代码。 - 使用
unicorn模拟执行- 虽然可以支持很多架构的运行，但是从汇编层构建出
CFG还是比较吃力的 - 具体的分析都对应着直接的汇编指令，再加上多架构这样处理起来非常麻烦
- 还有修复跳转，补丁指令，在原函数中代码分散，甚至还需要修复指令的重定位
- 虽然可以支持很多架构的运行，但是从汇编层构建出
- 使用
trace跟踪trace分析相对较简单,但缺点是你需要在真机上运行- 每次运行也不一定会覆盖所有路径
- 在还原算法或分析时看的是汇编指令，增加分析难度
AntiOllvm 简介
- 采用将二进制代码还原为
LLVM IR的方式，经过各种优化去除混淆后再编译回原文件 - 采用这种方案优点很多
- 本身
Ollvm就是在LLVM IR中转换代码然后编译，在还原回LLVM IR后能最大限度的还原特征 - 可以利用现有的
LLVM中的优化，各种分析也可以查找部分现成的 - 统一了所有架构的分析，分析方法通用，重建 CFG 非常容易
- 分析过程更加直观，不接触汇编代码，更容易分析出混淆规则
- 本身
大概思路
AntiOllvm使用 retdec 将二进制文件还原为LLVM IR- 使用
LLVM中的内部优化，将IR码优化为较高可读性的代码，这期间部分指令替换以及不可达代码就已经优化掉了 - 定制
Pass去除掉函数内部的 虚假控制流和平坦化 - 最后通过
LLVM将代码重新编译回汇编并回填文件
开发进度
| 架构 | ELF | COFF | Mach-O |
|---|---|---|---|
| Arm | Yes | ||
| Arm64 | |||
| X86 | |||
| X86_64 |
- 等测试稳定会后陆续开放其它架构
- IDA 插件的开发（需等所有架构开放后）
使用说明
- 该项目是收费项目，AntiOllvm仓库只会存放说明文件和一些测试样本的源码和二进制文件
- 目前还未提供可购买版本，鉴于目前不够稳定，样本量较少，后续稳定后会推出正式可购买版本
- 欢迎大家提供样本（越复杂越好）到我的邮箱 beichenzhizuoshi@163.com，也可在本仓库提交 issues 附带样本及说明，目前只接受
Arm架构的ELF样本，发送样本时请在标题上注明 二进制架构及文件格式 例如 Arm-ELF 测试样本, 内容上注明被混淆的 函数名称或地址，和你自认为的 混淆难度等级（1-3），我会在去混淆通过后回复你去混淆后的二进制文件
例子演示
- 见 AntiOllvm，在这个仓库会公布文档和一些测试的源码以及去混淆后的二进制文件
- 该样本是使用
openssl加密库，开启混淆，注意测试与MD5算法有关方法MD5_Update、md5_block_data_order，样本详细说明可以查看仓库 OpenSSLTest - 未混淆和去混淆后的运行对比
- 混淆过后的
MD5_UpdateCFG
- 混淆过后的
md5_block_data_orderCFG
- 未混淆
MD5_UpdateCFG如下:
- 去混淆后
MD5_UpdateCFG
- 未混淆
md5_block_data_orderCFG
- 去混淆后
md5_block_data_orderCFG
交流反馈
- 点击AntiOllvm 获取更多信息
[培训]二进制漏洞攻防（第3期）；满10人开班；模糊测试与工具使用二次开发；网络协议漏洞挖掘；Linux内核漏洞挖掘与利用；AOSP漏洞挖掘与利用；代码审计。
|
|
|---|---|
|
|
|
|
|
自信点，把？去掉。 |
|
|
|
|
|
你的帖子我也看过，但是我使用的方法跟你完全不一样，你用到了模拟执行，而我目前只是静态分析，不能说我使用retdec就是抄你的吧，样本我也公开了，你可以自己去试试你的方法效果怎样，反正我没试过。再说我添加了很多arm neon指令支持，还有修复各种Bug，回编译，这跟你那个完全没关系吧 |
|
|
大佬能不能放出优化的源码一起技术交流下 我看你这个图是纯去除有源码的平坦化的 还有能私聊一下这个反混淆值几个钱吗 我也想喝点汤 我这还有个还原vmp的半成品 最后 我没有模拟执行 那只是方便的叫法 我是纯静态分析跟踪var值变化 |
|
|
|
|
|
可以加群私聊 |
|
|
|
|
|
|
|
|
|
|
|
编译回二进制的目的是在于可以直接运行，生成二进制文件就可以用于其它工具分析，其实参数的识别我仔细分析过arm的参数，只要你传入的参数>=实际参数，那么多余的参数可以不用管，因为实际函数用不到，大于4个参数写入堆栈是在调用方堆栈上写入到sp正偏移，但是sp的值并没有改变，被调用函数方使用就读取没使用就不用读取，返回后sp还原，因此只要你保证参数大于等于实际参数就可以了。间接调用就把调用函数当作函数指针就行了，至于虚函数反编译后本质就只是偏移，只要保证翻译优化正确那么偏移就会正确，变参函数比如标准库这可以直接拿到函数签名。最后还有人工指定函数参数 |
|
|
你把r0-r3挂到call的use链上就可以了，因为r0-r3穿过call，是会被破坏的，所以编译器原生不信任经过call的r0-r3 |
|
|
你这边内部测试过多少个函数可以写回了？最大测试的函数有多大？ |
|
|
我正在测一个超大函数，论坛上找的样本，且是魔改版的混淆，需要点时间，目前的版本使用正常的ollvm基本上没有问题可以完美还原 |
|
|
超大是多大？我这边现在最大时26K已经写回了，正在尝试32k的，以前的mem-phi实现的有问题，正在重写 |
|
|
你也在去混淆？找到一个50多k的，函数大小无所谓，关键是混淆的程度 |
|
|
不是的，体积大小的影响太大了，各种情况覆盖的情况复杂很多。比如，这里有个9K的函数
看起来时不是挺复杂，但是实际上解起来很简单。 这个26K的，看起来就一点点，实际上复杂很多:
这个里面貌似有在做多媒体优化，大量的simd指令，写回去很麻烦。 这个是我最后转出来的结果15520:
|
|
|
真正的上超大的，可能是微信的so里面有2个 300k的函数，和一个 3M左右的混淆函数，64K以下的个人感觉还好 |
|
|
我个人感觉你这套机制有点问题，你太依赖于ret2dec本身的优化了，假如某个变形ollvm，把整个cfg断开了以后，也就是反编译器走不到下一个指令地址，断开了，那么你优化出来就是错的。你必须得先解开整个ollvm，找到下一个反汇编地址才行 |
|
|
所以为了支持arm的neon指令我花了大量时间翻译，软件只要做到80%能解就行了，即使解不完全还能正确编译回去也可以 |
|
|
|
|
|
所以你手工把llvm ir转成了arm neon？没有完全用他们的后端？ 我看你的帖子，其实没有完全看懂
最后于 2021-6-18 00:00
被baikaishiu编辑
，原因：
|
|
|
如果真有问题那也是IDA的问题，最主要保证翻译和优化正确，那么编译的结果自然正确，翻译的正确性需要详细的每条指令测试，优化的正确使用LLVM内部优化可以信任，其它如retdec的优化本身有许多bug，在非llvm内部优化尽量做到保守，保证其正确性。 |
|
|
是在翻译 arm neon 汇编指令时将其翻译为合法的 llvm ir，编译肯定的是用LLVM的后端，只是要自己处理符号重定位才能回填文件 |
