Explain the principle of root access in the Android system _java

Objective
always curious about the fundamentals of Android Root, and just recently ran into a problem with the Android default with Root, and here's how the Android system root works.

Principle
Android is an Open-source operating system based on the Llinux kernel, similar to the Ubuntu system, so getting root in Android is the same thing as getting root permissions on Linux. The way to get root permissions on a Linux system is to perform sudo or su at the command line, and then enter the power to get root permissions. The same is true of Android, such as application-layer program development, where the code to run root on the root phone is as follows:

  Process process = Runtime.getruntime (). EXEC ("su"); 
  DataOutputStream OS = new DataOutputStream (Process.getoutputstream ()); 
  ...... 
  Os.writebytes ("helloworld!\n"); 
  Os.flush (); 

As we can see, the android application gets root permission also needs to execute the SU command, so android can root the password on the SU program. However, Android itself does not want you to get root privileges, so most handsets are in the user version, and the default is not to have the SU binary program. So you want to get the Android root, the first step is to copy the compiled Su file to the Android phone's/system/bin or/system/xbin directory (why do you want to copy it to the/system directory? Because this partition is not Nosuid limited, and both/system/bin and/system/xbin are paths in the system environment variable path that can be executed directly by Su. Let's assume that you can put the compiled SU program in the XBin or Bin directory, and then you can type the SU claim on the Android phone's adb shell or the serial port.
After the Linux command line input su, it is necessary to enter the root password to be able to claim, but the android in Su and Linux su is not the same, the Android Su is not rely on the authentication password, and need to verify your previous permissions. This means that if you are root, you can switch to other users via Su, such as Shell, WiFi, audio, and so on. But if you are a user other than root, you cannot switch to root, prompting you to permission denied. In other words, it's useful to run Su with root, but I don't have root privileges at this point. This is the next issue to be discussed.
We view the permissions of the/usr/bin/passwd file under Ubuntu, as shown in the following illustration:

The permissions of this file is more special, Linux users generally know that the file is divided into R, W, x permissions, then this s is God horse meaning it? To answer this, s represents the owner of the file when any user executes the file, and the file owner is root. In short, whoever executes the file, he executes it as root.
See here, people are not all have ideas, that is to say, even if I am not the root user may also as root to execute the program, then I put an owner is the root of the SU program permission flag bit set to-rwsr-xr-x, then regardless of who executes it, are executed as root. This is good, Su decisive can carry out the success, then you will be able to get the root permissions smoothly.

Crack
The principle is clear, the root of the process is actually two steps:
1. The SU copy of the owner is root to the Android phone.
2. Set the SU's permission mark bit to-rwsr-xr-x.
The code written is probably as follows:

  cp/sdcard/su/system/xbin/ 
  chown root:root/system/xbin/su 
  chmod 4755/system/xbin/su 

The code looks simple, but to be truly successful, each sentence of the above code requires root permission execution. I rub, a little bit back before liberation, with chicken or egg before the problem similar to the code run requires root permissions, and the purpose of the code itself is to get root permissions, into a closed dead loop. But fortunately the Android system has bugs, so it gives you the chance to break the cycle of death.
The way to break it is to find a process that already has root permission to run this 3-line shell script, so that the script can execute smoothly. But already has the root permission process is the factory time to install on the handset, the code writes dead, you cannot control it to execute own code, this time needs to look for the flaw. For example, the Zergrush vulnerability of Android2.3 root permissions is to exploit a process stack overflow vulnerability with root privileges. The specific use of loopholes in the way everyone can Google themselves.

prevents root
from this analysis, we can simply understand that the solution to the Android system's ability to Su-power is to kill the Su file.