yashsingh1/xdaforums huggingface dataset:
[T-Mobile Samsung Galaxy Note5] guaneet:
Just unlocked my phone through the unlock app. Worked great for me
[T-Mobile Samsung Galaxy Note5] vlase_2:
Use a third-party unlocking service like UnlockRadar.com. They have this dedicated service for the T-Mobile Device Unlock App.

Check it out here: https://www.unlockradar.com/service/t-mobile-usa-device-unlock-app-official-unlock
[T-Mobile Samsung Galaxy Note5] red de0392:
I have unlocked device! Will be able to flash any rom on my phone, as in roms developed for other variants too?
[Nexus 6  General] itskapil:
Nice thing you came up. Sounds awesome.

We should have an alternate to all LLC thing, no matter how much respect (I owe you Chainfire thing) we got for the man who created CF Root (since Galaxy S days) and SupeeSU.
[Nexus 6  General] HolyAngel:
wow, tyvm for this! Will definitely test for ya and let you know.

I already applied your patch, built my own binaries and the boot.img but won't have a chance to test anything until tomorrow. Would love to get this %100 working fine and yeah, will use this from here on out instead of supersu.

Thanks again and yeah, will post when I have something ^^
[Nexus 6  General] ibsk8:
I will be following progress closely, as should others. Without something like this, many in the community may naively let a corporate entity control root access on their devices. This is extremely frightening, it may not happen right away but if you believe the an entity will not monetize or exploit the current situation I believe you are sadly mistaken.

I could be wrong, however, it's not a risk I will take lightly and no one else should either.

Thanks for this.
[Nexus 6  General] droidstyle:
Nice work!! Will be following this thread closely. :)
[Nexus 6  General] Larzzzz82:
Time for me to learn eclipse. And do a heck of a lot more reading. :)
[Nexus 6  General] doitright:
Just note that I use eclipse because I'm used to it. Its become the "old" way for android dev.
[Nexus 6  General] TheLoverMan:
i just paid for superSU is this the same people?
[Nexus 6  General] doitright:
I'm not sure what you are asking... are you asking if I am in any way affiliated with supersu, then you probably failed to read the first post in this thread altogether.

Charging money for a binary blob to use root on your device is borderline criminal, and unquestionably immoral. I'm sorry to hear that they got something out of you.
[Nexus 6  General] Lost Dog:
This is pretty great. I'll be watching this as well.

Perhaps this is not the place to take the tangent but why does root behave as it does and not more similar to a standard linux distro? It seems like it would be much more secure to have a sudo function as opposed to an all encompassing root. I'll admit I'm not that familiar with the inner working of the android OS but off hand I can't think of any program that absolutely needs to be automatically granted root every time it wants to run (I'm sure there are but even in this case the power user could chown it to standard root).

Wouldn't it be much more secure if you had to go in to developer options (which are already hidden by default) and turn on the option for sudo. This would then require a sudo-user password (perhaps even different than the standard lock screen password). Need to run a adblock update? Enter the password. Need to run Titanium backup? Enter the password... etc. Much more secure than a push of "accept".

Sorry for off topic but it's always made me wonder and seems like it would be root done right (see how I tied that back to the topic :cool:) If elevating programs/tasks to a superuser was more secure perhaps it would not need to be such an issue...
[Nexus 6  General] GuestX0057:
^ Some root functionality is just too common for a Linux like sudo password to be usable at all. I'll give 2 examples:

1. Since Lollipop Google disabled access to mobile network settings for third party apps. Now it's only possible with root. I have an app that together with Tasker automates my network changing. That network app needs root access EVERY time there is any changes to the connected network and when it wants to change the settings.

Phone connects to a different cell tower? Root needed to detect this and determine the mobile network status.

You can figure how many times this is required per day.

2. I use Greenify to force some misbehaving apps to sleep after the screen goes off. It needs to request root every time it wants to sleep one of those apps. In other words every time I use them, after my screen goes off and I turn it back on I'd be facing both my secure lockscreen and the sudo password.

