跟蘋果審核打交道時間也挺久了，市面上工具基本也都了解完了。無非是正則匹配混淆修改和修改ats代碼調用邏輯樹。了解llvm的初衷也是為了混淆方案，看看編譯期間到底做了什么，以及混淆的時候重點應該放在哪里。通過.ll文件看下中間過程，因為.ll文件是最終生成匯編代碼的最后一個過程。通過研究其可以有一些混淆方面的思路
先看下llvm編譯器對我們代碼做了什么
3671670579616_.pic_hd.jpg
圖片中是我們寫的一個方法還有里面的局部變量，右邊是在.m文件在打包生成最終的二進制文件的中間態(tài)，經歷了代碼語法分析和語意檢測后的中間編譯文件。我們可以看到我們命名的部分局部變量已經被替代了
在研究過程中還發(fā)現了一個比較有意思的事情，做下記錄，就是xcode提供了對編譯完成代碼的優(yōu)化選項，下圖中就是通過配置，對最后形成的二進制代碼的影響
3681670580018_.pic_hd.jpg
LLVM的優(yōu)化級別 -O0 -O1 -O2 -O3 -Os。llvm通過此幾種級別的設置，最終呈現的二進制文件是有所不同的。所以在如果你有方案或者其他，可以通過.ll文件暫時比對下混淆前后的文件。側重點應該放在方法執(zhí)行中的修改。
最近還在看app啟動優(yōu)化的二進制重排，帶來了一個思考就是應用類的加載順序是不是也是一個特征。
