『转自墙外』 [Android] Root 原理與手動 Root 詳細過程 @ Nexus One、Android 2.3.3、Ubuntu 10.04

前幫 SE X8 with Android 2.1 做過一次 root ([Android] Sony Ericsson XPERIA X8 - Root 教學、關閉拍照聲音)，使用的是 SuperOneClick，僅需抓一下手機驅動程式、連接好 micro usb 線，執行程式並按下按鈕，整個過程就結束了。隨後我開始研究到底 root 做了啥事，因為我總覺得好像只要把 su 這隻程式擺進 Android 系統中 ( /system/bin 和 /system/xbin ) ，似乎就完成動作了？？

幾番研究後，追了一些文章，其中看到這篇寫得滿仔細的：Simple SDK setup and manual root guide (Windows)，經測試也算正常 work 啦，不過有一些過程並不一樣，就順手記一下好了。除此之外，經過這幾篇的操作，稍微明瞭也修正一些觀念：

重灌：

在 [Android] 第一次使用實體手機 + 清乾淨 + 重裝系統 @ Nexus One 中，自以為透過  "重設為原廠設定" 和 "Recovery from update.zip" 可以回到最乾淨的系統狀態，事後我發現當我把手機 root 後並安裝 Superuser 後，經過上述兩者並不會移除 Superuser 程式，也讓我想起來看到 update.zip 裡頭的 script 事情，是的，上述兩者只能說依照 script 去做事，所以 script 上頭沒提到的就不會做。所以真正要清乾淨系統的方式，應該是要透過 flashboot 去重刷整個系統，如 [Android] Building AOSP & Back to Original Shipping Image @ Nexus One 、Ubuntu 10.04 x86 & Mac OSX 10.6.7 這篇中間所提到，完整清除資料並刷回原廠等動作。這樣也就很清楚為啥想要回復到原廠狀態需要 "原廠 ROM" 囉。

Root 原理：

整個流程目的是將修改後的 su 指令擺進 /system/bin 目錄中(有的還會提到 /system/xbin)，然而，預設系統是 Read Only 的，所以想辦法取得 root 權限，接著將系統弄成 Writable 後，把修改過的 su 擺好位置，除此之外，則是將 Superuser.apk 擺進 /system/app ，對 /system/app 目錄進行動作，等於安裝一套軟體，同理把程式移出去就代表移除，實際例子可參考 [Android] Sony Ericsson XPERIA X8 - 刪除內建程式。而 Superuser 這是一款可以管理 root 權限的程式，可以在 Android 手機上操作使用，常常被用來判斷你的手機是否 root 過，因為修改過的 su 版本都是搭配此程式使用的，故一般有 root 過的手機應該都會裝 Superuser 囉

總結流程：

設法拿到 root 權限 -> 更改系統為可讀寫狀態 -> 把修改版的 su 放進 /system/bin -> 安裝 Superuser.apk (擺進 /system/app 裡) -> 回復系統狀態 -> 收工

Root 方式：

手動處理

使用 Android SDK 之 adb 程式，透過 adb push 把檔案移到手機內，並透過 adb shell 連進手機，後續動作如 root 原理流程

透過 SuperOneClick.exe 代勞

實例參考：[Android] Sony Ericsson XPERIA X8 - Root 教學、關閉拍照聲音，仔細看程式的輸出的每一步，就是上述 root 原理的流程啦

透過安裝某個程式 (*.apk)

透過他搶到執行權限，接著把程式內偽裝成圖檔的程式執行(副檔名皆為 png 或 jpg 類的)，如此一來也能搞定

透過 update.zip 進行系統回復

仔細去看 script 就可以看到 root 原理的流程喔

在此以 Nexus One with Android 2.3.3 為例，在 Ubuntu 10.04 進行手動 root 流程：

以下是以 Nexus One with Android 2.3.3 進行測試的，不確定是否適用於其他手機環境，並且 root 手機存在風險，其自行評估負責，在此僅供個人筆記使用

Step 0：取得 Android SDK (此步驟可以跳過，因為接下來所需的檔案都在 GingerBreak.zip 裡都有)

