Root 是 Android 系統最高權限的代名詞。本文從 Linux 權限模型出發,深度剖析 Android Root 的核心機制:**su 二進制檔案、setuid 權限位、SELinux 防禦與繞過、Magisk 無痕掛載架構**,並說明廠商如何阻止 Root 及安全檢測手段。
Linux 中可執行檔若設定 **setuid 位(`chmod 4755`)**,執行時進程擁有者將變為檔案擁有者(通常是 root)。
-rwsr-xr-x 1 root root 123456 su # s 表示 setuid
普通用戶執行此 su 即獲取 root 權限。**Android 繼承此機制**,但出廠預設不包含 su 二進制檔,且系統分區掛載為 `nosuid`,導致即使推送 su 也無法生效。
su 二進制推送至系統分區(/system/xbin/ 或 /system/bin/),此分區無 `nosuid` 限制且在 PATH 中。chown root:root su && chmod 4755 su。死結: 上述操作本身需要 root 權限 → 先有雞還是先有蛋?
早期 Android 版本存在眾多內核/系統服務漏洞(如 zergRush 利用 vold 堆疊溢位),攻擊者透過已擁有 root 的進程上下文執行上述指令。現代 Android(5.0+)加強了 SELinux、內核強化、dm-verity,傳統漏洞利用極難。
Magisk 不修改 /system 分區,改用 **掛載命名空間** 在啟動階段將修改後的檔案覆蓋掛載至系統路徑:
su 介面,管理 App 授權。avc: denied)。magiskpolicy 動態注入允許規則,或將 su 執行於 u:r:magisk:s0 等寬鬆域。| 手段 | 原理 |
|---|---|
| dm-verity | 啟動時驗證系統分區完整性,任何修改導致開機失敗 |
| 硬體抽象層 (HAL) 鎖定 | Bootloader 鎖定,禁止刷入修改過的 boot.img |
| SafetyNet / Play Integrity API | 雲端驗證設備完整性、CTS Profile、Root 檢測 |
| SELinux Enforcing + 策略收緊 | 限制 root 進程實際能執行的操作 |
| 應用層檢測 | 檢查 su 二進制、magisk 掛載點、Superuser.apk 等特徵 |