Chatting with ROOT permissions-previous and current ROOT permissions

Chatting with ROOT permissions-previous and current ROOT permissions

Recently, my work has been very busy, and I have gradually moved away from the CSDN blog. However, when I encounter problems at work, I will be repeatedly guided to CSDN, therefore, I will share my learning achievements here, hoping to help those who need help.

In this article, we will explain from the beginning to the end what ROOT is?

1. Brief Introduction to ROOT permissions

2. Why ROOT?

3. ROOT permission of ADBD

4. In-depth source code

ROOT permission introduction:

ROOT permission is the highest permission in Linux kernel. If your identity is ROOT, you have ROOT permission. With the highest permissions, you can do whatever you want. In other words, if a malicious program obtains the ROOT permission, it can destroy your mobile phone and obtain the privacy... therefore, the manufacturer generally does not provide the ROOT permission to the user when producing the mobile phone. The official claim is to protect the security of the user's mobile phone, and then installs a bunch of automatic start-up devices, users who have never used or uninstalled the spam software in their lives (I believe Android users can understand what they mean), and Apple's jailbreak is to get the ROOT permission.

Why do I need to get the ROOT permission?

Apple users get the ROOT permission to install various software for free, and to get a more flexible operation experience, Apple does not install a bunch of disgusting software. Android users get the ROOT permission, the biggest goal is to uninstall these disgusting built-in software, while Android geeks are trying to get the log files and analyze bugs for various Android phones.

ROOT permission of ADBD:

What is ADBD? I believe everyone has seen this. IT male connected his mobile phone to a computer and then somehow popped up a dark window with lines of white letters on IT, then, you can easily tap the keyboard (generally, you can tap adb shell and then enter your mobile phone) to solve some mobile phone problems. This process that can interact with mobile phones is ADBD. This is like, when you go to a friend's house to play, and then your friend's house is relatively high-end, there is a visual walkie talkie before entering the door, then you first call a friend through the walkie talkie (hitting adb shell ), check if you are not at home (whether the mobile phone has the adb shell Command). If your friend is at home, he will open the door for you through the walkie talkie (successfully accessing the mobile phone ), the visual walkie talkie that provides this service is equivalent to ADBD. To put it bluntly, ADBD can provide you with a service channel to access your mobile phone.

So why do ADBD have ROOT permissions? This involves another thing closely related to the ROOT -- su.

After we start the system, the identity of using the mobile phone is a normal user. If we execute su, we can directly switch to the ROOT identity. Like the city of July 3, the legend of the legend, the legend of the legend, only the supreme building of the magic community can compete with him. When they came to heaven, the Jade Emperor applied the law, and allowed the city to switch directly to General fepeng, as a result, he had the memory and power of General Apsara, and fought against the building again. Su is such a magic command.

On the Qualcomm platform, the su code is located in: LINUX/android/system/extras/su. c.

In fact, the jailbreak or ROOT is to install su in the/system/bin directory on the mobile phone and set its permissions to 4755. When some programs require ROOT permissions, you can switch to the ROOT identity through su and execute it. Therefore, an application such as "Super User" is usually installed on the ROOT mobile phone, which is used to manage which software can be switched to the ROOT identity, which of the following cannot ensure the security of users? This idea is very naive. For formal software, people follow your path, informal software, and applications of a small super user, can this prevent me from getting the ROOT account.

So why do we need ADBD to get the ROOT permission? After the above explanation, you should be able to guess that if ADBD has the ROOT permission, you can use the adb tool to do whatever you want without leaving any trace (without installing su). You can delete your own junk software, obtaining files from any directory is highly secure. This method is used to obtain some system-level files.

In-depth code:

After reading the above text, many people may have this idea. Is it as simple as a ROOT mobile phone? Error! It is not easy at all.

First, the/system partition is a read-only file system, that is, you cannot write anything into the system partition. Second, even if you are lucky enough to install su under/system/bin, you cannot change its permissions to 4755. In addition, even if you are lucky enough to set su permissions to 4755, you cannot escape the anti-root mechanism of some mobile phones (that is, if the File Permission is detected to be 4755, delete the file ).

First, let's take a look at some of the su code:

 /* Until we have something better, only root and the shell can use su. */   myuid = getuid();    if (myuid != AID_ROOT && myuid != AID_SHELL) {        fprintf(stderr,"su: uid %d not allowed to su\n", myuid);        return 1;    }

This statement tells us that if su is not a ROOT or SHELL user, exit directly. It means that you must be the two users when switching identities. Fortunately, we can use adb shell to access, it's a SHELL user. It's dangerous.

if(argc < 2) {        uid = gid = 0;    } else {        int gids_count = sizeof(gids)/sizeof(gids[0]);        extract_uidgids(argv[1], &uid, &gid, gids, &gids_count);        if(gids_count) {            if(setgroups(gids_count, gids)) {                fprintf(stderr, "su: failed to set groups\n");                return 1;            }        }    }

