安裝透過檢查的是當前包，不是品牌授權
Android 會驗證 APK 的結構和簽名是否自洽。攻擊者修改 DEX、資源或 Manifest 後，可以使用自己的證書重新簽名，生成一個在技術上完整的新包。
系統能夠安裝這個包，不等於它擁有官方釋出身份。裝置側安裝校驗不會替業務方判斷渠道是否合法、賬號是否應該登入或高風險介面是否應該放行。
重簽名會破壞官方升級連續性
同一應用的覆蓋升級通常要求籤名身份保持連續。使用其他證書的包無法直接覆蓋官方安裝，往往只能改包名、解除安裝原應用或誘導使用者單獨安裝。
因此檢查重打包風險時，既要測試全新安裝，也要測試從當前線上版本升級。只測試安裝頁會漏掉簽名連續性、資料保留和渠道配置問題。
- 簽名證書摘要是否符合釋出計劃
- 能否從線上版本正常升級
- 包名與版本是否符合合法集合
- 渠道修改是否發生在最終簽名前
客戶端訊號要由服務端形成決策
客戶端可以上報包名、版本、簽名或平臺完整性訊號，但這些材料本身不是絕對可信結論。高風險操作應由服務端結合賬號、版本集合、裝置風險與請求行為進行判斷。
策略還需要灰度、誤報處理和應急回滾。如果服務端完全不區分版本與簽名，客戶端加固就難以阻止修改包繼續呼叫真實業務介面。
釋出記錄要能唯一定位最終 APK
每個候選包至少應記錄構建來源、包名、版本、簽名證書摘要、檔案摘要和渠道處理順序。靜態檢查、安裝升級與業務迴歸必須指向同一檔案身份。
任何重新構建、重簽名或渠道修改都會產生新的候選包。它需要重新進入驗證流程，不能沿用上一個檔案的透過結論。
- 最終檔案摘要可複核
- 釋出證書身份一致
- 渠道順序固定
- 迴歸結果繫結同一檔案
讓建議落到真實應用上
提交技術棧、關鍵路徑、目標系統範圍和當前候選包，由御盾給出針對性的保護與相容性驗證建議。