先看結論與判斷條件

  • 先用業務損失和攻擊收益給函式分級，再討論使用 VMP、Java2C、控制流處理還是僅做名稱混淆。
  • 啟動、渲染迴圈、高頻加解密與跨語言邊界屬於高敏感路徑，不能用普通功能迴歸代替效能和相容性基線。
  • 保護清單必須版本化，並與唯一候選包、簽名身份、構建配置和迴歸記錄繫結，否則無法歸因異常。
  • VMP 提高客戶端程式碼的分析與複用成本，不替代簽名治理、平臺完整性訊號、服務端授權和風險控制。

先把函式清單改成業務資產清單

全量覆蓋的第一個問題不是效能，而是缺乏選擇標準。程式碼倉庫裡同時存在核心演算法、授權判斷、協議編解碼、介面繫結、通用工具和第三方適配層。它們被還原後的損失完全不同。如果只按包名、類名或函式數量圈選，保護成本會被低價值程式碼迅速消耗，真正關鍵的路徑反而難以獲得穩定的迴歸資源。

可執行的做法是讓業務、安全和研發共同填寫資產表。每個候選函式至少回答四個問題：攻擊者讀懂它能獲得什麼，修改它能造成什麼損失，邏輯能否移到服務端，失敗時是否有安全回退。只有損失明確、客戶端必須保留且邊界可測的路徑，才進入下一輪技術選擇。

OWASP MASVS 把抗逆向與抗篡改歸為縱深防禦，並明確這些措施不能替代正確的安全架構。這個邊界意味著 VMP 的選擇條件必須來自威脅模型，而不是把技術名稱直接等同於安全結果。

候選函式分級時應記錄的最小資訊
判斷維度需要回答的問題適合進入高強度保護的訊號需要降級或後移的訊號
業務損失邏輯被複制、跳過或修改後會損失什麼授權、權益、核心演算法或關鍵協議會被直接繞過隻影響介面展示或低價值輔助功能
客戶端必要性最終決策是否必須留在本地離線、時延或平臺能力要求客戶端執行高風險決策可以由服務端完成
執行特徵呼叫頻率、執行緒和啟動階段是什麼低頻、邊界清楚、可單獨測量主執行緒啟動、高頻迴圈或無界耗時
故障回退保護異常時能否安全停止或切換有明確失敗狀態和可回滾配置異常會阻斷啟動且無法快速隔離
可驗證性怎樣證明保護後業務仍正確輸入輸出、場景和驗收責任人明確依賴隱式狀態且沒有穩定測試路徑
  • 資產負責人確認損失模型
  • 研發確認呼叫邊界和依賴
  • 測試確認可重複驗收路徑
  • 釋出負責人確認回滾條件

VMP 改變的是執行表示，不是全部安全責任

名稱混淆降低符號和結構的可讀性，控制流處理提高還原路徑的工作量，Java2C 把部分託管程式碼遷移到 Native 表示，VMP 則讓選中的邏輯透過新的指令表示和執行機制執行。它們可以疊加，但解決的問題、執行成本和故障模式並不相同。把多種手段寫成一條可配置的分層策略，比給全部函式套同一個級別更容易驗證。

攻擊者仍然可以觀察輸入輸出、呼叫時機、網路行為和執行狀態。涉及支付、權益、賬號授權或高風險資源訪問時，服務端仍應驗證賬號許可權、版本集合、請求上下文和平臺完整性訊號。客戶端保護的職責是增加分析、修改和規模化複用的成本，而不是把客戶端變成絕對可信環境。

保護範圍還要考慮可維護性。頻繁變化的業務膠水程式碼如果每次釋出都重新進入高強度處理，會擴大構建差異和迴歸面。相對穩定、價值高、介面清楚的核心模組更適合作為長期保護單元。

不同保護層的職責不能互相替代
保護層主要作用典型成本仍需配合的控制
名稱與結構混淆降低靜態閱讀和批次定位效率除錯、崩潰歸因與對映檔案管理完整性、服務端授權、關鍵邏輯保護
控制流與字串處理增加區域性還原成本，減少直接敏感線索包體、執行開銷和相容風險金鑰治理、日誌脫敏、執行驗證
Java2C 或 Native 化改變部分託管程式碼的分析面JNI 邊界、ABI 和 Native 崩潰SO 依賴、符號、異常與執行緒檢查
VMP改變選中程式碼的執行表示和分析路徑效能、故障半徑與候選包迴歸簽名、版本、服務端策略和釋出門禁

啟動鏈和高頻路徑必須先有可比較基線