There's are plenty of other apps that need to request root access on a regular basis. These were just a few examples. If you only need root for TiBu then a sudo password type of security measure would work. In my case all I'd be doing with my phone would be typing that password again and again.
[Nexus 6  General] scryan:
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
[Nexus 6  General] urrgevo:
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
[Nexus 6  General] golfgtiedition30:
Interesting thread. Thanks for your work....subscribed ;)
[Nexus 6  General] Philip:
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.

I've read a few articles suggesting that they would prefer to prevent people from rooting their phones (partially so that they can monetise Android Pay - which requires a Trusted Computer Base, which means unrooted - as well as controlling Ad Blockers, which affect a revenue stream). I also suspect that only a tiny minority of Android users - and most of them are probably on here - actually root their devices.

Regardless of the motives, having a technological monoculture is never a good thing, especially when it is delivered as a binary owned by an unknown organisation.

(No disrespect to Chainfire - I have had many years of root access to my devices thanks to his efforts.)
[Nexus 6  General] doitright:
Not quite.

"root" is the *name* of a privileged user, with user id of 0.

The "su" command (short for substitute user), is used to substitute your current user for another user, but most particularly root.

Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
[Nexus 6  General] doitright:
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
[Nexus 6  General] doitright:
Nope. The root directory can be setup to be accessible by specific users just by applying the appropriate permissions to the files.

The root directory and root user are not specifically related.
[Nexus 6  General] Philip:
Because the "third party" might actually be Google (or an organisation funded by them).

---------- Post added at 15:05 ---------- Previous post was at 15:02 ----------

Shouldn't need to su to root to do this - that's what setuid and setgid are for.
[Nexus 6  General] slifox0:
Good point. I've created some issues on phhusson's super-bootimg project to track these. Thanks again for both of your work on this so far.

---------- Post added at 08:29 PM ---------- Previous post was at 08:20 PM ----------

I don't think this approach will work. From the docs for the init system:

The import keyword is not a command, but rather its own section and is handled immediately after the .rc file that contains it has finished being parsed.

Your best bet will probably be to put a call in init.rc to execute your custom script after /data loads. However if you don't lock down that script, this might open up a security hole. Another option would be to call a script (stored in the boot image) which parses your /data/customizations.cfg and only allows an explicit set of actions (e.g. setting DPI to the given integer).
[Nexus 6  General] phhusson:
I made an autobuild bot in https://github.com/phhusson/super-bootimg

The result is available: http://superuser.phh.me/

Several notes:

- Those builds uses the verified boot feature available on recent devices.

To use it, fastboot flash keystore keystore.img (the keystore is the same for all devices), then flash the boot.img, then go back in verified mode. You should now get YELLOW state instead of ORANGE state on latest Nexus. On Nexus 9, you get a red warning instead of the open lock.

Theorically, this feature makes it possible to ensure noone reflashed your device with another boot.img. The bootloader should display the fingerprint of the keystore on yellow security screen. Check it is always the same fingerprint to ensure safety.

I'd appreciate feedback from 5X/6P users on this feature.

- THIS IS HIGHLY UNTESTED, TRIPLE CHECK WHAT YOU'RE DOING

- As already mentioned earlier, at the moment, only the -eng build will work, don't expect the -user build to do anything useful. (it starts su... and that's pretty much it).

But the -eng has su domain permissive, which isn't as secure as [MENTION=6124077]doitright[/MENTION]'s source-based roots.

If you want to add some ROMs or boot.img configurations into the auto-builder, you can see on https://github.com/phhusson/super-bootimg/tree/master/known-imgs how to add support for new ROMs. Ask if you want some other downloadable ROMs to be supported.

Edit: tombriden tested the keystore on Nexus 6P. It doesn't work. At all. DO NOT USE. It's even dangerous.

Sounds like these bootloaders doesn't respect their own documentation.
[Nexus 6  General] nicholseric:
Will the script\builder ever support removing chainfires su?
[Nexus 6  General] tombriden:
yep, fastboot flashing the keystore won't work at all and dd'ing it from recovery works but stops it booting altogether. Managed to get back into recovery to reflash my backup of the original keystore image but I don't recommend anyone else try it!
[Nexus 6  General] phhusson:
Mmm... Since it's mostly targeting Android M, and thus boot.img modification, I'm not sure what would you like to do? Delete the APK?

