檔案來自cnblogs 黑暗伯爵,文章地址:http://www.cnblogs.com/hangxin1940/archive/2011/07/10/2102087.html
之前是windows版的一個shell,黑暗伯爵改成了linux版本的,這是完整的包:/Files/super119/AndroidRootAndRecovery.zip
從指令碼來看,最關鍵的就是這個程式了:rageagainstthecage。粗粗google了一下,貌似這個程式以hack的方式,將運行在終端裝置上的adbd daemon進程以root的身份重啟,這樣裝置上的adbd就變成root許可權,從而我們可以在PC上通過adb來做很多root才能做的事情了 -- 比如,將/system掛載成rw,拷貝su, busybox這些玩意到ROM裡面,安裝recovery等等。
至於rageagainstthecage的hack方式,是通過不停的fork進程到進程數上限,然後裝置上adbd會重啟(有一定的幾率,是否會一定重啟到adbd),然後adbd重啟之後,在調用setuid將自己設定成非root使用者的時候,setuid會失敗,但是Android的adbd的代碼並沒有檢測setuid是否失敗了,於是,最終adbd以root身份運行了。下面是找到的英文解釋,有空去看下adbd的代碼,自己跟一下就清楚了:
First the code will check that there is an NPROC setting. This is the maximum number of simultaneous processes which the system will allow. A quick “ulimit -a” once connected over adb should show you this setting for your device (this is set to 3301 processes on a Droid Incredible). The code will then try to find the process ID of the currently running
adb daemon on the device. After that, the attack starts a loop to generated processes until it can no longer fork any more processes. Once the limit is hit, one process is killed off and the adb daemon process is restarted. As the code comment points out, this is a bit of a race at this point to make sure the adb can restart, but the number of processes stays maxed out. When the adb daemon starts up on an Android device, it is running as root. The code will later check if it should stay as root, or run in “secure” mode which drops its privileges to the “shell” account. This attack attemps to max out the process so that when the adb daemon attempts to call “setuid” in its code, the call will fail. The current adb code does not check if the setuid call was successful or not, so will happily keep running as root even if this fails.