Android root permission Analysis

Article 1

Currently, root Cracking in Android is a basic skill! There are also a lot of software for one-key cracking on the Internet, making root cracking more and more easy. But have you ever thought about how root cracking works? What is the essence of root cracking? Is it because of the Linux kernal vulnerability? This article will analyze the root cracking principle.

This article only describes the direction of the root principle, but it is not clearly described in some specific aspects. This article will make some necessary extensions and supplements for it.

If you have developed a program, the code for obtaining the root permission on the Root mobile phone is as follows:

   1: Process process = Runtime.getRuntime().exec("su");

   2: DataOutputStream os = new DataOutputStream(process.getOutputStream());

   3: ......

   4: os.writeBytes("exit\n");

   5: os.flush();

From the code above, we can see that the su program should be run first. In fact, the root secrets are all in the SU program. The default su program of the Android system can only be run by root and shell, this is safe. If you remove this restriction, it is root cracking!

Next, we will analyze how the program obtains the root permission. If you are familiar with the Linux su command, you may know that the su program has set the SUID bit, let's check the su permission settings on my mobile phone (which has been cracked by root,

We found that the su owner and all groups are root, which is actually a soft link of busybox. We checked the attributes of busybox and found that SUID and SGID are set, and the owner and all groups are root. What is the role of SUID and SGID? In this way, common users who run busybox obtain valid root users during the running of busybox. The su program is to start a new program and escalate its permissions to root (we mentioned above that Su is actually busybox, and its permissions at runtime are root, of course, you also have permissions to improve your permissions ).

Note that SUID must be set for Su on the Root phone, And SUID must be set for all Su programs on the Linux system. Refer to the su permissions on the UC Server:

We found that Su also sets the SUID bit, so that normal users can run the su program, and the su program will verify the root password, if the su program is correct, it can increase the user's root permission (because it sets the SUID bit, it is the root permission during runtime, so that it has the permission to improve its own permissions ).

In this way, we can see that the root 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 system default su program, other users will return an error when running ). However, the actual user permissions will not be checked after the crack, so that normal users can run the su program or escalate their permissions through the su program.

At this point, we are not confused about root cracking. Root cracking does not take advantage of any Linux kernel vulnerabilities (Linux kernel cannot have such a large vulnerability). It can be understood that root cracking is to implant the trojan Su in your system ", it cannot be said that it is a "Trojan" at all. If a malicious program runs in the system, Su can be used to improve its permissions. This result will be disastrous. In general, if the root user is a mobile phone, there will be a superuser application to allow the user to manage who is allowed to get the root permission. It is also an insurance for the system!

The above are some of Simon's personal understandings of root cracking. If something is wrong, you are welcome to correct it.

 

Next

 

The ultimate goal of the root cracking process is to replace the su program in the system. However, to replace the su program in the system requires the root permission. How to obtain the root permission during the root cracking process has become the focus of our research. Next we will first check the situation of the system to be cracked. Assume that the Android system to be cracked has the following conditions:

1. You can connect to the device through ADB, which generally means that the driver has been installed.
2. But ADB obtains the user permission as a shell user rather than a root user.

To understand the root cracking process, we need to first understand the ADB tool. The SDK contains the ADB tool. The device has the adbd service program running in the background to provide services for the ADB program of the development machine, the permission of adbd determines the permission of ADB. You can view the source code in/system/CORE/ADB and Android. mk. You will find that ADB and adbd are actually a piece of code and then compile it using a macro.

View the adb_main function of ADB. C and you will find the following code in adbd:

   1: int adb_main(int is_daemon)

   2: {

   3:     ......

   4:     property_get("ro.secure", value, "");

   5:     if (strcmp(value, "1") == 0) {

   6:         // don't run as root if ro.secure is set...

   7:         secure = 1;

   8:         ......

   9:     }

  10:  

  11:     if (secure) {

  12:         ......

  13:         setgid(AID_SHELL);

  14:         setuid(AID_SHELL);

  15:         ......

  16:     }

  17: }

From this we can see that adbd will detect the Ro. Secure attribute of the system. If this attribute is 1, it will downgrade its user permissions to shell users. Generally, when the device leaves the factory, the/Default. Prop file contains:

   1: ro.secure=1

This will automatically downgrade adbd to a shell user at startup.

Then, let's talk about when adbd is started? The answer is the system service configured in init. RC, started by the INIT process. Check that init. RC contains the following content:

   1: # adbd is controlled by the persist.service.adb.enable system property

   2: service adbd /sbin/adbd

   3:     disabled

If you have little knowledge about the android attribute system, you will know about it in init. the system services configured in RC are all root permissions at startup (because init is root, and its subroutine is also root ). From this we can know that the adbd program is executing:

   1: /* then switch user and group to "shell" */

   2: setgid(AID_SHELL);

   3: setuid(AID_SHELL);

The code is used as the root permission before, and the Shell Permission is changed only after the two statements are executed.

In this way, you can obtain the root permission during the root cracking process, that is, to make the above setgid and setuid functions fail to be executed, that is, the downgrade fails, then it continues to run under the root permission.

This actually exploits the rageagainstthecage vulnerability. For details, see Android ADB setuid Elevation of Privilege Vulnerability Analysis and rageagainstthecage. Here is a simple description:

1. If the Ro. Secure attribute of the factory is set to 1, adbd will also run under the shell user permission;

2. The process ratc created by the ADB tool also runs under the shell user permission;

3. ratc

Keep creating sub-processes (the sub-programs created by ratc will also run under the shell user permission), and then exit the sub-program to form a zombie process that occupies the process resources of shell users, until the number of processes that reach the shell user is rlimit_nproc (including adbd, ratc, and their subprograms), ratc will fail to create the subprocess. At this time, the adbd process will be automatically restarted by the Android system because it is a service of the Android system. At this time, ratc is competing to generate a subroutine. Before the adbd program executes setgid and setuid, ratc has created a new sub-process. If the process quota of the shell user has been reached, the execution of setgid and setuid by the adbd process will fail. Based on the code, we find that the adbd will continue to be executed after the failure. In this way, the adbd process will run under the root permission.

3. If you use ADB to connect to the device again, ADB will run under the root permission.

Through the above introduction, we found that the use of the rageagainstthecage vulnerability can allow adbd to get the root permission, that is, ADB to get the root permission. You can solve the problem after getting the root permission. Copy the su program after the cracking to the system.

In fact, the vulnerability blocking adbd is actually quite simple:

   1: /* then switch user and group to "shell" */

   2: if (setgid(AID_SHELL) != 0) {

   3:     exit(1);

   4: }

   5: if (setuid(AID_SHELL) != 0) {

   6:     exit(1);

   7: }

If the setgid and setuid functions fail to be executed, the adbd process exits unexpectedly and the vulnerability is blocked. Why is this vulnerability not blocked on so many devices? I think it is a device vendor's Policy (not to rule out the existence of silly x vendors). Although I know how to block the vulnerability, I just keep a backdoor for you and ask the third party to customize the ROM for themselves, improve the ease of use of your system.

So far, we have introduced the root process and the system situation after the root, and I believe you will not crack the root! If you have any comments on this article, please feel free to discuss with me.