只需從 Android SDK - http://developer.android.com/sdk/index.html 下載 Android SDK 後，並更新 SDK 即可。(執行 Android SDK 需要 Java 執行環境，別忘了抓一下 Java SDK 啦)

若在 Windows XP 則需要更新 Android SDK 以取得驅動程式，驅動程式擺在 C:\Program Files\android-sdk\extras\google\usb_driver\ 裡，記得 Nexus One 有普通模式(Google, Inc. Nexus One)和 fastboot 模式(htc, Inc. Android 1.0)，兩者所使用的驅動程式不同，但資料都在上述的目錄中。

Step 1：使用 GingerBreak.zip 為例，在 Simple SDK setup and manual root guide (Windows) 下載

裡頭有兩個目錄，一個是有 adb 程式，另一個有 Nexus One 之 Windows 上的驅動程式。

Step 2：在 Ubuntu 10.04 上，設定 USB 對應；在 Windows 上，則是安裝驅動程式(當設備接時，透過指定驅動程式的目錄來安裝)

此為 Ubuntu 10.04 的設置，若是 Windows 可跳過

$ sudo vim /etc/udev/rules.d/51-android.rules

# adb protocol on passion (Nexus One)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e12", MODE="0600", OWNER="<username>"
# fastboot protocol on passion (Nexus One)
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0fff", MODE="0600", OWNER="<username>"
# adb protocol on crespo (Nexus S)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e22", MODE="0600", OWNER="<username>"
# fastboot protocol on crespo (Nexus S)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e20", MODE="0600", OWNER="<username>"

別忘了將 <username> 替換掉。

$ sudo service udev restart

Step 3：正式進入 root 流程，使用 adb 指令與 Nexus One 互動

首先，將 Nexus One 啟動 USB Debug 模式，在 [設定] -> [應用程式] -> [開發] -> [USB 偵錯] 後，並使用 micro usb 與 PC 連接

使用 adb devices 確認是否有連到機器，應該要可以看到 HT##### 的東西：

$ adb devices

使用 adb push 將 GingerBreak.zip 裡的 su 、 Superuser.apk 、GingerBreak 和 busybox 複製到 /data/local/tmp 中：

$ adb /path/GingerBreak/su /data/local/tmp/
$ adb /path/GingerBreak/Superuser.apk /data/local/tmp/
$ adb /path/GingerBreak/GingerBreak /data/local/tmp/
$ adb /path/GingerBreak/busybox /data/local/tmp/

關於 busybox 的東西，其實，主因是 Android 手機內的環境沒有 cp 指令，所以上述作者透過 busybox 來做 copy 的動作。

使用 adb shell 連進手機查看：

$ adb shell
$ cd /data/local/tmp
$ ls -l
busybox
Superuser.apk
GingerBreak
su

透過 GingerBreak 取得 root 權限：

$ cd /data/local/tmp
$ chmod 755 GingerBreak
$ ./GingerBreak

[**] Gingerbreak/Honeybomb -- android 2.[2,3], 3.0 softbreak
[**] (C) 2010-2011 The Android Exploid Crew. All rights reserved.
[**] Kudos to jenzi, the #brownpants-party, the Open Source folks,
[**] Zynamics for ARM skills and Onkel Budi

[**] donate to [e-mail] if you like
[**] Exploit may take a while!

[+] Plain Gingerbread mode!
[+] Found system: 0x######## strcmp: 0x########
[+] Found PT_DYNAMIC of size 232 (29 entries)
[+] Found GOT: 0x########
[+] Using device /devices/platform/goldfish_mmc.0

vold: 0063 GOT start: 0x######## GOT end: 0x########

vold: 0063 idx: -#### fault addr: 0x########