There is something really fishy on this bootloader's implementation...

I hope I can get a hand on a Nexus or a Google bootloader developer soon enough.
[Nexus 6  General] nicholseric:
Lets say I have the Pure Nexus M rom installed, unfortunately, it uses chainfires binary in /system/xbin/su

Will the script ever be able to change the existing boot.img to remove that and change init to use your /sbin/su? If it is not removed, explicitly blocking it using sepolicy? And will it change the daemon to use the right path?
[Nexus 6  General] abuttino:
This would be a good idea for an updater script. Remove ChainFire's system root and flash the files needed for this.. I know of a few ROM developers that don't intend on stopping use of his solution.

They have great ROMs but don't care much about this situation.
[Nexus 6  General] phhusson:
I don't plan to mount /system partition read-write

Though we could imagine to mount -o bind /dev/null to it if needs be.

Ok, as [MENTION=336570]abuttino[/MENTION] mentions, this is relevant only for custom ROMs, so the question is more appropriate for when there is an update.zip of it.
[Nexus 6  General] craigacgomez:
[MENTION=6124077]doitright[/MENTION] I extended your patch a bit and wanted to share my changes...

First, I updated the sepolicies (after using your su.patch) to not require userdebug_or_eng for anything involving su... something like saying su on user builds. Here's the relevant commit

https://github.com/craigacgomez/pla...mmit/6341b416621a418ea03ee0eac87eaf3277ea0181

Second, I made a change to the daemonsu start in /system/core/rootdir/init.rc moving it to the very end of the init.rc file and I changed the class from main to late_start.

service daemonsu /sbin/su --daemon
class late_start
user root
seclabel u:r:su:s0
oneshot

