首先關於Root的方式，這裡不做詳解，可以有很多漏洞，比如利用uid溢位後歸為0，得到Root許可權，然後操作檔案系統等。 手機Root後，最重要的是，給手機安裝了su程式和superuser apk。 su一般被安裝在/system/xbin 或者 /system/bin 下面，su檔案的許可權如下： # ls su -l
ls su -l
-rwsr-sr-x    1 root     root         26336 Aug  1  2008 su 這裡可以看到，su的Owner和Group分別為Root，Root。 Other使用者具有exeute許可權，另外，su設定了suid和sgid，這個非常重要，後面會詳述，這個使得Su程序可以提升自身的EUID。 我們這裡以RootExplorer為例，看是如何申請和提升許可權的： 首先，ps一下，可以看到root explorer的資訊，這裡第一列是UID，更加準確的，應該是EUID。 app_73    1143  103   301620 39944 ffffffff 400194c4 S com.speedsoftware.rootexp
lorer 這裡可以看到，Root Explorer的EUID=10073（App Base是從10000開始的） 然後，Root Explorer通過Runtime方式，使用shell 命令列運行了“su”， 所以，會有一個Root Explorer啟動的sh： app_73    1159  1143  764    376   c003e454 4001cf94 S /system/bin/sh default情況下，程序的UID是繼承的，這裡sh的PPID是1143，說明是RootExplorer啟動的。 RootExplorer通過類似下面的程式碼執行“su”：

p = Runtime.getRuntime().exec("su"

);    

所以，1159  PID的sh會啟動su，這裡需要注意的是，su程序的Real UID是10073，因為繼承自parent，但是，其EUID卻提升為了ROOT，這就是由於SUID被設定的原因。 由於su程序的EUID是ROOT，所以導致了su可以做很多高許可權的事情。

su會通過：

sprintf(sysCmd, "am start -a android.intent.action.MAIN -n com.koushikdutta.superuser/com.koushikdutta.superuser.SuperuserRequestActivity --ei uid %d --ei pid %d > /dev/null", g_puid, ppid);
  if (system(sysCmd))
   return executionFailure("am.");

啟動SuperUser Request Activity來詢問使用者是否授權當前應用，如果否的話，則su將return 結束， 否則su會繼續執行。

得到使用者許可後（通過sqlite和SuperUser Request Activity交流使用者許可），su會將自己的Real UID也設定為ROOT：

 if(setgid(0) || setuid(0))
  return permissionDenied();

由於su的EUID是ROOT，所以su有許可權執行以上程式碼，執行完後su程序的Real UID，effective UID都變成了ROOT。 這裡為什麼要同時提升Real UID的許可權，後面會說明。

然後，su會啟動一個額外的sh來執行使用者的指令：

char *exec_args[argc + 1];
 exec_args[argc] = NULL;
 exec_args[0] = "sh";
 int i;
 for (i = 1; i < argc; i++)
 {
  exec_args[i] = argv[i];

 }
 execv("/system/bin/sh", exec_args);
 return executionFailure("sh");

 這裡非常關鍵的程式碼是execv！ 這裡沒有使用fork，而是直接使用execv，這將導致不會建立新的程序執行sh image，而是直接在當前su的程序空間load並執行sh image。 所以，return executionFailure("sh"); 正常情況下是永遠不會被執行的，執行完execv後，就開始直接sh的程式碼了。

這裡可以看到，由於複用su當前程序來執行sh，使得sh執行的程序的EUID，Real UID都是ROOT，那麼，任何操作都可以執行了。 如果不提升Real UID為Root的話，那麼只要sh執行中通過啟動外部程式的方式來完成操作的話，就會出現許可權問題，因為新啟動的程序只會繼承父程序的Real UID，而不是EUID，那麼新起的程序的Real UID=EUID= parent RealUID ！= ROOT，那麼某些操作可能有問題。 所以，su把自己的Real UID也提升為ROOT後，則不管啟動後的任何代後的子程序執行操作，都是以ROOT的許可權執行。

RootExplorer通過得到sh流後，就可以通過該流執行任何shell指令了：

1. try {   
2. // Preform su to get root privledges
3.    p = Runtime.getRuntime().exec("su");    
4. // Attempt to write a file to a root-only
5.    DataOutputStream os = new DataOutputStream(p.getOutputStream());   
6.    os.writeBytes("echo \"Do I have root?\" >/system/sd/temporary.txt\n");   
7. // Close the terminal
8.    os.writeBytes("exit\n");   
9.    os.flush();   

通過ps也可以明顯看到su變成了sh，如下，

app_73    1143  103   301620 39944 ffffffff 400194c4 S com.speedsoftware.rootexp
lorer
app_73    1159  1143  764    376   c003e454 4001cf94 S /system/bin/sh
root      1161  1159  772    388   c012e760 4007c578 S sh

這裡的PID=1161的程序其實是su（可以通過打log驗證），當執行execv("/system/bin/sh", exec_args);後，程序名就變成了sh。當然程序EUID不變，仍然是ROOT。

通過cat 程序的proc資訊，我們也可以看到其實RootExplorer自身的UID或者許可權根本沒有被提升（這是和linux上執行su不一樣的地方），

[email protected]:/proc/1143 # cat status
cat status
Name:   re.rootexplorer
State:  S (sleeping)
Tgid:   1143
Pid:    1143
PPid:   103
TracerPid:      0
Uid:    10073（Real）   10073（Effecttive）   10073（saved）   10073
Gid:    10073   10073   10073   10073

而su演變成的sh，卻是具有所有的ROOT UID：

[email protected]:/proc/1161 # cat status
cat status
Name:   sh
State:  S (sleeping)
Tgid:   1161
Pid:    1161
PPid:   1159
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0

總結： Android中App授權獲取Root許可權，其實不是App自身的許可權提升了，而是通過具有ROOT許可權的sh流來執行shell命令