Android root principle and process analysis

Pre-knowledge

The internal storage device of the Android phone is the ram and the Rom,ram is running memory, the power loss will lose everything, the contents of the ROM will not be lost after power off.

For example, the specification of a mobile phone says "2G ram,16g ROM". Theoretically, the larger the RAM, the smoother the system runs. Like a large 3D game, the operation needs about 300M of memory, then in memory 2G mobile phone can run smoothly, in 512M memory of the mobile phone almost can't run up, run up will be stuck. We can see the current amount of RAM remaining in the phone in Settings-manage applications-running, and the average 2GRAM phone shows that the available RAM is only 1G multipoint, because the Android system itself runs out of memory. Ram access is fast, but expensive, so the RAM in the phone is not particularly large.

The size of the ROM is almost nothing to do with a mobile phone card, it can be used as a built-in SD card (it is actually a built-in SD card). Its contents are divided into two chunks: System data, user files (i.e. our photos, songs, videos, etc.). System data only occupy a relatively small part, probably less than 1G, the rest of the user randomly put photos, videos and so on. When we use MTP (Media connection mode) to connect the phone to the computer, we can see the extra phone letter on the computer, in which we can view our own files. If the 16G ROM, connected to the computer will be found not so large, because a part of the system data is released.

In-memory system data partitioning is very important-it can be said that the entire Android system is on top.

So what exactly does the system partition contain? Roughly speaking, it includes the following content:

/system

/boot

/cache

/data

/recovery

/misc

/system is the Android system, which contains all the system applications, the framework to support these applications, system tools and so on. If you delete it, you will not be able to enter the Android system, you can not call to send text messages, but also can not play games, because the Android system has disappeared from your phone.

/data is the user data (note that the above user files are different), your text messages, call logs, contacts, etc., you use the browser to browse the page, enter the user name password, saved settings, are your user data. If you delete it, your phone will be the equivalent of "factory reset", your SMS, your app, etc. are missing.

/boot supervisor phone is booting normally. For example, you press the power button will first see the boot animation, and then smoothly into the Android system, you press and hold the volume key and the power button will enter the recovery, these are/boot to control. Do not think it is irrelevant to work, the Android system before booting is 0 and 1 on the disk, after the boot it becomes a system that can run, this is the credit of/boot.

/cache is the system's current cache, you browse the page is in the 15th row of the location, you play the game is stuck on this screen, are/cache to record.

/recovery usually not used, it is a small mobile phone system, just like the Android system. Its role is to be able to brush into the new ROM, system updates, backup user data and so on. (Specific function can install a clockworkmod look)

When Android starts, it executes the code under/boot and reads the Android system from the disk and mounts it to the/system directory. Note that the/system in this case is not a concept with the/system partition on the disk mentioned above: The/system partition is the data in the storage device, which is 0 and 1. The/system directory is a directory in the file system. The/system directory is a mount point for the/system partition.

Once mounted, it is possible to access the/system partition via the/system directory and read and write to it (requires root access).

Root principle and process

So, what is root permission? What does it count as root?

Performance: Su files under the/system/xbin folder, and has the rwsr-sr-x permission, it means that the phone has been root permissions.

In fact: Under the *nix system (the Android kernel is a Linux system), everything is file. such as disk, media, input and output ... Wait a minute. Like a disk, it is a file under/dev, and the process is described by various files under/proc. In the *nix system of all documents, the freedom to manipulate all files freely is the maximum freedom. This freedom is called "root" permission.

Visible, the freedom of root privilege is very large, if exploited maliciously, will put the whole system in danger (your text message, contact, your account password, your photo video, etc.). So neither the handset maker nor the Android system is actively open for root authorization. To get root permissions can only be done by non-normal means.

So the existing approach to root access is only one way of thinking, is the use of loopholes, break the rules:

1. Exploit the vulnerability in the Android source code (such as Rageagainstthecage vulnerability, by creating a large number of sub-processes to let the ADBD process demotion failed to obtain root privileges)

2. Swipe in the custom recovery and then use the modified recovery to brush the SU into the/system partition

