It’s only Tuesday, but it’s already been a pretty great week for Nexus Pixel fans. In a single day, we’ve seen the first alleged non-blurry pictures of the upcoming Google flagship phones and have gotten official confirmation from Google about the mythical October 4th event date.
Besides the news about the supposed pricing model for the Pixel phones, it looks like Pixel hype is now in full blast from now until October 4th. We’ve even gotten on the hype train to Pixel-ville, in our own patented XDA-tweaked engine, with our piece over the weekend discussing the potential custom development possibilities underlying seamless updates. But we weren’t being entirely honest with you in that piece, as not every piece of information we’ve uncovered paints a rosy picture. Because while digging around for clues about the Pixel phone’s partitions, we discovered an uncomfortable truth: it seems that root methods (in their current implementation) seem unfeasible for the time being.
The Superuser’s Losing Battle with Android
If you’re reading this article, chances are that you probably have a favorable opinion of rooting. After all, thanks to root access we’re able to do block ads system-wide, install custom themes, or forego the need for the a custom ROM thanks to the myriad of customizations available within the Xposed Framework. But for the average user, root access is absolutely meaningless. The term itself will draw a blank among non-enthusiasts. For carriers and OEMs, root access is a headache that prevents these companies from locking down your phone within their ecosystem of apps and services. We’ve argued ad nauseam that root and bootloader access should be a right for an informed consumer, and it might seem like we’ve been winning thanks to the availability of phones with unlockable bootloaders such as the OnePlus 3, Axon 7, Honor 8, and of course every Nexus device. But behind the scenes, there’s a different story: attaining root access has been a losing battle for consumers.
Google is responsible for patching exploits that allow for user apps to attain root access, as well as buffing Android’s security in general. Before the introduction of Android Marshmallow, there existed many different one-click root exploits that required neither a bootloader unlock nor boot image tampering. You might have heard about one of the more popular one-click methods, Kingroot. Kingroot is actually an amalgamation of multiple pre-Marshmallow root exploits – the app simply cycles through and tests which of its included exploits your device is vulnerable to. There are no prompts, no requests for user input, no indication that your device is being exploited besides the obvious fact that you explicitly started the app.
The implications of this should scream “unsafe” in your mind. Because of course these exploits could easily be repurposed for malicious purposes. And indeed, they already have been. That’s why Google sought to re-do how it approached Android security with Marshmallow. You will notice that with Android Marshmallow, one-click root methods that are accessed simply by opening up a user app have basically vanished. That’s thanks to the introduction of device-mapper-verity (dm-verity) checking the integrity of the /system partition at boot-time.
Any persistent root exploit that modifies /system would fail dm-verity, and cause your phone to fail the booting process. Dm-verity works by building a cryptographic hash tree of the /system partition. Each 4k block of storage has a corresponding SHA256 hash, and there exists a top-level “root” hash that the OEM uses with a special key to verify the integrity of the hash tree. Modifying even a single block of the /system partition (say, in the event that a root exploit attempts to grant itself su access) would break the cryptographic hash, and result in your phone saying that your /system partition is “corrupt.” Whether or not you can still access your device is up to the specific implementation of dm-verity by the manufacturer, but by default dm-verity is configured in a strictly enforcing “restart” mode which will reboot the phone when a corrupted block is detected. By the way, it’s worth noting that starting with Android Nougat, this strictly enforcing mode is now a requirement.
You can read a more technical explanation of dm-verity from this article.
The Rise of Systemless Root
With root exploits modifying /system out of the foray, how exactly do so many of our users on Marshmallow and Nougat have root access? In a previous article by XDA Developer Admin and famed CyanogenMod device maintainer, Pulser_G2 laid outlined the changes that developers would need to make in order to achieve root access on Marshmallow devices. Rather than re-iterate what Pulser_G2 laid out, I will quote from his excellent article about root challenges within Android Marshmallow:
If you want root today, on Android Marshmallow (6.0), you’re going to need to use a modified boot image. While it remains to be seen if this remains true indefinitely, it looks likely to be the case for some time – SELinux changes make it much harder to get root access without modifying the boot image. And as modifying the boot image requires an unlocked bootloader, this could put an end to root (and Xposed and other root features) on devices which are shipped with bootloaders that can’t be unlocked by end users. Dm-verity is also making an appearance, and it appears to be enabled in enforcing mode on new devices. That will make it hard to modify /system, even if you were to gain root access, without again having an unlocked bootloader.
What Pulser_G2 is saying here is essentially that we must find a way to attain root access without modifying /system. This is where “systemless” root comes from. In order for root access to work on our devices, the superuser executables and su daemon need to be started at boot. Before Marshmallow, this was achieved by modifying /system to include the scripts in init needed to achieve root access at boot, but thanks to dm-verity that it was no longer possible to modify /system. In order to get around this barrier, Chainfire developed a method that involved modifying the ramdisk in order to accomplish the following:
- Patch SELinux
- Start the su daemon at boot
- Disable dm-verity (if applicable)
- Disable forced encryption (if applicable)
This is how SuperSU works on most devices post-Lollipop (and with Samsung phones, post-KitKat). When “systemless” root was initially released, you might have gotten the impression that this method would co-exist with the “traditional” root that we’ve grown accustomed to. If you’ve been reading this article thus far without getting lost, then you’ve probably come to the realization that in reality, systemless root is currently THE default root method.
SuperSU Installation Process. Source: HowToGeek
Systemless Root Moving Forward
Taken all of the information we’ve outlined for you above, what exactly does this mean for Pixel phones? The answer lies within the changes to the partitions to accommodate seamless updates. Specifically, Google made a rather significant change to the /system partition. Dees_Troy discovered an interesting commit within the Nougat kernel source code as well as another commit within the ROM source that allowed him to come to the following conclusion:
What we used to think of as the system partition is now a complete root file system that includes what we traditionally thought of as the ramdisk as well as what is usually in /system.
Given what we know above about dm-verity and how systemless root currently works, it really does seem like current systemless root methods will no longer work. This is because since the ramdisk is now included within the /system partition, we can no longer make changes to the ramdisk to disable dm-verity. Thus, with dm-verity still active, we won’t be able to make changes to /system. How, then, will we achieve root access?
We spoke to Dees_Troy about this issue, and it looks like we would likely need to modify the kernel in order to disable dm-verity. This makes sense, since dm-verity protection lies within the kernel. Modifying the kernel to disable dm-verity and acquire root access is not a novel proposal, but it certainly complicates matters. For instance, installing a custom kernel would disable the ability to take OTA updates. Although, we won’t know exactly how many complications would arise, nor are we sure of exactly what approach developers would need to take to achieve root access, without having a device on hand. But given that current methods won’t work, achieving root access is definitely going to need a team effort from developers. Given how quickly Chainfire and co. seem to achieve root access on new Android versions, though, we’re confident that developers will be able to quickly overcome these hurdles.
0 comments:
Post a Comment