And with this init.rc change, I can now use Superuser even if I encrypt the device. Before this change, after encrypting my device, I noticed that daemonsu doesn't start, so I made the above change and tested in on my Nexus 9 & Nexus 5X and it works great!
[Nexus 6  General] baddison:
Love the way this thread is progressing!!! thanks [MENTION=6124077]doitright[/MENTION] for what you've started here :) :)
[Nexus 6  General] doitright:
Though not really applicable as an addition to my patch (since AOSP6 doesn't seem to have any user build option for supported devices), that should be very useful to phhusson. Thank you!

Any logs supporting this necessity? At first glance, it doesn't look like it should actually accomplish anything, since it should only depend on the availability of /sbin/su, which doesn't (or at least shouldn't) depend on the data partition... unless its crashing out when testing for the database? That might suggest that it would be better to look at the su binary to see what is going on rather than just starting it later in the boot.
[Nexus 6  General] tombriden:
This same issue hit me today when requiring my pattern to decrypt data. It was working fine when encryption used its default password. I changed to late_start in my boot.img and can confirm it does fix it
[Nexus 6  General] doitright:
Like I said, if there is a flaw that this works around, that isn't a fix. I need logs.
[Nexus 6  General] craigacgomez:
My C skills are fairly rudimentary and I am not sure what changes I can make to su to get more useful logging, but here's what I can tell you...

1. This test was done on a devices without default encryption enabled. Encryption was done post device setup with pin security.

2. Logcat on encrypted is not accessible until the device pin is entered.

3. On an encrypted device with the init.rc daemonsu service started as class main, when an app requests root and su.c su_main(*) calls connect_daemon(*), it fails to connect to the daemon socket and throws a ECONNREFUSED (111) error. I am assuming the daemon is not running and there is no socket open. Here's what is printed in the logcat when a su request is made in this case:

11-09 10:09:03.599 3514 3514 D su : starting daemon client 10088 10088
11-09 10:09:03.609 3515 3515 E su : connect failed with 111: Connection refused

4. On an encrypted device with the init.rc daemonsu service started as class late_start, when an app requests root and su.c su_main(*) calls connect_daemon(*), it successfully connect to the daemon socket and continues as expected. Here's what is printed in the logcat when a su request is made in this case:

11-09 09:51:57.655 3770 3770 D su : starting daemon client 10088 10088
11-09 09:51:57.667 3772 3772 D su : connecting client 3769
11-09 09:51:57.680 3774 3774 D su : remote pid: 3769
11-09 09:51:57.690 3775 3775 D su : remote pts_slave:
11-09 09:51:57.703 3776 3776 D su : remote uid: 10088
11-09 09:51:57.715 3777 3777 D su : remote req pid: 3472
11-09 09:51:57.727 3778 3778 D su : remote args: 1
11-09 09:51:57.739 3780 3780 D su : waiting for child exit
11-09 09:51:57.739 3782 3782 D su : su invoked.
11-09 09:51:57.755 3783 3783 D su : db allowed
11-09 09:51:57.769 3785 3785 D su : 10088 /sbin/su executing 0 /system/bin/sh using binary /system/bin/sh : sh

If there is any specific changes you can suggest to get you more information, I'd be happy to make the modifications and and provide the information.
[Nexus 6  General] doitright:
Those logs don't really say much. I would need to see something from when it crashes out.

How about adding a bug report to phhusson/Superuser ...
[Nexus 6  General] craigacgomez:
I finally have a logical explanation for this... and it's not an issue with the su code.

I did a bit of research about init.rc (Android Init Language) and how it works with Full Disk Encryption.

Basically, when we have an encrypted volume (not using the default password/not the forceencrypt way), Android starts up with a minimal framework to load the pin/password entry screen, which call the class_start main, thereby starting all services in class main. At this point only services in class main and class core are started.

Once the password has been verified, Android calls the class_reset main (thereby killing all services in class main) and then loads the full framework which involves calling class_start main & class_start late_start. At this point, services in class main are restarted and those in class late_start are started for the first time. Services in class core were never killed and continue running.

So here's what happens when we have this (code from your patch):

service daemonsu /sbin/su --daemon
class main
user root
seclabel u:r:su:s0
oneshot

1. When the minimal framework is loaded (to display the pin/password prompt), daemonsu starts up just fine when class_start main is called.

2. After verifying the password, daemonsu is killed because class_reset main is called

3. Since daemonsu is defined as oneshot (which means do not restart the service when it exits), when class_start main is called again, daemonsu is not restarted

In short, because class main is started twice for devices with encrypted data and because daemonsu is oneshot, daemonsu doesn't start when class main is started to second time.

What are our options?

1. Move daemonsu to class late_start which gets called only after decrypting and gets called only once

service daemonsu /sbin/su --daemon
class late_start
user root
seclabel u:r:su:s0
oneshot

2. Remove oneshot from the daemonsu service definition to allow daemonsu to respawn when class main is restarted

service daemonsu /sbin/su --daemon
class main
user root
seclabel u:r:su:s0
[Nexus 6  General] Mr_S:
Have a rough idea what's going on but following this thread for the sake of learning,I know you guys are doing a good job so a little thumbs up and sorry for ot!

Mr_s
[Nexus 6  General] dahawthorne:
I'm lost in the technical detail, so can I slip in a non-tech question?

I followed the instructions (clean install of MRA58R, replace boot, boot into Android, install superuser.apk) and it all went better than I had dared hope - a really impressive bit of programming, dotright. I noticed that there was no "Android is upgrading" and the slow count-up of the apps - just straight in there. Also in TWRP on my first backup I got the message "Do you want to keep the system as it is or allow editing?"

So my question is - since it appears that the system image is totally vanilla, can I expect future OTAs to install ok?

++++++++++

Blimey, have I killed this thread with a stupid question...? :)
[Nexus 6  General] slifox0:
It's not a stupid question, but this project is really in early stages and there's no expectation of providing guides/tutorials/assistance. In other words, if things break, you'll be on your own to fix it!

I can't speak for doitright's method, but for phhusson's patches (of which I'm using a subset) I ended up writing a script to easily download and patch the monthly official firmware updates from google and flash my phone. I can't take OTA updates because they fail to install for some reason ("Error" on the green android screen). But more importantly, the OTA updates likely install everything (radio, bootloader, recovery, boot, system, vendor) -- whereas what we want is to install everything, but repatch the new boot.img with superuser/etc. So, most likely you will not be able to take OTA updates without them wiping the boot.img mods -- and new OTA updates could come with a new kernel or initrd, and so would require a new custom-built or patched boot.img file (can't necessarily just reuse the boot.img from the last firmware version).

