Android SuperUser.apk 跟 su 之間的關係

Android SuperUser.apk 跟 su 之間的關係

此篇文章記錄了Android 被Root之後，使用者怎麼允許其他apk取得root的權限

首先先來看第三方APK是怎麼執行特殊權限的指令，下面是 DroidVNCServer的Code，是先執行su再執行需root權限的C程式

Process sh = Runtime.getRuntime().exec("su");

OutputStream os = sh.getOutputStream();

writeCommand(os, "chmod 777 " + getFilesDir().getAbsolutePath() + "/androidvncserver");

writeCommand(os, getFilesDir().getAbsolutePath() + "/androidvncserver " + password_check + " " + rotation + " " + scaling_string + " " + port_string + " " + testmode);

上面可以看到新增一個 Process object有了 root 權限之後，就可以執行 androidvncserver 這支程式了。

所以，第三方APK一定要先執行 sh 這支程式，但如果每支程式都可以隨便取得root的話就麻煩了，所以su就要搭配一支通知使用者的程式就是 SuperUser.apk。

su.c 的流程，首先因為第三方APK執行su，所以 su 可以取得 ppid，就是ProcessId of Parent Process。

有了PPID之後，就可以透過"ls –l"去查 /proc/$(PPID) 這個檔案的 owner 是誰。格式會是 app_$(user_id)，所以取得 user_id，也就是執行第三方APK的使用者，真正的UserId會是10000+ $(user_id)。此紀錄寫在/data/system/packages.xml，看第三方apk file的 owner 跟 group 都是 system，應該是在執行的時候才換UserId的，確定每一個APK都會對應一個永久的 UserId。

取得UserId之後，就去白名單資料庫裡面檢查有沒有包含這個UserId，也就是這支Apk能不能執行su的意思～

如果可以，就 call setuid 然後 execv 成 sh 了。注意，su程式有 setuid，且 owner 是root，所以 setuid 之後就變成root的sh了。

如果資料庫中找不到此UserId，就會透過 am start 把UserID跟PPID傳給SuperUser.apk，SuperUser.apk透過Intent取得此兩項資訊，再透過 ps filter UserId來取得要顯示的PackageName讓使用者選擇

選了Always之後，就在白名單中加入一筆，Count=10000的資料，選是就Count=1，選否就Count=-1;

接著回到su去判斷，su每次取得Count之後，都會把count-1，如果減一之後為0，就把此UserId移除白名單。

Android/Linux 是怎麼去管理每一支APK的UserId的？根據http://developer.android.com/guide/topics/security/security.html

At install time, Android gives each package a distinct Linux user ID. The identity remains constant for the duration of the package's life on that device. On a different device, the same package may have a different UID; what matters is that each package has a distinct UID on a given device.
紀錄在 /data/system/packages.xml

問題：

不知道有沒有是JAVA層級就可以直接取得Root權限的方式。

下面是網路上找到的，也順便分享，加上一點筆記了～
今日在做一個項目，要求有免費版與收費版，打算在同一個工程裡面，通過判斷來分別實現免費版和收費版不同的功能。這樣做可以省去重複編寫代碼。但Android的以下機制令我放棄了這種想法：

1.同一Apk中的同一包中的Activity調用時進程狀況驗證
同一Apk中同一個Package的Activity運行在同一個Process
[1]創建Project：
project name: FirstProject
package:com.demo
默認Activity:MainActivity
[2]添加一個新的Activity：
name:SecondActivity
[3]修改佈局。在MainActivity佈局中添加一個Button，當點擊此Button時啟動SecondActivity。在SecondActivity的佈局中放置一個Textview，以證明SecondActivity已啟動。
[4]運行程序，查看此Ap進程情況：
USER：app_36 PID：8360 NAME：com.demo
點擊按鈕，啟動SecondActivity，再次查看進程情況：
USER：app_36 PID：8360 NAME：com.demo
進程列表沒有變化，兩個Activity運行在同一進程中。

2.同一Apk中的不同包的Activity調用時進程狀況驗證
同一Apk中不同的Package的Activity運行在同一個Process
[1]將SecondActivity挪到包com.demo.second中去，相應修改AndroidManifest.xml中的name為：com.demo.second.SecondActivity
[2]運行程序，查看此時進程情況：
USER：app_36 PID：10593 NAME：com.demo
[3]點擊按鈕啟動SecondActivity，查看此時進程情況：
USER：app_36 PID：10593 NAME：com.demo
進程列表沒有變化，兩個Activity運行在同一進程中。即進程name只受AndroidManifest.xml中manifset結點的package屬性影響。

3.同一Apk中Activity process屬性修改後進程狀況驗證
可以透過 AndroidManifest.xml裡面添加屬性讓不同的Activity跑在不同的Process
[1]為SecondActivity添加process屬性，其值為:abc，也可以隨便是其他的:開頭的字符串，常見的是:remote：

