御盾先看結論與判斷條件
- 安裝成功、簽名驗證成功和官方釋出身份是三個不同判斷，不能用前兩個替代第三個。
- 重簽名包通常無法覆蓋由另一簽名身份安裝的官方版本，升級鏈是識別異常產物的重要門禁。
- 最終 APK 必須固定包名、版本、證書摘要、檔案摘要、構建來源和渠道處理順序。
- 服務端應維護允許的版本與應用身份集合，並把平臺完整性訊號作為風險輸入，而不是信任客戶端自報。
先區分安裝校驗、簽名身份和業務授權
Android 要求 APK 經過簽名。系統驗證的是安裝包結構和簽名資料能否證明當前內容由對應私鑰簽署。如果攻擊者修改 DEX、資源或 Manifest 後，再用自己的金鑰對修改結果完整簽名，新包在密碼學上可以是自洽的，因此可能滿足全新安裝條件。
這個結果只回答當前包是否有一個可驗證的簽名，不回答簽名者是不是官方釋出者。品牌授權、合法渠道、賬號是否允許登入、高風險介面是否放行，都屬於應用和服務端需要另外判斷的業務問題。
因此測試報告不能寫成重簽名後可安裝等於簽名保護失效，也不能寫成安裝失敗等於全部重打包風險已經閉合。正確問題是：修改包能否進入使用者裝置，能否冒充官方版本升級，能否連線真實服務，以及服務端怎樣識別和處置。
| 判斷 | 回答的問題 | 需要的證據 | 不能外推的結論 |
|---|---|---|---|
| 包體可解析 | 檔案結構能否被安裝器讀取 | 安裝器結果、Manifest 和資源結構 | 不能證明簽名合法或程式碼安全 |
| 當前簽名自洽 | 當前內容是否由當前證書對應私鑰簽署 | 簽名方案驗證和證書摘要 | 不能證明證書屬於官方 |
| 升級身份連續 | 能否覆蓋已安裝的官方應用 | 從真實線上版本執行升級 | 不能證明所有業務介面都會拒絕異常客戶端 |
| 業務授權透過 | 服務端是否允許賬號和版本訪問資源 | 服務端版本、賬號、完整性與行為策略 | 不能保證客戶端程式碼不可分析或修改 |
為什麼重簽名包往往只能全新安裝
Android 使用應用簽名身份維護更新連續性。已安裝應用接受覆蓋升級時，平臺需要確認新版本與既有版本滿足簽名身份規則。使用無關證書籤署的修改包，通常不能直接覆蓋官方版本，只能先解除安裝官方應用、改包名或誘導使用者在另一環境中安裝。
這也是為什麼重打包測試必須同時執行全新安裝和覆蓋升級。只執行全新安裝會漏掉簽名連續性，只執行覆蓋升級又會漏掉仿冒包透過其他包名或解除安裝重灌進入裝置的路徑。兩類結果要分別記錄。
簽名輪換和 Play App Signing 會讓釋出鏈更復雜。團隊應儲存當前和歷史允許的證書身份、輪換規則、上傳金鑰與應用簽名金鑰的職責，並在服務端策略裡使用與分發方式匹配的資料。不能把開發證書、上傳證書和最終分發證書混成一個欄位。
- 從當前線上版本執行覆蓋升級
- 執行解除安裝後的全新安裝
- 檢查包名變化和資料目錄影響
- 核對證書輪換與分發平臺規則
重打包治理要從最終產物身份開始
團隊經常只儲存構建號，卻沒有儲存最終 APK 的檔案摘要和簽名證書摘要。渠道資源注入、重新對齊、再次簽名或包體最佳化都可能改變最終檔案。安全掃描如果分析的是渠道處理前產物，線上使用者收到的檔案就沒有被同一證據覆蓋。
建議對每個可釋出候選包生成不可含糊的產物記錄：包名、versionCode、versionName、檔案 SHA-256、證書 SHA-256、簽名方案驗證結果、構建來源、渠道、處理順序和生成時間。靜態檢查、安裝升級、功能迴歸和服務端放行規則都引用這條記錄。
檔案摘要不是防護措施，它的價值是防止測試物件在流程中悄悄變化。任何摘要、簽名或渠道順序變化都意味著出現新候選包，需要重新執行受影響的門禁。
artifact:
package: com.example.redacted
version_code: 240
version_name: 2.4.0
sha256: REDACTED
signing:
certificate_sha256: REDACTED
schemes: [v2, v3]
distribution: managed-channel
pipeline:
- build-release
- harden-candidate
- channel-resources
- final-sign
acceptance:
install_fresh: required
upgrade_from_production: required
server_policy_check: required服務端必須把異常客戶端變成策略問題
客戶端可以上報包名、版本、證書或完整性材料，但被修改的客戶端也能修改普通上報欄位。服務端需要優先使用可驗證的訊號，並把賬號、版本、請求行為、裝置風險和分發環境組合成策略，而不是相信一個客戶端布林值。
Play Integrity 可以返回應用識別、裝置完整性、賬號許可和環境風險等 verdict。官方文件也說明某些訊號會因為系統版本、裝置形態、分發來源、Play 服務狀態或配置而不可用。正確做法是把不可用、失敗和高風險分別建模，並準備降級、二次驗證、限權或拒絕策略。
非 Google Play 分發場景不能照搬 Play 專屬訊號。企業分發、國內渠道和私有交付需要建立自己的允許版本集合、證書對映、升級機制和異常處置。平臺訊號是證據的一部分，不是跨渠道通用答案。
| 輸入 | 驗證方式 | 可能狀態 | 建議動作 |
|---|---|---|---|
| 版本與包名 | 與釋出臺賬和渠道規則比對 | 允許、過期、未知 | 允許、提示升級、限制高風險能力 |
| 應用識別訊號 | 驗證平臺返回的簽名和應用身份結果 | 已識別、未識別、不可用 | 正常、挑戰或限制、按渠道降級 |
| 賬號與許可 | 服務端賬號許可權和分發許可 | 有效、過期、異常 | 按資源範圍授權或拒絕 |
| 請求行為 | 速率、重放、裝置變化和業務上下文 | 正常、可疑、高風險 | 記錄、二次驗證、限流或阻斷 |
| 裝置與環境 | 平臺 verdict 與自有風險規則 | 滿足、弱訊號、未知 | 風險分級而非單點絕對判斷 |
釋出順序錯誤會讓前面的檢查全部失效
最終簽名之後再修改 DEX、資源或 Manifest，會破壞簽名所覆蓋的內容；在掃描完成後重新構建或重新簽名，則會讓掃描結論與最終檔案脫節。渠道處理工具如果需要改動包體，必須在最終簽名前完成，並在產物臺賬中固定順序。
AAB 分發還要區分上傳產物和使用者裝置收到的拆分 APK。團隊應從分發平臺下載或獲取實際交付產物進行抽查，確認包名、版本、簽名身份和關鍵資源與釋出記錄一致。不能用本地生成的通用 APK 自動代表所有裝置配置。
回滾包也必須進入同樣的簽名與升級驗證。事故發生時臨時拿一箇舊檔案重新簽名，可能因為版本號、簽名或資料遷移不滿足條件而無法覆蓋安裝。
| 階段 | 輸入 | 輸出證據 | 主要失敗條件 |
|---|---|---|---|
| Release 構建 | 凍結原始碼與依賴 | 構建記錄和基礎產物 | 依賴或配置不可復現 |
| 加固處理 | 明確保護配置 | 配置版本和候選產物 | 處理物件與目標版本不一致 |
| 渠道處理 | 渠道資源和合規資訊 | 渠道候選產物 | 簽名後仍修改內容 |
| 最終簽名 | 受控金鑰與最終包體 | 證書摘要和簽名驗證結果 | 使用錯誤金鑰或環境 |
| 驗收發布 | 唯一最終檔案 | 安裝、升級、業務和服務端門禁 | 用其他檔案替代已驗收物件 |
怎樣判斷重打包風險已經得到可釋出的控制
可釋出結論不是修改包永遠無法安裝，而是官方產物身份可追溯、異常產物無法無聲覆蓋官方版本、服務端能識別或限制不受信任客戶端、使用者有獲取正版和恢復的路徑、團隊能對最終交付檔案複核。
測試應保留成功和失敗兩類證據。成功路徑包括官方版本正常安裝升級、登入和關鍵業務；異常路徑包括無關證書覆蓋升級、未知版本訪問高風險介面、版本過期、完整性訊號不可用以及誤報恢復。只驗證拒絕而沒有恢復流程，會把真實使用者困在無法解決的狀態。
本文沒有聲稱任何加固技術可以單獨阻止所有重簽名安裝。重打包治理是簽名、升級、產物管理、客戶端韌性、平臺訊號和服務端策略共同完成的系統工程。
- 官方產物身份可以獨立複核
- 異常證書不能無聲覆蓋官方安裝
- 服務端對未知客戶端有分級策略
- 使用者能恢復到可信釋出渠道
- 回滾包已提前完成升級驗證
事實依據與適用邊界
以下內容區分官方事實、本文工程判斷和不能外推的範圍，避免把設計建議寫成未經驗證的產品結論。
| 本文判斷 | 事實或工程依據 | 適用限制 |
|---|---|---|
| 重簽名包可安裝不等於擁有官方釋出身份。 | Android 要求 APK 具有可驗證簽名；攻擊者可對自己修改後的內容使用自己的金鑰生成自洽簽名。 | 是否能安裝還受包名、裝置策略、系統版本和安裝來源影響，不能從設計原理推斷某個樣本結果。 |
| 覆蓋升級必須核對簽名身份連續性。 | Android 官方說明平臺使用應用簽名金鑰確認更新來自同一金鑰持有者。 | 證書輪換和分發平臺簽名規則需要按專案配置核對。 |
| 平臺完整性訊號應在後端驗證和處置。 | Play Integrity verdict 包含應用識別、裝置、賬號和環境資訊，官方建議後端依據風險做響應。 | Play 訊號不覆蓋所有國家、渠道、裝置和離線場景。 |
| 最終交付檔案必須與測試證據一一對應。 | 重新構建、修改資源或重新簽名都會改變產物身份和可能的執行行為。 | 檔案摘要只建立身份關聯，本身不提供抗篡改能力。 |
| 安裝失敗不能單獨證明重打包風險閉合。 | 異常包仍可能透過改包名、解除安裝重灌、其他渠道或服務端缺少版本策略繼續形成風險。 | 具體攻擊路徑必須在授權測試範圍內按真實分發和業務架構驗證。 |
工程常見問題
為什麼系統不直接拒絕所有非官方證書籤名的 APK？
Android 安裝器能夠驗證當前包的簽名是否自洽，但系統並不知道每個品牌認可哪張證書。官方身份需要由升級鏈、分發平臺和業務服務共同判斷。
重簽名包不能覆蓋升級，是否就沒有風險？
不是。攻擊者仍可能誘導解除安裝重灌、修改包名或利用服務端缺少版本策略繼續訪問業務。覆蓋升級只是治理矩陣中的一項。
客戶端讀取自己的證書摘要夠不夠？
不夠。被修改的客戶端可能同時修改本地檢查或上報邏輯。證書資訊可參與縱深防禦，但高風險授權應由服務端結合可驗證訊號做決定。
AAB 釋出後應該儲存哪個檔案的摘要？
儲存上傳 AAB 的身份，也要從分發平臺獲取並抽查實際交付產物。不同裝置可能收到拆分 APK，不能只儲存本地通用 APK。
什麼時候可以形成釋出結論？
當最終簽名產物身份固定，並完成安裝、從線上版本升級、關鍵業務、服務端策略、目標系統範圍和回滾驗證後，才能對已覆蓋範圍形成結論。