Android Device Rooting Lab

SEED Labs 1 Android Device Rooting Lab Copyright c 2015 - 2016 Wenliang Du, Syracuse University. The development of this document was partially funded by the National Science Foundation under Award No. 1303306 and 1318814. This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International License. A human-readable summary of (and not a substitute for) the license is the following: You are free to copy and redistribute the material in any medium or format. You must give appropriate credit. If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original. You may not use the material for commercial purposes. 1 Overview Android devices do not allow their owners to have the root privilege on the device. This is fine for normal customers, but for users who want to make deep customizations on their devices, this is too restrictive. There are ways to overcome these restrictions, most of which require the root privilege on the device. The process of gaining the root device on Android devices is called rooting. Being able to root Android devices is a very useful skill for security experts. The objective of this lab is two-fold. First, through this lab, students will get familiar with the process of device rooting and understand why certain steps are needed. Many people can root Android devices, but not many people fully understand why things have to be done in a particular way. Second, the entire rooting mechanism involves many pieces of knowledge about the Android system and operating system in general, so it serves as a great vehicle for students to gain such in-depth system knowledge. In this lab, we will ask students to develop a complete rooting package from scratch, and demonstrate how to use the package to root the Android VM provided by us. 2 Background Knowledge 2.1 Background Knowledge about Rooting The purpose of rooting an Android device is to gain the root privilege inside the Android OS. There are many reasons why people want to do that. For example, Android devices often come with many pre-installed system apps that are useless most of the time, but they take storage space, RAM, system resources, and drain device battery. These useless apps are generally known as bloatware; they are installed in protected places, and only the root user (or other privileged user) can remove them. Although the device is owned by a user, the user is not allowed to run code using the root privilege. Users can only get the root privilege if the device is rooted. In general, rooting allows users to customize their phones, removing restrictions, adding new features, and making changes to the system. There are several approaches to root an Android device, and we will discuss them in more details in this lab. Figure 1 provides a summary of these approaches. Modifying Android from inside. The first rooting approach is doing it from inside Android. For an un- rooted device, everything that the user runs is running with a normal user ID (not root). Therefore, rooting from inside Android means that the user has to gain the root privilege as a normal user. Obviously, this is impossible for a perfectly implemented operating system. However, the chances are that Android may not be perfectly implemented, so there might exist vulnerabilities in the system. If these vulnerabilities are inside the kernel or daemons running with the root privilege, users can exploit these vulnerabilities to gain the root privilege. This is one of the techniques to root Android devices. SEED Labs 2 In the past, there were many rooting exploits, such as RageAgainstTheCage, which took advantage of RLIMIT NPROC max, the value specifying how many processes a given UID can run. This exploit first uses "adb shell" to run a shell on the device via the adb daemon. The UID of the shell will be 2000. The exploit then forks new processes until the number of processes have reached the limit and the fork call will fail. At this point, the exploit kills the adbd daemon, and then reconnect to it using "adb shell". This causes the system to restart the adb daemon. When adb is started, it always has the root privilege, but it will drop the privilege to UID 2000 using setuid(2000). Unfortunately, the UID 2000 has already used up its process quota, so the call will fail. Unfortunately, the adb daemon fails to handle the failure correctly: instead of exiting, it keeps running, while retaining the root privilege. As results, the "adb shell" command will give users a root shell. This vulnerability has already been fixed after Android 2.2. You need to Modify Android OS because Stock Android OS doesn’t provide root Rooting Overview privilege to the user out of the box Unlocked bootloader allows Modify Android OS you to run your own OS by flashing the image file to specific Android Partition. Before Booting into After Booting into Android Android OS OS Find Vulnerability in Unlock Bootloader Stock Recovery only Android OS that escalate allows you to apply OTA User Privilege Change the entire Android updates authorized by System Image Update Android System manufacturer. We need Image by applying OTA to replace Stock Recovery with Custom Recovery to Gives root shell (Over The-Air) updates apply our own OTA Unpack Android System updates which bypasses Image (system.img) or get signature verification it from manufacturer or Replace Stock Recovery Getting root shell is trusted third party provider breakthrough, you can do with Custom Recovery whatever with root shell to Android file system Modify system image by changing build type or by adding some SUID su binary Custom Recovery will run update-binary from the OTA package to apply Basically update- Commercial Android devices uses User updates build which disallows root access via Gives root shell binary is a binary file shell. But It can be turned into the that runs updater- userdebug or engineering build which script that guides recovery to install files gives root access through the shell by Gives root shell setting ro.secure = 0. from OTA package to main Android OS to achieve rooting. Figure 1: Rooting Android Devices Modifying Android from outside. Since Android’s access control prevents a normal user from modifying the part of the system that is only modifiable by the root, doing it inside Android is going to subject to the access control. However, if we can do it from outside, we are not subject to Android’s access control any more. This leads to the second approach, which is to directly modify Android’s system files from outside. Assume that another operating system is installed on your Android device. This means that the device SEED Labs 3 has a dual-boot configuration, allowing you to boot into any of these two operating systems when the device powers on. If we boot into this second operating system, and become the root for this OS, we can mount the partition used by the Android system. Once this partition is mounted, we can access all the files stored inside the partition. Because Android is not running, its access control has no use. Therefore, we can make arbitrary changes to its files. For example, we can place some programs in the system, and modify Android’s initialization scripts, and ask Android to run our programs as a root during its initialization process. The good news is that most Android devices do have the second operating system installed, and it is called recovery OS. As the name indicates, it is meant for recovery purposes, but it is mostly used for updating operating system. The bad news is that this operating system also has access controls, preventing users from running arbitrary programs or commands. Recovery OS is typically placed on devices by vendors, who use the OS to update Android, but not wanting users to make arbitrary updates. To enforce that, recovery OSes do not give users a shell prompt, preventing users from running arbitrary commands. Instead, they take a package provided from outside (either from users or downloaded from the Internet); the package contains the commands and files needed for updating the Android OS. This mechanism is widely used for OS update, and it is called Over-The-Air (OTA) update. The package is called OTA package, which has a standard file structure that we will talk about later. Most recovery OSes only accept the packages made by the vendors to ensure that any update to the Android OS is approved by the vendors. This is enforced using digital signatures, i.e., the package needs to be signed by vendors, or it will not be accepted by the recovery OS. This protection becomes a roadblock for rooting, because the package that we use for rooting purposes will not come from the vendor of the device. We need to find ways to bypass this access control. Reinstall recovery OS. Instead of bypassing the access controls of the recovery OS, the easiest way is to replace the entire stock recovery OS with another recovery OS that does not have such access controls. This new recovery OS, called custom recovery OS, will not include the signature verification part, so we can provide any OTA packages to the recovery OS. This will allow us to make arbitrary changes to the Android partition. Here is another bad news. There is another access control that prevents us from replacing the stock recovery OS, and this time it is the bootloader. Bootloader is a low level code that loads an operating system or some other system software for the computer after the computer is powered on.

Load more