Android - Pros and cons of rooting using apps ("Soft Root") compared to other methods ("Hard Root")

Thanks to AndrewT who posted a link on chat, having this research paper as a refernce in one of the answers. This answer is entirely based on the this paper (May 2015) and highlights common user understandable aspects ( it has a lot of security related material for those interested)

---

• What are the pros and cons apart from above?

• If a device has both options - app based rooting and rooting by methods by developers, which one should I opt for?

Answer: It's all about malware vulnerability. Using Root exploits is a HUGE security risk and that over-weighs any other advantages

What is Soft Root and Hard Root?

• Soft Root : Root is obtained directly by running a piece of software (i.e., root exploits)- either by directly installing on the device or requiring adb shell through a PC connection

• Hard Root : Root is obtained by flashing su binary externally via an update package or ROM

Malware Threat - in general

• Even though legitimate, many convenient one-click root methods operate by exploiting vulnerabilities in the Android system. If not carefully controlled, such exploits can be abused by malware author to gain unauthorized root privilege.

• As described in the Android Malware Genome Project , 36.7% ( of 1260 ) malware samples had embedded at least one root exploit.

• These well-engineered exploits are not well protected, it is extremely dangerous if they fall in the wrong hands.

Who are major root providers and broadly, how does it work?

What are the types of root expolits ?

The paper covers 78 exploits studied. In general , the order of impact ( from the highest to lowest) :

• Kernel Exploits: Due to its privileged position, targeting Linux Kernel is natural to achieve full control over an Android device- example ,TowelRoot

• Library Exploits: the exploits targeting libraries that are used by Android system processes, or external libraries used for supporting different applications, example ZergRush exploit , libsysutils used by Volume Manager daemon

• Application and Application Framework Application layer root exploits : exploits targeting system applications or services, mostly include vulnerable logics introduced by setuid utilities, system applications, or services. example is a vulnerable setuid utility that is only present on XoomFE devices that has a command injection vulnerability

• Vendor-Specific Kernel or Drivers: Vendors either customize the kernel (e.g., Qualcomm’s custom Linux kernel branch) or provide vendor-specific device drivers for various peripherals (e.g., camera, sound). Such code runs inside the kernel space and the compromise of which can also lead to full control over the device.

Number wise , exploits are as in figure below

How difficult is it to lay your hands on Exploit (Source or Binary) ?

Very easy. Easily available from Google search, making it a cake walk for malware authors to leverage such exploits. Googling for 73 exploits lead to 68 of them being available - 46 with source code and 22 with binaries

How do these exploits work?

Major requirements for exploits to work (ordered from most difficult to least) ( malware tag has a lot of these instances)

• Requiring user interactions: (6 out of 78 studied)

  • Asking the user to download an app and manually interrupt the installation
  • Asking the user to boot into recovery at least once .
  • Asking the user to manually put the device into “battery saving” mode .
  • Asking the user to open a vendor specific app and hit a button

• Requiring adb shell through a PC connection: (17 out of 78 studied). For some exploits, adb shell connection is required because of the following most common reasons:

  • The exploit can successfully modify a setting in local.prop which enables root for adb shell only.

  • The exploit needs to write to a file owned by group shell and group-writable (not world-writable)

  • The exploit targets the adb daemon process that requires the attack process to run with shell user. For instance, the Rage Against the Cage exploit targets the vulnerability of adb daemon’s missing check on return value of setuid()

• Reboot: (6 out of 78 studied) Generally, many root exploits require at least one reboot. For instance, a symbolic link attack would allow an attacker to delete a file owned by system with weak permission, to setup a link at the same location to a protected file. After a reboot, the corresponding init scripts would attempt to change the permission of the original file to world-writable, which in reality changes the permission of the linked file

• None or permission: (44 out of 78 studied) The exploits in this category have no hard requirements, however, some of them may require certain Android permissions like READ LOGS in order for the process owner to be placed in certain user group.

Can these exploits be detected by Anti-Virus ?

