From ADB Prrmission denied to understanding Android mobile phone right behind

Scenario Description:

1. Connect Android phone, adb shell find xxxx, show ADB permission denied;

2. Google display needs to run under root authority, ADB root, no error output, again adb shell find XXXX, still show permission denied;

3. Found that the phone does not have root access, try Root Wizard and Kingroot one-click root failed.

Reason:

1. ADB is the Android SDK comes with debugging tools (Related: Android developer);

2. ADB is executed by default with Shell privileges (non-root), even if the phone and root permissions have been obtained, you need to display the switch adb root;

If the root permission is not obtained, the display switch is of course useless;

3. The major premise of the ADB's root access: The phone is rooted, currently relies on the root tool, and the root tool will generally have a list of trial models, the phones outside the list can not be root.

Analytical:

1. Why Root?

Android uses the Linux kernel, so as with Linux, no root privileges will be able to manipulate some files (such as system files, etc.).

2. "Root your phone", this sentence should have heard a lot, what is root on behalf of what?

The user's right to the mobile phone is generally ordinary users, mobile phone manufacturers prohibit users to obtain root privileges, root, that is, the user's shell privileges to elevate the root authority.

3. What is the general principle of root?

(Note in advance: The search for more than 2013 years or earlier, specifically mentioned crack details only apply to the Android version at that time, but guess the general principle is consistent, collation. ）

key "su" reference: Android system root hack principle analysis + Android's right to extract (root) What is the principle?

• In Linux, the execution of the SU command to enter a password to get root privileges, in Android, some mobile phone packaging system will directly remove the SU command, the other is not through the password to verify, but to see the user's original permissions. That is, if you are root, you can switch to other users through Su, such as Shell,wifi,audio or something. But if you are a user other than root, you can not switch back to root, you will be prompted to permission denied.
• In Linux, there is a special permission S, set suid (meaning that the user who executes the file temporarily has permission to the file owner). And Su's owner is root, so ordinary users run Su, you can get root permissions.

• Android Similarly, because the handset manufacturer may encapsulate other nature Su, so first need to confirm two points: 1. The SU command exists in the Android phone; 2. The SU command owner is root and the Execute permission is s.

So the point of root is to find a way to replace and execute su.

cp /data/tmp/su /system/bin/                   su to/system/partition
su                              #su的所有者置成rootchmod4775 /system/bin/su                      #把su置成-rwsr-xr-

The above operation requires root authority, and then into the loop, the conventional way can not be cracked.

Unconventional approach (ADBD vulnerability as an example) reference : Android system root Hack principle Analysis (cont.)

The Android init process starts with root and starts INIT.RC and its configured system services (including ADBD), adbd to shell permissions after executing the following two commands

/**/setgid (Aid_shell); setuid (Aid_shell);

The way to do this is to let the two commands fail, and the switch to shell fails with the original root permission.

(but actually after the Android4.2 the execution process of the SU command has been modified, after 5.X has changed, the specific information is not clear, temporarily retain the above )

From ADB Prrmission denied to understanding Android mobile phone right behind