建指南：Ubuntu 20.04打造Android NDK混淆工具鏈)
搞Android Native層開發(fā)的人大概率都遇到過這種尷尬場景自己辛辛苦苦寫的核心邏輯編譯成so扔進(jìn)APK里別人拖出來用反編譯工具一看函數(shù)名、調(diào)用關(guān)系、常量字符串清清楚楚核心算法幾乎是裸奔狀態(tài)。如果你正在做的是SDK保護(hù)、游戲反外掛、或者是收費(fèi)算法防破解這種裸奔基本等于送人頭。OLLVM就是在這一層做文章的。它是LLVM的一個(gè)衍生分支在編譯器層面加入了幾套代碼混淆Pass可以直接把產(chǎn)出so的控制流、指令形態(tài)、偽代碼結(jié)構(gòu)全部打亂不需要改動你的業(yè)務(wù)代碼。這篇實(shí)戰(zhàn)記錄要解決的問題很具體在一臺Ubuntu 20.04上從源碼構(gòu)建一套能用于Android NDK的OLLVM工具鏈然后讓項(xiàng)目的CMake構(gòu)建走這套工具鏈最終產(chǎn)出帶混淆效果的so庫。適合正在做App加固、SDK安全、以及想把代碼混淆工具鏈真正落地到日常構(gòu)建流程里的開發(fā)者參考。1. 為什么要折騰OLLVMNative代碼保護(hù)的痛點(diǎn)1.1 so庫裸奔的現(xiàn)狀很多應(yīng)用的核心邏輯之所以放到Native層本身就是為了增加逆向難度。但實(shí)際上普通的NDK編譯產(chǎn)物并沒有想象中那么安全。拿一個(gè)未做任何處理的so文件用常見逆向工具打開函數(shù)的導(dǎo)入導(dǎo)出表、符號名、跳轉(zhuǎn)邏輯基本都是直接可讀的。如果開發(fā)者在編譯時(shí)沒加-fvisibilityhidden甚至保留了完整符號表那基本等于把設(shè)計(jì)圖紙也一并交了出去。另一個(gè)容易被忽視的問題是邏輯結(jié)構(gòu)。即便去掉符號表匯編層面的指令序列仍然是有規(guī)律可循的。熟悉ARM匯編的人可以通過連續(xù)的條件跳轉(zhuǎn)、循環(huán)結(jié)構(gòu)、函數(shù)調(diào)用關(guān)系反推算法邏輯。換句話說普通編譯只是掩蓋了代碼的可讀性并沒有改變代碼的“形態(tài)”。而代碼混淆要做的就是改變形態(tài)把線性的執(zhí)行流程變成網(wǎng)絡(luò)狀把簡單的運(yùn)算變成等價(jià)但復(fù)雜的運(yùn)算。1.2 OLLVM到底做了什么OLLVM的全稱是Obfuscator-LLVM最初是某知名安全團(tuán)隊(duì)在LLVM基礎(chǔ)上做的一套開源混淆框架。它的核心用法不是給你一個(gè)打包工具而是給你一套“能用混淆Pass的編譯器”。你要做的就是用這套編譯器重新編譯原生代碼它會在編譯過程中自動完成混淆而不是在編譯后對二進(jìn)制做patch。它最常用的幾套Pass分別是控制流平坦化FLA函數(shù)體變成一個(gè)大循環(huán)加狀態(tài)分發(fā)器的結(jié)構(gòu)原來的if/else、循環(huán)邏輯全被拍平。分析的人看到的是一個(gè)巨大的switch-case調(diào)度器。虛假控制流BCF插入大量不會真實(shí)執(zhí)行的冗余條件分支讓反編譯工具的流程分析直接膨脹甚至卡死。指令替換SUB把簡單的加減乘除、位運(yùn)算換成等價(jià)但更復(fù)雜的計(jì)算序列從指令層面增加閱讀成本。這三套Pass可以獨(dú)立開啟也可以疊加。更關(guān)鍵的是OLLVM保留了LLVM的跨平臺能力這意味著它不光能編Android的ARM架構(gòu)也可以編iOS、桌面甚至嵌入式目標(biāo)。對Android安全領(lǐng)域來說它一直是Native層代碼保護(hù)的經(jīng)典方案。1.3 為什么自己構(gòu)建而不是拿現(xiàn)成的市面上很多商業(yè)加固方案都內(nèi)嵌了類似的編譯器混淆能力但如果你有自己的SDK或者專用算法庫直接用第三方加固平臺往往意味著把源碼編譯環(huán)境交給別人而且每次出包都要上傳、加密、下載調(diào)試鏈路拉長。自己構(gòu)建OLLVM工具鏈本質(zhì)上就是把混淆能力固化到本地構(gòu)建流程里一次搭好之后每次出包都是本地編譯產(chǎn)物配合自己的構(gòu)建腳本和簽名方案非常方便。另一方面自建工具鏈也方便二次定制。OLLVM雖然是開源框架但原始版本停留在LLVM 4.0時(shí)期很多新ARM指令、新ABI適配和編譯器優(yōu)化都跟不上。如果你后續(xù)想自己加一個(gè)專用Pass比如字符串加密、整數(shù)運(yùn)算編碼、函數(shù)調(diào)用花指令普通的商業(yè)加固平臺做不到只有自建的編譯器源碼才能讓你加得進(jìn)去。這也是很多安全團(tuán)隊(duì)堅(jiān)持本地工具鏈的根本原因。2. 環(huán)境準(zhǔn)備與工具鏈選型2.1 Ubuntu 20.04上的基礎(chǔ)依賴構(gòu)建OLLVM本質(zhì)上就是在構(gòu)建一個(gè)LLVM編譯器所以對系統(tǒng)的要求和你編譯普通C/C項(xiàng)目差不多。需要準(zhǔn)備的基礎(chǔ)依賴包括構(gòu)建工具集、CMake和Python。Ubuntu 20.04默認(rèn)源里就有這些包直接通過apt安裝就行sudo apt update sudo apt install build-essential cmake git python3 ninja-build libffi-dev libedit-dev這里有兩個(gè)細(xì)節(jié)值得說。第一個(gè)是CMake版本Ubuntu 20.04自帶的CMake是3.16版本構(gòu)建OLLVM 4.0完全夠用不需要折騰源碼安裝新版CMake。第二個(gè)是內(nèi)存和CPU核心數(shù)。LLVM全家桶編譯非常吃資源如果機(jī)器是8G內(nèi)存建議編譯的時(shí)候限制并行任務(wù)數(shù)不然很容易出現(xiàn)內(nèi)存耗盡被系統(tǒng)殺掉的情況。2.2 OLLVM源碼獲取與分支選擇OLLVM的源碼托管在GitHub它和LLVM官方倉庫最大的區(qū)別就是多了混淆相關(guān)的Pass實(shí)現(xiàn)。拉取源碼時(shí)要注意分支選擇OLLVM官方的混淆特性集中在llvm-4.0分支上git clone -b llvm-4.0 https://github.com/obfuscator-llvm/obfuscator.git拉下來之后目錄結(jié)構(gòu)看起來和普通LLVM源碼是一模一樣的但多了一個(gè)Obfuscator相關(guān)目錄里面就是各個(gè)混淆Pass的源碼實(shí)現(xiàn)。不要小看這個(gè)分支選擇如果你直接拉默認(rèn)分支可能拉到的是沒有任何混淆Pass的版本編譯出來和官方LLVM沒區(qū)別。初次接觸的人經(jīng)常有一個(gè)疑問為什么不用新版的LLVM因?yàn)镺LLVM的混淆Pass在LLVM 4.0之后沒有跟隨上游更新社區(qū)里雖然有一些移植到更高版本的fork但穩(wěn)定性普遍不如原始的llvm-4.0分支。對生產(chǎn)環(huán)境來說穩(wěn)定優(yōu)先我最終選定的是llvm-4.0分支。2.3 NDK版本匹配最容易踩的隱形坑這一節(jié)是整個(gè)工具鏈搭建里最容易被忽略、卻最容易讓人卡住的點(diǎn)。OLLVM是LLVM 4.0的衍生物而Android NDK從r17之后全面切換到更新的Clang并移除了老舊的GCC工具鏈。如果你拿一個(gè)全新的NDK比如r23、r25去對接OLLVM大概率會碰到系統(tǒng)頭文件不兼容、鏈接器版本不匹配、內(nèi)建編譯器宏定義缺失等一系列問題。我實(shí)測下來與OLLVM配合最穩(wěn)的是NDK r15c或r16b。這兩個(gè)版本里的Clang組件和LLVM 4.0同屬一個(gè)時(shí)代sysroot、libc、鏈接器都能對得上。你可以在Android Studio的SDK Manager里直接安裝指定版本的NDK也可以在項(xiàng)目的build.gradle里顯式鎖定android { ndkVersion 15.2.4203891 }這里寫的“15.2.4203891”就是NDK r15c對應(yīng)的版本號。版本鎖定很關(guān)鍵否則Android Studio在同步工程時(shí)會自動拉一個(gè)最新版NDK最后編譯階段報(bào)出各種晦澀的找不到頭文件錯(cuò)誤排查起來非常痛苦。2.4 為什么不直接拿官方LLVM編譯這個(gè)問題值得展開說。LLVM官方主線其實(shí)也帶了一些基礎(chǔ)的混淆相關(guān)工具比如控制流圖分析、指令調(diào)度優(yōu)化等但這些和OLLVM的核心訴求不是一回事。官方LLVM的定位是通用編譯器優(yōu)化它的目標(biāo)是讓代碼跑得更快、體積更小而OLLVM的目標(biāo)是讓代碼更難被讀懂兩者在優(yōu)化方向上甚至是有沖突的。舉個(gè)例子LLVM的優(yōu)化Pass會盡量消除冗余跳轉(zhuǎn)和合并基本塊而OLLVM的控制流平坦化恰恰要插入大量狀態(tài)變量和分發(fā)跳轉(zhuǎn)這在常規(guī)優(yōu)化看來完全是負(fù)優(yōu)化。所以你不能用官方LLVM加參數(shù)來模擬OLLVM必須用內(nèi)置了混淆Pass的編譯器版本。3. 核心構(gòu)建流程從源碼到混淆工具的產(chǎn)出3.1 CMake配置與構(gòu)建參數(shù)源碼拉下來之后推薦使用獨(dú)立的build目錄進(jìn)行構(gòu)建這樣源目錄不會混入構(gòu)建產(chǎn)物。進(jìn)入源碼目錄后執(zhí)行mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DLLVM_TARGETS_TO_BUILDX86;ARM;AArch64 -DLLVM_ENABLE_ASSERTIONSON ..解釋一下幾個(gè)重點(diǎn)配置項(xiàng)的含義。CMAKE_BUILD_TYPERelease表示編譯LLVM本身時(shí)開啟優(yōu)化這樣構(gòu)建出的OLLVM工具鏈運(yùn)行效率更高編譯Android代碼時(shí)速度更快。LLVM_TARGETS_TO_BUILD指定了需要生成的架構(gòu)支持這里填入X86、ARM、AArch64三個(gè)目標(biāo)X86是留給Ubuntu宿主機(jī)運(yùn)行的ARM和AArch64是Android設(shè)備需要的分別對應(yīng)32位和64位架構(gòu)。如果你明確只做64位應(yīng)用可以只保留X86;AArch64構(gòu)建時(shí)間和產(chǎn)物體積都會小一些。但做Android安全兼容測試時(shí)建議還是保留ARM因?yàn)槭忻嫔线€有不少armeabi-v7a的存量設(shè)備。LLVM_ENABLE_ASSERTIONSON這個(gè)選項(xiàng)很多人會漏掉。它在LLVM內(nèi)部啟用斷言檢查方便調(diào)試編譯器自身的問題。發(fā)布工具鏈時(shí)通常建議開上一旦混淆Pass內(nèi)部有邏輯錯(cuò)誤編譯階段會直接暴露而不是編譯出一個(gè)損壞的so到運(yùn)行期才崩潰。3.2 開始編譯以及資源控制配置完成之后正式進(jìn)入編譯階段make -j8這里的-j參數(shù)需要根據(jù)機(jī)器配置調(diào)整。我的經(jīng)驗(yàn)是每2G內(nèi)存配一個(gè)并行任務(wù)比較穩(wěn)妥比如8G內(nèi)存開-j416G內(nèi)存開-j8甚至-j12。OLLVM完整編譯在四核心八線程機(jī)器上大約需要30到45分鐘具體時(shí)間取決于CPU主頻和磁盤性能。如果機(jī)器內(nèi)存確實(shí)緊張可以考慮降低并行數(shù)但不要試圖用make -j1硬扛那樣等待時(shí)間會非常漫長。另外編譯過程中如果看到某個(gè)編譯任務(wù)出現(xiàn)internal compiler error或者被Killed基本就是內(nèi)存不足要么降低并行數(shù)要么關(guān)掉一些常駐內(nèi)存的進(jìn)程。構(gòu)建完成后重點(diǎn)關(guān)注build/bin目錄下生成的幾個(gè)可執(zhí)行文件。最重要的是clang和clang它們就是帶混淆Pass的編譯器本體。接下來可以通過執(zhí)行./bin/clang --version確認(rèn)版本信息如果輸出中包含clang version 4.0相關(guān)字樣說明工具鏈本體已經(jīng)構(gòu)建成功。3.3 工具鏈完整性驗(yàn)證拿到clang之后不要急著接入Android工程先做一個(gè)最小驗(yàn)證。比如寫一個(gè)簡單的C文件用OLLVM clang直接編譯成目標(biāo)平臺的匯編確認(rèn)混淆Pass能正常工作echo int foo(int a, int b) { return a b; } test.c ./build/bin/clang -target aarch64-linux-android -mllvm -sub -c test.c -o test.o執(zhí)行完之后用工具檢查目標(biāo)文件llvm-objdump -d test.o。如果沒有這個(gè)工具也可以用objdump。看到匯編里出現(xiàn)多段復(fù)雜的位運(yùn)算替代簡單的加法指令說明指令替換Pass生效。如果直接看到add指令說明參數(shù)沒傳進(jìn)去或者工具鏈有問題。這類最小驗(yàn)證非常重要它能幫你區(qū)分兩件事到底是OLLVM沒構(gòu)建成功還是后面接入Android工程時(shí)參數(shù)配置錯(cuò)了。我見過太多人一次性把工具鏈接入大工程結(jié)果出現(xiàn)問題之后根本不知道去哪里排查最后把NDK、CMake、編譯器全部重來一遍浪費(fèi)大量時(shí)間。4. Android項(xiàng)目接入CMake集成與混淆參數(shù)實(shí)戰(zhàn)4.1 全局替換與項(xiàng)目級指定兩個(gè)方案對比OLLVM工具鏈構(gòu)建好之后接入Android項(xiàng)目有兩種思路。第一種是直接替換NDK里的clang也就是把OLLVM產(chǎn)物放到$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/目錄下覆蓋原有的編譯器。這種方式的好處是Android Studio構(gòu)建時(shí)不需要改任何配置所有C/C代碼自動走OLLVM編譯壞處是極其危險(xiǎn)一旦某個(gè)版本出問題整個(gè)NDK都被污染而且不同工程想用不同混淆策略就無法實(shí)現(xiàn)。第二種是項(xiàng)目級配置在CMakeLists里指定編譯器路徑。我的建議是如果想要一份干凈可控的產(chǎn)物一定要用第二種方案。Android Studio現(xiàn)在原生支持通過CMake配置外部編譯器不需要全局去動NDK目錄。4.2 用CMakeLists鎖定OLLVM編譯器在項(xiàng)目級的CMakeLists.txt里只需要覆蓋幾個(gè)核心變量就可以把默認(rèn)編譯器切換到OLLVMset(NDK_HOME $ENV{ANDROID_NDK_HOME}) set(OLLVM_HOME /your/path/to/ollvm/build) set(CMAKE_C_COMPILER ${OLLVM_HOME}/bin/clang) set(CMAKE_CXX_COMPILER ${OLLVM_HOME}/bin/clang) set(CMAKE_SYSROOT ${NDK_HOME}/sysroot) set(CMAKE_C_COMPILER_TARGET aarch64-linux-android) set(CMAKE_CXX_COMPILER_TARGET aarch64-linux-android) set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -gcc-toolchain ${NDK_HOME}/toolchains/llvm/prebuilt/linux-x86_64 --sysroot${NDK_HOME}/sysroot) set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -gcc-toolchain ${NDK_HOME}/toolchains/llvm/prebuilt/linux-x86_64 --sysroot${NDK_HOME}/sysroot)這段配置里幾個(gè)關(guān)鍵點(diǎn)要解釋清楚。CMAKE_SYSROOT指向的是NDK提供的系統(tǒng)根目錄里面包含了Android平臺的系統(tǒng)頭文件和庫文件沒有它編譯器根本不知道目標(biāo)平臺的API定義。-gcc-toolchain則是指向NDK自帶的GCC兼容工具鏈主要作用是告訴編譯器去哪里找內(nèi)建的庫搜索路徑。不同ABI需要改CMAKE_C_COMPILER_TARGET的值對應(yīng)關(guān)系如下ABICMAKE_C_COMPILER_TARGETarm64-v8aaarch64-linux-androidarmeabi-v7aarmv7a-linux-androideabix86i686-linux-androidx86_64x86_64-linux-android如果你的項(xiàng)目同時(shí)打多個(gè)ABI一般是在build.gradle的externalNativeBuild段通過targets配置對應(yīng)的CMake參數(shù)。4.3 混淆Pass怎么開梯度策略非常關(guān)鍵編譯器切換到OLLVM之后不會自動混淆。你必須在編譯選項(xiàng)里顯式開啟對應(yīng)的Pass。三種經(jīng)典Pass的命令行參數(shù)如下-mllvm -fla # 控制流平坦化 -mllvm -bcf -mllvm -bcf_prob60 # 虛假控制流概率60% -mllvm -sub -mllvm -sub_loop3 # 指令替換循環(huán)3次在CMake里可以對特定的本源文件開啟混淆而不是一股腦全部加上set_source_files_properties( native-lib.cpp PROPERTIES COMPILE_FLAGS -mllvm -fla -mllvm -bcf )強(qiáng)烈建議用這種按文件粒度開啟的方式。原因很簡單混淆是有代價(jià)的?？刂屏髌教够瘯岩粋€(gè)簡單的函數(shù)體擴(kuò)大數(shù)倍甚至十幾倍指令替換會增加CPU計(jì)算時(shí)間虛假控制流會讓so體積明顯膨脹。如果全工程無差別開啟最直接的后果就是包體暴漲、性能下降還可能出現(xiàn)個(gè)別函數(shù)混淆后觸發(fā)編譯器后端的問題。我的典型做法是先對核心加解密函數(shù)、關(guān)鍵校驗(yàn)函數(shù)單獨(dú)開啟-fla和-sub確認(rèn)穩(wěn)定后再對一些普通輔助函數(shù)開-bcf。業(yè)務(wù)代碼保持不混淆否則每次發(fā)版都會收到各種莫名其妙的性能客訴。4.4 so產(chǎn)物的符號處理代碼經(jīng)過混淆只能讓分析者看不懂邏輯但如果so導(dǎo)出表里還留著函數(shù)名那就等于告訴別人“重點(diǎn)看這里”。所以編譯完成后一定要做符號表清理常規(guī)做法是加-fvisibilityhidden默認(rèn)隱藏所有符號只對JNI導(dǎo)出函數(shù)單獨(dú)標(biāo)注可見性。示例代碼如下__attribute__((visibility(default))) extern C JNIEXPORT jstring JNICALL Java_com_example_app_NativeBridge_getKey(JNIEnv* env, jobject thiz) { // only this function is exported }編譯完成后還可以用NDK自帶的llvm-strip工具去掉剩余符號信息${NDK_HOME}/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-strip --strip-unneeded libnative-lib.sostrip之后再檢查導(dǎo)出表應(yīng)該只剩下JNI標(biāo)準(zhǔn)接口和少量動態(tài)依賴符號。到這一步一個(gè)可發(fā)布的混淆so才真正具備防護(hù)價(jià)值。5. 常見問題與排查實(shí)錄5.1 編譯期間的高頻報(bào)錯(cuò)對照整個(gè)搭建過程中遇到的最典型的幾個(gè)問題我做了一個(gè)速查表按現(xiàn)象、原因、解決方式三列給出方便直接對照現(xiàn)象原因解決方法fatal error: sys/cdefs.h file not found編譯器沒有正確指定sysroot在CMake或編譯命令里加--sysroot$NDK_HOME/sysrootunable to find target或架構(gòu)解析失敗CMAKE_C_COMPILER_TARGET沒有配置或拼寫錯(cuò)誤按上文ABI對照表檢查target三元組unknown argument: -mllvm混淆參數(shù)通過CMAKE_C_FLAGS傳入時(shí)位置不對被鏈接器解析了確保-mllvm類型的參數(shù)附加在COMPILE_FLAGS而不是LINK_FLAGS編譯過程中進(jìn)程被Killed內(nèi)存不足默認(rèn)并行任務(wù)太多降低make -j數(shù)量比如從-j8降到-j4鏈接時(shí)找不到libunwind或libc相關(guān)符號NDK版本和OLLVM不匹配換NDK r15c/r16b并統(tǒng)一版本安裝好的OLLVM clang無法運(yùn)行依賴庫缺失或動態(tài)鏈接異常執(zhí)行l(wèi)dd bin/clang檢查依賴安裝libffi、libedit等庫5.2 混淆后的so在真機(jī)上崩潰這是一個(gè)非常讓人頭大的問題編譯沒報(bào)錯(cuò)構(gòu)建也成功一裝到真機(jī)上直接崩潰但是不混淆的版本一切正常。根據(jù)經(jīng)驗(yàn)90%以上這類問題原因集中在幾個(gè)地方。第一個(gè)是浮點(diǎn)和內(nèi)聯(lián)匯編。OLLVM在某些Pass組合下會把浮點(diǎn)運(yùn)算改寫而目標(biāo)Android設(shè)備的老舊GPU/CPU對異常浮點(diǎn)處理不當(dāng)時(shí)會產(chǎn)生SIGFPE。這種情況下建議先把-sub關(guān)閉逐步添加Pass找到具體哪個(gè)Pass觸發(fā)問題。第二個(gè)是?？臻g和基本塊爆炸?？刂屏髌教够谀承┐蠛瘮?shù)上會生成巨大的狀態(tài)機(jī)導(dǎo)致棧使用量飆升進(jìn)而觸發(fā)棧溢出。解決方案是排除體積過于巨大的函數(shù)或者在大函數(shù)上只開-bcf不開-fla。第三個(gè)是O2優(yōu)化級別與混淆Pass的相互影響。常見的組合是編譯命令帶了-O2混淆后再優(yōu)化導(dǎo)致某些尾調(diào)用被改寫成跳轉(zhuǎn)破壞了混淆的結(jié)構(gòu)。一般做法是先-O0驗(yàn)證功能再開-O1或者-O2做最終產(chǎn)物。5.3 性能與安全強(qiáng)度的平衡建議關(guān)于混淆強(qiáng)度這是最容易被忽略的經(jīng)驗(yàn)問題。新人往往覺得Pass開得越全越好概率越高越好其實(shí)混淆的收益在超過一個(gè)閾值后增長緩慢成本卻直線上升。比如-bcf_prob100和-bcf_prob60對分析者的困擾程度其實(shí)是差不多的但前者的so體積可能是后者的兩倍以上運(yùn)行耗時(shí)也更高。我的經(jīng)驗(yàn)是核心機(jī)密算法函數(shù)用-fla和-sub普通的協(xié)議封裝函數(shù)用-bcf難度已經(jīng)足夠。只有當(dāng)你確定某個(gè)函數(shù)是攻擊者的主攻目標(biāo)時(shí)才需要把三種Pass全部拉滿。還有一個(gè)細(xì)節(jié)是關(guān)于調(diào)試信息的?；煜蟮陌绻€留著調(diào)試符號等于一切白做。Release構(gòu)建里一定要設(shè)CMAKE_BUILD_TYPERelease同時(shí)清理DWARF信息和注釋相關(guān)的字符串。5.4 自動化打包鏈路的關(guān)鍵一環(huán)工具鏈搭好之后最好把它固化進(jìn)構(gòu)建腳本避免每次手動改環(huán)境變量?？梢栽陧?xiàng)目的根目錄放一個(gè)ollvm.env里面統(tǒng)一導(dǎo)出路徑。在構(gòu)建腳本里source一下確保CI環(huán)境和本地構(gòu)建環(huán)境一致。如果團(tuán)隊(duì)里多人協(xié)作一定統(tǒng)一NDK版本和OLLVM構(gòu)建版本并把兩個(gè)路徑通過環(huán)境變量而不是硬編碼的方式傳入項(xiàng)目。否則每個(gè)人的機(jī)器編譯出的so行為可能不一致排查問題時(shí)各說各話。我個(gè)人在實(shí)際操作中的體會是這套鏈路最花時(shí)間的從來不是OLLVM本身的編譯而是NDK版本和編譯器路徑的匹配。很多崩潰問題排查到最后發(fā)現(xiàn)源頭只是老版clang和新版sysroot之間的ABI不兼容。如果你也想在自己的SDK里試驗(yàn)建議從arm64-v8a一個(gè)ABI、一個(gè)源文件、一個(gè)混淆Pass開始先跑通全流程再逐步鋪開。最后想再提醒一句OLLVM解決的是“代碼被人讀懂”的問題解決不了“密鑰怎么藏、校驗(yàn)怎么做”這些業(yè)務(wù)層面的安全設(shè)計(jì)兩者是配合關(guān)系不是替代關(guān)系。 OLLVM源碼構(gòu)建指南：Ubuntu 20.04打造Android NDK混淆工具鏈
搞Android Native層開發(fā)的人大概率都遇到過這種尷尬場景自己辛辛苦苦寫的核心邏輯編譯成so扔進(jìn)APK里別人拖出來用反編譯工具一看函數(shù)名、調(diào)用關(guān)系、常量字符串清清楚楚核心算法幾乎是裸奔狀態(tài)。如果你正在做的是SDK保護(hù)、游戲反外掛、或者是收費(fèi)算法防破解這種裸奔基本等于送人頭。OLLVM就是在這一層做文章的。它是LLVM的一個(gè)衍生分支在編譯器層面加入了幾套代碼混淆Pass可以直接把產(chǎn)出so的控制流、指令形態(tài)、偽代碼結(jié)構(gòu)全部打亂不需要改動你的業(yè)務(wù)代碼。這篇實(shí)戰(zhàn)記錄要解決的問題很具體在一臺Ubuntu 20.04上從源碼構(gòu)建一套能用于Android NDK的OLLVM工具鏈然后讓項(xiàng)目的CMake構(gòu)建走這套工具鏈最終產(chǎn)出帶混淆效果的so庫。適合正在做App加固、SDK安全、以及想把代碼混淆工具鏈真正落地到日常構(gòu)建流程里的開發(fā)者參考。1. 為什么要折騰OLLVMNative代碼保護(hù)的痛點(diǎn)1.1 so庫裸奔的現(xiàn)狀很多應(yīng)用的核心邏輯之所以放到Native層本身就是為了增加逆向難度。但實(shí)際上普通的NDK編譯產(chǎn)物并沒有想象中那么安全。拿一個(gè)未做任何處理的so文件用常見逆向工具打開函數(shù)的導(dǎo)入導(dǎo)出表、符號名、跳轉(zhuǎn)邏輯基本都是直接可讀的。如果開發(fā)者在編譯時(shí)沒加-fvisibilityhidden甚至保留了完整符號表那基本等于把設(shè)計(jì)圖紙也一并交了出去。另一個(gè)容易被忽視的問題是邏輯結(jié)構(gòu)。即便去掉符號表匯編層面的指令序列仍然是有規(guī)律可循的。熟悉ARM匯編的人可以通過連續(xù)的條件跳轉(zhuǎn)、循環(huán)結(jié)構(gòu)、函數(shù)調(diào)用關(guān)系反推算法邏輯。換句話說普通編譯只是掩蓋了代碼的可讀性并沒有改變代碼的“形態(tài)”。而代碼混淆要做的就是改變形態(tài)把線性的執(zhí)行流程變成網(wǎng)絡(luò)狀把簡單的運(yùn)算變成等價(jià)但復(fù)雜的運(yùn)算。1.2 OLLVM到底做了什么OLLVM的全稱是Obfuscator-LLVM最初是某知名安全團(tuán)隊(duì)在LLVM基礎(chǔ)上做的一套開源混淆框架。它的核心用法不是給你一個(gè)打包工具而是給你一套“能用混淆Pass的編譯器”。你要做的就是用這套編譯器重新編譯原生代碼它會在編譯過程中自動完成混淆而不是在編譯后對二進(jìn)制做patch。它最常用的幾套Pass分別是控制流平坦化FLA函數(shù)體變成一個(gè)大循環(huán)加狀態(tài)分發(fā)器的結(jié)構(gòu)原來的if/else、循環(huán)邏輯全被拍平。分析的人看到的是一個(gè)巨大的switch-case調(diào)度器。虛假控制流BCF插入大量不會真實(shí)執(zhí)行的冗余條件分支讓反編譯工具的流程分析直接膨脹甚至卡死。指令替換SUB把簡單的加減乘除、位運(yùn)算換成等價(jià)但更復(fù)雜的計(jì)算序列從指令層面增加閱讀成本。這三套Pass可以獨(dú)立開啟也可以疊加。更關(guān)鍵的是OLLVM保留了LLVM的跨平臺能力這意味著它不光能編Android的ARM架構(gòu)也可以編iOS、桌面甚至嵌入式目標(biāo)。對Android安全領(lǐng)域來說它一直是Native層代碼保護(hù)的經(jīng)典方案。1.3 為什么自己構(gòu)建而不是拿現(xiàn)成的市面上很多商業(yè)加固方案都內(nèi)嵌了類似的編譯器混淆能力但如果你有自己的SDK或者專用算法庫直接用第三方加固平臺往往意味著把源碼編譯環(huán)境交給別人而且每次出包都要上傳、加密、下載調(diào)試鏈路拉長。自己構(gòu)建OLLVM工具鏈本質(zhì)上就是把混淆能力固化到本地構(gòu)建流程里一次搭好之后每次出包都是本地編譯產(chǎn)物配合自己的構(gòu)建腳本和簽名方案非常方便。另一方面自建工具鏈也方便二次定制。OLLVM雖然是開源框架但原始版本停留在LLVM 4.0時(shí)期很多新ARM指令、新ABI適配和編譯器優(yōu)化都跟不上。如果你后續(xù)想自己加一個(gè)專用Pass比如字符串加密、整數(shù)運(yùn)算編碼、函數(shù)調(diào)用花指令普通的商業(yè)加固平臺做不到只有自建的編譯器源碼才能讓你加得進(jìn)去。這也是很多安全團(tuán)隊(duì)堅(jiān)持本地工具鏈的根本原因。2. 環(huán)境準(zhǔn)備與工具鏈選型2.1 Ubuntu 20.04上的基礎(chǔ)依賴構(gòu)建OLLVM本質(zhì)上就是在構(gòu)建一個(gè)LLVM編譯器所以對系統(tǒng)的要求和你編譯普通C/C項(xiàng)目差不多。需要準(zhǔn)備的基礎(chǔ)依賴包括構(gòu)建工具集、CMake和Python。Ubuntu 20.04默認(rèn)源里就有這些包直接通過apt安裝就行sudo apt update sudo apt install build-essential cmake git python3 ninja-build libffi-dev libedit-dev這里有兩個(gè)細(xì)節(jié)值得說。第一個(gè)是CMake版本Ubuntu 20.04自帶的CMake是3.16版本構(gòu)建OLLVM 4.0完全夠用不需要折騰源碼安裝新版CMake。第二個(gè)是內(nèi)存和CPU核心數(shù)。LLVM全家桶編譯非常吃資源如果機(jī)器是8G內(nèi)存建議編譯的時(shí)候限制并行任務(wù)數(shù)不然很容易出現(xiàn)內(nèi)存耗盡被系統(tǒng)殺掉的情況。2.2 OLLVM源碼獲取與分支選擇OLLVM的源碼托管在GitHub它和LLVM官方倉庫最大的區(qū)別就是多了混淆相關(guān)的Pass實(shí)現(xiàn)。拉取源碼時(shí)要注意分支選擇OLLVM官方的混淆特性集中在llvm-4.0分支上git clone -b llvm-4.0 https://github.com/obfuscator-llvm/obfuscator.git拉下來之后目錄結(jié)構(gòu)看起來和普通LLVM源碼是一模一樣的但多了一個(gè)Obfuscator相關(guān)目錄里面就是各個(gè)混淆Pass的源碼實(shí)現(xiàn)。不要小看這個(gè)分支選擇如果你直接拉默認(rèn)分支可能拉到的是沒有任何混淆Pass的版本編譯出來和官方LLVM沒區(qū)別。初次接觸的人經(jīng)常有一個(gè)疑問為什么不用新版的LLVM因?yàn)镺LLVM的混淆Pass在LLVM 4.0之后沒有跟隨上游更新社區(qū)里雖然有一些移植到更高版本的fork但穩(wěn)定性普遍不如原始的llvm-4.0分支。對生產(chǎn)環(huán)境來說穩(wěn)定優(yōu)先我最終選定的是llvm-4.0分支。2.3 NDK版本匹配最容易踩的隱形坑這一節(jié)是整個(gè)工具鏈搭建里最容易被忽略、卻最容易讓人卡住的點(diǎn)。OLLVM是LLVM 4.0的衍生物而Android NDK從r17之后全面切換到更新的Clang并移除了老舊的GCC工具鏈。如果你拿一個(gè)全新的NDK比如r23、r25去對接OLLVM大概率會碰到系統(tǒng)頭文件不兼容、鏈接器版本不匹配、內(nèi)建編譯器宏定義缺失等一系列問題。我實(shí)測下來與OLLVM配合最穩(wěn)的是NDK r15c或r16b。這兩個(gè)版本里的Clang組件和LLVM 4.0同屬一個(gè)時(shí)代sysroot、libc、鏈接器都能對得上。你可以在Android Studio的SDK Manager里直接安裝指定版本的NDK也可以在項(xiàng)目的build.gradle里顯式鎖定android { ndkVersion 15.2.4203891 }這里寫的“15.2.4203891”就是NDK r15c對應(yīng)的版本號。版本鎖定很關(guān)鍵否則Android Studio在同步工程時(shí)會自動拉一個(gè)最新版NDK最后編譯階段報(bào)出各種晦澀的找不到頭文件錯(cuò)誤排查起來非常痛苦。2.4 為什么不直接拿官方LLVM編譯這個(gè)問題值得展開說。LLVM官方主線其實(shí)也帶了一些基礎(chǔ)的混淆相關(guān)工具比如控制流圖分析、指令調(diào)度優(yōu)化等但這些和OLLVM的核心訴求不是一回事。官方LLVM的定位是通用編譯器優(yōu)化它的目標(biāo)是讓代碼跑得更快、體積更小而OLLVM的目標(biāo)是讓代碼更難被讀懂兩者在優(yōu)化方向上甚至是有沖突的。舉個(gè)例子LLVM的優(yōu)化Pass會盡量消除冗余跳轉(zhuǎn)和合并基本塊而OLLVM的控制流平坦化恰恰要插入大量狀態(tài)變量和分發(fā)跳轉(zhuǎn)這在常規(guī)優(yōu)化看來完全是負(fù)優(yōu)化。所以你不能用官方LLVM加參數(shù)來模擬OLLVM必須用內(nèi)置了混淆Pass的編譯器版本。3. 核心構(gòu)建流程從源碼到混淆工具的產(chǎn)出3.1 CMake配置與構(gòu)建參數(shù)源碼拉下來之后推薦使用獨(dú)立的build目錄進(jìn)行構(gòu)建這樣源目錄不會混入構(gòu)建產(chǎn)物。進(jìn)入源碼目錄后執(zhí)行mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DLLVM_TARGETS_TO_BUILDX86;ARM;AArch64 -DLLVM_ENABLE_ASSERTIONSON ..解釋一下幾個(gè)重點(diǎn)配置項(xiàng)的含義。CMAKE_BUILD_TYPERelease表示編譯LLVM本身時(shí)開啟優(yōu)化這樣構(gòu)建出的OLLVM工具鏈運(yùn)行效率更高編譯Android代碼時(shí)速度更快。LLVM_TARGETS_TO_BUILD指定了需要生成的架構(gòu)支持這里填入X86、ARM、AArch64三個(gè)目標(biāo)X86是留給Ubuntu宿主機(jī)運(yùn)行的ARM和AArch64是Android設(shè)備需要的分別對應(yīng)32位和64位架構(gòu)。如果你明確只做64位應(yīng)用可以只保留X86;AArch64構(gòu)建時(shí)間和產(chǎn)物體積都會小一些。但做Android安全兼容測試時(shí)建議還是保留ARM因?yàn)槭忻嫔线€有不少armeabi-v7a的存量設(shè)備。LLVM_ENABLE_ASSERTIONSON這個(gè)選項(xiàng)很多人會漏掉。它在LLVM內(nèi)部啟用斷言檢查方便調(diào)試編譯器自身的問題。發(fā)布工具鏈時(shí)通常建議開上一旦混淆Pass內(nèi)部有邏輯錯(cuò)誤編譯階段會直接暴露而不是編譯出一個(gè)損壞的so到運(yùn)行期才崩潰。3.2 開始編譯以及資源控制配置完成之后正式進(jìn)入編譯階段make -j8這里的-j參數(shù)需要根據(jù)機(jī)器配置調(diào)整。我的經(jīng)驗(yàn)是每2G內(nèi)存配一個(gè)并行任務(wù)比較穩(wěn)妥比如8G內(nèi)存開-j416G內(nèi)存開-j8甚至-j12。OLLVM完整編譯在四核心八線程機(jī)器上大約需要30到45分鐘具體時(shí)間取決于CPU主頻和磁盤性能。如果機(jī)器內(nèi)存確實(shí)緊張可以考慮降低并行數(shù)但不要試圖用make -j1硬扛那樣等待時(shí)間會非常漫長。另外編譯過程中如果看到某個(gè)編譯任務(wù)出現(xiàn)internal compiler error或者被Killed基本就是內(nèi)存不足要么降低并行數(shù)要么關(guān)掉一些常駐內(nèi)存的進(jìn)程。構(gòu)建完成后重點(diǎn)關(guān)注build/bin目錄下生成的幾個(gè)可執(zhí)行文件。最重要的是clang和clang它們就是帶混淆Pass的編譯器本體。接下來可以通過執(zhí)行./bin/clang --version確認(rèn)版本信息如果輸出中包含clang version 4.0相關(guān)字樣說明工具鏈本體已經(jīng)構(gòu)建成功。3.3 工具鏈完整性驗(yàn)證拿到clang之后不要急著接入Android工程先做一個(gè)最小驗(yàn)證。比如寫一個(gè)簡單的C文件用OLLVM clang直接編譯成目標(biāo)平臺的匯編確認(rèn)混淆Pass能正常工作echo int foo(int a, int b) { return a b; } test.c ./build/bin/clang -target aarch64-linux-android -mllvm -sub -c test.c -o test.o執(zhí)行完之后用工具檢查目標(biāo)文件llvm-objdump -d test.o。如果沒有這個(gè)工具也可以用objdump。看到匯編里出現(xiàn)多段復(fù)雜的位運(yùn)算替代簡單的加法指令說明指令替換Pass生效。如果直接看到add指令說明參數(shù)沒傳進(jìn)去或者工具鏈有問題。這類最小驗(yàn)證非常重要它能幫你區(qū)分兩件事到底是OLLVM沒構(gòu)建成功還是后面接入Android工程時(shí)參數(shù)配置錯(cuò)了。我見過太多人一次性把工具鏈接入大工程結(jié)果出現(xiàn)問題之后根本不知道去哪里排查最后把NDK、CMake、編譯器全部重來一遍浪費(fèi)大量時(shí)間。4. Android項(xiàng)目接入CMake集成與混淆參數(shù)實(shí)戰(zhàn)4.1 全局替換與項(xiàng)目級指定兩個(gè)方案對比OLLVM工具鏈構(gòu)建好之后接入Android項(xiàng)目有兩種思路。第一種是直接替換NDK里的clang也就是把OLLVM產(chǎn)物放到$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/目錄下覆蓋原有的編譯器。這種方式的好處是Android Studio構(gòu)建時(shí)不需要改任何配置所有C/C代碼自動走OLLVM編譯壞處是極其危險(xiǎn)一旦某個(gè)版本出問題整個(gè)NDK都被污染而且不同工程想用不同混淆策略就無法實(shí)現(xiàn)。第二種是項(xiàng)目級配置在CMakeLists里指定編譯器路徑。我的建議是如果想要一份干凈可控的產(chǎn)物一定要用第二種方案。Android Studio現(xiàn)在原生支持通過CMake配置外部編譯器不需要全局去動NDK目錄。4.2 用CMakeLists鎖定OLLVM編譯器在項(xiàng)目級的CMakeLists.txt里只需要覆蓋幾個(gè)核心變量就可以把默認(rèn)編譯器切換到OLLVMset(NDK_HOME $ENV{ANDROID_NDK_HOME}) set(OLLVM_HOME /your/path/to/ollvm/build) set(CMAKE_C_COMPILER ${OLLVM_HOME}/bin/clang) set(CMAKE_CXX_COMPILER ${OLLVM_HOME}/bin/clang) set(CMAKE_SYSROOT ${NDK_HOME}/sysroot) set(CMAKE_C_COMPILER_TARGET aarch64-linux-android) set(CMAKE_CXX_COMPILER_TARGET aarch64-linux-android) set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -gcc-toolchain ${NDK_HOME}/toolchains/llvm/prebuilt/linux-x86_64 --sysroot${NDK_HOME}/sysroot) set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -gcc-toolchain ${NDK_HOME}/toolchains/llvm/prebuilt/linux-x86_64 --sysroot${NDK_HOME}/sysroot)這段配置里幾個(gè)關(guān)鍵點(diǎn)要解釋清楚。CMAKE_SYSROOT指向的是NDK提供的系統(tǒng)根目錄里面包含了Android平臺的系統(tǒng)頭文件和庫文件沒有它編譯器根本不知道目標(biāo)平臺的API定義。-gcc-toolchain則是指向NDK自帶的GCC兼容工具鏈主要作用是告訴編譯器去哪里找內(nèi)建的庫搜索路徑。不同ABI需要改CMAKE_C_COMPILER_TARGET的值對應(yīng)關(guān)系如下ABICMAKE_C_COMPILER_TARGETarm64-v8aaarch64-linux-androidarmeabi-v7aarmv7a-linux-androideabix86i686-linux-androidx86_64x86_64-linux-android如果你的項(xiàng)目同時(shí)打多個(gè)ABI一般是在build.gradle的externalNativeBuild段通過targets配置對應(yīng)的CMake參數(shù)。4.3 混淆Pass怎么開梯度策略非常關(guān)鍵編譯器切換到OLLVM之后不會自動混淆。你必須在編譯選項(xiàng)里顯式開啟對應(yīng)的Pass。三種經(jīng)典Pass的命令行參數(shù)如下-mllvm -fla # 控制流平坦化 -mllvm -bcf -mllvm -bcf_prob60 # 虛假控制流概率60% -mllvm -sub -mllvm -sub_loop3 # 指令替換循環(huán)3次在CMake里可以對特定的本源文件開啟混淆而不是一股腦全部加上set_source_files_properties( native-lib.cpp PROPERTIES COMPILE_FLAGS -mllvm -fla -mllvm -bcf )強(qiáng)烈建議用這種按文件粒度開啟的方式。原因很簡單混淆是有代價(jià)的?？刂屏髌教够瘯岩粋€(gè)簡單的函數(shù)體擴(kuò)大數(shù)倍甚至十幾倍指令替換會增加CPU計(jì)算時(shí)間虛假控制流會讓so體積明顯膨脹。如果全工程無差別開啟最直接的后果就是包體暴漲、性能下降還可能出現(xiàn)個(gè)別函數(shù)混淆后觸發(fā)編譯器后端的問題。我的典型做法是先對核心加解密函數(shù)、關(guān)鍵校驗(yàn)函數(shù)單獨(dú)開啟-fla和-sub確認(rèn)穩(wěn)定后再對一些普通輔助函數(shù)開-bcf。業(yè)務(wù)代碼保持不混淆否則每次發(fā)版都會收到各種莫名其妙的性能客訴。4.4 so產(chǎn)物的符號處理代碼經(jīng)過混淆只能讓分析者看不懂邏輯但如果so導(dǎo)出表里還留著函數(shù)名那就等于告訴別人“重點(diǎn)看這里”。所以編譯完成后一定要做符號表清理常規(guī)做法是加-fvisibilityhidden默認(rèn)隱藏所有符號只對JNI導(dǎo)出函數(shù)單獨(dú)標(biāo)注可見性。示例代碼如下__attribute__((visibility(default))) extern C JNIEXPORT jstring JNICALL Java_com_example_app_NativeBridge_getKey(JNIEnv* env, jobject thiz) { // only this function is exported }編譯完成后還可以用NDK自帶的llvm-strip工具去掉剩余符號信息${NDK_HOME}/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-strip --strip-unneeded libnative-lib.sostrip之后再檢查導(dǎo)出表應(yīng)該只剩下JNI標(biāo)準(zhǔn)接口和少量動態(tài)依賴符號。到這一步一個(gè)可發(fā)布的混淆so才真正具備防護(hù)價(jià)值。5. 常見問題與排查實(shí)錄5.1 編譯期間的高頻報(bào)錯(cuò)對照整個(gè)搭建過程中遇到的最典型的幾個(gè)問題我做了一個(gè)速查表按現(xiàn)象、原因、解決方式三列給出方便直接對照現(xiàn)象原因解決方法fatal error: sys/cdefs.h file not found編譯器沒有正確指定sysroot在CMake或編譯命令里加--sysroot$NDK_HOME/sysrootunable to find target或架構(gòu)解析失敗CMAKE_C_COMPILER_TARGET沒有配置或拼寫錯(cuò)誤按上文ABI對照表檢查target三元組unknown argument: -mllvm混淆參數(shù)通過CMAKE_C_FLAGS傳入時(shí)位置不對被鏈接器解析了確保-mllvm類型的參數(shù)附加在COMPILE_FLAGS而不是LINK_FLAGS編譯過程中進(jìn)程被Killed內(nèi)存不足默認(rèn)并行任務(wù)太多降低make -j數(shù)量比如從-j8降到-j4鏈接時(shí)找不到libunwind或libc相關(guān)符號NDK版本和OLLVM不匹配換NDK r15c/r16b并統(tǒng)一版本安裝好的OLLVM clang無法運(yùn)行依賴庫缺失或動態(tài)鏈接異常執(zhí)行l(wèi)dd bin/clang檢查依賴安裝libffi、libedit等庫5.2 混淆后的so在真機(jī)上崩潰這是一個(gè)非常讓人頭大的問題編譯沒報(bào)錯(cuò)構(gòu)建也成功一裝到真機(jī)上直接崩潰但是不混淆的版本一切正常。根據(jù)經(jīng)驗(yàn)90%以上這類問題原因集中在幾個(gè)地方。第一個(gè)是浮點(diǎn)和內(nèi)聯(lián)匯編。OLLVM在某些Pass組合下會把浮點(diǎn)運(yùn)算改寫而目標(biāo)Android設(shè)備的老舊GPU/CPU對異常浮點(diǎn)處理不當(dāng)時(shí)會產(chǎn)生SIGFPE。這種情況下建議先把-sub關(guān)閉逐步添加Pass找到具體哪個(gè)Pass觸發(fā)問題。第二個(gè)是?？臻g和基本塊爆炸?？刂屏髌教够谀承┐蠛瘮?shù)上會生成巨大的狀態(tài)機(jī)導(dǎo)致棧使用量飆升進(jìn)而觸發(fā)棧溢出。解決方案是排除體積過于巨大的函數(shù)或者在大函數(shù)上只開-bcf不開-fla。第三個(gè)是O2優(yōu)化級別與混淆Pass的相互影響。常見的組合是編譯命令帶了-O2混淆后再優(yōu)化導(dǎo)致某些尾調(diào)用被改寫成跳轉(zhuǎn)破壞了混淆的結(jié)構(gòu)。一般做法是先-O0驗(yàn)證功能再開-O1或者-O2做最終產(chǎn)物。5.3 性能與安全強(qiáng)度的平衡建議關(guān)于混淆強(qiáng)度這是最容易被忽略的經(jīng)驗(yàn)問題。新人往往覺得Pass開得越全越好概率越高越好其實(shí)混淆的收益在超過一個(gè)閾值后增長緩慢成本卻直線上升。比如-bcf_prob100和-bcf_prob60對分析者的困擾程度其實(shí)是差不多的但前者的so體積可能是后者的兩倍以上運(yùn)行耗時(shí)也更高。我的經(jīng)驗(yàn)是核心機(jī)密算法函數(shù)用-fla和-sub普通的協(xié)議封裝函數(shù)用-bcf難度已經(jīng)足夠。只有當(dāng)你確定某個(gè)函數(shù)是攻擊者的主攻目標(biāo)時(shí)才需要把三種Pass全部拉滿。還有一個(gè)細(xì)節(jié)是關(guān)于調(diào)試信息的?；煜蟮陌绻€留著調(diào)試符號等于一切白做。Release構(gòu)建里一定要設(shè)CMAKE_BUILD_TYPERelease同時(shí)清理DWARF信息和注釋相關(guān)的字符串。5.4 自動化打包鏈路的關(guān)鍵一環(huán)工具鏈搭好之后最好把它固化進(jìn)構(gòu)建腳本避免每次手動改環(huán)境變量?？梢栽陧?xiàng)目的根目錄放一個(gè)ollvm.env里面統(tǒng)一導(dǎo)出路徑。在構(gòu)建腳本里source一下確保CI環(huán)境和本地構(gòu)建環(huán)境一致。如果團(tuán)隊(duì)里多人協(xié)作一定統(tǒng)一NDK版本和OLLVM構(gòu)建版本并把兩個(gè)路徑通過環(huán)境變量而不是硬編碼的方式傳入項(xiàng)目。否則每個(gè)人的機(jī)器編譯出的so行為可能不一致排查問題時(shí)各說各話。我個(gè)人在實(shí)際操作中的體會是這套鏈路最花時(shí)間的從來不是OLLVM本身的編譯而是NDK版本和編譯器路徑的匹配。很多崩潰問題排查到最后發(fā)現(xiàn)源頭只是老版clang和新版sysroot之間的ABI不兼容。如果你也想在自己的SDK里試驗(yàn)建議從arm64-v8a一個(gè)ABI、一個(gè)源文件、一個(gè)混淆Pass開始先跑通全流程再逐步鋪開。最后想再提醒一句OLLVM解決的是“代碼被人讀懂”的問題解決不了“密鑰怎么藏、校驗(yàn)怎么做”這些業(yè)務(wù)層面的安全設(shè)計(jì)兩者是配合關(guān)系不是替代關(guān)系。