deflat 腳本學習【去除OLLVM混淆】

deflat腳本鏈接：GitHub - cq674350529/deflat: use angr to deobfuscation

deflat 腳本測試

這里以代碼混淆與反混淆學習-第一彈中的OLLVM 混淆樣本為例進行去除?！綥LVM-4.0】

(相關資料圖)

控制流平坦前	控制流平坦后

python deflat.py --file main-bcf --addr 0x401180

deflat.py 成功去除后效果：

去混淆后，效果還算可以，能分析程序流程了。

deflat 腳本分析【angr】

利用符號執(zhí)行去除控制流平坦化 - 博客 - 騰訊安全應急響應中心 (tencent.com)

angr documentation

利用angr符號執(zhí)行去除控制流平坦化 - 0x401RevTrain-Tools (bluesadi.github.io)

序言：函數(shù)的第一個執(zhí)行的基本塊主(子)分發(fā)器：控制程序跳轉到下一個待執(zhí)行的基本塊retn塊：函數(shù)出口真實塊：混淆前的基本塊，程序真正執(zhí)行工作的版塊預處理器：跳轉到主分發(fā)器

如第一彈中分析：OLLVM 的控制流平坦化是將程序的一般邏輯劃分為很多個真實執(zhí)行的塊，然后通過分發(fā)器進行鏈接。其實就是一個Switch結構，每次執(zhí)行完真實塊后，進行預處理，再跳轉到主分發(fā)器，繼續(xù)分發(fā)，最終達到平坦化的效果。

顯然，去控制流平坦化就是要找到真實塊間的跳轉邏輯，打破Switch結構束縛。

具體來說，有如下步驟：

靜態(tài)分析CFG得到序言/入口塊、主分發(fā)器、子分發(fā)器/無用塊、真實塊、預分發(fā)器和返回塊。利用符號執(zhí)行恢復真實塊的前后關系，重建控制流根據(jù)第二步重建的控制流Patch程序，輸出恢復后的可執(zhí)行文件靜態(tài)分析

首先明確：【以下結論針對OLLVM項目，其他大佬加料的OLLVM混淆還需要單獨分析】

函數(shù)的開始地址為序言的地址序言的后繼為主分發(fā)器后繼為主分發(fā)器的塊為預處理器后繼為預處理器的塊為真實塊無后繼的塊為retn塊剩下的為無用塊

angr 獲取類似Ida的 CFG

獲取真實塊、主分發(fā)器、預處理器、序言、retn塊和無用塊

獲取真實塊的細節(jié)

angr 恢復真實塊執(zhí)行邏輯，重建控制流

利用angr 強大的符號執(zhí)行功能，找到各真實塊的連接邏輯。

這里對于兩個分支的模擬執(zhí)行，只需關注cmov指令，就可以分別對應得到eax、ecx，然后獲得后續(xù)真實塊?！揪窒扌院艽蟆?/p>

符號執(zhí)行 symbolic_execution（）函數(shù)，返回后繼真實塊。

Patch程序恢復執(zhí)行邏輯

如此便完成了 deflat腳本的簡單處理分析。

小結

分析下來，其實就是定位到所有真實塊，然后利用angr符號執(zhí)行將真實塊間的執(zhí)行邏輯進行串聯(lián)。最后進行patch程序，重建控制流。

但顯然存在一些問題，我們默認了如下規(guī)則:

函數(shù)的開始地址為序言的地址序言的后繼為主分發(fā)器后繼為主分發(fā)器的塊為預處理器后繼為預處理器的塊為真實塊無后繼的塊為retn塊剩下的為無用塊

但是在實際去除控制流平坦化過程中，上面的默認思路已經被加混淆的開發(fā)者做了處理。

例如：

后繼為預處理器的塊不一定是真實塊；預處理器不一定存在；存在分支的真實塊跳轉的判斷邏輯，不一定是cmov指令;deflat腳本默認模擬執(zhí)行最多兩個分支，但真實情況可能不只兩個分支；可能存在一個向前更新的數(shù)組，依據(jù)程序運行進行更新，決定當前真實塊的跳轉【這導致angr對于該塊的模擬執(zhí)行得不到正確的跳轉】程序在加混淆前，已經被添加了花指令或其他處理，程序CFG圖已經被打破；某個塊存在死循環(huán)，會使angr符號執(zhí)行卡死……

