御盾先看結論與判斷條件
- 不要只提交一個同名安裝包，必須記錄來源、版本、檔案摘要、簽名計劃和計劃釋出渠道。
- 不要只說需要最高強度，應說明哪些邏輯被還原或修改後會造成什麼業務損失。
- 技術棧要覆蓋語言、構建、最低系統、ABI、Native、動態載入、跨平臺框架和第三方 SDK。
- 在 PoC 前寫清成功、失敗、未覆蓋、停止和回滾條件，避免把能啟動誤當成可以釋出。
先提供一個能夠被唯一識別的候選包
候選包是後續配置、測試和結論的共同物件。至少需要包名或 Bundle ID、版本、構建來源、檔案 SHA-256、當前簽名狀態、目標籤名計劃和計劃釋出渠道。如果暫時不能交付檔案，也應明確專案處於架構、開發、聯調還是釋出準備階段。
同名檔案不代表同一產物。重新構建、重新簽名、修改渠道資源或替換依賴都會產生新身份。每次變化要說明哪些驗證需要重跑，不能把舊候選的透過結論直接貼到新檔案。
涉及商業程式碼和使用者資料時，應透過中央御盾平臺的受控專案流程提交。公開專題站只提供方法與入口，不接收賬號、安裝包、證書或專案秘密。
| 欄位 | 示例內容 | 用途 | 常見缺口 |
|---|---|---|---|
| 應用身份 | 包名或 Bundle ID、版本 | 對應釋出、升級和測試範圍 | 只有市場名稱 |
| 檔案身份 | SHA-256 與生成時間 | 保證所有證據指向同一檔案 | 同名覆蓋舊檔案 |
| 構建來源 | 分支、提交、CI 任務或釋出記錄 | 問題回溯與重新構建 | 無法說明來源 |
| 簽名計劃 | 當前狀態、最終證書和簽名環節 | 驗證升級和釋出身份 | PoC 後隨意重籤 |
| 分發範圍 | 商店、企業或私有渠道 | 決定完整性訊號和交付檢查 | 預設所有渠道相同 |
把需要保護的程式碼寫成業務損失
最高強度、全部保護和防破解都不是可執行需求。請列出核心演算法、授權判斷、協議處理、內容權益、模型或關鍵本地決策，並說明它被讀懂、複製、修改或跳過後會造成什麼損失。
同時說明這些邏輯為什麼必須留在客戶端。可以由服務端完成的高風險授權，應優先由服務端決定；需要離線、低時延或平臺本地能力的路徑，再評估客戶端保護。這樣才能把 VMP 留給真正需要改變執行表示的程式碼。
每項資產還要有負責人、呼叫入口、執行頻率、執行緒、輸入輸出、依賴和失敗回退。沒有獨立驗收路徑的資產，即使價值很高，也要先補測試條件。
| 資產型別 | 應說明的損失 | 客戶端必要性 | 建議準備的驗收 |
|---|---|---|---|
| 授權與權益 | 本地分支被跳過後可訪問何種資源 | 離線能力或本地快速判斷 | 正常、過期、篡改和服務端複核 |
| 核心演算法 | 被複制後損失的商業價值 | 端側效能、隱私或離線 | 輸入輸出一致、效能和邊界資料 |
| 協議與金鑰使用 | 重放、偽造或批次濫用的後果 | 裝置繫結或本地通訊 | 錯誤、重放、輪換和服務端限制 |
| 端側模型或規則 | 模型、提示或後處理被複制和修改 | 離線、隱私或低時延 | 版本配對、載入、回滾和日誌 |
| 第三方關鍵介面 | SDK 被繞過或錯誤呼叫的後果 | 平臺或渠道要求 | 真實賬號、簽名和回撥路徑 |
技術棧清單決定相容性測試邊界
Android 專案應說明 Java、Kotlin、NDK、Gradle 和 Android Gradle Plugin 版本，minSdk、targetSdk、釋出 ABI、是否使用反射、序列化、動態類載入、熱修復、外掛化、WebView、Native 和多程序。iOS 專案應說明 Swift、Objective-C、最低系統、擴充套件、動態庫、執行時特性和簽名能力。
Flutter、React Native、Unity、Cocos 或其他跨平臺框架還要記錄框架版本、橋接方式、引擎與業務 Native 庫。不能只寫跨平臺，因為不同版本的產物結構、啟動和第三方整合差異很大。
第三方登入、支付、推送、地圖、音影片、統計、風控、熱修復和廠商服務可能依賴反射、簽名、Manifest、URL Scheme、JNI、資源或自身完整性檢查。首次評估時完整列出，比發生閃退後逐個猜測更節省時間。
- 語言、構建系統和主要外掛版本
- 最低與目標系統、裝置和 ABI
- Native、JNI、動態載入和跨平臺框架
- 多程序、WebView、熱修復與外掛化
- 登入、支付、推送、音影片等關鍵 SDK
簽名、渠道和升級計劃要在 PoC 前說清楚
PoC 產物使用什麼簽名、正式釋出由誰簽名、渠道資源在簽名前還是簽名後處理、是否使用 Play App Signing、iOS 使用哪種分發方式，這些都會影響安裝、升級、完整性訊號和最終檔案身份。
Android 官方說明應用簽名金鑰用於確認更新來自同一金鑰持有者。PoC 如果使用臨時證書，只能驗證對應環境，不能自動證明能覆蓋線上版本。正式驗收要在授權和安全流程允許的前提下使用與釋出鏈一致的簽名計劃。
渠道處理必須固定順序。最終簽名後再修改包體會破壞簽名，驗收後重新構建或重籤則產生新候選。回滾版本也要提前驗證簽名、版本號、資料遷移和覆蓋升級。
| 問題 | 為什麼重要 | PoC 可接受狀態 | 正式驗收要求 |
|---|---|---|---|
| 誰完成最終簽名 | 決定金鑰責任和產物身份 | 臨時簽名需明確限制 | 與正式流程一致且可審計 |
| 渠道何時修改包體 | 修改會改變檔案和簽名覆蓋內容 | 順序可說明 | 簽名前完成並重新固定身份 |
| 如何覆蓋線上版本 | 驗證簽名與版本連續性 | 可暫不執行但標記未覆蓋 | 從真實線上版本升級 |
| 如何回滾 | 事故時必須可執行 | 準備基線候選 | 回滾包提前驗證並有責任人 |
在開始前定義 PoC 的成功、失敗和停止條件
PoC 不是生成一個能安裝的加固包。應提前確定要觀察的保護範圍、靜態暴露面、啟動、關鍵業務、效能預算、目標系統、ABI、第三方 SDK、安裝升級和異常回退。每個專案都可以有不同權重，但不能沒有定義。
成功條件要可測，例如關鍵輸入輸出一致、目標系統逐項透過、啟動變化在專案預算內、異常路徑安全、保護配置能夠回溯。失敗條件包括啟動阻斷、關鍵業務錯誤、不可接受效能變化、目標範圍相容失敗或無法歸因。
停止條件防止盲目擴大範圍。若候選身份不一致、缺少基線、關鍵日誌無法取得、簽名流程未確認或測試環境與釋出範圍不匹配，應先補條件再繼續。
| 狀態 | 含義 | 報告要求 | 是否可釋出 |
|---|---|---|---|
| 已驗證 | 同一候選在約定範圍取得證據 | 寫明方法、環境、結果和邊界 | 僅對該範圍可判斷 |
| 失敗 | 出現可重複的阻斷或不符合預算 | 保留最早差異和影響 | 不可按原配置釋出 |
| 未執行 | 缺少裝置、賬號、資料或授權 | 寫明原因和下一步 | 不能借其他結果替代 |
| 不適用 | 專案明確不包含該平臺或能力 | 給出判定依據 | 不進入本次範圍 |
project_stage: release-candidate
artifacts:
baseline: identified
protected_candidate: pending
assets:
- entitlement-decision
- protocol-core
stack:
platform: Android
min_os: project-defined
abis: [arm64-v8a]
critical_journeys:
- cold-launch
- sign-in
- protected-operation
acceptance:
functional_parity: required
performance_budget: project-defined
compatibility_matrix: required
rollback_rehearsal: required
boundaries:
- no_unverified_attack_resistance_claim
- uncovered_devices_remain_open資料完整後，御盾評估會形成什麼交付
完整輸入能夠支援三個連續階段。第一階段確認資產、技術棧和釋出鏈，形成初始保護範圍與風險清單；第二階段生成可追溯 PoC，並在同一候選身份上執行靜態和執行檢查；第三階段根據結果調整範圍，完成目標矩陣、釋出邊界和回滾條件。
具體保護能力、平臺支援、效能預算和交付週期需要根據真實專案確認。本頁沒有使用客戶案例、透過率或通用效能數字，也不承諾沒有候選包就能給出最終效果。
登入、註冊、申請、價格和專案資料統一進入御盾中央平臺。專題站不會建立第二套賬號或申請系統。提交前可以先按本文清單整理材料，避免在專案開始後反覆補候選身份和釋出範圍。
- 候選包、基線和釋出鏈可追溯
- 保護資產和業務損失說清楚
- 技術棧、第三方和目標矩陣完整
- 成功、失敗、未覆蓋和回滾已定義
- 敏感資料只透過中央平臺提交
事實依據與適用邊界
以下內容區分官方事實、本文工程判斷和不能外推的範圍，避免把設計建議寫成未經驗證的產品結論。
| 本文判斷 | 事實或工程依據 | 適用限制 |
|---|---|---|
| 候選包身份是評估證據的共同主鍵。 | 重新構建、簽名、渠道修改和依賴變化都會改變最終檔案及可能的執行行為。 | SHA-256 用於識別檔案，不代表檔案已經安全。 |
| VMP 保護目標應來自業務損失和威脅模型。 | OWASP MASVS 將抗逆向與抗篡改視為針對特定威脅的縱深防禦，不替代服務端和整體架構。 | 標準不能證明某個候選包或配置已經透過。 |
| 簽名和升級計劃必須在正式驗收中閉合。 | Android 使用應用簽名身份確認更新連續性，Apple 平臺也要求可執行程式碼遵循程式碼簽名鏈。 | 不同分發方式和證書輪換策略需要按專案核對。 |
| 能安裝和能啟動不是完整 PoC 結論。 | 釋出還涉及關鍵業務、效能、系統、ABI、第三方、升級、監控和回滾。 | 專案可根據真實使用者範圍裁剪矩陣，但必須明確未覆蓋項。 |
| 專題站不接收敏感專案資料。 | 賬號、申請和專案資料統一由御盾中央平臺承接，內容站只提供公開方法和跳轉。 | 具體資料許可權和保留規則以中央平臺和專案約定為準。 |
工程常見問題
只有 APK，沒有原始碼，可以申請評估嗎？
可以先確認產物和目標，但保護配置、問題歸因和重新構建能力可能受限。應說明是否能提供構建配合、符號、測試賬號和基線。
第一次溝通必須提供正式簽名嗎？
不一定。可以使用受控測試簽名開展部分 PoC，但必須明確不能代表線上升級和正式簽名鏈，正式驗收前需要補齊發布計劃。
為什麼要列出全部第三方 SDK？
第三方 SDK 可能依賴反射、簽名、資源、JNI、初始化順序或自身完整性檢查，是相容問題的重要來源。
能不能直接要求全量最高強度？
可以提出風險偏好，但最終範圍仍需根據業務價值、執行頻率、故障半徑和迴歸能力分層，否則很難形成穩定釋出結論。
文章裡的資料可以直接透過專題站上傳嗎？
不可以。專題站只提供公開內容，登入、註冊、申請和專案資料必須跳轉御盾中央平臺處理。