前言

在上一篇中我们讲过MOV混淆和SMC自解码，这两种反静态分析的手段在中等偏难的题目中会遇见。但是在今天的文章中我们会讲解到LLOM这种工业级的混淆方式，在CTF题目中也是很常见的，为此我们要来分析LLOM混淆。除此之外，讲解了常见的混淆模式，在第六节中我们会去探索一些不太常见的反静态分析手段。同时预报一下，在我的下一个系列中会分析《CTF中的反动态调试》的相关技术。
第五节 OLLVM混淆（LLOM）
什么是LLVM？
LLVM是构架编译器(compiler)的框架系统，以C++编写而成，用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time)，对开发者保持开放，并兼容已有脚本。
LLVM计划启动于2000年，最初由美国UIUC大学的Chris Lattner博士主持开展。2006年Chris Lattner加盟Apple Inc.并致力于LLVM在Apple开发体系中的应用。Apple也是LLVM计划的主要资助者。
目前LLVM已经被苹果IOS开发工具、Xilinx Vivado、Facebook、Google等各大公司采用。（源自百度百科的解释）
而我们的主题并不是llvm这个架构编译器，而是基于这个架构编译器的obfuscator-llvm。
为了不重复造轮子，我就不会解释OLLVM。
在下面我推荐两篇文章：大家在看之前，请先浏览这两篇文章。
https://security.tencent.com/index.php/blog/msg/112
https://xz.aliyun.com/t/4960
配置OLLVM

Github地址：https://github.com/obfuscator-llvm/obfuscator/wiki/Installation
上面地址安装的是oLLVm-4.0
Github：https://github.com/AllocAndInit/ollvm5.0.1
上面这个是最新的。
我先安装4.0的看看感觉

但是我们在执行第四步的时候可能会出现这样的错误

这个时候我们需要更换一下我们的第四步命令
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_INCLUDE_TESTS=OFF ../obfuscator/
但是我们在完成最后编译环节的时候，有些电脑可能会出现这样的错误提示，
c++:internal compiler error:killked(program cclplus)　
编译就终止了。
解决方案就是扩大swap分区的容量，这个问题是swap分区太小而导致的。
笔者的环境是Ubuntu18.04，怎样增加swap分区呢？
查看我们的盘符情况：free -h

我的分区只有2G
创建一个swap文件
sudo mkdir /swap
cd /swap
进行扩充（下面的命令是扩6G，可以根据实际情况更改）
sudo dd if=/dev/zero of=swapfile bs=1G count=6

因为dd是不会查看进度的
同时这个命令可以查看进度

sudo watch -n 5 killall -USR1 dd

然后将生成的文件转换成swap文件

sudo mkswap -f swapfile

这里我报错了,需要我们手动将文件夹的权限转换成600

sudo chmod 0600 /swap/swapfile
然后直接激活

sudo swapon /swap/swapfile

（以下步骤可以不用执行，不影响安装环境）
但是这样重启后会直接失效
你如果需要的话可以进行重新激活

sudo swapon /swap/swapfile
如果需要一直保持这个swap,则需要将其写在/etc/fstab文件中

sudo nano /etc/fstab

解决好上面这个报错，就可以继续执行编译环节。安装环境就没有什么问题了。我们就开始来试一试这个混淆方式吧。

OLLVM的初体验

为了让大家熟悉附加平坦化，我写了一个简单的C代码，然后用两种编译实现一下，看看返回编后的效果。在附件中我会上传我的源代码。
在正常编译下后反汇编的效果：

核心代码：

对源代码未进行保护。
接下来我们看看经过OLLVM编译的反汇编效果：

而关键代码：

关键代码就受到保护。
简单的演示就到这里。各位师傅们有兴趣可以多探究一下。
如何去平坦化

在我的上一篇文章中，有详细的讲解如何配置去平坦化，如果读者没有配置，请先参考上篇文章配置环境后进行阅读下面的内容。
在这里我将采用2019全国信息安全专项赛上的一个题目flat，进行测试（附件会有相关资料）。
打开IDA直接分析

开局就发现有点熟悉，很可能就是采用了OLLVM混淆

在我们用strings命令查看，便看到一段很有意思的字符。在这里我们已经知道个大概了，不慌，进入程序再看看。

现在基本上很确定是OLLVM混淆。那我们就直接还原check函数。

这是我还原的check1函数。还原的很彻底。
接下来我们就不用怎么分析。直接还原所有的check函数。Flag就非常容易分析出来。虽然这题可以手动分析出来，不去平坦化，肯定会花去不少时间。
那这题我就不具体分析了，我直接给出题解：http://mp.weixin.qq.com/s?__biz=MzU3ODc2NTg1OA==&mid=2247484146&idx=1&sn=43f4f00339ea244a27c1d8b22d2fe5c5&chksm=fd7117bfca069ea98ec310f8eeef35ad08bb39a9ddde67042bf1b5b6ae5c8a50d69cb7f66a18&mpshare=1&scene=23&srcid=&sharer_sharetime=1566915918208&sharer_shareid=1999a7068cdb9c4191541446b49b93e1#rd （感谢星盟安全团队的题解）。

总结

分析了这么多反静态分析的手段，在比赛中或多或少会遇到，有事并不会单独出现。希望读者们多多研究一下这些手段。手段是旧的，但是出题者的想法总是层出不穷的。