最近有個(gè)朋友找到我說(shuō)他們的App上線不到一周就被扒了源碼核心算法被抄得干干凈凈連注釋都沒(méi)刪。這種事在Android圈子里太常見(jiàn)了APK說(shuō)白了就是個(gè)壓縮包DEX文件反編譯成smali或者直接用jadx看Java偽代碼門(mén)檻低到讓開(kāi)發(fā)者想哭。于是他們想上加固但一問(wèn)方案又猶豫了——市面上的加固方案確實(shí)能防逆向但啟動(dòng)速度慢個(gè)一兩秒、包體積膨脹幾十兆、低端機(jī)直接卡成PPT這種代價(jià)誰(shuí)能受得了這個(gè)痛點(diǎn)就是XopProtector這個(gè)項(xiàng)目要解決的問(wèn)題。它不是那種“把整個(gè)APK加密成黑盒”的重型方案而是走了一條更克制的路子按需保護(hù)、精準(zhǔn)加固把性能損耗控制到幾乎感知不到的程度。這篇博文我會(huì)把整個(gè)加固實(shí)踐從頭到尾拆開(kāi)講為什么傳統(tǒng)加固會(huì)把性能做崩、XopProtector的設(shè)計(jì)思路是什么、我在實(shí)測(cè)里拿到了哪些數(shù)據(jù)、以及加固之后踩過(guò)的那些坑。適合Android開(kāi)發(fā)者、負(fù)責(zé)打包發(fā)版的技術(shù)同學(xué)還有那些正糾結(jié)“要不要上加固、該怎么選方案”的人來(lái)看。1. 加固這件事先想清楚我們到底在防什么1.1 靜態(tài)分析、動(dòng)態(tài)調(diào)試和二次打包三個(gè)威脅要分開(kāi)看很多團(tuán)隊(duì)一說(shuō)“加固”就想著把所有代碼全部加密最好讓人連類(lèi)名都看不見(jiàn)。但實(shí)際威脅模型根本沒(méi)這么籠統(tǒng)。我在實(shí)踐里習(xí)慣把風(fēng)險(xiǎn)拆成三類(lèi)第一類(lèi)是靜態(tài)分析。攻擊者拿到APK以后用jadx或者JEB打開(kāi)直接看Java層偽代碼核心的加密算法、簽名校驗(yàn)、后端接口地址全部一覽無(wú)余。更麻煩的是smali可以被直接修改改完再重打包就能繞過(guò)很多客戶(hù)端校驗(yàn)。這類(lèi)攻擊占了絕大多數(shù)防護(hù)的關(guān)鍵在于讓關(guān)鍵邏輯在靜態(tài)層面不可讀、不可改。第二類(lèi)是動(dòng)態(tài)調(diào)試。攻擊者在Root設(shè)備上跑Frida或者XposedHook關(guān)鍵函數(shù)運(yùn)行時(shí)拿到參數(shù)和返回值。這就不是簡(jiǎn)單做代碼混淆就能防住的需要對(duì)抗調(diào)試器、檢測(cè)注入、甚至對(duì)關(guān)鍵調(diào)用做動(dòng)態(tài)校驗(yàn)。但話(huà)說(shuō)回來(lái)普通App遇到的攻擊者90%都停留在靜態(tài)分析層面動(dòng)態(tài)調(diào)試的威脅等級(jí)其實(shí)沒(méi)有那么高。第三類(lèi)是篡改二次打包。廣告注入、植入病毒、盜用簽名這類(lèi)問(wèn)題主要靠簽名校驗(yàn)和完整性校驗(yàn)來(lái)防范本質(zhì)上和代碼加密關(guān)系不大。想清楚這三類(lèi)威脅之后結(jié)論就很明顯了我們不需要把所有代碼都變成密文只需要把“被抄了會(huì)死”的那部分代碼保護(hù)起來(lái)。這也是XopProtector最核心的設(shè)計(jì)出發(fā)點(diǎn)——?jiǎng)e做無(wú)差別加密做精確打擊。1.2 傳統(tǒng)加固方案為什么會(huì)把性能做崩市面上商業(yè)加固主流的做法是“DEX整體加密 運(yùn)行時(shí)解密”。安裝包里的classes.dex被抽空或者加密App啟動(dòng)的時(shí)候通過(guò)自定義ClassLoader去解密、還原真正的DEX。這種方式安全性的確高但代價(jià)也實(shí)打?qū)?。第一個(gè)代價(jià)是啟動(dòng)時(shí)間暴漲。解密和加載DEX是IO密集CPU密集的操作而且是在主線程的Application.attachBaseContext階段執(zhí)行。如果項(xiàng)目足夠大光這一步就要吃掉幾百毫秒甚至一秒多。在這期間用戶(hù)看到的是一個(gè)白屏或者啟動(dòng)圖體驗(yàn)已經(jīng)扣分了。第二個(gè)代價(jià)是方法調(diào)用變慢。有些方案會(huì)把DEX里的方法體抽走只在調(diào)用的時(shí)候從Native層還原。這就意味著每次進(jìn)入這些方法都要走一次“回調(diào)Native→解密→執(zhí)行”的鏈路。方法調(diào)用的開(kāi)銷(xiāo)從原來(lái)的幾納秒級(jí)變成幾十微秒甚至更高循環(huán)里調(diào)用一百次肉眼可見(jiàn)地卡。第三個(gè)代價(jià)是兼容性風(fēng)險(xiǎn)。Android的ART運(yùn)行時(shí)對(duì)ClassLoader、DEX格式的要求非常嚴(yán)格定制ROM上更容易出問(wèn)題。很多商業(yè)加固在某些系統(tǒng)版本上啟動(dòng)直接崩排查起來(lái)極其痛苦。這些方案之所以這么重根本原因是它們“把所有雞蛋都放在一個(gè)籃子里”——試圖用一套加密邏輯保護(hù)所有代碼那必然只能在性能、兼容性和安全性之間做取舍。而XopProtector的答案是既然我們不能為了加固犧牲性能那就只保護(hù)那些真正值得保護(hù)的東西。2. 為什么很多加固方案在Android 7以上的機(jī)器上會(huì)翻車(chē)2.1 ART、Dex2Oat和Class驗(yàn)證這三個(gè)機(jī)制決定了加固的上限先說(shuō)一個(gè)背景知識(shí)。從Android 5.0開(kāi)始系統(tǒng)默認(rèn)運(yùn)行時(shí)從Dalvik換成了ART。ART會(huì)做AOT編譯安裝App的時(shí)候通過(guò)dex2oat把DEX文件編譯成native指令這樣運(yùn)行的時(shí)候能直接執(zhí)行機(jī)器碼性能提升非常明顯。Android 7以后又加入了JIT變成了混合編譯模式安裝時(shí)先不AOT運(yùn)行時(shí)熱點(diǎn)代碼才被JIT編譯空閑時(shí)再通過(guò)dex2oat做AOT。這個(gè)機(jī)制對(duì)加固方案來(lái)說(shuō)是個(gè)考驗(yàn)。因?yàn)閐ex2oat在處理DEX文件的時(shí)候會(huì)對(duì)類(lèi)做驗(yàn)證檢查字節(jié)碼的合法性。如果發(fā)現(xiàn)DEX的指令結(jié)構(gòu)有問(wèn)題、或者方法引用指向不存在的類(lèi)就會(huì)拋VerifyError。很多加固方案為了隱藏代碼會(huì)對(duì)DEX做大幅修改甚至破壞原有的字節(jié)碼結(jié)構(gòu)結(jié)果就是dex2oat驗(yàn)證不通過(guò)運(yùn)行時(shí)只能走解釋執(zhí)行性能大幅下降。還有更麻煩的如果ClassLoader的行為超出了ART的預(yù)期某些Android版本上直接ClassNotFoundException或者ClassCastException。我在實(shí)際項(xiàng)目里見(jiàn)過(guò)一個(gè)加固App在Android 9上運(yùn)行流暢到了Android 12上啟動(dòng)就崩查到最后就是加固方案對(duì)ClassLoader的處理在新的系統(tǒng)版本上不再兼容。2.2 抽取式加固的“運(yùn)行時(shí)還原”損耗是積少成多現(xiàn)在很多方案喜歡做“方法級(jí)抽取”——把關(guān)鍵方法從DEX里抽出來(lái)放到Native層保存。App運(yùn)行的時(shí)候ClassLoader拿到DEX之后不是直接用而是要先把抽取的方法體填回去。聽(tīng)起來(lái)很巧妙但實(shí)際工程項(xiàng)目里方法調(diào)用往往是一個(gè)套一個(gè)的。A方法調(diào)用B方法B方法調(diào)用C方法如果每一個(gè)都是抽取方法那么每次進(jìn)入這些調(diào)用鏈都要觸發(fā)一次從Native還原到Java層的過(guò)程。這個(gè)還原過(guò)程本身就包含了一些邏輯開(kāi)銷(xiāo)查找方法、分配內(nèi)存、構(gòu)造方法對(duì)象、賦值回去。單看一次可能只有幾百微秒但一個(gè)循環(huán)里調(diào)用幾百次累積起來(lái)就是幾秒級(jí)別的卡頓。還有一個(gè)容易被忽略的問(wèn)題內(nèi)存。還原出來(lái)的方法體不是用完就丟的它需要占用內(nèi)存。如果抽取的方法太多App運(yùn)行一段時(shí)間以后內(nèi)存里塞滿(mǎn)了還原出來(lái)的方法塊內(nèi)存占用直線上升GC頻繁觸發(fā)卡頓就是這么來(lái)的。2.3 兼容性問(wèn)題本質(zhì)上是在對(duì)抗操作系統(tǒng)的“不透明更新”做Android安全的人都有一個(gè)共識(shí)你的加固方案真正要面對(duì)的敵人不是攻擊者而是操作系統(tǒng)本身。因?yàn)椴僮飨到y(tǒng)每個(gè)版本都在變——ClassLoader的實(shí)現(xiàn)細(xì)節(jié)在改ART的驗(yàn)證邏輯在改JIT編譯策略也在改。商業(yè)加固廠商必須不停地適配新版Android一旦跟不上用戶(hù)就會(huì)遇到閃退、卡死、各種奇怪的運(yùn)行時(shí)錯(cuò)誤。這個(gè)問(wèn)題的根子在于加固方案本質(zhì)上是在“偽造”一個(gè)操作系統(tǒng)認(rèn)為合法的DEX結(jié)構(gòu)同時(shí)還要在里面藏自己的私貨。一旦系統(tǒng)更新的某個(gè)細(xì)節(jié)和你的“偽裝”沖突整個(gè)App就崩了。所以一個(gè)長(zhǎng)期維護(hù)、尤其是一個(gè)開(kāi)源或者自研的加固方案最難的其實(shí)不是功能實(shí)現(xiàn)而是跟著Android版本持續(xù)做兼容性適配。這一點(diǎn)上XopProtector的策略是“少動(dòng)底層多動(dòng)上層”——不去偽造DEX結(jié)構(gòu)不去破壞ClassLoader機(jī)制把精力放在指令混淆、字符串加密、關(guān)鍵邏輯抽取這些對(duì)系統(tǒng)更友好的方向。這種方式雖然看起來(lái)不夠炫酷但換來(lái)的是更穩(wěn)定的兼容性和更低的運(yùn)行時(shí)開(kāi)銷(xiāo)。3. XopProtector的加固實(shí)踐按需保護(hù)精確打擊3.1 第一步梳理代碼分清哪些必須要保護(hù)XopProtector在做加固之前第一步不是配置工具而是做代碼梳理。我的習(xí)慣是建一張表把所有類(lèi)按“被逆向后的損失程度”和“被調(diào)用的頻率”兩個(gè)維度打分。先看損失程度。拿一個(gè)工具類(lèi)App舉例核心資產(chǎn)的排序大概是這樣的簽名生成邏輯、Token校驗(yàn)邏輯這一類(lèi)被抄走等于賬號(hào)體系失守?fù)p失極高加密算法和密鑰管理這類(lèi)是安全基石一旦泄露所有通信都等于透明損失極高業(yè)務(wù)核心規(guī)則、積分計(jì)算邏輯、活動(dòng)風(fēng)控規(guī)則被抄了等于商業(yè)邏輯白送損失高普通工具方法、網(wǎng)絡(luò)請(qǐng)求封裝、UI輔助等這些被看到了也無(wú)傷大雅損失低。再看調(diào)用頻率。冷啟動(dòng)路徑、主線程加載路徑、頻繁循環(huán)里的方法這些對(duì)性能極度敏感任何額外開(kāi)銷(xiāo)都能被用戶(hù)感知到而一些低頻調(diào)用的功能比如“設(shè)置頁(yè)的關(guān)于我們”、“反饋?lái)?yè)面提交”就算加固后慢了用戶(hù)也無(wú)感。把這兩個(gè)維度畫(huà)完你會(huì)發(fā)現(xiàn)真正需要深度保護(hù)的類(lèi)往往只占總代碼量的10%到20%。其余代碼用普通的混淆就夠了。這也回答了一個(gè)很多人問(wèn)我的問(wèn)題為什么XopProtector的包體積增加比傳統(tǒng)方案小很多因?yàn)樗緛?lái)就沒(méi)打算把所有代碼都拖下水。3.2 第二步選擇合適的加固策略分層處理XopProtector對(duì)不同的類(lèi)采用不同的策略這是我實(shí)踐中用下來(lái)最順手的分層方式第一層對(duì)于正常的業(yè)務(wù)代碼做常規(guī)混淆就夠了也就是把類(lèi)名、方法名、字段名改成ab、cd這種無(wú)意義的名稱(chēng)。這層目的是增加閱讀成本幾乎不帶來(lái)運(yùn)行時(shí)開(kāi)銷(xiāo)。第二層對(duì)敏感類(lèi)做控制流混淆和數(shù)據(jù)混淆?？刂屏骰煜淖龇ㄊ前言厩逦臈l件分支、循環(huán)結(jié)構(gòu)打散插入垃圾指令和不透明謂詞讓人看smali的時(shí)候根本搞不清程序真正會(huì)走哪條路徑。數(shù)據(jù)混淆則是對(duì)關(guān)鍵的字符串做加密處理讓攻擊者沒(méi)辦法通過(guò)直接搜索字符串就定位到關(guān)鍵函數(shù)。第三層對(duì)核心算法和校驗(yàn)邏輯做Native化處理。把最關(guān)鍵的方法用JNI寫(xiě)到C/C里編譯成.so文件。這一層的原則是“小而精”只搬最敏感的幾個(gè)邏輯進(jìn)去而不是把整個(gè)業(yè)務(wù)代碼都往Native里塞。這里插一句很多團(tuán)隊(duì)一上來(lái)就說(shuō)“我們能不能全用Native寫(xiě)”我能理解這個(gè)沖動(dòng)但你真要把所有業(yè)務(wù)邏輯都搬到Native層開(kāi)發(fā)效率、調(diào)試成本會(huì)成倍上升而且.so文件自身的加載、初始化也是耗時(shí)點(diǎn)。權(quán)衡之后你會(huì)發(fā)現(xiàn)Java層加Native混編是最理性的選擇。3.3 第三步性能關(guān)鍵路徑要“繞道走”前面講的是“保護(hù)什么代碼”現(xiàn)在說(shuō)一個(gè)更關(guān)鍵的細(xì)節(jié)怎么讓被保護(hù)的代碼依然跑得快。一個(gè)比較有效的做法是“性能關(guān)鍵路徑不加密只混淆”。就拿冷啟動(dòng)來(lái)說(shuō)Application的onCreate方法、首頁(yè)的onCreate方法、首屏布局的inflate過(guò)程這些都是用戶(hù)能直接感知的慢。如果把這些類(lèi)也做深度抽取啟動(dòng)速度肯定受影響。我的做法是在這些啟動(dòng)路徑上只做輕度的混淆和字符串加密不做方法抽取和Native化。另一個(gè)做法是“方法調(diào)用不走反射”。很多加固方案為了保護(hù)方法會(huì)把方法改成通過(guò)反射調(diào)用這又帶來(lái)了性能開(kāi)銷(xiāo)。在XopProtector實(shí)踐中我會(huì)檢查所有加固后的關(guān)鍵類(lèi)確保被保護(hù)的方法都是直接調(diào)用反射只用于初始化階段的一次性查找查完之后緩存Method對(duì)象后面的調(diào)用全部復(fù)用。還有一個(gè)小細(xì)節(jié)AES加解密、RSA簽名這些操作JNI實(shí)現(xiàn)的性能就比Java層好不少尤其是做得比較多、且數(shù)據(jù)量大的場(chǎng)景。所以XopProtector的關(guān)鍵加密邏輯用C實(shí)現(xiàn)也算是在安全性之外白撿了一點(diǎn)性能收益。3.4 第四步把加固流程嵌入Gradle構(gòu)建鏈說(shuō)到底覆蓋一個(gè)項(xiàng)目的加固方案流程必須能自動(dòng)化。手動(dòng)跑一兩次沒(méi)問(wèn)題每次發(fā)版都手動(dòng)搞那就等著出錯(cuò)吧。在XopProtector的實(shí)踐里我把加固流程做成了一個(gè)Gradle插件在packageRelease這個(gè)Task之后自動(dòng)執(zhí)行。整個(gè)流程大概是這樣的# 1. 打包出未加固的APK ./gradlew assembleRelease # 2. 執(zhí)行加固腳本輸入原始APK輸出加固后的APK python3 xop_protect.py \ --input app-release-unsigned.apk \ --output app-release-protected.apk \ --config protect_config.json \ --keystore release.jks \ --key-alias release_alias # 3. 驗(yàn)證加固結(jié)果檢查簽名、檢查保護(hù)類(lèi)是否生效 python3 xop_verify.py --apk app-release-protected.apk一個(gè)小經(jīng)驗(yàn)簽名一定要在加固之后重新做。順序錯(cuò)了的話(huà)加固會(huì)破壞原有簽名導(dǎo)致安裝失敗。這里推薦用apksigner來(lái)做V1V2簽名尤其是Android 7以上必須要有V2簽名才能裝。protect_config.json里需要聲明哪些類(lèi)要進(jìn)Native保護(hù)、哪些類(lèi)只做混淆。我會(huì)把白名單和黑名單都維護(hù)成獨(dú)立配置文件這樣每次發(fā)版前只需要確認(rèn)這些配置沒(méi)有漏項(xiàng)。隨著項(xiàng)目迭代新加的類(lèi)如果沒(méi)有被配置文件覆蓋到gradle插件會(huì)給出警告方便及時(shí)補(bǔ)齊。4. 實(shí)測(cè)數(shù)據(jù)XopProtector加固后的性能損耗到底有多少4.1 測(cè)試環(huán)境與測(cè)試方法做性能測(cè)試之前我的原則是不要用旗艦機(jī)自欺欺人。很多時(shí)候你拿一臺(tái)驍龍8系手機(jī)測(cè)出來(lái)完全無(wú)感換到一臺(tái)用了兩年的中端機(jī)上就原形畢露。這次測(cè)試我用了一臺(tái)中端Android手機(jī)Android 12系統(tǒng)8GB內(nèi)存日常使用已經(jīng)有些卡頓感了。這種設(shè)備上還能跑出好成績(jī)才說(shuō)明方案本身靠譜。測(cè)試維度我選了四個(gè)冷啟動(dòng)時(shí)間、熱啟動(dòng)時(shí)間、包體積變化、以及一個(gè)高頻方法調(diào)用的耗時(shí)。冷啟動(dòng)時(shí)間用adb命令來(lái)測(cè)簡(jiǎn)單、可重復(fù)# 清空App進(jìn)程記錄冷啟動(dòng)時(shí)間 adb shell am force-stop com.example.protectedapp adb shell am start -W -n com.example.protectedapp/.MainActivity輸出的TotalTime就是冷啟動(dòng)耗時(shí)。熱啟動(dòng)測(cè)試我會(huì)在App切到后臺(tái)三分鐘之后再重新打開(kāi)它記錄從點(diǎn)擊圖標(biāo)到首幀可交互的時(shí)間。包體積直接用ls -lh看APK大小。方法調(diào)用耗時(shí)我在代碼里埋了System.nanoTime()統(tǒng)計(jì)測(cè)試一個(gè)加密方法的調(diào)用耗時(shí)。4.2 冷啟動(dòng)和熱啟動(dòng)讓我意外的一組數(shù)據(jù)直接放數(shù)據(jù)。業(yè)務(wù)App的體積不算大DEX文件加起來(lái)差不多11MB關(guān)鍵可執(zhí)行類(lèi)大約60個(gè)。未加固的原始APK冷啟動(dòng)平均耗時(shí)952ms用XopProtector默認(rèn)配置全部保護(hù)關(guān)鍵類(lèi)之后冷啟動(dòng)平均耗時(shí)1013ms只保護(hù)真正高敏感類(lèi)約15個(gè)類(lèi)之后冷啟動(dòng)平均耗時(shí)978ms。這個(gè)數(shù)據(jù)說(shuō)明兩件事。第一XopProtector的底層實(shí)現(xiàn)確實(shí)把運(yùn)行時(shí)的額外工作壓到了很低因?yàn)榧词贡Ｗo(hù)全開(kāi)也才多了60ms出頭要知道傳統(tǒng)的抽取式方案動(dòng)不動(dòng)就是幾百毫秒起步。第二按需保護(hù)這個(gè)策略是真實(shí)有效的只保護(hù)高敏感類(lèi)的方案比保護(hù)全部關(guān)鍵類(lèi)又少了35ms而且實(shí)際代碼量更大之后差距還會(huì)拉大。熱啟動(dòng)的數(shù)據(jù)更有意思。未加固APK的熱啟動(dòng)是382ms加固之后反而更低了——356ms這個(gè)差距屬于測(cè)試誤差范圍可以理解為熱啟動(dòng)性能基本無(wú)損。因?yàn)閄opProtector的加固邏輯只在初始化階段做了一次預(yù)處理后續(xù)運(yùn)行的時(shí)候完全走正常路徑?jīng)]有熱路徑上的額外開(kāi)銷(xiāo)。4.3 包體積增加控制在一個(gè)合理的范圍加固另一個(gè)讓人頭疼的問(wèn)題就是APK膨脹。傳統(tǒng)方案動(dòng)不動(dòng)就加個(gè)5MB到10MB尤其那些內(nèi)置了很重的so文件的方案輕輕松松把包體積推高一個(gè)級(jí)別。這次XopProtector的項(xiàng)目里包體積的控制比我預(yù)想的好。原始APK是18.7MB加了XopProtector之后是91MB。。。等等不是我重新核對(duì)了一下數(shù)據(jù)實(shí)際是19.4MB增加量大約是700KB。其中主要是Native層新增的.so文件和少量資源文件的加密開(kāi)銷(xiāo)。700KB對(duì)于一個(gè)移動(dòng)應(yīng)用來(lái)說(shuō)幾乎感知不到這意味著下載轉(zhuǎn)化率不會(huì)因?yàn)檫@個(gè)受到影響。不過(guò)這里要說(shuō)個(gè)實(shí)話(huà)這個(gè)數(shù)據(jù)是在“保護(hù)范圍受限”的前提下得出的。如果你把項(xiàng)目里所有方法都拉到Native層保護(hù)包體積一樣會(huì)漲得很快。所以關(guān)鍵在于你能不能用前面的分層策略把真正需要保護(hù)的類(lèi)收斂到一個(gè)合理的規(guī)模。4.4 方法的調(diào)用耗時(shí)和運(yùn)行時(shí)表現(xiàn)除了啟動(dòng)時(shí)間我特別關(guān)注的是“高頻方法調(diào)用有沒(méi)有變慢”。因?yàn)楹芏郃pp卡頓不是啟動(dòng)慢而是某個(gè)循環(huán)、某個(gè)頻繁回調(diào)里的方法變慢了。我找了一個(gè)項(xiàng)目里被頻繁調(diào)用的加密方法在原生DEX狀態(tài)下平均單次調(diào)用耗時(shí)約0.68微秒加固之后同一方法的耗時(shí)約0.71微秒。這個(gè)差距在工程上可以忽略不計(jì)。原因就是XopProtector對(duì)方法的加密是在“字節(jié)碼語(yǔ)義層”做的不是“運(yùn)行時(shí)動(dòng)態(tài)解密層”做的——方法調(diào)用不需要額外的解鎖過(guò)程。另一個(gè)值得看的指標(biāo)是Native堆內(nèi)存的增長(zhǎng)。整體跑了一遍加固后的App做了一系列常見(jiàn)操作以后Native堆內(nèi)存穩(wěn)定在可接受的水平?jīng)]有泄漏式增長(zhǎng)。這一點(diǎn)我會(huì)在下面的穩(wěn)定性排查部分展開(kāi)。4.5 安全性驗(yàn)證反編譯以后到底能看到什么性能達(dá)標(biāo)的同事我還順手驗(yàn)證了一下加固效果。用jadx打開(kāi)加固后的APK直接看被保護(hù)類(lèi)的代碼核心方法變成了JNI的native調(diào)用方法體內(nèi)部的核心邏輯變成一個(gè)黑盒字符串是加密過(guò)的密文控制流被混淆成一段看不太懂的邏輯。普通攻擊者走到這一步就已經(jīng)很難受。當(dāng)然作為一個(gè)做安全的人我得提醒一句沒(méi)有任何加固方案是絕對(duì)不可破解的所有方案都只是提高攻擊成本。XopProtector的目標(biāo)很明確——讓90%的攻擊者放棄讓剩下10%的人花幾周時(shí)間才搞定你一周就能打補(bǔ)丁修復(fù)的問(wèn)題。5. 加固之后穩(wěn)定性排查是少不了的硬仗5.1 啟動(dòng)閃退八成是ClassNotFound或者VerifyError加固之后的Crash最經(jīng)典的故障就是啟動(dòng)階段ClassNotFoundException。場(chǎng)景一般是這樣的加固配置里把某個(gè)類(lèi)指定為“Native保護(hù)”但代碼里其他類(lèi)也在引用這個(gè)類(lèi)一旦ClassLoader加載的順序不對(duì)就拋出異常。排查的思路是這樣的先看崩潰日志如果是ClassNotFoundException立刻檢查加固配置文件里的類(lèi)清單如果是VerifyError說(shuō)明混淆后字節(jié)碼結(jié)構(gòu)有問(wèn)題——典型的成因是混淆插樁和原有Lambda表達(dá)式?jīng)_突。這里有一個(gè)我踩過(guò)的坑Android的Lambda表達(dá)式在字節(jié)碼層是用invokedynamic實(shí)現(xiàn)的有些混淆器處理不當(dāng)會(huì)把invokedynamic指令弄壞導(dǎo)致ART驗(yàn)證失敗。解決方法是把這類(lèi)類(lèi)名加到混淆白名單里讓它們跳過(guò)控制流混淆這一層。5.2 熱修復(fù)和插件化能不能和加固共存這個(gè)問(wèn)題問(wèn)到的人特別多。我的經(jīng)驗(yàn)是熱修復(fù)方案和深度加固天然沖突。熱修復(fù)的原理是下發(fā)新的DEX或者補(bǔ)丁包讓ClassLoader優(yōu)先加載補(bǔ)丁類(lèi)但加固之后的類(lèi)已經(jīng)被改過(guò)結(jié)構(gòu)了補(bǔ)丁如果和加固后的結(jié)構(gòu)對(duì)不上熱修復(fù)就會(huì)失效。如果你項(xiàng)目里已經(jīng)用了熱修復(fù)我的建議是加固保護(hù)范圍必須刻意避開(kāi)熱修復(fù)涉及的類(lèi)否則兩邊打架最終的坑還是你自己填。插件化的原理類(lèi)似插件里的類(lèi)大多數(shù)是動(dòng)態(tài)加載的加固要對(duì)插件里的類(lèi)做保護(hù)需要單獨(dú)配置插件包的加固方案。這個(gè)問(wèn)題的答案沒(méi)有標(biāo)準(zhǔn)解完全看你的架構(gòu)設(shè)計(jì)怎么走。但只要記住一個(gè)原則——加固不應(yīng)該影響你既有架構(gòu)的運(yùn)行機(jī)制如果影響了就得調(diào)整保護(hù)策略而不是反過(guò)來(lái)讓業(yè)務(wù)遷就加固工具。5.3 加固后Crash上報(bào)的符號(hào)化問(wèn)題這是一個(gè)大家容易忽略的細(xì)節(jié)。加固之后崩潰日志里的調(diào)用棧不再指向原始的方法名而是被混淆過(guò)的名稱(chēng)。如果Crash上報(bào)平臺(tái)不做符號(hào)還原你看到的崩潰堆棧就是一堆a(bǔ)b.cd()排查起來(lái)非常痛苦。所以我在項(xiàng)目里做了一件事在加固流程中自動(dòng)保存一份混淆映射表并且上傳到Crash平臺(tái)讓平臺(tái)可以自動(dòng)做符號(hào)還原。這樣線上出了崩潰我拿到的是還原后的可直接閱讀的Java調(diào)用棧。這一步雖然不是加固本身的一部分但沒(méi)有它加固后排查問(wèn)題會(huì)浪費(fèi)大量時(shí)間。5.4 不同廠商系統(tǒng)的適配與渠道包發(fā)版適配問(wèn)題在加固方案里總是繞不開(kāi)的。我這次測(cè)試時(shí)在Android 9、Android 11、Android 12、Android 13上分別做了啟動(dòng)測(cè)試基礎(chǔ)功能都能正常跑通。不過(guò)在一些廠商系統(tǒng)上尤其是那些對(duì)ClassLoader做了深度定制的ROM我需要進(jìn)安全模式排查最后把個(gè)別系統(tǒng)不兼容的類(lèi)放到保護(hù)范圍之外。多渠道打包也是每次發(fā)版都要過(guò)的坎。如果你們還在用傳統(tǒng)的方式在加固后進(jìn)行渠道寫(xiě)入需要特別小心因?yàn)榧庸瘫旧頃?huì)改變APK的結(jié)構(gòu)。我建議用Gradle插件把V2簽名和渠道信息放在同時(shí)處理順序一定是“先加固、再寫(xiě)渠道、最后簽名”。順序一旦反了系統(tǒng)可能拒絕安裝。6. 最后分享一點(diǎn)我的實(shí)際體會(huì)如果讓我總結(jié)XopProtector這次實(shí)踐里最有價(jià)值的經(jīng)驗(yàn)就是那句話(huà)加固方案不是越強(qiáng)越好而是越精準(zhǔn)越好。我見(jiàn)過(guò)太多團(tuán)隊(duì)一上來(lái)就全量加密結(jié)果線上啟動(dòng)失敗、性能暴跌、用戶(hù)差評(píng)一片最后只能灰度回退。而真正可持續(xù)的加固方案一定是在安全性能和開(kāi)發(fā)維護(hù)之間找到了平衡點(diǎn)。我個(gè)人的操作習(xí)慣是每個(gè)季度會(huì)把保護(hù)范圍重新過(guò)一遍看看有沒(méi)有新加的類(lèi)需要納入保護(hù)、有沒(méi)有已經(jīng)下線的類(lèi)需要從配置里剔除。這個(gè)習(xí)慣幫我在保證安全性的同時(shí)把性能損耗控制在一個(gè)幾乎可以忽略的水平。還有一個(gè)建議是自己要經(jīng)常做“踩點(diǎn)測(cè)試”——每隔一段時(shí)間就站在攻擊者的角度用反編譯工具看一下加固后的APK把那些一眼就能看出業(yè)務(wù)邏輯的地方記錄下來(lái)分析是否需要進(jìn)一步加強(qiáng)。安全工作不是裝上了就萬(wàn)事大吉它更接近一場(chǎng)長(zhǎng)期的攻防博弈隨時(shí)迭代、持續(xù)加固才能始終跑在攻擊者的前面。