[Nexus 6  General] doitright:
Well first off, you *cannot* enable dm-verity with the hosts file modified. So I'll give you a little trick;

mount -o bind /data/hosts /system/etc/hosts

Regarding the provision of a binary boot image with verity enabled, to be honest, it isn't a high priority. We are working on a mechanism to apply the changes to an existing boot.img via recovery script, which will allow you to choose whether you want verity on or off.

For the time being, if you would like to turn verity ON, my instructions aren't *that* hard to follow.... or for that matter, you could go about it the easy way and rip apart and repack the boot image. However, you need to make sure that the actual verity key matches stock. The one on my boot.img's comes from the AOSP source tree at ./build/target/product/security/verity_key -- I haven't compared, but I believe that this is a TEST key rather than google's actual key.

I haven't looked into what mechanisms are being employed to determine whether or not the device has root, but I have a feeling that we may be able to work around it... assuming, of course, that they are actually set up to detect /sbin/su to begin with....

Thoughts are;

1) name of the executable on the PATH,

2) presence of setuid executable anywhere on the system,

3) presence of android control applications with specific names.

There is really only so much you can do to detect it, so throw in the right number of wrenches and randomizers, and you escape their ability to detect. For instance, (1) su does not need to be named "su" to work. You can name it "geoff" and it will still do the job, in fact, it doesn't even need to be on the PATH. You can throw it in /junk/ and it will still work, only difference is that you will need to call it by absolute path, so "/junk/geoff". (2) the su daemon is executed by init, which runs *as* root, which means that setuid is not actually necessary for it to work. (3) randomize the name of the control application and it can no longer be detected on that basis.

(4) the su functionality can actually be hidden within a different binary altogether, having it branch based on detected conditions. For instance, the /init binary can fork during its first run, with a child process becoming the "su daemon", call /init as a non-root user and it follows a path where it becomes the su client.

For some/most of these ideas, however, it would be *necessary* for the end user to build it themselves. The reason being that a widely shared and consistent change would be easy to detect. For instance, if we distributed a modified init that hid the su functionality within, all they would have to do is check the md5sum on /init to detect it. If it was built by the end user, however, the file will come out slightly different for everybody.

However, do note that ULTIMATELY, the fight for an undetectable root is not a fight that we can win. All they have to do is require that verified boot be activated, and then they can detect that the boot.img has been modified.

Our HOPE though, is that once we get all of our ideas to bump up security over root access to "sane", that they won't be so worried about it.

See the big problem that I'm sure they are worried about, is about how badly root access is abused on Android. You *shouldn't EVER* grant ANYTHING permanent general root access, so while they probably aren't so worried about YOU messing with any part of the transaction, they ARE worried that you have granted a permanent allow to some application that might be capturing that transaction and handing it all over to a hostile. That is a serious danger, and it makes their position understandable.