基礎知識

LLVM是lowlevel virtual machine的簡稱，它誕生于2003.10伊利諾伊大學香檳分校，創始人是ChrisLattner，它是一個完整的編譯器框架，它兼容大部分主流開發語言例如：C, C++, Objective-C等等，它也兼容大部分主流的平臺：x86, x86-64, PowerPC, PowerPC-64,ARM,Thumb等等。

（圖片來源網絡）

LLVM會先將源碼生成為與目標機器無關的LLVMIR代碼，然后把LLVMIR代碼先優化，再向目標機器的匯編語言而轉換。LLVM編譯器主要細分為前端、中層優化和后端的3部分構成。

(圖片來源網絡)

OLLVM就是在LLVM的基礎上增加了obfuscator(混淆)， Obfuscator-LLVM (OLLVM) 是2010 年 6 月由 Yverdon-les-Bains 的瑞士西北應用科技大學安全實驗室針對LLVM編譯組件開發的代碼混淆工具，該工具完全開源，這個OLLVM主要為了增加逆向工程的難度，保證代碼的安全性。

Obfuscator-LLVM (OLLVM)集成了LLVM編譯器,并且兼容LLVM支持的所有語言(C,C++, Objective-C, Ada and Fortran)和平臺(x86, x86-64, PowerPC,PowerPC-64,ARM,Thumb,SPARC,Alpha,CellSPU,MIPS, MSP430, SystemZ,XCore)。

OLLVM的混淆原理，就是在不改變源代碼功能前提下，將C或C++代碼中的控制語句if、while、for、do等轉換成switch分支語句。這樣實現的優勢是，它可以模糊switch中case代碼塊之間的關系，從而增加逆向分析代碼難度。

