从llvm编译过程看马甲混淆

跟苹果审核打交道时间也挺久了，市面上工具基本也都了解完了。无非是正则匹配混淆修改和修改ats代码调用逻辑树。了解llvm的初衷也是为了混淆方案，看看编译期间到底做了什么，以及混淆的时候重点应该放在哪里。通过.ll文件看下中间过程，因为.ll文件是最终生成汇编代码的最后一个过程。通过研究其可以有一些混淆方面的思路
先看下llvm编译器对我们代码做了什么

3671670579616_.pic_hd.jpg

图片中是我们写的一个方法还有里面的局部变量，右边是在.m文件在打包生成最终的二进制文件的中间态，经历了代码语法分析和语意检测后的中间编译文件。我们可以看到我们命名的部分局部变量已经被替代了
在研究过程中还发现了一个比较有意思的事情，做下记录，就是xcode提供了对编译完成代码的优化选项，下图中就是通过配置，对最后形成的二进制代码的影响

3681670580018_.pic_hd.jpg
LLVM的优化级别 -O0 -O1 -O2 -O3 -Os。llvm通过此几种级别的设置，最终呈现的二进制文件是有所不同的。所以在如果你有方案或者其他，可以通过.ll文件暂时比对下混淆前后的文件。侧重点应该放在方法执行中的修改。
最近还在看app启动优化的二进制重排，带来了一个思考就是应用类的加载顺序是不是也是一个特征。