yashsingh1/xdaforums huggingface dataset:
[Nexus 6  General] Shadow53:
If you go to superuser.phh.me, you may be able to find a version of the boot image for flounder
[Nexus 6  General] CptDaniela:
This image is still in the AOSP-M branch of the seSupersuer/AOSP-SU-PATCH/bin.

Or you could build it ;)
[Nexus 6  General] b8842dc0:
Thanks! Should have figured that out.
[Nexus 6  General] doitright:
Have you bothered to look in the M branch?

Also note that flounder (Nexus 9) have 7.0 sysimages available, I suggest upgrading it.

https://developers.google.com/android/images
[Nexus 6  General] b8842dc0:
Thanks, CptDaniela pointed me in the right direction yesterday. I should have thought of changing branches. It was a total oversight on my part. Sorry for the noise.
[Nexus 6  General] Krzysiek_CK:
After a fresh installation of the November NBD91P image, I get stock on the boot animation after installing shamu-N-boot.img.
[Nexus 6  General] b8842dc0:
What do you mean when you say "I get stock"? Are you saying that you are flashing the shamu-N-boot image but the superuser app is complaining?
[Nexus 6  General] Krzysiek_CK:
Phone does not complete booting, it stays on the boot animation.
[Nexus 6  General] Shadow53:
Have you tried using the stock boot image and downloading the superuser.zip file that patches it instead? That's worked for me.
[Nexus 6  General] b8842dc0:
It is my suspicion that something has changed with the November update. In my case, I compiled the su binary and Superuser.apk from RDR's source. Then I patched the NBD91P AOSP source code, with RDR's source code patch and copied the newly compiled su binary into the appropriate place in the AOSP source code. Finally, I compiled NBD91P. Everything builds and the ROM flashes successfully. When I reboot, my phone boots up just fine. I install the superuser.apk. But following that, any other app that needs root complains that it can't get root privileges.

UPDATE: I guess it would help if I got ALL of DIR's patches installed. Last night I realized that I missed applying a patch. ;) I've recompiled my ROM, with ALL of the patches and root is working, as expected. I should have looked over everything I did before assuming that the problem wasn't with me. :)

For anybody having trouble with the DIR's pre-built boot images on the latest November Nexus update, let me second DIR's call that the best way to do this is to build it yourself. For the past year, I haven't done that. I've started doing that now and it is really cool. And when you build your own boot image to match your ROM, you won't have boot issues.

Two thumbs up for perhaps the coolest project on XDA!
[Nexus 6  General] thetransit123:
Hi, can i root the nexus 6 with this application?

*Link removed*

The name of the app is auto root tools

Im running android 7.0 stock unrooted

Moderator Edit: No
[Nexus 6  General] doitright:
Yep, obviously something must have changed in the policy for 7.1, which I haven't actually looked at yet, because I use a Nexus 6 and we haven't got our 7.1 build yet.

I should be able to go over it some time this week or next.

Tell me something; did the policy patch actually apply cleanly?
[Nexus 6  General] b8842dc0:
Sorry. This is what happens when I get distracted in the middle of a post. Intended to include that information. No, the policy patch does not apply cleanly. Some of the other stuff results in "Hunk succeeded" warnings, but no failure. Here is the output of the policy patch:

patching file app.te

Hunk #5 succeeded at 454 with fuzz 1 (offset 15 lines).

patching file blkid.te

patching file blkid_untrusted.te

patching file device.te

patching file domain.te

Hunk #4 FAILED at 234.

Hunk #6 FAILED at 299.

Hunk #7 succeeded at 304 (offset -2 lines).

Hunk #8 succeeded at 340 (offset -2 lines).

Hunk #9 succeeded at 368 (offset -2 lines).

Hunk #11 succeeded at 400 (offset 2 lines).

Hunk #12 succeeded at 419 (offset 2 lines).

Hunk #13 succeeded at 446 (offset 2 lines).

Hunk #14 succeeded at 472 (offset 2 lines).

Hunk #15 succeeded at 489 (offset 2 lines).

Hunk #16 succeeded at 505 (offset 7 lines).

Hunk #17 succeeded at 513 (offset 7 lines).

Hunk #18 succeeded at 531 (offset 7 lines).

Hunk #19 succeeded at 557 (offset 7 lines).

Hunk #20 succeeded at 576 (offset 7 lines).

Hunk #21 succeeded at 590 (offset 7 lines).

