A Look at Marshmallow Root & Verity Complications

A Look at Marshmallow Root & Verity Complications

As the dust settles on the Android 6.0 release, Nexus users galore are diving for OTAs and Factory Images, and getting ready for the latest iteration of the Android operating system.

While, from the outside, Android 6.0 appears (visually, at least) remarkably similar to Android 5.0 and 5.1  (the Lollipop releases), there are a number of significant changes on the inside. One of them potentially has ramifications for the custom ROM and root communities. First, a little background. If you are not interested in this, just skip down to “Why is this Important”.

A Feature Called Verity

The problem (it’s a problem if you like root and modifying devices) stems from something I pointed out a long time back, when it first hit AOSP – the introduction of dm-verity to Android. Verity is a security feature, originally found in ChromeOS, designed to provide assured and trustworthy computing devices, preventing malicious software from modifying a device. Back in Android 4.4, Google announced verity for Android, and then all remained quiet. While there has been some research into using verity, for the most part, things have been quiet. Until now, that is.


With Android 6.0, Google has begun to up their game on device security. One of the fundamental requirements for this is to prevent the software on a device from being modified without a user’s knowledge – while many here at XDA take root for granted, imagine a user’s device being rooted without their knowledge or consent, and root access being used to steal their data. For this reason, Google has started to implement verification of the system partition on some devices. They also recently updated their support pages to cover this.

What Does this Mean for Rooted Users?

With verity in place, any changes made to the system partition will be detected on boot or access. You’ll then be faced with one of the errors as seen above. Some allow you to proceed, and some want to protect you by stopping the device from booting. There are three states available. One is shown when the bootloader is unlocked, indicating you may be at risk until you re-lock the bootloader. This is the case since a modified kernel image can bypass verity, since the kernel ramdisk contains the keys used to verify a system’s state.

Things look rather un-fun for root-aspiring users on locked-down devices.

The next state is shown (presumably) when verity is disabled or off, or can’t be checked due to modifications to the ramdisk. I cannot be sure, on account of my lack of a Nexus 5X or 6P to investigate, but my suspicion (based around the messages) is that if you load another ROM, which then places its own kernel onto the device, the “different operating system” page will appear.

The final state is the red warning stating the device is corrupt. I suspect this means the image contains verity, but the verification failed due to the system image being modified. Again, we can’t be sure without hardware in-hand, but that error looks to be the one you’ll see if a stock device were modified by a piece of malicious software.

Why is This Important?

On Android M (6.0), root currently requires modifications to be made to the kernel image, in addition to the filesystem. This means that, even if we ignore verity (such as on an older Nexus device like a Nexus 7 2013), a new kernel image is needed, to bypass SELinux protections which prevent root access from working.

If you want root today, on Android Marshmallow, you’re going to need to use a modified boot image.

Until now, there have been modified kernels to set SELinux into permissive mode, but this is a non-ideal fix, as it means you don’t get the security benefits of SELinux protection. And, after the Stagefright saga, I assume you can see the benefits of SELinux and other protections against security exploits.

XDA Senior Recognized Developer, Chainfire, master of all-things root has released an updated version of SuperSU which retains SELinux in enforcing mode, but it once again requires modifications to be made to the SELinux configuration of the boot image. This means you need to install SuperSU, as well as a modified boot image.

And that’s all well and good, until US carriers enter the mix. The bastions of anti-consumer-choice, the stalwarts such as AT&T and Verizon are known to enjoy locking down devices, preventing users from installing custom firmware through their bootloader locks. Indeed, Verizon are particularly bad at not even passing firmware updates onto users, with the Sony Xperia Z3v not set to receive Marshmallow while the rest of the Z3 range (and indeed the Z2 range) will. Heck, they’ve still not even rolled out Lollipop to the device, despite it being available for quite some time (November 2014) on the regular Z3.

In lieu of an unofficial bootloader unlock (those are fairly rare these days, short of leaked engineering bootloaders for a few Samsung devices), it seems highly unlikely that you’ll be getting root on Android 6.0 without some divine intervention – the combination of dm-verity (to stop your phone from booting with any modifications to the system partition), and the requirement for SELinux changes in the ramdisk (to let root work), look set to make things rather un-fun for root-aspiring users of these locked-down devices.

Android Pay?

Finally, Android Pay. It probably sounds completely unrelated to the rest of this article, but it is in fact fairly relevant. Android Pay relies on the new SafetyNet APIs within Google’s proprietary services framework, which is designed to provide device state attestations on whether a device is rooted, or otherwise modified or running in an unapproved state.

While there is a project looking at spoofing responses to SafetyNet, it currently requires an Xposed plugin, and this doesn’t look likely to change, given how it works. Xposed requires root, and makes modifications to the system partition. That makes this difficult to carry out on a bootloader-locked device. Even then, things like this are just entering into a game of cat-and-mouse with Google. With SafetyNet, rooted devices (or indeed devices modified at all), are viewed as “non-CTS compliant”, which is a euphemism for modified devices.

There’s much more written about SafetyNet in this teardown blog post, but it certainly seems we can identify some areas Google want to clamp down on. Firstly, they don’t like root, Xposed, and anything modifying the system partition. Secondly, it seems Google is considering detecting users that have ad blocking enabled – the SSL handshake checks on pubads.g.doubleclick.net certainly suggest to me that Google want to know if you’re blocking ads on your device. Considering that root is usually a pre-requisite there, but that the VPN API could potentially be used to do this without root, it looks like Google at least want to have an idea who (or how many people) are blocking ads. Ad blocking is a topical issue given the push from Apple to support it in the web browser (arguably to encourage people to use apps more, where they control the experience and can offer non-blockable ads), and these moves are interesting.


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.

Does this change your view of bootloader locked devices? Has Android reached the stage where you would still buy a bootloader locked device if your carrier gave you a good deal, or are you only interested in unlocked devices? What root apps or features would you miss on a locked bootloader?

Feel free to share your thoughts in the comments below.

About author


Developer Admin at xda-developers, interested in everything in mobile and security. A developer and engineer, who would re-write everything in C or Assembler if the time was there.

We are reader supported. External links may earn us a commission.