Since the root exploits are highly sensitive and may be leveraged by various Android malware, it is expected that anti-virus software on Android platform can identify most of them, including the ones implemented by root providers. Overall, the result shows that the state-of-the-art security products on Android platform still cannot address root exploits effectively

4 representative Android anti-virus products were used to test the largest provider (name not revealed) having 167 exploits. Because originally downloaded exploits from the providers database have packed the actual exploit code and employed a tamper-detection mechanism, study crafted 3 different versions for every exploit:

1. Original exploit fetched directly from providers servers, with packing and tamper-detection on.

2. Unpacked exploit, which will expose all actual exploit logic to anti-virus products.

3. Re-packed exploit with tamper-detection disabled.

Exploit binaries engineered by large root providers are surprisingly “clean” as all major anti-virus software have difficulty detecting them as table below shows

Conclusion

Simple. Stay away from Soft Root methods unless you are capable of dealing with the consequences

There are a few advantages to rooting using the official process.

1. It's officially supported on many phones. This means you can use a process that's documented by the manufacturer, and tools from an official source, or a trustworthy third party (CWM or TWRP), instead of having to run a tool that you got from some dodgy website.

2. Because it's officially supported, most of the time, a system update won't change the process, so you don't need to go looking around for "the latest" rooting method. In contrast, software updates tend to patch vulnerabilities, so exploit methods will often stop working after an update.

3. Because of the above, after you "soft root" you might be tempted to not install a system update, because that update patches the vulnerability and stops your rooting method working. With the official process, there's no reason to stay on an old, vulnerable version.

As well as the convenience of a one-click method (mentioned in the question), there are some other advantages of doing it that way instead.

1. Unlocking the bootloader to "hard root" wipes the phone, so you have to set things up again and restore data from backup. Typically "soft rooting" via a vulnerability doesn't need to wipe the phone, and that can be a lot more convenient.

2. Because rooting modifies the system partition, typically you can't do an OTA update afterwards: the updater recognises the system is modified, and bails out. But some "soft root" methods on some phones avoid this problem, so you can do an OTA update without having to unroot or flash a new system image. This is also a bit easier. Either way, you'll still have to root again after an update.

3. Since you don't have to unlock the bootloader, there's no temptation to leave it unlocked. This has the security benefit that people can't flash new ROMs to your phone (e.g. if it is stolen and they want to circumvent the screen lock or factory reset protection).

What Beeshyams says about security is important, but to my mind it's irrelevant to the question. It's good to point out or remind people that every "soft rooting" method is exploiting a security vulnerability, and malware could use just the same vulnerability to install rootkits on your phone. However, the vulnerability is there whether you use it or not. The security risk comes from the possibility of the rooting method. Rooting your phone by exploiting the vulnerability doesn't make it more exploitable, or worse.

If your phone can be rooted by a rooting app/exploit, then it is vulnerable to malware. This is true just the same regardless of whether you root it or what method you use. Not using the exploit (by doing a "hard root" instead, or just by not rooting) will not protect you from malware, nor will it reduce your exposure.

^{On request by OP, some details from chat:}

Good question, but hard to answer: there are a few more things to consider.

1. it's not just "app based versus USB" – and even your "Difficulty in unrooting" is not necessarily the fault of "app based" in general, but rather that of a specific app causing that difficulty.
2. From a security point of view: if there's an app that can root my device – who says another app doesn't just do that without my consent? We all know there's malware out there doing exactly that (in order to integrate itself as system app, to be protected against factory-reset).
3. However, if there's no such app (and in the hope that's because it cannot be done by an app on this device/ROM), it's much harder for such malware. If then there's an easy method via USB, I feel a little safer :) It's rather unlikely some other app manages to attach an USB cable, download something to my computer, and runs that combo to do harm.

So above might count as "contra app-based" – but if such an app already exists for the device in question, there's not much we can do about. Even if we say "it's safer the other way round", that doesn't protect us against #2. Sure, we can check that before buying a device – but who says such an app doesn't pop up the day after?