There are quite a few app based rooting methods. A recent review 9 free software apps to root Android devices, points to some of them and there may be more apps, paid or otherwise.
From what I understand,
Plus Points
Ease of rooting
Don't need a laptop or computer
Minuses
Based on exploits, so may not work if exploits are denied by OS updates
Difficulty in unrooting (as I see on some forums for my device Huawei Honor 6)
Questions:
- 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?
Note: I am not seeking app suggestion or recommendation.
Answer
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 connectionHard 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 vulnerablesetuid
utility that is only present on XoomFE devices that has a command injection vulnerabilityVendor-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 foradb
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:
Original exploit fetched directly from providers servers, with packing and tamper-detection on.
Unpacked exploit, which will expose all actual exploit logic to anti-virus products.
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
No comments:
Post a Comment