Hunk #22 succeeded at 602 (offset 7 lines).

Hunk #23 succeeded at 611 (offset 7 lines).

2 out of 23 hunks FAILED -- saving rejects to file domain.te.rej

patching file file_contexts

patching file fsck.te

patching file fsck_untrusted.te

patching file gatekeeperd.te

patching file init.te

patching file kernel.te

patching file keystore.te

patching file lmkd.te

patching file logd.te

Hunk #1 succeeded at 63 (offset 1 line).

patching file netd.te

patching file postinstall.te

Hunk #1 FAILED at 21.

Hunk #2 FAILED at 32.

2 out of 2 hunks FAILED -- saving rejects to file postinstall.te.rej

patching file sgdisk.te

patching file su.te

patching file toolbox.te

patching file untrusted_app.te

Hunk #1 succeeded at 79 (offset 1 line).

Hunk #2 succeeded at 94 (offset 1 line).

patching file vold.te
[Nexus 6  General] doitright:
Right, so probably some fairly simple adjustments needed there. Definitely no point in even bother to try to compile it if the patch doesn't *entirely* apply. Every single change is deliberate and critical.
[Nexus 6  General] leviathenx:
*EXTREMELY* new to android development in general. I've tried to look into how to compile everything, but can't seem to find what I'm looking for. Can someone assist me please? I just flashed down from 7.0 nougat to 5.1.1 lolipop to try and conserve battery on my nexus 6, but would still like to have root access. A BIG THANK YOU IN ADVANCE
[Nexus 6  General] b8842dc0:
Hi doitright, any updates on the patches for the 7.1 code?

Thanks!
[Nexus 6  General] Strephon Alkhalikoi:
[MENTION=7070761]b8842dc0[/MENTION]: It's unlikely he'll be able to reply, as his account is currently "disabled", a euphemism for him being banned.

Check out phh Superuser (search for it).
[Nexus 6  General] b8842dc0:
Thanks, I hadn't noticed that. :(

But, I did just notice that there is an android-7.1 branch there. Should have noticed that. So it looks like it is still getting maintained, by somebody called lbdroid.
[Nexus 6  General] androcraze:
I think that's him.
[Nexus 6  General] scholbert:
Hey doitright!

I knew Koush's projekt and i read your postings in the meantime.

So to be more precisely:

Huge thanks for the revival and following the FOSS way :good:

No crashes here and actually no issues so far!

To give further details:

I am using an unlocked device and flashed your boot.img to emmc in the meantime.

Checked some stuff while being root within Android Terminal app, e.g mounting system partition r/w, copy some files, step into directories which require root permission.

I used Amaze filemanager as well, changed the settings for root explorer mode and it worked without issues.

Let me leave a short comment on that:

I appreciate this method, but as i'm used to know the risk of using a rooted device on a daily base, there's no problem for me with a more general implementation.

The user should have some responsibility as well and be aware of the flaws.

EDIT

O.k. i guess i'll have to learn about latest security designs :o

http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/

Keep on your good work!

Agreed...

Thanks for your reply and have fun!

scholbert
[Nexus 6  General] doitright:
Interesting thing to note is that some of my own software broke with 6.0/supersu, which I worked around by jumping through multiple contexts. With *this* implementation, it goes right back to working as expected with out the context hopping.

I do generally agree with this, HOWEVER, the problem on Android is that the weaknesses in the implementation of root access has led to a very severe abuse of the privilege, including loss of sensitivity to the severity of the warning and authorization. On top of that, just handing out a root shell to some untrusted application is asking for trouble no matter how you look at it. Even if does something very necessary, useful, and appropriate, how do you really know that it isn't also installing a backdoor while the rootshell is open?

To strike a more proper balance, we do have some ideas that we are looking into;

1) Additional contexts derived from su with different/elevated privileges, like su_sensitive, which will be basically wide-open, but difficult to access (enforcement of strong password on the commandline, no auto-allow, no involvement of android application, etc., just a very plain make sure the user REALLY means it EVERY time.), another context su_bindmount, that will only be accessible automatically during bootup to bind mount things from /data/ (that are only writable by su_sensitive) into /system/ (this is a really cool function, since it can allow safe selective replacement of system files without breaking dm-verity, like /system/etc/hosts/)

2) sudo or a sudo-like infrastructure for more precise control over what an application is authorized to do *with* root.

