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.

Through the introduction in "root cracking Principle Analysis 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 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:

Int adb_main (int is_daemon)

{

......

Property_get ("ro. secure", value ,"");

If (strcmp (value, "1") = 0 ){

// Don't run as root if ro. secure is set...

Secure = 1;

......

}

If (secure ){

......

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:

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:

# Adbd is controlled by the persist. service. adb. enable system property

Service adbd/sbin/adbd

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:

/* Then switch user and group to "shell "*/

Setgid (AID_SHELL );

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 keeps creating sub-processes (the sub-programs created by ratc will also run under the shell user permission), and then the sub-program exits 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 preceding setgid and setuid are executed in the adbd program, ratc has created a new sub-process, so the shell user's process quota has been reached, the execution of setgid and setuid by the adbd process will fail. Based on the code, adbd will continue to execute after the Code fails to be found. 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:

/* Then switch user and group to "shell "*/

If (setgid (AID_SHELL )! = 0 ){

Exit (1 );

}

If (setuid (AID_SHELL )! = 0 ){

Exit (1 );

}

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 by so many slave nodes? 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!