[2]運行程序，查看進程情況：
USER：app_36 PID：12137 NAME：com.demo
[3]點擊按鈕，啟動SecondActivity，查看進程情況：
USER：app_36 PID：12137 NAME：com.demo
USER：app_36 PID：12303 NAME：com.demo:abc
進程表多了一項。兩個Activity各自有一個進程，SecondActivity的進程名稱為 包名+後綴

4.不同Apk中不同包名的Activity進程狀況驗證
不同Apk不同Package的Activity跑在不同的Process
[1]運行FirstProject：
USER：app_36 PID：12137 NAME：com.demo
[2]創建SecondProject：
project name: SecondProject
package:com.demo2
默認Activity:MainActivity
[3]運行SecondProject：
USER：app_37 PID：14191 NAME：com.demo2
進程表多了一項。兩個Activity各自有一個進程，同時其進程用戶名、包名也不同，互不影響。

5.不同Apk，簽名相同、包名相同的Activity進程狀況驗證
系統是透過key跟PackageNamme去決定唯一的apk
[1]修改SecondProject的包也為com.demo，相應要修改AndroidManifest.xml內容。
[2]運行SecondProject，查看進程情況：
USER：app_36 PID：14944 NAME：com.demo
進程表只有一項，但是實際上FirstProject此時已經被覆蓋了，系統中只存在SecondProject了，因為模擬器調試時apk使用的簽名key都是一樣的，系統看到key一樣，包名一樣認為這個包就是FirstProject所以覆蓋掉了。
可以通過DDMS複製/data/system/packages.xml查看一下內容。

這個文件裡面，package name都是唯一的，同時可以看到用戶名是通過userId來決定的。

6.不同Apk，簽名不相同，包名相同的Activity進程狀況驗證
Package如果相同，Key不一樣，就無法自動安裝，所以要先手動反安裝
常常在兩台PC間安裝同一支程式無法裝就是這個原因
[1]在Eclipse的Package Explorer導航樹中選中FirstProject，點右鍵。
[2]Android tools–>Export Signed Application Package，按照嚮導創建一個用指定key簽名的apk包。
[3]同樣導出Second Project。
[4]切換窗口到模擬器，按Home鍵–>按Menu鍵–>設置–>應用程序–>管理應用程序–>SecondProject–>卸載。這是為了用命令行安裝做準備。
[5]啟動一個命令行窗口，執行adb install firstproject.apk,會提示成功安裝。
[6]執行adb install secondproject.apk，提示安裝失敗。
默認的Apk其安裝時會分配新的UserId，即此時FirstProject以及SecondProject的UserId可以認為是不同的。
包名不同，則簽名key是否相同無所謂，兩個apk都可以安裝。【第4個實驗】
包名相同時，簽名key相同則會覆蓋【第5個實驗】；簽名不同則第二個apk安裝會失敗。【第6個實驗】

7.不同Apk，Share User Id相同，包名不同時進程情況分析
[1]修改firstproject、secondproject的AndroidManifest.xml的manifest結點，增加屬性

android:sharedUserId=com.demouser

com.demouser沒有顯示，只是給系統判斷用?
[2]修改secondproject的包為com.demo2，不然其會覆蓋firsetproject。
[3]運行firsetproject、secondproject，查看進程列表：
USER：app_35 PID：19993 NAME：com.demo2
USER：app_35 PID：20045 NAME：com.demo2
問題：這裡不知道為什麼 firstproject的 NAME會是 com.demo2?應該是打錯了，看下一個實驗就知道，如果包名一樣的話，firstProject會被取代
仍然存在兩個進程。進程的用戶名一樣，說明shareUserId確實有效了，但是進程名字一個不一樣。
再次導出/data/system/packages.xml，查看其內容：

Xml代碼

可以看到兩個項目的UserId都是10035，確實是一樣的。

8.不同Apk，Share User Id相同，包名不同、指定Activity的process屬性進程情況分析
[1]修改SecondProject的MainActivity的process屬性，指定綁定到進程名為com.demo的進程上：

android:process=com.demo>

[2]運行firstProject、SecondProject，查看進程情況：
USER：app_35 PID：21387 NAME：com.demo
firstProject還會繼續執行嗎？
兩個Activity運行於同一個進程。

9.不同Apk，Share User Id相同，包名不同、簽名key不同
經實驗，安裝第二個apk時會提示INSTALL_FAILED_UPDATE_INCOMPATIBLE錯誤，安裝失敗。

總結：
UserId不同時：

包名不同：未設定process屬性時，各自的Activity在各自的進程。
即使process指定了包名，也不會和另一個用戶的同名包共享進程。如果可以的話，就有漏洞啦～

包名相同：

簽名相同：覆蓋舊的同包名apk。

簽名不同：新的apk會安裝失敗。【簽名key一般都是不同的】

UserId相同時：

包名不同：未設定process屬性時，各自的Activity在各自的進程。
process屬性指定，則可以共享進程。

包名相同：

簽名相同：覆蓋舊的同包名apk。

簽名不同：新的apk會安裝失敗。【簽名key一般都是不同的】