應用啟動不是一個單點。Android 官方把冷啟動拆成程序建立、Application 建立、主執行緒啟動、Activity 建立、佈局和首次繪製，並使用 TTID 與 TTFD 分別觀察首幀和完全可互動時間。保護程式碼如果位於 Application、ContentProvider、類初始化或首屏關鍵路徑，異常可能在監控 SDK 初始化之前發生，普通線上日誌未必能完整捕獲。

高頻函式的風險來自累計成本。單次增加很小的執行時間，在渲染迴圈、音影片處理、協議迴圈或批次資料處理裡會被放大。驗收不能只記錄一次平均值，應在相同裝置狀態和候選包身份下比較分佈、長尾、主執行緒佔用、記憶體變化和異常率。本文不給出通用損耗數字，因為具體結果依賴函式結構、保護配置、裝置、編譯器和執行頻率。

冷啟動、熱啟動和已經預熱的測試環境不能混為一談。至少要固定安裝狀態、程序狀態、賬號資料和網路條件，並把未保護基線與保護候選包放在同一測量方法下。

高敏感路徑的驗證重點
路徑為什麼敏感必須觀察放行條件
Application 與 ContentProvider發生在首屏和多數監控初始化之前程序建立、初始化順序、最早異常、TTID無新增啟動失敗，時間變化在專案預算內
主執行緒高頻函式累計延遲會直接影響互動呼叫次數、單次與總耗時、卡頓和 ANR關鍵使用者路徑分佈可接受且無新長尾
Native 與 JNI 邊界涉及 ABI、註冊、異常和執行緒約束庫裝載、JNI 異常、目標 ABI、崩潰棧目標矩陣逐項透過，未覆蓋項被標記
後臺批處理可能放大 CPU、電量和記憶體成本任務時長、峰值資源、取消與重試不破壞系統限制和業務時限
  • 分別記錄冷啟動和業務可互動時間
  • 使用相同安裝與賬號資料條件
  • 同時觀察平均值和長尾分佈
  • 把效能預算寫進驗收而不是事後解釋

把保護範圍做成可審閱、可回滾的配置

一個可以長期維護的保護清單，不能只是工具介面裡的若干勾選。它應當像釋出配置一樣進入版本管理，記錄資產標識、選擇原因、保護級別、依賴、效能預算、負責人和回滾條件。這樣出現問題時，團隊才能回答某個函式為什麼被保護、從哪個版本開始、由誰驗收。

配置變更應採用小批次推進。先選擇少量價值最高且邊界最清楚的路徑形成 PoC，再逐組擴大。每組擴充套件都生成新的候選包身份和迴歸記錄，不能在同一檔名下覆蓋舊產物。

下面的 YAML 只是公開安全的資料形態示例，不對應御盾內部配置格式，也不包含真實類名、函式名或產品實現。

  • 每項選擇都有業務原因
  • 配置變化能對應到候選包
  • 高風險路徑擁有獨立迴歸
  • 回滾不依賴重新猜測舊配置
保護範圍清單的公開安全示例
asset: premium-entitlement-decision
owner: commerce-team
client_required: true
threats:
  - unauthorized-logic-reuse
  - local-branch-tampering
execution:
  phase: post-login
  frequency: low
  main_thread: false
protection:
  tier: high
  rollback_group: entitlement-v1
acceptance:
  - output-parity
  - latency-budget
  - target-os-matrix
  - signed-candidate-identity

驗收必須繫結同一候選包和同一發布鏈

構建成功只能證明工具鏈生成了產物，安裝成功只能證明當前包在當前裝置滿足安裝條件。最終驗收還要覆蓋簽名身份、從線上版本升級、冷啟動、關鍵業務路徑、異常恢復、目標系統和目標 ABI。靜態分析、效能測量和相容迴歸必須指向同一檔案身份。

建議為未保護基線和每個保護候選包記錄檔案摘要、包名、版本、簽名證書摘要、構建來源、保護配置版本和渠道處理順序。任何重新構建、重簽名或渠道修改都會產生新候選身份，需要重新進入受影響的驗證步驟。

釋出判斷應明確三類結論：已驗證範圍、未執行範圍和失敗範圍。沒有裝置、系統或業務資料時，應寫成未覆蓋並限制灰度，而不是借用另一個版本或另一臺裝置的成功結果。

從 PoC 到釋出的最小門禁
門禁證據不能接受的替代物失敗動作
候選身份摘要、版本、簽名、配置與構建來源同名檔案或口頭確認停止流轉並重新固定產物
功能一致關鍵輸入輸出和異常路徑對照只開啟首頁或單次演示縮小範圍並定位最早差異
效能預算相同條件下的啟動和關鍵路徑分佈不同裝置的單個平均值回退高頻路徑或調整層級
相容矩陣目標系統、ABI、裝置型別和第三方路徑模擬器或單一新系統標記未覆蓋並限制釋出
釋出閉環升級、簽名、渠道、監控與回滾演練重新簽名後的另一個包重新執行受影響門禁

