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


Question

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




  1. Ease of rooting


  2. Don't need a laptop or computer




Minuses




  1. Based on exploits, so may not work if exploits are denied by OS updates


  2. 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 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?



enter image description here



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



enter image description here



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) ( 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



enter image description here



Conclusion



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


Topics


2D Engines   3D Engines   9-Patch   Action Bars   Activities   ADB   Advertisements   Analytics   Animations   ANR   AOP   API   APK   APT   Architecture   Audio   Autocomplete   Background Processing   Backward Compatibility   Badges   Bar Codes   Benchmarking   Bitmaps   Bluetooth   Blur Effects   Bread Crumbs   BRMS   Browser Extensions   Build Systems   Bundles   Buttons   Caching   Camera   Canvas   Cards   Carousels   Changelog   Checkboxes   Cloud Storages   Color Analysis   Color Pickers   Colors   Comet/Push   Compass Sensors   Conferences   Content Providers   Continuous Integration   Crash Reports   Credit Cards   Credits   CSV   Curl/Flip   Data Binding   Data Generators   Data Structures   Database   Database Browsers   Date &   Debugging   Decompilers   Deep Links   Dependency Injections   Design   Design Patterns   Dex   Dialogs   Distributed Computing   Distribution Platforms   Download Managers   Drawables   Emoji   Emulators   EPUB   Equalizers &   Event Buses   Exception Handling   Face Recognition   Feedback &   File System   File/Directory   Fingerprint   Floating Action   Fonts   Forms   Fragments   FRP   FSM   Functional Programming   Gamepads   Games   Geocaching   Gestures   GIF   Glow Pad   Gradle Plugins   Graphics   Grid Views   Highlighting   HTML   HTTP Mocking   Icons   IDE   IDE Plugins   Image Croppers   Image Loaders   Image Pickers   Image Processing   Image Views   Instrumentation   Intents   Job Schedulers   JSON   Keyboard   Kotlin   Layouts   Library Demos   List View   List Views   Localization   Location   Lock Patterns   Logcat   Logging   Mails   Maps   Markdown   Mathematics   Maven Plugins   MBaaS   Media   Menus   Messaging   MIME   Mobile Web   Native Image   Navigation   NDK   Networking   NFC   NoSQL   Number Pickers   OAuth   Object Mocking   OCR Engines   OpenGL   ORM   Other Pickers   Parallax List   Parcelables   Particle Systems   Password Inputs   PDF   Permissions   Physics Engines   Platforms   Plugin Frameworks   Preferences   Progress Indicators   ProGuard   Properties   Protocol Buffer   Pull To   Purchases   Push/Pull   QR Codes   Quick Return   Radio Buttons   Range Bars   Ratings   Recycler Views   Resources   REST   Ripple Effects   RSS   Screenshots   Scripting   Scroll Views   SDK   Search Inputs   Security   Sensors   Services   Showcase Views   Signatures   Sliding Panels   Snackbars   SOAP   Social Networks   Spannable   Spinners   Splash Screens   SSH   Static Analysis   Status Bars   Styling   SVG   System   Tags   Task Managers   TDD &   Template Engines   Testing   Testing Tools   Text Formatting   Text Views   Text Watchers   Text-to   Toasts   Toolkits For   Tools   Tooltips   Trainings   TV   Twitter   Updaters   USB   User Stories   Utils   Validation   Video   View Adapters   View Pagers   Views   Watch Face   Wearable Data   Wearables   Weather   Web Tools   Web Views   WebRTC   WebSockets   Wheel Widgets   Wi-Fi   Widgets   Windows   Wizards   XML   XMPP   YAML   ZIP Codes