VMP 加固為什麼不建議全量覆蓋

先看攻擊收益，再看函式數量

一個函式是否值得進入 VMP，首先取決於攻擊者還原或修改它以後能得到什麼。授權判斷、核心演算法、協議解析、內容權益和關鍵本地決策通常具有更明確的保護價值。

介面繫結、通用工具方法和頻繁變化的業務膠水程式碼，即使數量很多，也不一定值得承擔同樣的保護與迴歸成本。保護範圍應該和業務損失對應，而不是和倉庫規模對應。

• 還原後是否能繞過關鍵規則
• 修改後是否會形成直接損失
• 邏輯能否遷移到服務端
• 路徑能否被獨立迴歸

啟動與高頻路徑要特別謹慎

應用啟動、類初始化、渲染迴圈和高頻加解密函式對延遲與異常更敏感。把這些路徑大面積納入高成本保護，可能放大啟動時間、執行緒競爭和故障定位難度。

這並不意味著高頻函式永遠不能保護，而是需要先有未保護版本的基線，再對呼叫頻率、單次耗時、失敗回退和影響範圍進行測量。

用分層策略縮小故障半徑

名稱混淆、控制流處理、Java2C 與 VMP 解決的問題和成本不同。可以讓低價值程式碼使用低成本手段，把 VMP 留給少量高價值函式，並讓簽名、完整性與服務端策略繼續承擔各自責任。

每次擴大範圍時只增加一組可解釋的函式，並保留配置版本。出現崩潰或效能變化時，團隊才能快速定位是程式碼路徑、保護配置還是第三方依賴造成的。

• 按資產價值分層
• 保護配置可以版本化
• 每次變更範圍可解釋
• 失敗時可以回退

驗收結論必須繫結真實候選包

最終範圍應在同一候選包上驗證安裝、啟動、關鍵業務路徑、崩潰、包體、資源消耗和目標系統版本。單次演示透過不能替代持續迴歸。

如果還沒有候選包，只能給出選擇方法和待驗證項，不能提前承諾效能損耗、相容範圍或防護結果。