Android operating system Get root permission principle detailed analysis _android

Android Root access cracking analysis

Many friends of the new Android machine has not cracked the root permissions, can not use some high privileges of the software, as well as a number of highly privileged operations, in fact, crack the root of the mobile phone is relatively simple and safe, the principle of cracking root authority is in the phone/system/bin/or/ system/xbin/directory to place an executable "su", which is a binary file, equivalent to a computer EXE file, only in the system placed this "su" file is not to the phone's software or hardware caused any failure.

The following code is part of the code in the original SU of the Android system, and it can be seen that only the processes that allow Getuid () for aid_root and Aid_shell can log in using Su.

Copy Code code as follows:

<span style= "font-size:18px" ><strong>/* Until we have something, only the root and the shell can be use SU. */
myUID = Getuid ();
if (myuid!= aid_root && myuid!= Aid_shell) {
fprintf (stderr, "su:uid%d not allowed to su\n", myUID);
return 1;
}</strong></span>

Face in Superuser this Android program Su no longer has the above part, so any process can use Su to log in, some of the Android program to use root permissions may be used similar to (this is also a part of the Superuser code):

Copy Code code as follows:

Process process = Runtime.getruntime (). EXEC ("su");
DataOutputStream OS = new DataOutputStream (Process.getoutputstream ());
Os.writebytes ("mount-oremount,rw/dev/block/mtdblock3/system\n");
Os.writebytes ("BusyBox cp/data/data/com.koushikdutta.superuser/su/system/bin/su\n");
Os.writebytes ("BusyBox chown 0:0/system/bin/su\n");
Os.writebytes ("chmod 4755/system/bin/su\n");
Os.writebytes ("exit\n");
Os.flush ();

This is part of the code in the Superuser and Android apps mentioned above:

Copy Code code as follows:

if (Setgid (GID) | | setuid (UID)) {
fprintf (stderr, "su:permission denied\n");
return 1;
}

It looks like this is the place for permission switching. For ordinary users to be able to use the SU,SU permission if so:

-rwsr-xr-x. 1 root root 34904 November 3 2010/bin/su

This is the same as the computer version of SU.

From the above analysis can be considered to crack the root of Android is the essence: in the system to add a user can be used to log the SU command. Of course, this is the first way to get root.

To. A rageagainstthecage in a program that z4root Android's root permissions for Android may be a program that manages to get root privileges.

Second article:

If you've developed a program, the code that gets root on the root phone is as follows:

Copy Code code as follows:

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

From the above code we can see the first to run the SU program, in fact, the root of the secret is in the SU program, "Android Root rights crack analysis" in the Android system to the default Su program can only root and shell to run Su, this is safe. If this limit is taken away, it is root cracked!

Below we carefully analyze how the program is to obtain root permissions, if the SU command of Linux familiar friends may know that the SU program is set suid bit, we look at my phone (has root cracked) on the SU permission settings,