混淆的具體實現思路，首先將要實現代碼平坦化的函數分成多個基本塊(就是case代碼塊）和一個入口塊，并為每個基本塊設置編號，并讓這些基本塊都有共同的前驅模塊和后繼模塊。前驅模塊主要是進行基本塊的分發，后繼模塊的分發通過改變switch變量來實現。

OLLVM和LLVM主要的功能的代碼差異點如下圖所示

OLLVM功能介紹

OLLVM全面模式支持以下四種代碼包含模式

1、-mllvm -fla： 控制流化扁平化

2、-mllvm -sub：指令替換

3、-mllvm -bcf： 控制流程

4、-mllvm -sobf： 字符串加密

以OLLVM保護后的功能效果都在文章的后部分進行展示。

-mllvm -fla中fla的全稱:Control Flow Flattening,它也稱為控制流扁平化，這個功能模式主要原理就是把一些if-else語句，嵌套成do-while語句。

它支持以下3種保護功能模式：

-mllvm -fla: 激活控制流扁平化

-mllvm -split：激活基本塊分裂。一起使用時提高平整度。

-mllvm -split_num=3：如果激活通行證，則在每個基本塊上應用 3 次。默認值：1

-mllvm -sub，它的全稱Instructions Substitution，它又稱為指令替換，這個的原理可以理解為就是不改變功能的前提下，將簡單的指令替換成更復雜的指令，當有多個等效指令序列可用時候，會隨機選擇一個指令進行替換。這個混淆它并不會增強過多的安全性，因為它可以通過重新優化生成的代碼輕松刪除，如果選擇使用隨機生成器以不同數值作為種子，指令替換會在生成的二進制文件中帶來多樣性。

它支持以下的2種模式功能：

-mllvm -sub：激活指令替換

-mllvm -sub_loop=3：如果激活了傳遞，則在函數上應用3次。默認值：1

-mllvm -bcf，它的全稱Bogus Control Flow，也稱為虛假控制流。這個主要原理就是在當前基本塊之前添加一個新的基本塊用來修改函數調用圖，這個新的基本塊包含一個不透明的謂詞，通過有條件地跳轉到原來的基本塊。原始的基本塊也會被克隆并填充隨機的垃圾指令。

這虛假控制流代碼保護模式主要通過在不改變代碼功能前提下往代碼里面嵌套幾層的判斷邏輯，這種模式下會大大影響程序的性能，因為它在代碼下混雜著真真假假的代碼。

這個模式下它支持3種功能選項：

-mllvm -bcf: 激活偽造的控制流通道

-mllvm -bcf_loop=3: 如果 pass 被激活，在一個函數應用 3 次。默認值：1

-mllvm -bcf_prob=40：如果激活通行證，一個基本塊將以 40% 的概率被混淆。默認值：30

-mllvm -sobf也稱為字符串混淆，主要實現將代碼中的字符串做加密，使得無法通過靜態逆向方式直接看到字符串信息。

它主要支持2種功能模式選項：

-mllvm -sobf：編譯時候添加選項開啟字符串加密

-mllvm -seed=0xdeadbeaf：指定隨機數生成器種子流程

OLLVM編譯

編譯OLLVM前需要以下的工具和代碼：

1、OLLVM源碼(基礎之源)

https://releases.llvm.org/download.html

2、cmake工具(將OLLVM轉換為sln項目)

https://cmake.org/download/

3、Visual studio工具（編譯OLLVM源碼）

https://visualstudio.microsoft.com/zh-hans/

在window環境下編譯OLLVM的源碼主要需要經歷2個步驟

1、通過利用cmake將OLLVM的源碼轉換為sln的項目

可以通過利用cmake工具或者用命令行方式轉換，下面以命令行方式轉換的

cmake -Thost=x64 -G "Visual Studio 16" E:ollvm9obfuscator-llvm-9.0.1obfuscator-llvm-9.0.1

上面要主要的是Visual Studio 16這個代表你環境中安裝的vs版本，我安裝2019版本的，所以用它。

通過執行以上命令后就會出現下圖的效果

2、用Visual studio 2019 直接編譯前面生成的OLLVM項目，主要編譯Release版本。編譯后正確情況下會生成bin和lib兩個文件夾。

OLLVM集成

通過前面的編譯后生成的bin和lib文件夾，集成到NDK中，并通過android studio編譯器進行so代碼保護的應用。

將vs編譯生成后的bin和lib文件夾，替換到NDK中的llvm文件夾下面toolchainsllvmprebuiltwindows-x86_64(替換之前切記做下備份，萬一出問題了還能回滾)

通過配置Android.mk文件進行設定需要對so文件采用什么方式的全局代碼保護。

可能大家會覺得保護強度越強越好，代碼虛擬化、字符串混淆、指令替換等等都給用下去，那樣就安全了，其實不是這樣的，這些強度雖然上去了但是會給項目帶來非常大的負擔。往往會帶來負面性能影響。

個人建議：可以針對字符串做個混淆(-mllvm -sobf)，外加指定核心函數進行做代碼保護。這樣強度也有了，對應用的性能影響方面也相對較小。

上圖中Android.mk設置的保護方式屬于全局的保護，設置后整個so就都會基于設置的保護。

通過配置Application.mk文件，進行指定ollvm的clang具體版本數據(這個具體版本數據也可以lib文件夾下clang文件夾下查看)。

OLLVM保護效果

為了更好展示分析ollvm保護后的效果，主要通過基于__attribute((__annotate__(("sub"))))這種方式，對指定函數進行做保護，而沒有進行配置全局的保護。

下圖的代碼功能效果僅是為了測試OLLVM的虛假指令保護后的實現效果

下圖是基于IDA工具的原始和虛假控制流的代碼保護流程圖，可以看到代碼的執行流程已被調整變得相對復雜化，這樣就大大強化了代碼的安全強度，這種逆向分析其代碼至少靜態分析起來就費勁了。

下圖是通過指定函數進行設置指令替換的功能的代碼展示

通過下圖IDA靜態的代碼流程圖可以很清晰分析到，它實際上代碼流程是沒有任何變化的，所以這種保護模式下的代碼保護功能時沒有很明顯的效果的。

下圖的代碼是通過調用ollvm的控制流扁平化功能進行對函數保護的代碼展示

通過下圖IDA的代碼流程圖，可以看到代碼控制流扁平化保護后，整個流程就變得復雜化了。這就讓代碼的安全性上升一個層次了，這樣逆向分析還原代碼功能的成本就大大提高了。

小結

通過上文OLLVM的一系列的原理集成、編譯、配置、集成、代碼生成、效果展示，主要為了給SO代碼的防破解防逆向增加點門檻，提高點安全性。這系列的代碼保護對于專業搞逆向的人員來說，它們可以通過基于Trace、unicron、frida這些方式去還原和去除OLLVM的混淆保護。

對于代碼的安全性思考，不過在安全攻防對抗的過程中防御一直屬于被動狀態的也是相對滯后的。安全防護也是隨著對抗去不斷去提高變強。

代碼安全防護方面可以借助于OLLVM然后進行做定制魔改，現有的逆向工具更多是基于標準化進行做反匯編，那么我們可以對這些逆向工具做些防護(可以多個方案結合)，然后調整成為一些非標準化的，這樣會大大增加逆向分析的成本。

只要逆向分析成本超過所破解后所獲取的收益，那么你的代碼就相對安全了。