yashsingh1/xdaforums huggingface dataset:
[Nexus 6  General] PanchoPlanet:
Transparoot @ solara1973

Pp.
[Nexus 6  General] optoisolator:
Which version(s) of Android is this method compatible with?
[Nexus 6  General] doitright:
You missed the whole discussion. We are NOT changing the name of the application. It is Superuser. PERIOD. The name is regarding the github organization name.
[Nexus 6  General] doitright:
It isn't needed for pre-selinux (i.e. <= 4.4), could apply to 5.x (but I don't work on obsolete versions, so unsupported). Generally best for 6.0 and probably later.
[Nexus 6  General] semail00:
Hello,

I have read many posts and now a lot of confusion in my head, Can i use this method to do with the root on my Nexus 6 mra58n ? I have download from this site ( https://github.com/seSuperuser) the files inside this folder AOSP-SU-PATCH and later proceed with installing recovery , kernel ( Shamu 6.0 boot image inside folder AOSP-SU-PATCH ) and superuser ?

Thanks in advance.

Rgds.
[Nexus 6  General] stokholm:
Just flash the boot image in bootloader mode and install the apk however you like. You'll find both in the bin folder.
[Nexus 6  General] semail00:
Thanks to your immediately reply.

Will I flash only boot immage ( with ADB command ) and install supersu apk in the bin folder but without any recovery custom ? Can i leave recovery stock?

Thanks again.

Rgds
[Nexus 6  General] gee2012:
You need a custom recovery to flash custom files like a superuser.zip for instance.

-Edit- read you meant a apk file install, in that case you don`t need a custom recovery afaik.
[Nexus 6  General] nicholseric:
You can use fastboot flash boot boot.img or from a terminal you can use dd if=boot.img of=/dev/block/platform/msm_sdcc.1/by-name/boot
[Nexus 6  General] semail00:
Ok I will proceed with flash boot image ( shamu-6.0-boot.img in the folder BIN ) by commands ADB and after I install Superuser apk ( also this file in the folder BIN ). Thanks everybody.

Last my question is If are you installing a modified recovery which is yours best advice?

Thanks and rgds.
[Nexus 6  General] stokholm:
I'm a little confused.

What is the relationship between phhusson's boot images (http://superuser.phh.me/) and the ones available in seSuperuser/AOSP-SU-PATCH/bin?

And is the Superuser.apk in seSuperuser/AOSP-SU-PATCH/bin just an older version of the one in the Play Store?
[Nexus 6  General] kxs783kms:
SUpremeRoot

---------- Post added at 10:53 AM ---------- Previous post was at 10:50 AM ----------

SUpplementalRoot

---------- Post added at 10:56 AM ---------- Previous post was at 10:53 AM ----------

SimpULRoot

---------- Post added at 10:59 AM ---------- Previous post was at 10:56 AM ----------

SupremeUser
[Nexus 6  General] nicholseric:
I use TWRP from here https://twrp.me/devices/motorolanexus6.html , instructions included there. Then instead of using the boot.img, you can flash a zip using the custom recovery. Check out the superuser.zip here http://xdaforums.com/android/software-hacking/wip-selinux-capable-superuser-t3216394/ with that version of the zip, get phh superuser from the app store instead of doitrights apk.

---------- Post added at 06:32 PM ---------- Previous post was at 06:15 PM ----------

Unless you intend on maintaining your own ROM or customizing the SE policy, use the phh images and even better, use the superuser.zip from http://xdaforums.com/android/software-hacking/wip-selinux-capable-superuser-t3216394/ He explains the different .img's there. The phh\doitrigh two boot images are based on the same code but phh builds his more regularly and offers a choice of SE policies. Doitrights approach is based on changing your Android source branch for ROM maintainers so they can customize SE policy and incorporate it into the build process. He offered the binaries as a courtesy, they usually trail behind phh, currently by 9 days. Same with the apk.
[Nexus 6  General] semail00:
Sorry but now I do not know what to do if you go ahead with Doitright or PHH.

If I decide to go ahead with the method of PHH i can know starting from MRA58N with unlocked bootloader what files I need and how to install to obtain root?

Thanks and rgds.
[Nexus 6  General] stokholm:
But doitright's image is enforcing. What's the equivalent phhusson image? user? power? Because eng is permissive if I understand correctly.

Edit: Since my confusion seems to be mostly related to the things phhusson has going on, I decided to ask my questions in his thread instead. Please don't reply to this post.
[Nexus 6  General] vMAC:
Sorry to ask a simple question how do I root with this?
[Nexus 6  General] _that:
Read post #2.
[Nexus 6  General] istperson:
Hi!

I've tried to apply the su.patches to my android-6.0.0_r3 based rom, and the build stopped with errors in:

external/sepolicy/app.te:216:ERROR 'unknown type su' at token ';' on line 4251:
neverallow { appdomain -su -bluetooth } self:capability *;
# bluetooth requires net_admin and wake_alarm.
checkpolicy: error(s) encountered while parsing configuration
make: *** [out/target/product/shamu/obj/ETC/sepolicy_intermediates/sepolicy] Error 1

Am I doing something wrong here?
[Nexus 6  General] doitright:
The mechanism for generating them is different. The boot images at me.phh.superuser are generated by modifying the FACTORY boot images, while the ones in AOSP-SU-PATCH are built from source.

The boot images and applications are *NOT* compatible with each other, due to varying package naming conventions. They are otherwise very similar.
[Nexus 6  General] doitright:
You obviously didn't read Pierre's thread. He says, very specifically, that his approach is currently putting selinux PERMISSIVE, and is thus, not yet nearly as secure as the images I have provided. The *goal* of his approach, is to provide an selinux policy that is equivalent to the one I have provided and equally secure, but since his objective is to create a more global support rather than requiring boot images built from source, there is still a lot of work to do in applying those policy differences.

I.e., it isn't always trivial, or even *possible* to build the boot image from source, and very often even if you can, that boot image you create ends up being integrated with some custom system image like CM, that is *far* from compatible with the factory sysimage. Since device manufacturers don't typically publish the selinux policy that they are building, you end up completely lacking the ability to build a boot image from source.

If you are looking for a secure "daily driver", your best option is the boot image + application linked to in this thread, under AOSP-SU-PATCH/bin/. If you would like to test out to provide feedback/assistance in development of the universal approach, you should try Pierre's update.zip.
[Nexus 6  General] doitright:
Let me get back to you on that one.
[Nexus 6  General] doitright:
I just did a build against r26, and the patch holds up without alteration. I have a strong suspicion that I know what is wrong with your build, and it has to do with an assumption I made during the development of the patch. The only thing that I see that could cause the "su" type to not be known, is to try to make a "user" build, rather than a more common "userdebug" build. AOSP does not actually include a "user" build option for any devices, hence my assumption is that anyone building a system image will be building a "userdebug" build.

If you take a look at the file platform/external/sepolicy/su.te, you will notice that the bulk of the file (including the type definition for 'su') is wrapped inside a "userdebug_or_eng" block. So when you build a "user" build, nothing inside there will actually be defined.

Now, problem for building a "user" build, is that there are other places where userdebug_or_eng is used within the policy source, and those other places need to be adjusted as well in order for a "user" build to complete successfully with my sepolicy adjustments.

Now the good news is that you can get by this whole problem by simply redefining "userdebug_or_eng", which you will find in the file platform/external/sepolicy/te_macros around line 306 (that's where it is in r26, could be moved a bit in other revisions).

This is the line in question;

define(`userdebug_or_eng', ifelse(target_build_variant, `eng', $1, ifelse(target_build_variant, `userdebug', $1)))

If you just change that part `eng' to `user', that will be enough to trick it into including all of the code normally blocked by userdebug_or_eng.
[Nexus 6  General] semail00:
Doitright, thanks for your clear explanation and your work. Now more clear also as I am a newbie.

Rgds
[Nexus 6  General] jerdog:
For context:

[MENTION=6124077]doitright[/MENTION] - I am going to make this very public so that it is clear to EVERYONE with half a brain. What you have just stated above, is absolutely FALSE. Anyone could easily go to Github, search for Chainfire, and find his github repos (https://github.com/Chainfire/) and identify a few of the public open source projects he's done. And then anyone who has followed XDA for any amount of time would know that Chainfire's contributions to OmniROM's OpenDelta are well-known, and - you guessed it - open source.

https://github.com/omnirom/android_packages_apps_OpenDelta

Also, anyone who has followed the XDA community would know that Chainfire has personally helped MANY developers with their own projects time and time again.

So I am here to publicly state that this outright character assassination and trolling is against XDA's rules (which you've been warned about before) and is full of lies to suit your interests. It stops now. You don't have to pull this political crap in order to get interest in your project - just do your project and let it speak for itself. You're not Linus - you're building on the shoulders of giants. Be respectful.
[Nexus 6  General] istperson:
Thank you, you're absolutely right. And i was right too, I was doing something wrong.

And the funny thing is, that I had in the back of my mind that I need to check the "userdebug_or_eng" blocks, because I was building neither, but when I took a deep breath and jumped into patching the sepolicy files, it totally slipped my mind.

Thanks again.
[Nexus 6  General] stokholm:
I don't know if you discussed this with Pierre, but do the two of you plan to both keep an updated set of boot images? Given advice I got in this thread, I tried Pierre's, but I can't get it to boot on my Nexus 6.
[Nexus 6  General] phhusson:
Thanks.

That's plain wrong.

What do you call secure?

I don't consider your SU secure either.
[Nexus 6  General] doitright:
I strongly suggest that you consider the context of things before making inconsiderate and unfounded claims about someone.
[Nexus 6  General] jerdog:
Which this reply alone is akin to the pot calling the kettle black. The difference, is that the kettle (me) actually has read all of your statements, trolling comments, etc. and taken that into account. The context I am using is your downright unfounded assertion that Chainfire has, and I quote "NEVER been involved in open source code", as well as all of your other statements about stolen code, etc.

As I said, it ends now.
[Nexus 6  General] androcraze:
Yeah, it does needs to end now, for everyone involved in this silly back-and-forth.

[MENTION=6124077]doitright[/MENTION], [MENTION=1915408]phhusson[/MENTION], and [MENTION=487859]jerdog[/MENTION]:

Petty bickering gets everyone nowhere quickly. We have better things to argue about, and none of those things involve this project.

I am sooooo grateful for all the work and effort you are putting into creating a practical, open-sourced root solution. Please keep up the excellent work.
[Nexus 6  General] ceribik:
In what way did it stop booting?

Did you ever try looking into this again (verified boot with a custom keystore on a nexus 6P)?
[Nexus 6  General] phhusson:
It finally worked. (I was just giving him wrong device's boot.img :s)

I did some extensive research about it here:

http://xdaforums.com/android/software-hacking/verified-boot-disk-encryption-testings-t3248161
[Nexus 6  General] thaidroid:
I'm confused, is this the same method by chainfire?

Forum Home xda-developers XDA Community Apps SuperSU [WIP][2015.10.30] Android 6.0 Marshmallow by Chainfire

http://xdaforums.com/apps/supersu/wip-android-6-0-marshmellow-t3219344

Patched the wrong thing see the link.
[Nexus 6  General] jerdog:
Not really - it is a similar way but meant to be open source driven from the start. Don't pay any attention to the misinformation.
[Nexus 6  General] :
So, getting an N6 tomorrow , to replace my M8.

How do I root? Tell me everything ! :p

(Ok, kidding….I will use this thread or chainfires…. Whatever seems appropriate , and thank you for the info. ;) )
[Nexus 6  General] stokholm:
It's been told. Start at page 1.
[Nexus 6  General] gee2012:
Burry your phone into the ground and root will come eventualy, if you water it that is ;)
[Nexus 6  General] b8842dc0:
Hi, I've been following this project for a few weeks, holding off on rooting my shamu, waiting for this to stabilize, as I'm not interested in a closed-source root. Thanks again for the work you guys are doing on this. I've got a few questions and one comment:

1. This may seem obvious, or perhaps a very stupid question, but for us non-developers out there who place a lot of faith in the work you guys do for us: I'd like to confirm the steps detailed by doitright in his second post in this thread.

If the nexus 6 has not been rooted previously, then all that needs to be done to root is:

a. install the superuser.apk from the GitHub repo, listed in the second post.

b. flash the appropriate boot.img from the same repo, listed in the second post.

Is this correct?

2. Looking at the GitHub repo, it looks like there haven't been any updates in 15 days. Does this mean that there isn't much that needs to be done anymore? How would you guys classify the level of stability, currently? For non-developers who value what you are doing, but primarily value working stability, is it ready for the rest of us? For confirmation (because there have been questions and/or previous issues), does this currently work well with encrypted nexuses?

3. Finally, a comment, given the security issues that might arise from installing a highjacked superuser.apk or boot.img, might I suggest that you guys post md5sums in the original post (or second post), so that we can verify that we are downloading what we (and you) believe we are downloading?

Thanks!
[Nexus 6  General] ahpukuh:
Damn, just installed this a couple days ago

Got a new Nexus 6 and upgraded to Marshmallow first off. Installed all my apps, then decided to unlock the bootloader. Installed everything again, went to root and It failed because I was following the lollipop directions. Phone wouldn't even boot, got to a screen telling me it was corrupted. I thought it was bricked, two days after I bought it. Found the fix By kingpin, thank you!! , now it's all recovered, rooted, running a custom launcher, fat and happy. Now I find this. So I need to what? Go all the way back to factory and start over? Can I just uninstall supersu?

---------- Post added at 01:05 AM ---------- Previous post was at 12:51 AM ----------

Capitalparallax

Wow, nearly exactly the same thing happened to me. Glad it didn't go that far. Worst part for me I think is that everything is working beautifully now, and "maybe" I can't trust supersu...
[Nexus 6  General] abuttino:
I suppose that you can't run this with Viper because it needs Permissive?
[Nexus 6  General] stevetrooper:
6.0.1 is now available for download

Now that 6.0.1 is available to download : https://developers.google.com/android/nexus/images will we need a new boot.img to keep root?
[Nexus 6  General] CapitalParallax:
In an effort to pay penance for asking Q&A in a discussion thread, I went ahead and just tried it to see what would happen. Here are my results for my fellow nooblets trying to understand things.

Having wiped EVERYTHING via TWRP and starting with a clean slate, I proceeded to flash Google's Marshmallow files via fastboot. I flashed my TWRP.img in place of Google's. I did the same with doitright's boot.img. After initial boot, I downloaded the .apk here and installed it, followed by root checker from Play. I did have root, and so far Titanium Backup has been happy with it. So far so good, will update as things come up.
[Nexus 6  General] AlxMAX:
I went through all the steps and eventually I have managed to make it work for Google's new baby, Android 6.0.1 MMB29K. The branch for the repository is android-6.0.1_r3. One of the patches in AOSP-SU-PATCH/patchsplit failed and it was an important one: system_core.patch. It failed because of the many modification made by Google's developers. However one can modify the files by hand. Be sure that su compilation and superuser.apk compilation use the same value defined in packageName.
[Nexus 6  General] _that:
Did you submit your changes as a pull request? Or where can we find them?
[Nexus 6  General] AlxMAX:
I don't have any account on github and I am not too at ease with the git tool, consequently, I couldn't submit any change. The patch failed most probably because the offset of the changes was too big. I have downloaded a clean version of the repository from the android-6.0.1_r3 branch and I have run a diff -Naurp between this clean version and the modified one. I get almost the same diff file as system_core.patch, the only big difference being the one for init.rc.

Part of system_core.patch:

--- a/rootdir/init.rc
+++ b/rootdir/init.rc
[COLOR="Red"][b]@@ -653,6 +653,12 @@ service flash_recovery /system/bin/install-recovery.sh[/b][/COLOR]
class main
oneshot

+service daemonsu /sbin/su --daemon
+ class main
+ user root
+ seclabel u:r:su:s0
[COLOR="Red"][b]+[/b][/COLOR]
service racoon /system/bin/racoon
class main
socket racoon stream 600 system system

The same part in my core.diff:

--- core.orig/rootdir/init.rc	2015-12-08 18:15:22.000000000 +0200
+++ core.new/rootdir/init.rc	2015-12-08 10:26:55.524235316 +0200
[COLOR="Red"][b]@@ -691,6 +691,11 @@ service installd /system/bin/installd[/b][/COLOR]
service flash_recovery /system/bin/install-recovery.sh
class main
oneshot
[COLOR="Red"][b]+ [/b][/COLOR]
+service daemonsu /sbin/su --daemon
+ class main
+ user root
+ seclabel u:r:su:s0

service racoon /system/bin/racoon
class main

I have also attached the core.diff that I have obtained. external_sepolicy.patch also made the patch program show some warnings, but the offsets of the changes were small and it went ahead. As you can see, the modifications are not so numerous. The rest is OK.
[Nexus 6  General] doitright:
Yup.

It is very dd-usable. My time has been distracted in other projects / family / work, so my attention here has been a bit on the low side lately.

There are precisely three people who have access to the repository I link to. All are trustworthy. Its reasonably safe.

If you are concerned beyond that (which is refreshing and encouraged!), then your proper approach is to build from source. We have provided *all* of the resources necessary to do so.

md5sum really isn't going to improve your security at all in this, since anyone can generate an md5sum. md5sum is also very obsolete -- you can add padding to binary files to easily alter its md5sum into anything you like. As far as crypto-hash security, md5sum should no longer be used. Even if you upgraded to a more modern and secure crypto-hash, like SHA2, that wouldn't prove that the binaries are secure anyway. Crypto-hash is used to prove that someone knows a secret without being able to recover that secret from its proof. For example, you store the crypto-hash of a password on a server, then you can prove that you have the password by regenerating the crypto-hash from the real password. The fact that the binaries exist in public to generate the hash from breaks this use. And while it may be true that you can store the hash on one cloud to validate the binary on another, that use depends on the trustworthiness of the clouds storing the data. Frankly, I wouldn't. I certainly don't trust xda, and the other side can be broken into from multiple angles as well.

So the answer is *no*, I won't be posting md5sums.

HOWEVER, the Android application package contains proper signatures. While we haven't yet set up with a group-based signing key for it, this is something we will eventually implement. In addition, we can use the application's security to validate the binary by including a *strong* crypto-hash (SHA-2) of the binary in the application package.
[Nexus 6  General] doitright:
No problem ;)