I also can't answer the TWRP question -- I'm actually using the stock bootloader as my goal is to stay as stock as possible (only modifications to boot.img).
[Nexus 6  General] dahawthorne:
Thanks, slifox0. I thought that it might be the case that the OTA might check wider than just the system image.

I'm ok to try to sort out any problems - in fact I quite enjoy the excitement... :)
[Nexus 6  General] doitright:
I like the #2 option best. Can you submit a pull request?
[Nexus 6  General] doitright:
Yep, like the other response said.

As far as taking updates goes, I don't now if they check the contents of the boot partition for a match or not. If not, then in theory, it could take the update **IF** you are running the factory recovery (not TWRP!), but you don't want to since when it reboots at the end of the update, if there is a new boot.img, it will obliterate the changes and encrypt your data partition.

Your options are to either update manually, or block the update notification. Since the updates are actually just for show (none of the "critical" patches are even *useful* to exploit), I tend to the latter and just to full updates occasionally when I have nothing better to do. Feel free to compile and install my ota blocker to stop the notice from annoying you; https://github.com/lbdroid/StopOTA -- but you will have to build it yourself.

As far as killing the thread goes... not so much. I've been really busy with my day job and some other projects that need to get done before it starts snowing here (Toronto).
[Nexus 6  General] dahawthorne:
Thanks, doitright. I'm a convert to the manual update, so I'll be doing that in future. The OTA would be handy, but not essential - it takes away some of the propellorhead fun. :)

Actually I just dropped into this thread again to recommend your work in this thread:

http://xdaforums.com/google-nexus-5/help/to-root-mra58n-t3247016

Which I've had to cancel because it's a N5 forum. I'm having a bad day, it seems... :)
[Nexus 6  General] phhusson:
Ok, so new OTAs do applypatches on boot.img, and boot.img does change for every update, so indeed OTA is no go.

To handl eOTAs, I see some options, none that I find satisfactory:

1) Have our own OTA system (Nexus security updates are <10MB, so it doesn't sound too hard)

2) In pre-recovery service, copy back original boot.img, but then user have to reroot by himself

3) [MENTION=6124077]doitright[/MENTION]'s StopOTA

4) 2) + Change recovery to re-root after OTA
[Nexus 6  General] doitright:
I haven't actually looked, but do you think that (1) is actually an option? I would expect the boot.img changes to be a binary patch to the full image itself rather than breaking it apart and patching the insides. If that is the case, then you wouldn't be able to apply the patch against a customized boot.img anyway.

But anyway.... (5) md5sum boot partition, install update, md5sum boot partition, if different, re-root, else carry on.
[Nexus 6  General] phhusson:
That's why I said to have our own OTA system: We generate the update.zip ourselves (would just be original update.zip, with modified boot.img)

How do you apply the update if you don't have original boot.img, how do you reroot?
[Nexus 6  General] doitright:
Ah, ok that makes sense then. I suppose store it somewhere on the data partition with a context that keeps it nice and safe.

Well... at least the re-rooting part is easy, with the binary sepolicy patching approach.
[Nexus 6  General] phhusson:
I think you mixed with option 2) then, option 1) doesn't original boot.img on the device.

For option 2), what I think, is to have a ro property containing the checksum of the original boot.img, another property with its URL

And su_daemon contexts does the checks/writes back.

Not really, where do you re-root? In recovery? So you have changed recovery to re-root? In system? In to-be-written by update boot.img?
[Nexus 6  General] nicholseric:
As far as storing any part of this persistant root mechanisim away from prying eyes, how about a file based image that is loop mounted from /data/ or some offset in the Persistent Data Block?

So you are rooted, then you get an OTA and it replaces your boot.img. What automatic function gets the customized update.zip into cache for flashing from factory recovery? #3 could do this.