許多開發者關心：App 在已 Root 的 Android 裝置上運行，資料是否安全？ 簡短回答：風險顯著增加，傳統沙箱隔離失效，必須採取額外防護措施。
Root 裝置的兩大核心風險
- 使用者可直接存取 App 私有目錄：
/data/data/com.your.package/ 下的 SharedPreferences、資料庫、快取檔案均可被 Root 使用者讀取、修改、刪除。
- 其他 App 可繞過權限檢查存取資料：惡意 App 取得 Root 權限後，可讀取任意 App 的私有檔案、注入程式碼、Hook 系統 API 竊取記憶體資料。
分層防護策略
第一層：根本原則——敏感資料不落地
- **不儲存** 明文密碼、Token、金鑰、個資至裝置。
- 需持久化時：加密後再存，解密鑰匙由 Server 下發或衍生自使用者輸入（如生物辨識、PIN）。
- 記憶體中處理完畢立即清除（
Arrays.fill(byteArray, (byte)0)）。
第二層：加密演算法與金鑰管理
- 採用 **AES-256-GCM** 或 **ChaCha20-Poly1305**（需 API 20+），避免自行設計「混淆演算法」（如
savedValue = (((realValue*10)+1)/365*23)*50+1 這類安全性極低的混淆）。
- 金鑰**不硬編碼**在程式碼、不存 SharedPreferences。使用 Android Keystore System（硬體支援 TEE/StrongBox）生成、儲存金鑰，金鑰不可導出。
- 關鍵操作（付款、解密）在 **Server 端** 執行，客戶端僅負責收集輸入、顯示結果。
第三層：Root 偵測與風險控制
- App 啟動時檢測 Root 特徵（
su 二進位檔、Magisk 隱藏特徵、build.tags=test-keys 等）。
- 偵測到 Root：拒絕啟動、限制功能（唯讀模式）、上報風控系統**、要求裝置驗證**（SafetyNet / Play Integrity API）。
- 注意：Root 偵測非絕對可靠（Magisk 可隱藏），需配合 Server 端風控。
第四層：程式碼保護與完整性驗證
- 啟用
minifyEnabled true + shrinkResources true + ProGuard/R8 混淆。
- 關鍵邏輯（加密、授權、Root 檢測）移至 **Native 層 (C/C++ NDK)**，增加逆向難度。
- 使用 **VMP 加固**（如騰訊樂固、愛加密、Bangcle）或 **RASP**（Runtime Application Self-Protection）偵測 Hook、注入、調試器。
總結：安全是系統工程，非單點防禦
| 層級 | 核心措施 |
|---|
| 資料層 | 不落地、強加密、Keystore 管鑰、Server 端核心運算 |
| 環境層 | Root 偵測、Play Integrity 驗證、模擬器偵測 |
| 程式碼層 | 混淆、NDK 關鍵邏輯、加固、RASP |
| 傳輸層 | TLS 1.2+、Certificate Pinning、簽名驗簽 |
Root 裝置將 App 置於「敵對環境」，唯有**假設客戶端完全不可信**、將核心邏輯與金鑰前置至 Server、配合多層客戶端防護，才能將風險降至可接受範圍。