哪些情況不應直接擴大 VMP 範圍

如果團隊還不能說明關鍵資產、沒有穩定候選包、缺少目標系統矩陣或連未保護基線都沒有，繼續擴大範圍只會增加無法歸因的變數。此時正確動作是補齊資產和測試條件，而不是用更高覆蓋率掩蓋驗證缺口。

反射、序列化、動態類載入、熱修復、外掛框架、JNI 註冊、第三方自校驗和啟動期 SDK 都可能對名稱、程式碼佈局、裝載順序或異常行為有隱式依賴。它們不是一律不能保護，但必須單獨列出並在真實業務入口驗證。

服務端能夠承擔的高風險決策，應優先在服務端形成最終授權。客戶端 VMP 可以保護必要的本地計算和決策材料，卻不能保證執行環境永遠可信，也不能獨自阻止合法客戶端憑據被濫用。

最終範圍不是一次會議裡的永久結論。業務邏輯、編譯鏈、SDK 和目標系統變化後，需要重新審閱資產價值、執行頻率和相容邊界。

  • 沒有基線時先補基線
  • 沒有回滾時不擴大故障半徑
  • 隱式依賴路徑單獨建組
  • 服務端可承擔的決策不留給客戶端獨自完成

事實依據與適用邊界

以下內容區分官方事實、本文工程判斷和不能外推的範圍，避免把設計建議寫成未經驗證的產品結論。

本文判斷事實或工程依據適用限制
VMP 應作為威脅驅動的縱深防禦，而不是安全架構替代品。OWASP MASVS-RESILIENCE 將混淆、抗篡改、抗靜態和動態分析列為提高韌性的控制，同時強調安全仍依賴可驗證設計、密碼學和服務端驗證。該標準說明控制目標，不證明任何具體產品或配置已經達到目標。
啟動路徑需要獨立效能基線。Android 官方把啟動分為冷、溫、熱狀態，並使用 TTID 與 TTFD 區分首幀和完全可互動時間。官方指標定義不能替代專案在真實候選包和目標裝置上的測量。
簽名和升級連續性必須獨立驗收。Android 官方說明每個 APK 必須簽名，平臺使用簽名身份判斷已安裝應用的更新是否來自同一金鑰持有者。簽名一致只證明發布身份鏈的一部分，不證明業務邏輯未被濫用。
平臺完整性訊號應由服務端納入策略。Play Integrity 返回應用、裝置、賬號和環境相關 verdict，後端可依據風險分級響應。訊號可能不可用或受分發環境限制，不能把單個 verdict 當成絕對信任。
不存在脫離函式、裝置和配置的通用效能損耗數字。VMP 成本與執行頻率、執行緒、程式碼結構、保護實現、編譯器和裝置共同相關，因此必須透過同條件對照建立結論。這是工程判斷，不是對御盾或其他產品效能的實測宣告。

工程常見問題

是不是覆蓋越多，逆向成本就一定越高？

覆蓋增加可能提高部分分析工作量，也會擴大效能、相容和迴歸成本。真正影響攻擊收益的是高價值路徑是否被有效處理，以及簽名、完整性和服務端策略是否形成閉環。

啟動函式是否絕對不能進入 VMP？

不是絕對禁止，但啟動期故障半徑大、監控可能尚未初始化，必須先有冷啟動基線、明確預算、目標系統矩陣和快速回滾方案。

如何判斷某個函式是高價值函式？

看它被還原或修改後是否能繞過授權、複製演算法、濫用協議或造成直接業務損失，同時確認邏輯必須留在客戶端並且能夠獨立迴歸。

沒有當前候選包時可以先確定最終範圍嗎？

可以形成初步資產分級和 PoC 清單，但不能提前承諾效能、相容性或最終保護效果。最終範圍必須由真實候選包的對照結果確認。

VMP 之後還需要服務端風控嗎？

需要。客戶端保護提高分析和修改成本，賬號授權、交易、權益和高風險資源訪問仍應由服務端結合版本、賬號和風險訊號做最終決定。

想用自己的 App 驗證？

提交候選包、目標系統和關鍵業務路徑，申請御盾 PoC 與相容性評估。

繼續閱讀: VMP 加固是什麼，如何選擇保護範圍

申請 App 加固測試填寫完整資料