[+] fault address in range (0x########,idx=-####)
[+] Calculated idx: -####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

vold: 0635 idx: -000####

[!] dance forever my only one
#

當看到 "dance forever my only one" 以及提示符號從 "$" 換成 "#" 時，代表取得"暫時性"的 root 權限了。依照 GingerBreak 的執行過程，感覺有點類似透過 Buffer Overflow 去取的 root 權限，但細節不清楚還需研究。

趁著 root 權限時，將系統設定為可讀寫：

# mount
...
/dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0
...
# mount -oremount,rw /dev/block/mtdblock3 /system
# mount
...
/dev/block/mtdblock3 /system yaffs2 rw,relatime 0 0
...

將 su 和 Superuser.apk 移到特定位置：

# cd /data/local/tmp
# chmod 755 busybox
# chmod 777 /system/bin /system/app
# ./busybox cp /data/local/tmp/su  /system/bin/
# ./busybox cp /data/local/tmp/busybox  /system/bin/
# ./busybox cp /data/local/tmp/Superuser.apk /system/app
# chown root /system/bin/su /system/bin/busybox
# chmod 4755 /system/bin/su
# chmod 755 /system/bin /system/app

回復系統狀態：

# mount
...
/dev/block/mtdblock3 /system yaffs2 rw,relatime 0 0
...
# mount -oremount,ro /dev/block/mtdblock3 /system
# mount
...
/dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0
...

清除垃圾：

# cd /data/local/tmp
# ls
busybox
sh
boomsh
Superuser.apk
GingerBreak
su
# rm busybox sh boomsh Superuser.apk GingerBreak su
# ls
#

收工！此時可以在手機上看到 Superuser 程式，接著離開 root 環境、adb shell：

# exit
$ exit

別忘了把手機重開，就完成 root 動作！

以 adb shell 測試 root：

重開機後，使用 adb shell 與手機連線，並使用 su 指令切換成 root，可以看見手機畫面有訊息：

$ adb shell
$ su



如果沒有動作，隨著倒數時間一樣會被拒絕，而按下拒絕的結果，那就是熟悉的拒絕句子：

su: permission denied

若按下允許，自然就會從 "$" 換成 "#" 並取得 root 權限。

以 app 測試 root：

從 Android Market 安裝 SSHDroid 這程式，這是 SSH Server ，把他的預設開啟的 port 調到 22 (<1024也可)，接著選 Start 後，可以看到詢問頁面：



一樣按下拒絕程式就會顯示相關錯誤訊息，若按下允許，那就會正常執行，並可以看到服務成功綁在 22 port：



接著可以透過 ssh root@10.0.2.3 的方式登入 Android 手機，此時就是以 root 權限執行任何動作囉！





最後，來提提上述重要程式的細節，先來說說 GingerBreak 這隻程式，總共才 550 行上下，但使用的系統觀念很多，我也還不太了解，稍微筆記：

複製一份 /proc/self/exe 和 /system/bin/sh 擺在 /data/local/tmp 中，分別為 boomsh 和 sh
依照系統編譯的版本，決定等會要使用的策略
從 /proc/net/netlink 中，取出執行中的 vold 資訊(pid)
從 /system/libc/libc.so 找尋 system 和 strcmp 相關的特徵
從 /system/bin/vold 中，找尋相關資訊(還不太懂，晚點再看)
從 /etc/vold.fstab、/system/etc/vold.fstab 中，找尋一個 dev_mount 裝置，若都找不到改用 /devices/platform/msm_sdcc.2/mmc_host/mmc1 。
透過 socket 不斷寫資訊給執行中的 vold (在 vold src 中可看到 process_config函數)，類似請他掛載裝置。
一直重複動作 7 直到系統出錯而拿到 root 權限。
關於 GingerBreak 的部分還不太懂，上述極可能有誤，有空再仔細查看。

接著提提 su 的部分，原版 su 部份，在 http://android.git.kernel.org/?p=platform/system/extras.git;a=blob;f=su/su.c 可看到 line 60 的片段：

/* Until we have something better, only root and the shell can use su. */
myuid = getuid();
if (myuid != AID_ROOT && myuid != AID_SHELL) {
    fprintf(stderr,"su: uid %d not allowed to su\n", myuid);
    return 1;
}

可知當執行的 uid 必須是 AID_ROOT 或 AID_SHELL 時，才能取得權限。看看修改後的 su，在 https://github.com/ChainsDD/su-binary 可取得 su.c、su.h 和 activity.cpp 三程式，其中 main 寫在 su.c，稍微研究一下流程：

取得等待使用 root 權限的程式指令
如果運行身份是 AID_ROOT 就讓他通過，結束A
從資料庫的紀錄中，判斷該程式指令是否已經被設定成允許或拒絕，如果資料庫裡有資料，那馬上回應 allow 或 deny，結束B
如果資料庫中沒資料，接著開啟一個 socket 連線，並且隨後叫起 Superuser 管理介面，詢問使用者是否要允許或拒絕
從 Superuser 介面得知使用者的回應，透過 sockect 回傳，而 su 將依照結果給予 allow 或 deny，結束C
上述共有 3 種正常的結束方式，不正常的結束就不多提。因此，這個 su 程式，整體上須搭配 Superuser.apk 來使用，依需求叫起 com.noshufou.android.su.REQUEST 或 com.noshufou.android.su.NOTIFICATION 出來，並把使用者決定的結果回傳至 socket 連線。除此之外，若使用者勾選記憶目前的設定，代表以後將默認為允許或拒絕，那 Superuser 介面上還會把允許或拒絕的結果一同紀錄到 databases 中。

那 root 的安全問題？

Q1：惡意程式若直接先改寫資料庫資料，不就可以安然通行？

由 su.h 中得知，資料庫擺在 /data/data/com.noshufou.android.su/databases/permissions.sqlite 位置，該路徑上的存取是需要 root 權限，因為惡意程式還沒取得 root 權限，所以無法變更資料庫內容。但他也還是可以走 GingerBreak 流程，透過漏洞取得 root 權限。

Q2：只要都透過 Superuser 管理，這樣就十分安全嗎？

不。假設有 A, B 兩個程式，其中 A 是介面上看起來超讚超方便的便利程式，但他在使用時需要 root 權限，而使用者也給予並默認後，以後他就用 root 權限一直運行。結果 B 是惡意程式，雖然他無法拿到 root 權限，但 A 可以幫他啊(幫 B 更新資料至資料庫中)，所以，一隻惡意程式無法自行運行，但如果有搭配套餐的模式，那麼 B 就有機會取得。整體上這個權限機制並非十分安全，但對一般情況來說，算是夠了。

Q3：如何安全使用？

定期去查看 Superuser 上的紀錄，請盡可能搞懂給予 root 權限的程式到底做了什麼事。隨意下載的程式，沒有使用要記得移除。

結論：

記得去年就看 iOS app 相關文章，隨著 app 的量大，就曾聽到別人提過，以後使用者可能都只使用大廠軟體，就像現實生活中，人會有追求名牌的行為，這個現象將導致名牌廠會越做越好越大，在加上商譽影響，名牌廠就比較不會有惡意程式的行為，雖然仍不可保證就絕對不會有惡意。此外，其他無名程式，依舊存在惡意程式的機會，為了降低風險，資安意識下，就比較會去用 open source 或原廠軟體，以通訊軟體來說，有 MSN、Mail 等類，與帳號、隱私有高度相關性，雖然原廠不見得做的好或方便操作等，但基於資安方面，還是建議安裝原廠程式，不然就是使用有用原廠公開 API 的開發程式。

參考資料：

https://github.com/ChainsDD/su-binary/blob/master/su.h
https://github.com/ChainsDD/su-binary/blob/master/su.c
https://github.com/ChainsDD/su-binary/blob/master/activity.cpp

https://github.com/ChainsDD/Superuser/blob/master/AndroidManifest.xml
https://github.com/ChainsDD/Superuser/blob/master/src/com/noshufou/android/su/SuRequest.java
https://github.com/ChainsDD/Superuser/blob/master/src/com/noshufou/android/su/SuNotificationReceiver.java

http://rootzwiki.com/wiki/index.php/Gingerbreak
http://wikifilez.com/Root%20Files/gbreak/GingerBreak.tgz
http://wikifilez.com/Root%20Files/gbreak/GingerBreak-v1.00.apk
http://wikifilez.com/Root%20Files/gbreak/GingerBreak-v1.10.apk

http://android.git.kernel.org/?p=platform/system/vold.git;a=tree
http://android.git.kernel.org/?p=platform/system/vold.git;a=blob;f=main.cpp