這也導致了，這個deflat腳本的普適性較低，除了能夠處理OLLVM官方項目做的混淆，對加了其他PASS或者處理的混淆，基本用不了。

所以對于去除不了的OLLVM混淆，我們需要根據(jù)程序的實際混淆效果，對deflat腳本進行修改，再進行去混淆。

【這也要求對deflat 腳本比較熟悉，可以更快上手】

失敗的花指令控制流平坦化嘗試

使用代碼混淆與反混淆學習-第一彈中加了花指令的程序，進行OLLVM控制流平坦化混淆，看看效果。

源代碼如下：

# clang 執(zhí)行內聯(lián)匯編加 -fasm-blocks 或者 -fms-extensions 或者 -masm=intelclang -mllvm -fla -mllvm -split -mllvm -split_num=3 main-call-加花.cpp -lm -fasm-blocks -o main-call-加花# 需要對源代碼作一些修改

存在較大的問題，我的OLLVM 環(huán)境是在Ubuntu上搭建的，對于上述內聯(lián)匯編加的花指令無法編譯通過！

【或許可以在Windows 上移植OLLVM，進行編譯（好像挺難的）】

可以看到，花指令用到的標簽、$ 出現(xiàn)報錯。

【最終也沒解決編譯問題，或許本就不可以，ollvm 不具備這樣的處理能力，也可能是我代碼的問題，如果博客前的你有任何想法，歡迎與我交流】

TSCTF-J 2022-upx_revenge實戰(zhàn)分析

TSCTF-J 2022 WP

對upx_revenge題目進行分析。

首先直接使用deflat 腳本。

python deflat.py --file upx_revenge_test --addr 0x4016D0

發(fā)現(xiàn)沒有找到retn 塊。

處理多個retn塊

回到ida 查看cfg 圖發(fā)現(xiàn)原因：存在其他的退出塊。

這里需要改進deflat 腳本，使其存在很多retn塊。

# 其他位置的retn_node，對應改為list處理if supergraph.out_degree(node) == 0:            retn_node.append(node)

成功運行，但是去除效果不行。

去除后CFG圖

多個comv的處理

很明顯看出，程序的真實塊間的邏輯串聯(lián)失敗，也就是重建控制流失敗。

產生原因

顯然，這里存在2個分支，因為有兩個cmov【相同判斷】，并且call 函數(shù)，對分支跳轉是有作用的，這里var_CC是順序執(zhí)行，動態(tài)更新的。

【deflat 腳本只處理了執(zhí)行有一個cmov指令的情況，且hook了call函數(shù)】

【由于var_CC是順序執(zhí)行，動態(tài)更新也可以看出，deflat 腳本的模擬執(zhí)行思路已經無法對真實塊的后繼進行確定了】

但這里做個測試，不hook call 看是什么效果。

可以知道，取消hook call 對真實塊后繼的查找毫無影響，這是因為deflat中的模擬執(zhí)行，只是基于comv處的模擬。對前文并無任何關聯(lián)。

顯然，該deflat腳本的無法處理了?！尽?/p>總結angr

就upx_revenge這道題而言，

deflat 腳本中angr 對局部的模擬執(zhí)行顯然無法獲取真實塊間的執(zhí)行順序，重建控制流顯然也無從談起。當然靜態(tài)查找各個控制流平坦化的功能塊效果還是可以的。

那么如何通過angr,有序的、聯(lián)系上文地進行模擬執(zhí)行，獲取真實塊的執(zhí)行邏輯，顯然是關鍵點！

【??? 后續(xù)學習了，有思路再更新】

unicorn

[原創(chuàng)]ARM64 OLLVM反混淆-Android安全-看雪論壇-安全社區(qū)|安全招聘|bbs.pediy.com (kanxue.com)

Unicorn反混淆：恢復被OLLVM保護的程序(一) - 簡書 (jianshu.com)

使用unicorn 模擬執(zhí)行框架獲取真實塊間的執(zhí)行順序，重建控制流。

【還沒學過 unicorn 使用，，，】

ida

使用IDA microcode去除ollvm混淆(上) - 先知社區(qū) (aliyun.com)

GitHub - PShocker/de-ollvm: IDA Python Script for anti ollvm

利用ida 現(xiàn)成的CFG 圖，以及idc 腳本，動態(tài)運行程序，獲取真實塊的執(zhí)行順序，從而恢復控制流。

關鍵詞：