Root cracking Principle Analysis of Android system (continued)

The above "Analysis of root cracking principles of Android system" describes how an application obtains root permissions after root cracking of Android system. Some netizens raised questions about the root cracking process. This article will analyze the root cracking process to answer this question.

Analysis on Root cracking principles of Android system
We should understand that 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, the root permission is required.
Obtaining root permissions during the solution 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, and the device has the adbd service program background.
Run to provide services for the ADB program of the development machine. The permissions of adbd determine the permissions of ADB. You can view the source code in/system/CORE/ADB.
Android. mk you will find that ADB and adbd are actually a piece of code, and then compiled using macros.

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 has been creating sub-processes (the sub-programs created by ratc are also
Will run under the shell user permission), and then the subroutine exits to form a zombie process, occupying the shell user's process resources until the number of processes reaches the shell user
Rlimit_nproc (including adbd, ratc, and its subprograms). This is where ratc will fail to create a sub-process. At this time, the adbd process is killed because it is
The Android system service will be automatically restarted by the Android system. At this time, ratc is competing to generate subprograms. Execute the above setgid and setuid in the adbd Program
Before, ratc has created a new sub-process, and the shell user's process quota has been reached, the adbd process will fail to execute setgid and setuid. According to the Code, we send
After the current failure, adbd will continue to execute. 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. We can solve the remaining issues after obtaining the root permission. Copy the cracked su program to the system (see the Introduction In "root cracking Principle Analysis of Android system ), there is no technical content.

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 are so many
Is this vulnerability not blocked on the slave? I think it's a device vendor's Policy (not to rule out the existence of a silly vendor). Although I know how to block the vulnerability, I just keep a backdoor for you and let the third party customize it for myself.
To 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.

Original