Correct.

The "skimming" is what led you to this question. In fact, that user was performing a fancy experiment -- maintain a fully factory stock system image, and dm-verity enabled/enforcing. The end result was that he was very successful in the experiment, though we have not yet implemented what we learned from it.

In fact, the boot image that you will be installing has dm-verity *disabled*, which means that the corrupt message *will not* appear.
[Nexus 6  General] doitright:
Usually the easiest and most reliable way to DO that, is by installing the factory system image. If you want to try some other way, then by all means, do so. But if after trying, it doesn't boot any more, or other weird things happen, you may find it necessary to to a proper system wipe anyway.

Resetting the system partition is really easy anyway, so you might as well just to make sure.

Just grab the system.img out of the archive you get from google, and run "fastboot flash system system.img".

Then you can install the root boot.img knowing with certainty that your system is clean.
[Nexus 6  General] doitright:
I'm not sure what "Viper" is, besides a snake, or why such snake would require Permissive...?
[Nexus 6  General] doitright:
Unclear. I'll have to take a look at it to find out what changed.

I'll say that it *probably* does NOT need an updated boot.img.

Maybe try and find out?
[Nexus 6  General] doitright:
Your changes are actually consistent with what I would expect anyway (even for 6.0.0). I split the original patch into individual patches in a "quick and dirty" way, and yes, it was broken like you found. I hadn't yet gotten around to fixing it to apply.
[Nexus 6  General] Lost Dog:
I've tried it... While it boots and for the most part works there is something funky with it. The battery percentage is all honked up... mine is reporting 4,014% and the status bar visually shows the battery as full. I dirty flashed 6.0.1 (fastboot flashed the system.img while leaving everything else untouched). I've seen reports that flashing the stock boot.img fixes the battery issue but I've not tried this myself.

