控制流平坦化兼容吗？聊聊我在实际逆向中踩过的那些坑
哎呀,今天又有人问我这个问题了——“控制流平坦化兼容吗？”说实话，每次看到这个问题，我都忍不住想笑，因为这个问题本身就有点像在问“辣椒辣吗”一样，答案不是简单的“是”或“不是”，得看你说的是什么场景下的兼容。
先给大家一个链接,方便后面反复查阅：控制流平坦化兼容吗，这篇文章我会持续更新，把我在实战中遇到的各种兼容性问题都记录进去。
先搞明白，控制流平坦化到底是个啥玩意儿
如果你还没接触过控制流平坦化（Control Flow Flattening，简称CFF），那我简单说一嘴，这玩意儿说白了就是一种代码混淆技术，它把原本清晰的if-else、while、for这些控制流结构，全部打散成一个大的switch-case调度器，原来你代码里是“先做A，再做B，如果C就做D”，经过CFF之后，变成了“不管三七二十一，先跳到调度器，调度器告诉你下一步去哪，做完再回来问调度器”。
听起来是不是挺变态的？但这就是它的目的——让逆向的人看得头大。
我第一次遇到CFF的时候,整个人都懵了，那代码打开一看，全是while(1)套switch，里面几十个case，变量名还都是v1、v2、v3……我当时就想摔键盘，真的。
那回到正题，控制流平坦化兼容吗？
这个问题得拆开看,你说的“兼容”，到底是跟什么兼容？
第一种情况：CFF跟不同的编译器兼容吗
答案是：基本兼容，但表现不一样。
OLLVM（Obfuscator-LLVM）是最早把CFF做火的，它基于LLVM IR层面做变换，所以理论上支持LLVM能编译的所有语言和平台，但实际用起来嘛……哎，坑可不少。
比如你在Android NDK上用OLLVM做CFF，不同NDK版本出来的效果就不一样，我试过用NDK r21和r25分别编译同一份代码，r21出来的CFF结构还算规整，r25出来的直接给你整出一堆冗余跳转，反编译出来跟天书似的，你说这算兼容吗？算，但兼容得让你想骂人。
还有GCC那边,也有类似的插件能做CFF，但跟OLLVM的兼容性就……怎么说呢，各玩各的吧，你把OLLVM混淆过的代码拿去给GCC编译？别想了，IR都不一样。
第二种情况：CFF跟反混淆工具兼容吗
哈哈,这个问题就有意思了。
市面上那些反混淆工具,比如D-810、GooMBA之类的，对CFF的处理能力参差不齐，有些工具号称能“一键还原CFF”，但我实测下来，简单的CFF确实能还原个七七八八，稍微复杂一点的——比如加了不透明谓词、加了虚假控制流的——直接歇菜。
我记得有一次分析一个恶意样本,那CFF搞得跟迷宫似的，我用了三个不同的反混淆工具，结果三个工具给出的还原结果都不一样，你说这兼容吗？兼容了个寂寞。
不过话说回来,IDA Pro 7.7之后的版本对CFF的识别能力确实强了不少，配合Hex-Rays反编译器，很多时候能自动帮你把switch调度器给优化掉，但也不是万能的，遇到那种变态级别的CFF，还是得手动慢慢跟。
第三种情况：CFF跟不同架构兼容吗
这个其实还好,因为CFF是在IR层面做的，所以x86、x64、ARM、ARM64这些主流架构都能用，但问题在于，不同架构下的指令特征不一样，你写反混淆脚本的时候得分开处理。
比如ARM64下,CFF的调度器经常用CSEL、CSINC这些条件选择指令来实现，而x86下更多用CMOV，你要是写了一个针对x86的反混淆规则，拿去ARM64上跑，那肯定不兼容啊。
第四种情况：CFF跟性能兼容吗
这个嘛……怎么说呢，CFF本质上是用性能换安全性，你想想，本来一个简单的if-else，现在要经过调度器跳来跳去，CPU的分支预测器都要被你玩坏了。
我做过一个测试,同一段算法，未混淆版本跑100万次用了0.8秒，CFF混淆后用了3.2秒，你说这兼容吗？功能上兼容，性能上……你自己掂量吧。
一些实用的建议
如果你正在纠结“控制流平坦化兼容吗”这个问题，我给你几个实在的建议：
-
别指望一套方案打天下，不同的编译器、不同的架构、不同的混淆强度，你都得准备不同的应对策略。
-
反混淆工具只是辅助，别想着靠工具一键搞定，工具能帮你省30%的力气就不错了，剩下的70%还得靠手动分析。
-
多积累特征库，我自己的习惯是，每遇到一种新的CFF变种，就把它的特征记录下来，下次遇到类似的就能快速识别。
-
性能敏感的场景慎用CFF，如果你做的是移动端App，本来性能就紧张，再上CFF，那用户体验……你自己想吧。
最后说两句
控制流平坦化兼容吗？我的答案是：在功能层面基本兼容，在实战层面处处是坑，但正是这些坑，才让逆向分析变得有意思，不是吗？
好了,今天就唠到这儿，如果你也有踩过CFF的坑，欢迎在评论区分享，咱们一起避雷，别忘了收藏这篇文章：控制流平坦化兼容吗，后续我会继续更新更多实战案例。
下次见啦,拜拜！