3) eventual deprecation of auto-allow for conventional su, since it is more consistent with standard linux application of su which always demands a password (though we can forego the password and use an allow button), and auto-allows can be handled by sudo with a more proper degree of granularity, since that is what sudo is actually *for*.

Will do!
[Nexus 6  General] nicholseric:
Long live superuser!

Installed your binary boot image. First thing I did was install QuickEdit. Upon browsing to /data, it requested root and I granted permanently. Eyes bloody. I created a local.prop with qemu.sf.lcd_density=360 . Reboot. Love the tablet mode for Chrome and Gmail on the Nexus 6! 360 is the sweet spot. Then using QuickEdit again, I copied and pasted the hosts file to /etc/hosts from http://winhelp2002.mvps.org/hosts.txt . ProjectFi bandwidth saver! Fired up jackpal.androidterm and #su. Eyes were pleased at 360! See attachment.

Any chance you will post a binary with the necessary bits to keep dm_verity happy? "For bonus points, use the verity_key file from the FACTORY boot.img, and return fstab.shamu line 53 to its original state. This will RE-ENABLE dm-verity security on your system partition, and without denying you your root!"

I had AndroidPay already set up but never tried paying yet. From reading http://www.xda-developers.com/googl...-with-root-and-android-pay-in-the-xda-forums/ with dm_verity missing and presence of /sbin/su and modified /system/etc/hosts I doubt it will work. I'll try tomorrow.
[Nexus 6  General] nicholseric:
Android Pay update - As I suspected, I could not add another card (error below) and the existing card (not previously activated) would not activate (no error),after the merchant issued the authorization. Not really a big deal, looks like I can build the boot image myself with verity on or repack the stock image.

Android Pay cannot be used - Google is unable to verify that your device or the software running on it is Android compatible.

I cant wait to see how this new superuser and features develop! Thanks doitright and phhusson!
[Nexus 6  General] doitright:
Don't you just love that error message? Like the code that makes the message could even run on something that isn't "Android compatible".
[Nexus 6  General] camcory:
Well I applied the patches to sepolicy,core and device built it all up but couldn't use your Superuser.apk had to build my own but so far so good. Shamu enforcing and encrypted.
[Nexus 6  General] doitright:
Probably the packageName. Doing the build through eclipse doesn't really work right, so it ends up breaking the packagename (and apparently also the layouts) if you don't set it back to koush's original package name. It ends up with the binary tying to one name, and the android application to the other. Its probably getting to be time for me to update to the new way of building things ;)
[Nexus 6  General] sykopompos:
[MENTION=6124077]doitright[/MENTION] I see that you did allow on the su domain, I would have probably went with an auditallow which lets it act like permissive with letting it through but still shows in the logs of the avc so we see exactly what is being requested
[Nexus 6  General] doitright:
Excellent idea! Please send me a pull request ;)
[Nexus 6  General] sykopompos:
I'm being lazy about turning on my computer.

As far as the rest of the policy, userdebug and eng already have su access to the other domains so you might be able to patch user build into that instead of patching each domain for su access, when I stop being lazy, I give it a test run to see if it could slim down your patch a bit
[Nexus 6  General] doitright:
I don't quite understand what you mean. It sounds like you are referring to the list of "-su" that are added throughout. If that is the case, you need to understand that neverallow rules don't actually become part of the policy, they are just used to validate allow rules. As a consequence of allowing the su domain to access things, it needs to be excluded from the neverallow rules in order to satisfy the build system.

You will also note that I changed the su domain from the AOSP source. I have it ENFORCING, which required the dontaudit rules to be swapped with allow rules, hence necessitating the exclusions.
[Nexus 6  General] sykopompos:
That's not what I was referring to, the userdebug_or_eng su exceptions throughout the policy are for the actual su domain to be created and is stripped out in a user build by design, it has nothing to do with the never allow rules other then catching that it is in the general policy which is a no no.

If you build userdebug, it adds all those su exceptions to those domains that you whitelisted yourself slimming down on your patch a bit (should be able to change eng to user to get those into the user policy)

Edit for link https://github.com/marshmako/platfo...mmit/af56ac19545ff083ceb3c1ddf4bf8e2663d4b934

Edit 2, previous commit was replaced with this one https://github.com/marshmako/platfo...mmit/88ce951d89c4c4ad4d870ca34cc5bdcc8b60f54d
[Nexus 6  General] baddison:
As a linux user myself, I totally agree with this line of thought. Seems it would be easier to simply grant SU rights as needed with each app request....