3. Boot from SD card to modify/SYSTEM partition (only a few models have this function)

Exploit the loophole of the source code, there are several famous cases. For example, rageagainstthecage loophole, some call it the setuid right loophole. The code by the ADBD background service sub-process exhaustion forced adbd Restart, adbd at the time of the reboot with root permissions, under normal circumstances adbd will call setuid to drop the permissions to the shell, But because Rageagainstthecage let ADBD's zombie process fill the whole system, this time setuid will call the failure, the last adbd is retained the root privilege to run, thus complete the root power.

See: http://blog.sina.com.cn/s/blog_da6ccaf60101g86r.html

However, the success rate of root has been very low in this way, because as the Android system upgrades, the vulnerability is blocked in one. Most of the tools used to root in this way are "one click Root" apk on the phone.

The second way is also the root success rate is very high one way, is through the PC-side tool, connect the phone to root. The PC-side tool selects the corresponding modified recovery based on the model (with the highest recognition of the clockworkmod recovery), which is brushed into the recovery corresponding hardware address via the cat or DD command.

The command is as follows:

ADB push stockrecovery.img/sbin/

ADB shell "DD if=/sbin/stockrecovery.imgof=/dev/block/platform/mmci-omap-hs.1/by-name/recovery"

ADB reboot

Recovery is actually a small mobile phone system, but also the Linux kernel. In other words, it can be understood that the mobile phone has a dual system, one is the Android system, one is recovery. If the Android system is destroyed (for example, by deleting the/system partition in ROM), the phone can still enter the recovery.

How do I get root access through recovery? The principle is very simple, after entering the recovery, the/system partition becomes a hardware disk block in the ROM, which of course can be freely modified. We put Su into the/system/xbin folder, give Rwsr-sr-x permission, Basic is done.

How do you put it there?

See the following: http://blog.csdn.net/happy_6678/article/details/7242594

A detailed introduction to the scripting language edify see: http://blog.csdn.net/tody_guo/article/details/7948083

This is done in a few simple steps:

Ui_print ("Mounting system ...");

Run_program ("/sbin/busybox", "Mount", "/system");

Ui_print ("Deleting old files ...");

Delete ("/system/bin/su", "/system/xbin/su", "/system/app/superuser.apk");

Ui_print ("Copying files ...");

Package_extract_dir ("System", "/system");

Ui_print ("Fixing permissions ...");

Set_perm (0, 0, 06755, "/system/bin/su");

Ui_print ("symlinking ...");

Symlink ("/system/bin/su", "/system/xbin/su");

Ui_print ("unmounting system ...");

Run_program ("/sbin/busybox", "Umount", "/system");

As for the third way, generally only very few models support from the SD card boot to root or brush the machine, here is a brief introduction to this situation root idea: because it is from the SD card boot, so the SD card will have corresponding boot.img. Modify the boot.img here, you can achieve our goal.

Boot.img after decompression is like this:

Where Init.**.rc is the startup script that is responsible for mounting the Android system from the/system partition to the/system directory and modifying its permissions to RO (read-only). Here we notice that when the Init script runs, it has permission to modify the/system directory.

If we modify the init script here, before/system's permission becomes RO, the SU is placed in the/system/xbin directory and the permissions are modified, and the root permission is obtained.

It is not difficult to modify the Init script, and the Init script uses ail (Android initlanguage), which is described in more detail in the following: http://blog.csdn.net/nokiaguy/article/details/9109491

After modifying the Init script, and then re-boot.img, put the SD card to boot from the SD card, you are done.

Bootloader Plus Lock

Bootloader definition: bootloader is the first code of the embedded system after power-on, after it completes the initialization of the CPU and related hardware, the operating system image or the solidified embedded application is loaded into memory and then jumps to the space where the operating system is located, and the operating system starts running.

Bootloader Locking: "Lock" bootloader refers to the bootloader before loading the operating system image or other important firmware, it will be signed verification, the signature does not match the START process aborted.

It is necessary to unlock the bootloader before root and brush.

Android root principle and process analysis