I attempted to revert to 6.0.0 but was flooded with "com.android.phone has stopped" messages. Re-flashing the 6.0.1 system.img fixed that problem so I decided to live with the wonky battery display.
[Nexus 6  General] doitright:
I appreciate the report. I'll see about setting up some newer boot images.

The reason why the com.android.phone process crashed on you is because the 6.0.1 update obviously updated the database version for it.
[Nexus 6  General] pellen:
Just tried this on a clean flash of 6.0.1, and I see the same issues as Lost Dog.
[Nexus 6  General] ziddey:
Issue is probably in init. I poached sepolicy and added the daemon to init.rc (/system/xbin since init is stock) and it seems to be working fine. Might have an extra denial as a result (isolated_app to app_data_file) but it seems to work.

edit: switched to doitright's 6.0.1 sepolicy and am still seeing the same denials. Maybe I screwed up my contexts along the way, but they look right. Either way, nothing seems to be broken (as far as the new denials).

minminguard and some other xposed modules don't work because xsharedpreferences gets denied (isolated_app to app_data_file as well although I think the source used to be untrusted_app or system_app?)
[Nexus 6  General] AlxMAX:
Why do you mix the kernel for 6.0.0 with the kernel for 6.0.1? Since there is a radio update from 6.0.0 to 6.0.1, I suspect there are also changes to the kernel too. An they most probably affect the battery logic.
[Nexus 6  General] androcraze:
If this is for the Nexus 6, I'd label it as such; many folks reading this thread aren't using the N6.