Root Android and install recovery Linux Shell script & Android root Principle

The file is from the Dark Count of cnblogs,ArticleAddress: http://www.cnblogs.com/hangxin1940/archive/2011/07/10/2102087.html

 

Previously, it was a Windows shell, and the dark count was changed to the Linux version. This is the complete package:/files/super119/androidrootandrecovery.zip

 

From the script point of view, the most important thing is thisProgramNow: rageagainstthecage. It seems that this program restarts the adbd daemon process running on the terminal device in the form of hack, so that the adbd on the device becomes the root permission, so that we can do a lot of root tasks on the PC through ADB-for example, Mount/system to RW, copy Su, busybox, and install recovery.

As for the hack method of rageagainstthecage, the maximum number of processes is reached through the fork process without stopping, and the adbd on the device will be restarted (there is a certain probability that the device will be restarted to adbd ), after the adbd is restarted, when setuid is called to set itself as a non-root user, the setuid will fail, but the android adbdCodeIt does not check whether the setuid fails. Therefore, adbd eventually runs as root. The following is an English explanation. If you have time to look at the adbd code, you will be clear about it:

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 shocould 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 shoshould 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.