Edited to add: ...but after reading through the explanations, I've got a better understanding of how/why root needs to work the way it does. Thanks much [MENTION=6124077]doitright[/MENTION] & others.

I'll be following this thread very closely...eager to jump on board.
[Nexus 6  General] doitright:
I'll admit that I have a pretty serious cold right now and I'm not all there, but I'm pretty sure that you aren't seeing the whole picture properly.

The AOSP su domain is PERMISSIVE, which means that it doesn't *need* to be excluded in order for the policy to build.

I changed it to enforcing.

For the purposes of my patch, the userdebug_or_eng test is irrelevant, since my builds are userdebug. In fact, AOSP doesn't even include a user build options for ANY supported device.

You're building on Linux

Lunch menu... pick a combo:
1. aosp_arm-eng
2. aosp_arm64-eng
3. aosp_mips-eng
4. aosp_mips64-eng
5. aosp_x86-eng
6. aosp_x86_64-eng
7. aosp_deb-userdebug
8. aosp_flo-userdebug
9. full_fugu-userdebug
10. aosp_fugu-userdebug
11. mini_emulator_arm64-userdebug
12. m_e_arm-userdebug
13. mini_emulator_mips-userdebug
14. mini_emulator_x86_64-userdebug
15. mini_emulator_x86-userdebug
16. aosp_flounder-userdebug
17. aosp_hammerhead-userdebug
18. aosp_hammerhead_fp-userdebug
19. aosp_shamu-userdebug

Which would you like? [aosp_arm-eng]
[Nexus 6  General] sykopompos:
You just confused me there.

The domain being permissive has nothing to do with it building or not, kit kat had the whole system permissive except a few domains, lollipop had a more enforcing policy on several more domains but still had others being permissive.

A single domain being permissive does not stop the policy from building or changes the policy into a full permissive, it just makes that one domain permissive while the rest of the policy is enforcing.

Userdebug or eng builds with the su.te while user has that domain stripped out so it can have adb commands ran unlike user which has it stripped. Those can be expanded on without adding su domain access to all the other domains
[Nexus 6  General] doitright:
Right. Permissive does NOT stop it from building.

ENFORCING stops it from building.

Like the new su domain.

When the su domain is converted into enforcing and the dontaudits are converted into allows, those new allows conflict with the neverallows and the build breaks.

Go ahead and try NOT allowing su access to those domains. su isn't very useful if you cut off its balls.
[Nexus 6  General] sykopompos:
Why would you convert su over to an enforcing domain though?

Converting it to enforcing and giving it full allow rules is practically the same thing unless you are going for auditallow which basically turns it right back to permissive, you aren't cutting off it's legs, you are just making more work for yourself

Don't audit rules is just telling the selinux not to audit that domain and when turning it back on you hit the neverallow rules, you can walk right past them if you are making the policy since they are like child safety locks and can be bypassed with raw.

