Detailed analysis of the principle of obtaining root permission by Android operating system

Analysis of Android root permission cracking

Many Android machines newly purchased by mobile phone users have not cracked the root permission and cannot use some software requiring high permission and perform some high permission operations. In fact, cracking the mobile phone root permission is relatively simple and safe. The principle of cracking the root permission is to place an executable file "Su" in the / system / bin / or / system / xbin / directory of the mobile phone, This is a binary file, which is equivalent to the EXE file on the computer. Just putting this "Su" file in the system will not cause any failure to the software or hardware of the mobile phone.

The following code is part of the original Su of the Android system. It can be seen that only getuid () is allowed to be aid_ Root and aid_ Shell processes can log in using su.

-Rwsr-xr-x. 1 root 34904 November 3, 2010 / bin / Su

This is the same as the computer version of Su.

From the above analysis, it can be considered that the essence of cracking the root permission of Android is to add an Su command that any user can use to log in to the system. Of course, this can only be done after obtaining root permission

Yes. In z4root, a program to crack the root permission of Android, there is a rage against the cage, which may be the program trying to get the root permission.

Second article:

If you have carried out program development, the code for obtaining root permission on your mobile phone is as follows:

Let's carefully analyze how the program obtains the root permission. If friends familiar with the Su command of Linux may know that the Su program sets the suid bit, let's check the Su permission setting on my mobile phone (which has been cracked by root),

Again, not only does Su on the root phone need to set suid, but all Su programs on Linux systems need to set suid bit. Please refer to the permissions of Su of UC server:

We found that Su also sets the suid bit, so that ordinary users can also run the Su program. The Su program will verify the root password. If it is correct, the Su program can increase the user's permission to root (because it sets the suid bit and the running period is root permission, so it has the right to increase its own permission).

In this way, we can see that the fundamental principle of Android system cracking is to replace the Su program in the system, because the default Su program in the system needs to verify the actual user permissions (only root and shell users have the right to run the default Su program of the system, and other users will return errors). The cracked Su will not check the actual user permissions, so that ordinary users can also run the Su program or upgrade their permissions through the Su program.

Here we are not mysterious about root cracking. Root cracking does not take advantage of any Linux kernel vulnerabilities (Linux kernel can not have such a large vulnerability). It can be understood that root cracking is to implant a "Trojan Su" in your system. It is not too much to say that it is a "Trojan horse". If malicious programs run in the system, they can also use Su to improve their permissions. This result will be disastrous. Therefore, in general, there will be a superuser application on the root phone to allow users to manage who is allowed to obtain root permission, which can be regarded as adding a layer of insurance to the system!

Through the introduction of "analysis of root cracking principle of Android system" above, you should understand that the ultimate goal of root cracking process is to replace the Su program in the system. However, in order to replace the Su program in the system, it needs root permission. How to obtain root permission in the root cracking process has become the focus of our research. Now let's check the system we need to crack, assuming that the Android system we need to crack has the following conditions:

View ADB of ADB. C_ Main function, you will find the following code in adbd:

Then let's talk about when adbd started? The answer is the system service configured in init.rc, which is started by the init process. Let's see the following in init.rc:

In this way, we can introduce the method of obtaining root permission in the root cracking process, that is, let the above setgid and setuid functions fail to execute, that is, demotion fails, and then continue to run under root permission.

In fact, this exploits a rageagainstthecage vulnerability. For specific analysis, please refer to the analysis of Android ADB setuid privilege raising vulnerability and rageagainstthecage. Here is a brief explanation:

In fact, it's easy to plug the vulnerability of adbd:

So far, we have introduced the root process and the system after root. I believe you won't be mysterious about root cracking any more!