deflat 腳本學(xué)習(xí)【去除OLLVM混淆】

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

deflat 腳本測(cè)試

這里以代碼混淆與反混淆學(xué)習(xí)-第一彈中的OLLVM 混淆樣本為例進(jìn)行去除?！綥LVM-4.0】

(相關(guān)資料圖)

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

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

deflat.py 成功去除后效果：

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

deflat 腳本分析【angr】

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

angr documentation

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

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

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

顯然，去控制流平坦化就是要找到真實(shí)塊間的跳轉(zhuǎn)邏輯，打破Switch結(jié)構(gòu)束縛。

具體來說，有如下步驟：

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

首先明確：【以下結(jié)論針對(duì)OLLVM項(xiàng)目，其他大佬加料的OLLVM混淆還需要單獨(dú)分析】

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

angr 獲取類似Ida的 CFG

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

獲取真實(shí)塊的細(xì)節(jié)

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

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

這里對(duì)于兩個(gè)分支的模擬執(zhí)行，只需關(guān)注cmov指令，就可以分別對(duì)應(yīng)得到eax、ecx，然后獲得后續(xù)真實(shí)塊。【局限性很大】

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

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

如此便完成了 deflat腳本的簡(jiǎn)單處理分析。

小結(jié)

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

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

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

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

例如：

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

這也導(dǎo)致了，這個(gè)deflat腳本的普適性較低，除了能夠處理OLLVM官方項(xiàng)目做的混淆，對(duì)加了其他PASS或者處理的混淆，基本用不了。

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

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

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

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

源代碼如下：

# clang 執(zhí)行內(nèi)聯(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-加花# 需要對(duì)源代碼作一些修改

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

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

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

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

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

TSCTF-J 2022 WP

對(duì)upx_revenge題目進(jìn)行分析。

首先直接使用deflat 腳本。

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

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

處理多個(gè)retn塊

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

這里需要改進(jìn)deflat 腳本，使其存在很多retn塊。

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

成功運(yùn)行，但是去除效果不行。

去除后CFG圖

多個(gè)comv的處理

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

產(chǎn)生原因

顯然，這里存在2個(gè)分支，因?yàn)橛袃蓚€(gè)cmov【相同判斷】，并且call 函數(shù)，對(duì)分支跳轉(zhuǎn)是有作用的，這里var_CC是順序執(zhí)行，動(dòng)態(tài)更新的。

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

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

但這里做個(gè)測(cè)試，不hook call 看是什么效果。

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

顯然，該deflat腳本的無法處理了。【】

總結(jié)angr

就upx_revenge這道題而言，

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

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

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

unicorn

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

Unicorn反混淆：恢復(fù)被OLLVM保護(hù)的程序(一) - 簡(jiǎn)書 (jianshu.com)

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

【還沒學(xué)過 unicorn 使用，，，】

ida

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

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

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

關(guān)鍵詞：