前言：破除 App 防護的常見誤區
本文主要的目的是要解釋並說明下列常見問題：
- 「為什麼只靠 ProGuard/R8 保護 App 是不夠的？」
- 「你以為你的 App 混淆了嗎？其實駭客看得很清楚。」
- 「別把『代碼優化工具』當成『資安防護系統』。」
作為資安顧問，我們經常聽到開發團隊詢問：「我們已經開啟了 minifyEnabled true 啟用了 ProGuard/R8，這樣還不夠安全嗎？」
事實上，ProGuard 是為了讓 App 跑得更快、體積更小；而 DexGuard 是為了讓 App 活得更久、資料更安全。 這篇文章將從技術架構與攻防實戰的角度，深度拆解這兩者的本質差異。
架構師觀點
ProGuard (或 R8)：本質是字節碼（bytecode）優化器 (Optimizer)。運用這個工具的目的是減少「冗餘代碼」與「方法數限制」(因為，單個 DEX 檔最多只能包含 65,536 個方法引用)。 你會認為 ProGuard 有進行 App 的「防護」，是因為 ProGuard/R8 有提供了「名稱混淆」的功能。在我們更多瞭解「App 防護」的全貌之後，你會發現「名稱混淆」僅僅只是眾多 App 防護功能之一而已。
而 DexGuard：除了提供 ProGuard 的功能之外，其本質是防護盾 (Protector)。目的是幫助 App 防禦「靜態逆向分析」與「動態時期的竄改」。
在金融、支付或含有敏感個資的 App 架構中，僅依賴 ProGuard 等同於將金庫鎖匙放在門口地墊下。
ProGuard 的本質與安全極限
ProGuard（現今 Android Gradle Plugin 預設多使用 R8）是優秀的開源工具，但我們必須認清它的定位。
ProGuard/R8 的核心任務
- Shrinking (縮減)：透過 Tree Shaking 演算法移除未使用的 Class 與 Method，主要解決 64k 方法數限制問題。
- Optimization (優化)：在 Bytecode 層級進行指令優化，提升執行效能。
- Name Obfuscation (名稱混淆)：將
UserAuthenticationManager重新命名為a.b.c。
# ProGuard 的混淆僅止於「改名」
# 不想被改名的部分要透過 keep rule 進行排除
-keep class com.rlr.innovation.Core { *; }
為什麼這在資安專家眼中不夠？
攻擊者使用工具（如 JADX）反組譯後，雖然類別名稱變成了 a.b.c，但程式邏輯（Control Flow）、字串常數（Strings）與 API 金鑰依然是明文：
- 字串洩漏：API Endpoint、加密金鑰、寫在字串中的密碼在 Bytecode 中清晰可見。
- 邏輯還原：ProGuard 不會改變程式的控制流程，經驗豐富的駭客能輕易還原業務邏輯。
DexGuard：多層次縱深防禦架構
DexGuard 採用的策略是 「縱深防禦 (Defense in Depth)」，分為靜態與動態兩大維度。
1. 靜態防護層 (Static Protection)
當攻擊者拿到 App 的安裝包時，可以進行靜態分析。因此，我們的防禦目的是讓反組譯後的程式碼變得「不可讀」且「難以分析」。
| 功能維度 | ProGuard/R8 | DexGuard |
|---|---|---|
名稱混淆 | ✅ 基礎 (a.b.c) | ✅ 進階 (重載與多型混淆) |
字串加密 | ❌ (明文) | ✅ 全域/局部加密 (執行時解密) |
控制流混淆 | ❌ (保留原始邏輯) | ✅ 扁平化、偽造邏輯 (Spaghetti Code) |
算術混淆 | ❌ (無) | ✅ 隱藏常數運算 |
Native (JNI) 防護 | ❌ (無) | ✅ .so 混淆與字串加密 |
資源/Asset 加密 | ❌ (無) | ✅ 保護 XML, 圖片, 憑證 |
2. 動態防護層 (RASP - Runtime Application Self-Protection)
這是資安架構中最關鍵的一環。當 App 運行在受駭環境（Compromised Environment）時，DexGuard 充當了 App 的「免疫系統」。 因此，我們需要在 App 運行時，透過各項運行環境的檢測，判斷 App 是否在一個「安全」的環境。
像是：
- 環境偵測：偵測 Root 權限(Magisk, KernelSU)、模擬器、虛擬空間 (Virtual Space)。
- 攻擊偵測：偵測 Hooking 框架 (Frida, Xposed)、動態除錯 (Debugger Attachment)。
- 竄改偵測：驗證 APK 簽章與完整性，防止 Repackaging (二次打包)。
攻防實戰：靜態分析與動態注入
為了更具體說明，我們來看兩個常見的攻擊場景：
場景 A：API 金鑰竊取 (靜態分析)
- ProGuard 保護下：攻擊者使用
grep搜尋 APK 反組譯代碼，直接找到String apiKey = "AIzaSy..."。 - DexGuard 保護下：字串被加密且分散儲存，並在執行時透過反射或 Native 層動態解密。攻擊者看到的只有一堆亂碼與複雜的解密函數調用。
場景 B：繞過生物辨識驗證 (動態注入)
- ProGuard 保護下：攻擊者使用 Frida 腳本 Hook
onAuthenticationSucceeded方法，強制回傳true，直接繞過指紋驗證。 - DexGuard 保護下：
- 偵測：App 啟動時偵測到 Frida 守護進程或異常記憶體段。
- 防禦：App 自動崩潰 (Crash) 或向伺服器發送威脅警報 (透過 ThreatCast)。
- 阻礙：即使攻擊者嘗試 Hook，由於方法名稱與控制流已被高度混淆，定位 Hook 點變得極度困難。
技術決策矩陣
作為顧問，我建議根據 「資產價值」 與 「風險模型」 來選擇工具：
適用 ProGuard/R8 的專案
必須使用 DexGuard 的專案
合規性考量
若您的 App 需要通過以下資安檢測或法規，DexGuard 幾乎是標準配備：
- OWASP MASVS (Mobile Application Security Verification Standard)
- PCI-DSS (支付卡產業安全標準)
- GDPR (對於資料保護的技術要求)
- 台灣金管會針對金融 App 的資安檢測基準
結語
「只做名稱混淆」不等於「安全」，「做了字節碼優化」也不等於「防護」。
在現代 App 架構中，ProGuard 負責讓程式跑得更好，而 DexGuard 負責確保程式是在安全的環境下執行正確的邏輯。對於我們的客戶，通常建議在專案初期就將 DexGuard 納入 CI/CD 流程，落實 DevSecOps，而非在發布前才倉促防護。
想評估您的 App 是否需要導入 靜態/動態RASP 防護？或需要協助設定複雜的 DexGuard 規則？歡迎聯絡珥力創新技術顧問團隊進行安全健檢。