Truthfully if you are going through that much work on it and you plan to give different levels then you might as well do something similar to converting the su binary as run-as and define it as a more restrictive policy and then make a new binary for your su_sensitive but that you gotta get app devs on board to use those new defined uses
[Nexus 6  General] doitright:
To prevent selinux from being disabled or a new policy loaded (which has a similar impact).
[Nexus 6  General] sykopompos:
But you still gave su access to the kernel domain (I'll have to look at your patch again but that is what it looks like but I could be wrong) which still can load a new policy then.

You could strip the permissive part and drop the dontaudit on the kernel to not load a new policy then define the rest of the normal kernel changes (for kernel devs)
[Nexus 6  General] sykopompos:
I see now that you blocked kernel security out with a comment and added it to the never allow rules for the policy
[Nexus 6  General] doitright:
edit; delete. Redundant.
[Nexus 6  General] doitright:
Yep.
[Nexus 6  General] Eddiemc:
CyanogenMod's superuser, am I correct in assuming it's similar to this type of root compared to superSU?

I seem to remember Koush working on it in his cm days..

You've provided some great info around supersu's implementation, care to share some on cm's superuser?

Regards - e
[Nexus 6  General] nicholseric:
I unpackaged your image and copied in factory verity_key, they did not match:

Your binary contains md5sum 64b2221df7a1e5c026992a5777a38769

shamu-mra58k-factory-5b07088c contains md5sum 7dae101f4f28f700499678fa8d6dafe4

I modified the init.rc for hosts, diff'd here against factory:

diff init.rc ../../../shamu-mra58k-factory-5b07088c/shamu-mra58k/boot/ramdisk/init.rc

268,270d267

< # if it exists, mount bind /data/hosts to /system/etc/hosts

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

<

657,662d653

< oneshot

<

< service daemonsu /sbin/su --daemon

< class main

< user root

< seclabel u:r:su:s0

And turned verity on in fstab, diff'd here against your fstab:

[havealoha@CentOS7-DELL9020 ramdisk]$ diff fstab.shamu ../ramdisk-original/fstab.shamu

6c6

< /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait,verify=/dev/block/platform/msm_sdcc.1/by-name/metadata

---

> /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait

After repacking, I flashed this and factory system.img but superuser says that the su binary needs updating and I get the corrupt device boot message. http://g.co/ABH

Any idea where I went wrong? Here is the .img https://goo.gl/M386c8
[Nexus 6  General] doitright:
I haven't looked at CM's, to be honest. What I can say, however, is that it is far too integrated with the rest of CM to be useful to anyone else.

As I recall, Koush had some kind of falling out with CM when CM was being converted into MS's lap dog over... I think it was licensing of something. I believe that Koush may have had GPL in some of his projects, and refused to relicense to APL, which CM required in order to close the source of some branches of some projects. Note that Superuser wasn't involved, since Koush forked APL code to start the project.

I suspect (without looking) that CM is still operating on a fork of Koush's Superuser, just as we are. As for how far they have diverged... your guess is as good as mine.

Edit: CONFIRMED. CM is still working off of a fork of Koush's su: https://github.com/CyanogenMod/android_system_extras_su/commits/cm-13.0
[Nexus 6  General] doitright:
At first glance it *looks* ok. I would have to take a much closer look at it though, but can't right now. I'm utterly exhausted, sick, and I have family coming over shortly.
[Nexus 6  General] Eddiemc:
Thanks and thanks☺ keep up the good work. This seems to me the only "sane" way to root android roms now (closed source company owned root method is just insane). I hope it will spread and turn in to the superior (ease of implementation for noobs) alternative to superSU.
[Nexus 6  General] nicholseric:
I have a feeling it might be local selinux and the su binary. Maybe the upack and repack process. When or if you ar anyone else has time, that would be much appreciated. Get well soon!
[Nexus 6  General] Lost Dog:
This is kind of similar to what we're seeing now in the open source router firmware world. So many people were unlocking country restricted wifi bands the FCC has put pressure on the router manufactures to close source much of the code. In many cases the control over the wifi has now been moved to closed source portions of the firmware making it off limits. Unfortunately more and more of the source code is being placed in the protected firmware. When you get people putting out custom firmwares to use frequencies that are restricted and can cause interference, then boosting the transmit power the FCC can get touchy.

Don't get me wrong.... I understand the appeal to move to a empty frequency when you're in a crowded area but it's been noticed and we are seeing the results.

I would love if we could manage to get the su situation to a place where it could be trusted and still allow things like Google Pay, etc to live along side it.
[Nexus 6  General] doitright:
That shouldn't be, since the verity applied to the system partition, not the boot partition. The boot partition integrity is the responsibility of the bootloader. In fact, the kernel *can't* validate the integrity of the boot partition, since it is part of it. Or maybe they do have funky code in the kernel that checks back to the boot partition -- if that is the case, we just need to slice that code off and rebuild the kernel (proving that the kernel can't be trusted to validate itself).
[Nexus 6  General] doitright:
I promise you that FCC has nothing to do with this. Like you said, the FCC sensitive code is already in firmware blobs.
[Nexus 6  General] nicholseric:
I gave up on the repackage idea and sync'd my AOSP, compiled supersu, patched with your su.patch, copied su into place, turned on verity in fstab, replaced with factory verity_key, added my init.rc hosts mount bind and made bootimage! To my surprise, compared to making CM, there were no obstacles or errors except Open JDK, make complained despite your patch so I changed line 184 to false "ifeq ($(requires_openjdk), false)"

After flashing factory system.img and this new boot.img, at boot I get the corrupt device warning. Surprisingly, now I cant su in terminal emulator, I get a permission denied. I also get a opendir failed, Permission denied after cd'ing to /data and doing an ls. cd'ing to /system/etc and cat hosts reveals that the mount bind hosts did not work either.

Here is that image: https://goo.gl/D2jha7