We found that Su's owner and all groups are root and are actually busybox soft links, and we look at the BusyBox property discovery, which sets Suid and Sgid, and the owner and all groups are root. What is the role of Suid and Sgid? If you are not clear, please refer to the Linux process's actual user ID and valid user ID, so that the normal user running BusyBox, busybox running process to get the root of the valid users. The SU program launches itself into a new program and promotes its own privileges to root (as we mentioned in the previous case, Su is BusyBox, and the runtime's permissions are root and, of course, permissions to elevate their privileges).

Again, not only does Su need to set suid on the root phone, the SU program on all Linux systems needs to set the SUID bit. Please refer to the UC server's SU permissions:

We found that Su also set the SUID bit, so that ordinary users can also run the SU program, the SU program will verify the root password, if the correct SU program can increase the user rights root (because it set the SUID bit, runtime is root permissions, so that it has the right to elevate their permissions).

In this way we can see that the fundamental principle of the Android system is to replace the SU program in the system because the default SU program in the system needs to verify the actual user rights (only root and shell users have permission to run the system's default SU program, and other users will return an error if they run it). And after the cracked Su will not check the actual user rights, so that ordinary users will be able to run the SU program, but also through the SU program to elevate their privileges.

It's not a mystery to root cracking here. Root cracked does not take advantage of what Linux kernel vulnerabilities (the Linux kernel can not have such a large vulnerability exists), could be understood as root cracking is embedded in your system "Trojan Su", said it is "Trojan" is not too much, Such a result would be disastrous if a malicious program were to run in the system and would be able to elevate its permissions through SU. So in general, root over the phone will have a superuser application to allow users to manage who can get root permissions, but also to the system to add a layer of insurance it!

Through the introduction of the Android root cracking principle analysis, we should understand that the ultimate goal of the root cracking process is to replace the SU program in the system. But to replace the system in the SU program itself is the need for root authority, how to root in the process to obtain root access, become the focus of our research. Let's take a look at what we need to do to break down the system, and assume that the Android system that needs to be cracked has the following conditions:

Copy Code code as follows:

1, can be connected to the device through the ADB, generally means that the driver has been installed.
2, but ADB access to user rights is shell users, not root.

To understand the root cracking process, we first need to understand the ADB tools, the SDK contains ADB tools, device-side ADBD service program running backstage, for the development of the ADB program to provide services, ADBD permissions, determine the authority of the ADB. Specific users can view the source code under/SYSTEM/CORE/ADB, view android.mk you will find that the ADB and adbd are actually a piece of coding, and then compiled with macros.

To see the ADB.C adb_main function you will find the following code in ADBD:

Copy Code code as follows:

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 detects the Ro.secure property of the system, and if that property is 1, it will demote its user rights to the shell user. General equipment in the factory when the/default.prop file will have:

Copy Code code as follows:

Ro.secure=1

This will cause the ADBD to be automatically demoted to shell users when they start up.

And then we'll introduce the adbd when it started? The answer is the system service configured in Init.rc, which is started by the Init process. We looked at the following in the init.rc:

Copy Code code as follows:

# ADBD is controlled by the Persist.service.adb.enable system property
Service ADBD/SBIN/ADBD
Disabled

A friend who has little knowledge of the Android property system will know that the system service configured in Init.rc is root (because Init is root and its subroutines are root). From this we can know the ADBD program in the execution:

Copy Code code as follows:

/* Then switch User and group to "Shell" * *
Setgid (Aid_shell);
Setuid (Aid_shell);

The code is root before the shell permission is executed only after executing the two sentences.

This allows us to lead root cracking process to obtain the root of the method, that is, the above setgid and setuid function failure, that is, the downgrade failed, then continue to run under the root permissions.

This actually utilizes a rageagainstthecage loophole, the concrete analysis please refer to "The Android adb setuid right flaw analysis" and "Rageagainstthecage". Here's a simple note:

Copy Code code as follows:

1, the factory set the Ro.secure property is 1, then ADBD will also run under the shell user rights;

2, the ADB tool created by the process RATC also run under the shell user rights;

3, RATC has been creating a child process (RATC created by the subroutine will also run under the shell user Rights), followed by the subroutine exit, form a zombie process, occupy the shell user's process resources, until the number of processes to reach the shell user is Rlimit_ Nproc (including ADBD, RATC, and subroutines), this is RATC will create child process failure. This time, kill the ADBD,ADBD process. Because it is an Android service that will be automatically restarted by the Android system, the RATC is competing to produce subroutines. Before the ADBD program executes Setgid and setuid above, RATC has created a new subprocess, then the shell user's process quota has been reached, and adbd process execution Setgid and setuid will fail. According to the code we find that ADBD will continue to execute after the failure. This way the ADBD process will run under root permissions.

3, this is the use of the ADB to connect the device, then the ADB will run under root permissions.

Through the above introduction we found that the use of rageagainstthecage vulnerabilities, can enable ADBD to obtain root permissions, that is, the ADB obtained root privileges. Get root permission the rest of the problem will be good to do, after the copying of the SU program to the system (see "Android Root Crack Principle Analysis" above), there is no technical content of things.

In fact, blocking the adbd of this loophole is actually quite simple:

Copy Code code as follows:

/* 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, the ADBD process exits unexpectedly and the vulnerability is blocked. Why are so many devices not plugged into this loophole? I think it is the device manufacturer's strategy (do not rule out the existence of Silly X), although know how to seal the loophole but is to keep a back door to everyone, so that the third party to their own custom ROM, improve the usability of their systems.

At this point we have the root of the process and root system after the introduction of the situation, I believe you will not be the root of the mystery of the crack!