When determining whether there are other parameters when executing su, we only execute su, that is, argc <2 is true, su can also be switched to another user (argc> 2, for more information, see the use of the su command. At this time, both uid and gid are set to 0. That is, the ROOT user's ID and group number.

if(setgid(gid) || setuid(uid)) {        fprintf(stderr,"su: permission denied\n");        return 1;   }

Here we are, it is it. This is our ultimate goal. We will turn me into general Apsara. If everything goes well, you will be able to turn it into success (switching to ROOT successfully)

/* Default exec shell. */    execlp("/system/bin/sh", "sh", NULL);

After each su operation, it is changed to root #. Then you can continue to run the command on the console. However, you are already ROOT and have a high permission.

When the Android system is started, ADBD is the ROOT permission, but is then downgraded. The function used to determine whether to downgrade is should_drop_privileges:

static int should_drop_privileges() {#ifndef ALLOW_ADBD_ROOT    return 1;#else /* ALLOW_ADBD_ROOT */

First, determine whether or not ALLOW_ADBD_ROOT is defined. if the system does not allow you to ROOT, 1 will be returned directly, and nothing will be read below, just like when looking for a job, no matter how powerful you are, if none of your first requirements are met, you can pass it directly. It's hard to say anything.

    int secure = 0;    char value[PROPERTY_VALUE_MAX];  /* run adbd in secure mode if ro.secure is set and    ** we are not in the emulator    */   property_get("ro.kernel.qemu", value, "");    if (strcmp(value, "1") != 0) {        property_get("ro.secure", value, "1");        if (strcmp(value, "1") == 0) {            // don't run as root if ro.secure is set...            secure = 1;

The following shows how to obtain the system attributes and determine whether to enable the ROOT permission. kernel. the qumu attribute is set to. It's okay to give you another chance to judge ro. whether secure is also 1. If yes, I'm sorry you cannot get the root permission. I want to set secure to 1 (secure to 1 means downgrading, which will be explained later). Then:

           // ... except we allow running as root in userdebug builds if the            // service.adb.root property has been set by the "adb root" command            property_get("ro.debuggable", value, "");            if (strcmp(value, "1") == 0) {                property_get("service.adb.root", value, "");                if (strcmp(value, "1") == 0) {    secure = 0;            }            }        }    }

Haha, I gave you another chance to judge ro again. debuggable is not 1. If not, sorry, I must downgrade. Otherwise, I will give you another chance to judge the service. adb. if the value of the root attribute is also 1, it will not be downgraded. Generally, when compiling the ROM version, colleagues will compile two versions, one is the project version, and the other is the ADBD with the ROOT permission, in this way, developers can easily debug the system. The other is the version we use, called the user version, which has no ROOT permission. We can see that the property_get attribute is used to determine whether to downgrade.

    return secure;#endif /* ALLOW_ADBD_ROOT */}

Finally, return secure. We can see that the final variable deciding whether to downgrade is secure. If the source code is available, only the final value of secure is 0, regardless of the version, it is the ROOT permission.

If (random () {random (); gid_t groups [] = {AID_ADB, AID_LOG, AID_INPUT, AID_INET, AID_NET_BT, random, random, AID_SDCARD_RW, random }; if (setgroups (sizeof (groups)/sizeof (groups [0]), groups )! = 0) {exit (1);/* then switch user and group to "shell" */if (setgid (AID_SHELL )! = 0) {<span style = "white-space: pre"> </span> // past vulnerability, blocked exit (1 );} if (setuid (AID_SHELL )! = 0) {<span style = "white-space: pre"> </span> // previous vulnerability exit (1 );} D ("Local port disabled \ n ");}

From this code, we can see that if should_drop_privileges returns 1, it can be downgraded. The downgrade function is setgid (AID_SHELL) and setuid (AID_SHELL). Some hackers have used some methods, if setgid and setuid fail to be executed, that is, the downgrade fails. In the previous Code, there is no exit. If setuid and setgid fail to be executed, the downgrade will not be performed.

ROOT is not so easy. There are many known vulnerabilities, but they are all blocked. Not all root tools can succeed. It depends on the method used for root.

What is the root permission for accessing root?

Is it related to super users? Root is a verb that indicates the ability to change system permissions. A Super User is just a software tool to exercise permissions. Just like the relationship between a computer and qq, you have a bunch of qq Software in your hand. Can't you use a computer.

You cannot directly use a Super User. It is not so easy to use the mobile phone root. Nowadays, many software have a one-click root function. You can try it. What is the Mobile Phone Manager on your computer. If it doesn't work, you need to manually root it. Easy to view mobile phone models

What is the Root permission of the Android mobile phone? How can I obtain the Root permission?

Root permission indicates the highest permission. As long as you have the ROOT permission, you can operate your Android phone at will, such as deleting the built-in program of the system, disabling auto-start items during startup, and flashing, just like Administrator permissions on your computer, what a hacker needs to do first is to obtain the highest permissions on your computer and then control your computer. Many apps on Android require ROOT permissions, just as Apple requires jailbreak. Therefore, we recommend that you still get the ROOT permission and be free of charge. We recommend that you use software such as "brush Genie" and "Zhuo master" to download the software to your computer and install it, connect to the phone and follow the prompts.