I was always curious how rooting works behind the scenes. After the recent acquisition of the new Eee Pad Slider, a cellular tablet in which so far no one has been able to implement the superuser rights obtained through the very rooting for this amazing equipment with such great potential and it made me finally sit down and find out what rooting is means that this entails from a technical point of view, and how hackers in the wild approach rooting (root is the root of the new device. Although all this information exists, I could not find a good article in which l have the technical level of detail that I expected, and the corresponding introduction to the overall picture, so I decided to write my own.
This is not a guide to rooting a specific Android device. Rather, this is a general explanation of how standard ROMs (Permanent Storage) of Android try to prevent unprivileged access (Regular user access without privileges), how hackers attack this problem and how rooting software uses various exploits to protect against these security mechanisms.
I. Purpose
Let's first take a step back and consider , that it iswe mean “Rooting.” Forget about flashing custom ROMs, turning on a WiFi modem, or installing Superuser.apk; In essence, rooting is getting root access to the underlying Linux system for Android and, thus, gaining absolute control over the software that runs on the device. The things that require root access in a typical Linux system are the introduction and liquidation of file systems, the launch of your favorite SSH (network protocol for the application layer that allows you to remotely control the operating system) or HTTP (protocol for the application layer of data transfer) or DHCP (network protocol, allowing network devices to automatically obtain an IP address and other parameters,everything is on a Linux / Android system, and this is the real goal of rooting.
Android standard builds usually do not allow users to execute arbitrary code as root. In essence, this means that you, as a user, are given only limited control over your own device; You can get your device to complete task X,only if the manufacturer explicitly allowed it and sent a program for this. You will not be able to use third-party applications to perform a task that your manufacturer does not want to perform. WiFi modem is a good example of this. Cellular operators obviously do not want you to connect your phone at no extra charge. Thus, many phones come with their own proprietary applications for the WiFi modem, which require additional costs. But without root access, you cannot install a free alternative, such as Wireless Tether For Root Users (This program includes a modem (via wifi) for "rutted" phones running Android); Why is this a common practice (rutting) a riddle for me? The only difference between mobile phones, tablets and computers is their form factor; but while the PC vendor would have suffered a huge failure if it had tried to prevent users from running arbitrary programs on their machines, cell phone providers are clearly not judged by the same principle. But such arguments belong to another article.
II. Enemy: OEM ROM Protection Mechanisms for Android
Bootloader and Recovery
The bootloader, the first piece of code that is executed when the device is turned on, is responsible for loading the Android OS and recovery system and flashing a new ROM. People call some bootloaders “unlocked” if the user can flash and load arbitrary ROMs without hacking; Unfortunately, many Android devices have locked bootloaders that you will have to crack to force them to do something other than loading a standard ROM. The Samsung smartphone that I used a few months ago had an unlocked bootloader; I could press a certain combination of hardware keys on the phone, connect it to a computer and transfer any custom ROM to it using Samsung utilities without having to bypass any protection mechanisms. The same does not apply to my Motorola Droid 2 Global; loader, as far as I know, you can’t hack. The Eee Pad slider, on the other hand, is an interesting beast; as with other devices based on nVidia Tegra 2, its bootloader is controlled through the nvflash utility, but only if you knowsecure boot key (SBK) of the device. (SBK is the AES private key used to encrypt commands sent to the bootloader; the bootloader will only accept the command if it has been encrypted with a specific device key.) Currently, since the SBK Eee Pad Slider is not publicly known, the bootloader remains unavailable.
System Restore is the second part of low-level code on board any Android device. It is separate from the Android user interface and is usually located in its own section; it is usually loaded by the bootloader when a certain combination of hardware keys is pressed. It is important to understand that this is a completely independent program; Linux and the Android user area do not load when booting into recovery, and here there is no high-level concept such as root. This is a simple program, which is actually very primitive for the OS, and it has absolute control over the system and will do anything you like while the code is embedded in it. The recovery of stocks depends on the manufacturer, but often includes such functions, how to reformat the / data section (return to factory settings) and update firmware ROM (update.zip located in the root of the external microSD card), signed by the manufacturer. Notesigned by the manufacturer ; As a rule, custom update files cannot be flashed unless you receive the manufacturer’s private key and sign your custom update to them, which in most cases is impossible and illegal in certain jurisdictions. However, since the recovery is stored in the / system, / data and / cache sections (more on that later), you can replace it with a recovery order if you have access to the Linux / Android root shell. Most people do this only after rooting their device; ClockworkMod Recovery is a popular third-party recovery image that allows you to flash arbitrary ROMs, create backups and restore partitions, and much more.
DAS
ADB (see.ADB White Papers) allows a PC or Mac to connect to an Android device and perform certain operations. One such operation is to run a simple shell on a device using the adb shell command. The real question is from which user the commands executed by this shell process are executed. It turns out that this depends on the value of the Android system property called ro.secure. (You can view the value of this property by typing getprop ro.secure either through the ADB shell or through the terminal emulator on the device.) If ro.secure = 0, the ADB shell will execute commands as the root user on the device. But if ro.secure = 1, the ADB shell will run commands on the device as an unprivileged user. Guess why ro.secure is installed on almost every standard Android Android build. But can we change the value of ro.secure in the system? The answer is no, as implied by ro in the name of the property. The value of this property is set at boot time from the default.prop file in the root directory. Root directory content essentiallycopied from the partition to the internal storage at boot time, but you cannot write the partition if you are not yet a root user. In other words, this property denies root access through ADB, and the only way to change it is to get root access first. Therefore, it is safe.
Android interface
On Android, all applications that you can see or interact directly with are executed as _un_privileged. Logically, a program running as an unprivileged user cannot run another program that runs as a privileged user; otherwise, any program can simply run another copy in privileged mode and gain privileged access to everything. On the other hand, a program running as root can run another program as root or an unprivileged user. On Linux, privileges are usually exercised using su and sudo programs; they are often the only programs in the system, which are capable of making the setuid (0) system call, this changes the current program from starting as an unprivileged user to starting as root. Applications that designate themselves to require root actually just execute other programs (often just their own binaries that come with the application) su. Not surprisingly, standard OEM discs never come with these su, you cannot just download or copy it; for it, the SUID bit must be set, which indicates to the system that programs are allowed to increase their run-time privileges to root. But, of course, if you are not a root user, you cannot set the SUID bit in the program. To summarize, we can say that this means that any program with which you can interact on Android (and, therefore, working in non-privileged mode) cannot either 1) get privileged access and execute in privileged mode, or 2) run another program that runs in privileged mode. If so, the Android system itself is largely protected from attempted privilege escalation. We will see the loophole used by rooting applications on the device in the next section.
III. Struggling with the system
If your device has an unlocked bootloader installed, you are almost done. An example is the Samsung phone that I had. Since the bootloader allowed for the flashing of arbitrary ROMs, someone essentially pulled out a standard ROM from the phone (using dd (UNIX program designed for both copying and converting files)), added su and repacked it to the modified ROM. All I, as a user, had to do was turn off the phone, press a certain combination of hardware keys to start the phone in firmware mode, and use Samsung utilities to flash the modified ROM on the phone.
Believe it or not, some manufacturers do not actually install ro.secure. If so, rooting is even easier; Just connect the phone to the computer and run ADB, and now you have a shell that can execute any program as root. Then you can set the / system function as read-write, read su, and all your dreams will come true
This is not a guide to rooting a specific Android device. Rather, this is a general explanation of how standard ROMs (Permanent Storage) of Android try to prevent unprivileged access (Regular user access without privileges), how hackers attack this problem and how rooting software uses various exploits to protect against these security mechanisms.
I. Purpose
Let's first take a step back and consider , that it iswe mean “Rooting.” Forget about flashing custom ROMs, turning on a WiFi modem, or installing Superuser.apk; In essence, rooting is getting root access to the underlying Linux system for Android and, thus, gaining absolute control over the software that runs on the device. The things that require root access in a typical Linux system are the introduction and liquidation of file systems, the launch of your favorite SSH (network protocol for the application layer that allows you to remotely control the operating system) or HTTP (protocol for the application layer of data transfer) or DHCP (network protocol, allowing network devices to automatically obtain an IP address and other parameters,everything is on a Linux / Android system, and this is the real goal of rooting.
Android standard builds usually do not allow users to execute arbitrary code as root. In essence, this means that you, as a user, are given only limited control over your own device; You can get your device to complete task X,only if the manufacturer explicitly allowed it and sent a program for this. You will not be able to use third-party applications to perform a task that your manufacturer does not want to perform. WiFi modem is a good example of this. Cellular operators obviously do not want you to connect your phone at no extra charge. Thus, many phones come with their own proprietary applications for the WiFi modem, which require additional costs. But without root access, you cannot install a free alternative, such as Wireless Tether For Root Users (This program includes a modem (via wifi) for "rutted" phones running Android); Why is this a common practice (rutting) a riddle for me? The only difference between mobile phones, tablets and computers is their form factor; but while the PC vendor would have suffered a huge failure if it had tried to prevent users from running arbitrary programs on their machines, cell phone providers are clearly not judged by the same principle. But such arguments belong to another article.
II. Enemy: OEM ROM Protection Mechanisms for Android
Bootloader and Recovery
The bootloader, the first piece of code that is executed when the device is turned on, is responsible for loading the Android OS and recovery system and flashing a new ROM. People call some bootloaders “unlocked” if the user can flash and load arbitrary ROMs without hacking; Unfortunately, many Android devices have locked bootloaders that you will have to crack to force them to do something other than loading a standard ROM. The Samsung smartphone that I used a few months ago had an unlocked bootloader; I could press a certain combination of hardware keys on the phone, connect it to a computer and transfer any custom ROM to it using Samsung utilities without having to bypass any protection mechanisms. The same does not apply to my Motorola Droid 2 Global; loader, as far as I know, you can’t hack. The Eee Pad slider, on the other hand, is an interesting beast; as with other devices based on nVidia Tegra 2, its bootloader is controlled through the nvflash utility, but only if you knowsecure boot key (SBK) of the device. (SBK is the AES private key used to encrypt commands sent to the bootloader; the bootloader will only accept the command if it has been encrypted with a specific device key.) Currently, since the SBK Eee Pad Slider is not publicly known, the bootloader remains unavailable.
System Restore is the second part of low-level code on board any Android device. It is separate from the Android user interface and is usually located in its own section; it is usually loaded by the bootloader when a certain combination of hardware keys is pressed. It is important to understand that this is a completely independent program; Linux and the Android user area do not load when booting into recovery, and here there is no high-level concept such as root. This is a simple program, which is actually very primitive for the OS, and it has absolute control over the system and will do anything you like while the code is embedded in it. The recovery of stocks depends on the manufacturer, but often includes such functions, how to reformat the / data section (return to factory settings) and update firmware ROM (update.zip located in the root of the external microSD card), signed by the manufacturer. Notesigned by the manufacturer ; As a rule, custom update files cannot be flashed unless you receive the manufacturer’s private key and sign your custom update to them, which in most cases is impossible and illegal in certain jurisdictions. However, since the recovery is stored in the / system, / data and / cache sections (more on that later), you can replace it with a recovery order if you have access to the Linux / Android root shell. Most people do this only after rooting their device; ClockworkMod Recovery is a popular third-party recovery image that allows you to flash arbitrary ROMs, create backups and restore partitions, and much more.
DAS
ADB (see.ADB White Papers) allows a PC or Mac to connect to an Android device and perform certain operations. One such operation is to run a simple shell on a device using the adb shell command. The real question is from which user the commands executed by this shell process are executed. It turns out that this depends on the value of the Android system property called ro.secure. (You can view the value of this property by typing getprop ro.secure either through the ADB shell or through the terminal emulator on the device.) If ro.secure = 0, the ADB shell will execute commands as the root user on the device. But if ro.secure = 1, the ADB shell will run commands on the device as an unprivileged user. Guess why ro.secure is installed on almost every standard Android Android build. But can we change the value of ro.secure in the system? The answer is no, as implied by ro in the name of the property. The value of this property is set at boot time from the default.prop file in the root directory. Root directory content essentiallycopied from the partition to the internal storage at boot time, but you cannot write the partition if you are not yet a root user. In other words, this property denies root access through ADB, and the only way to change it is to get root access first. Therefore, it is safe.
Android interface
On Android, all applications that you can see or interact directly with are executed as _un_privileged. Logically, a program running as an unprivileged user cannot run another program that runs as a privileged user; otherwise, any program can simply run another copy in privileged mode and gain privileged access to everything. On the other hand, a program running as root can run another program as root or an unprivileged user. On Linux, privileges are usually exercised using su and sudo programs; they are often the only programs in the system, which are capable of making the setuid (0) system call, this changes the current program from starting as an unprivileged user to starting as root. Applications that designate themselves to require root actually just execute other programs (often just their own binaries that come with the application) su. Not surprisingly, standard OEM discs never come with these su, you cannot just download or copy it; for it, the SUID bit must be set, which indicates to the system that programs are allowed to increase their run-time privileges to root. But, of course, if you are not a root user, you cannot set the SUID bit in the program. To summarize, we can say that this means that any program with which you can interact on Android (and, therefore, working in non-privileged mode) cannot either 1) get privileged access and execute in privileged mode, or 2) run another program that runs in privileged mode. If so, the Android system itself is largely protected from attempted privilege escalation. We will see the loophole used by rooting applications on the device in the next section.
III. Struggling with the system
If your device has an unlocked bootloader installed, you are almost done. An example is the Samsung phone that I had. Since the bootloader allowed for the flashing of arbitrary ROMs, someone essentially pulled out a standard ROM from the phone (using dd (UNIX program designed for both copying and converting files)), added su and repacked it to the modified ROM. All I, as a user, had to do was turn off the phone, press a certain combination of hardware keys to start the phone in firmware mode, and use Samsung utilities to flash the modified ROM on the phone.
Believe it or not, some manufacturers do not actually install ro.secure. If so, rooting is even easier; Just connect the phone to the computer and run ADB, and now you have a shell that can execute any program as root. Then you can set the / system function as read-write, read su, and all your dreams will come true
. (Rooted device)
But many other Android devices have blocked bootloaders and ro.secure are configured. As explained above, they should not have root privileges, since you can only interact with unprivileged programs on the system, and they cannot help you execute any privileged code. So what is the solution?
We know that a number of important programs, including low-level system services, must be run with root privileges even on Android in order to gain access to hardware resources. By typing ps on the Android shell (either through ADB or through the terminal emulator on the device), you will get access. These programs are launched by the init process, the first process launched by the kernel (I often feel that the kernel and init process are similar to Adam and Eve - the kernel is spawned by init in a certain way, and init then starts and spawns all the other processes (A rather strange explanation)), which should start as root, because it must run other privileged system processes.
The key idea: if you can hack or trick one of these system processes working in privileged mode to execute arbitrary code, you will get privileged access to the system. Here's how all the methods work with one click, including z4root, gingerbreak, and so on. If you're really curious, I highly recommend this excellent presentation about the various exploits used by current rutting tools., but the details here are not as relevant as the simple idea underlying them. This idea is that in system processes running as superuser in the background, there are vulnerabilities that, if used, will allow us to execute arbitrary code as root. Well, this “arbitrary code” is certainly a piece of code that penetrates the / system in read-write mode and installs a copy of su on the system, so from now on we don’t have to jump through the hoops (Use complex methods) to run programs that we wanted to run in the first place.
Since Android is open source, as well as Linux, people have been thoroughly studying and analyzing the source code of various system services until they find a security hole that they can use. This is becoming increasingly difficult as Google and the accompanying various parts of the code fix these specific vulnerabilities when they are discovered and published, which means that exploits will become obsolete over time with newer devices. But the good news is that manufacturers are not stupid enough to promote OTA updates to fix the vulnerability only to prevent rooting, as it is very expensive for them; In addition, devices on the market always lag behind the latest software releases. So it’s going to be quite a while..
---Post written by Blueberry, Infosec community.
But many other Android devices have blocked bootloaders and ro.secure are configured. As explained above, they should not have root privileges, since you can only interact with unprivileged programs on the system, and they cannot help you execute any privileged code. So what is the solution?
We know that a number of important programs, including low-level system services, must be run with root privileges even on Android in order to gain access to hardware resources. By typing ps on the Android shell (either through ADB or through the terminal emulator on the device), you will get access. These programs are launched by the init process, the first process launched by the kernel (I often feel that the kernel and init process are similar to Adam and Eve - the kernel is spawned by init in a certain way, and init then starts and spawns all the other processes (A rather strange explanation)), which should start as root, because it must run other privileged system processes.
The key idea: if you can hack or trick one of these system processes working in privileged mode to execute arbitrary code, you will get privileged access to the system. Here's how all the methods work with one click, including z4root, gingerbreak, and so on. If you're really curious, I highly recommend this excellent presentation about the various exploits used by current rutting tools., but the details here are not as relevant as the simple idea underlying them. This idea is that in system processes running as superuser in the background, there are vulnerabilities that, if used, will allow us to execute arbitrary code as root. Well, this “arbitrary code” is certainly a piece of code that penetrates the / system in read-write mode and installs a copy of su on the system, so from now on we don’t have to jump through the hoops (Use complex methods) to run programs that we wanted to run in the first place.
Since Android is open source, as well as Linux, people have been thoroughly studying and analyzing the source code of various system services until they find a security hole that they can use. This is becoming increasingly difficult as Google and the accompanying various parts of the code fix these specific vulnerabilities when they are discovered and published, which means that exploits will become obsolete over time with newer devices. But the good news is that manufacturers are not stupid enough to promote OTA updates to fix the vulnerability only to prevent rooting, as it is very expensive for them; In addition, devices on the market always lag behind the latest software releases. So it’s going to be quite a while..
---Post written by Blueberry, Infosec community.
