yashsingh1/xdaforums huggingface dataset:
[Nexus 6  General] haibane:
Why can't there simply be an update system like cyanogenmod has. It integrated the latest information and provides otas separate from Android. Obviously I'm not doing the work so I may be asking a lot lol
[Nexus 6  General] phhusson:
That's my 1) ;)

But I expect to support hundreds/thousands of devices, and though I think I can bear the bandwidth of the boot.img-s, I don't expect to support the bandwidth for the whole firmwares/updates.

Current problem is that OTA does NOT replace boot.img. It checks that the boot.img is the original one.

For the other part, I can't see how something in /data or in persistent data block can be used to have persistant root, neither of those have root power.

Though we could indeed trick the recovery into flashing the real update.zip, and then flash a root-ing update.zip. This would require extra care as to not totally kill the security in recovery, and proper recovery handling
[Nexus 6  General] scholbert:
Hi!

Confirmed!

I am using the modified boot image from doitright's repository on Nexus 5.

Everything else is MRA58K stock. Did not even install TWRP :angel:

Yesterday i got an update message for the November patchset and started the process.

Shortly after reboot the error message appeared!

If boot.img get's replaced with a custom one, no official OTA anymore (though you will get the message without any further patch).

Obviously there are some file/partitition checks under the hood...

BTW, thanks for all the efforts going on here :good:

Regards,

scholbert
[Nexus 6  General] doitright:
This is one of the things that I *really like* about google/nexus. If it was any other vendor, they wouldn't care if you'd made modifications, install the updates anyway, and break the whole world.... and of course, lock the bootloader when they're finished.
[Nexus 6  General] NOSTALGIA:
i really hope theres a more eary way of flashing this script...

noob on using a machine....
[Nexus 6  General] haibane:
You do realize this is effectively pre-alpha right?
[Nexus 6  General] NOSTALGIA:
i do... if i just have the machine now.. it should be fine.. but my main pc is borked.. so i have to use neighbors pc.. but... its not available all the time..
[Nexus 6  General] Adreaver:
You shouldn't be flashing anything in this stage of testing if you don't have an easy way to get back.
[Nexus 6  General] NOSTALGIA:
i know. thats why im holding my horses for now
[Nexus 6  General] craigacgomez:
Done!
[Nexus 6  General] b8842dc0:
Thanks doitright (and the others helping) for this very important project. I realize the software development on this project is, as it was stated a few posts earlier, pre-alpha. Therefore, I'm going to wait. However, I do need my shamu rooted -- eventually. Therefore my question is this:

Regarding step 0 of the instructions (quoted above), I've never rooted a phone and then tried to removed root. And currently, my nexus isn't rooted. If I proceed in the interim with rooting using supersu, then what are the steps involved with "getting rid of supersu and all of its tentacles"? Is that a very difficult process? If my long term plans are to have root using "root done right", am I better off waiting for your software to progress beyond beta? Or should I proceed with supersu for now and don't look back until the time is right? (By the way, I'm asking this question purely from a technical perspective -- not related to the free/libre nature of these two options.)

Thanks!
[Nexus 6  General] slifox0:
To uninstall the previous root method, you'll have to flash the official system.img (from google) and the custom boot.img (from this project -- though soon it may be a single image with system/boot/etc packaged together). There might be some pieces leftover in your data partition, like the SuperSU.apk at least; you'd have to track down all these pieces to delete them. Finally if SuperSU is nefarious (though there is no evidence at the moment), it's possible they might even modify the recovery (i.e. TWRP) for persistence.

The proper way is to flash the full firmware image from google -- including bootloader, recovery, boot, system, vendor, and userdata (reflashing userdata will cause a "factory reset" of all your data/settings/apps/etc). This should be done all at once from the bootloader (e.g. using the flash-all.sh script provided in the system image) to get the device completely back to a known good state and avoid any persistence. If you want to absolutely sure everything is good, you could lock the bootloader again and check that there are no verification errors, then unlock again. Then you can flash the open source root package, TWRP, etc.

The former option seems easier, but to do a thorough job would actually be somewhat hard. The latter option is a lot more straightforward, but would also involve redownloading and reconfiguring all your apps; this would be my preference, though.
[Nexus 6  General] b8842dc0:
Ugh! Thanks for the nice reply. I think I'll hold off on supersu in the hopes that this project progresses nicely.

Thanks.
[Nexus 6  General] doitright:
Keep in mind that "pre-alpha" or whatever nomenclature is preferred for incomplete software, doesn't mean that it doesn't work. It just means that we haven't validated every aspect of it for security compliance, and/or there are certain features/characteristics that are, as of yet, unimplemented.

Fact is, that our code is more functional/reliable/secure than "that other", regardless of the different labels being applied. The difference is that WE TAKE YOUR SECURITY SERIOUSLY, rather than implement whatever compromise is the easiest to make things sort-of-work immediately.

The only place where ours has obvious rough edges is in the UI itself. Yep, ugly. UGLY UGLY UGLY UGLY UGLY!!!!!

But it does the job ;)

I could NEVER recommend that other binary root to anybody. It would be very very very irresponsible to do so.

My recommendation would be like so; our code is early, so if you don't need root yet, I'd recommend using *NO* root. If you can't wait for more stability, USE THIS NOW.

Well... lets say tomorrow. I am aware of a bug that breaks it if you have crypto enabled on your phone. I'm going to run some new builds tonight with the update to fix that (thanks craigacgomez!).

The reason I would recommend this over that binary root is very simple; we are transparent about what we are doing. Open source and transparent, even if incomplete and/or potentially buggy, is a safer bet than a black box, ESPECIALLY when it lacks audit by a responsible and trustworthy 3rd party. This is because whatever flaws they have, they are hiding from you.

BUT TO ACTUALLY ANSWER THE QUESTION:

All of the partition images for the various Nexus devices are available here: https://developers.google.com/android/nexus/images?hl=en

So if you want to return your system to factory, the easiest way is you extract the system.img from the archive, reboot to bootloader/fastboot mode, and run "fastboot flash system system.img".

Some people have other adjustments done to their system partition. If this is the case and they want to preserve those changes, then the steps can be somewhat more complicated. I really can't go into the details of the procedure they will have to follow, since it depends on the changes they've made, which is why I make a very general statement of putting it back to the way it should be with respect to root.
[Nexus 6  General] dahawthorne:
[MENTION=6124077]doitright[/MENTION].

Can I ask what may be another stupid question? If you continue to update your superuser.apk (and I hope you will), presumably upgrading to the new version is a simple case of installing the new apk over the old? And is it only the apk that you need to update, not the modified boot image?

I've been using your root for a couple of weeks and I've seen no problems. I don't even mind the unusual (but perfectly functional) UI - it's different, but not ugly... :)
[Nexus 6  General] doitright:
Most of the grit is in the boot.img (su binary + selinux policy + startup script). The Android application is just an interface to control the su processes. So... it means that for mostly *cosmetic* changes, you would see changes in the Android application, and for *functional* changes, you would see an updated boot.img.

But remember that the end goal here is to apply the changes to an already-built binary boot.img, rather than providing full boot.img built from source... so ultimately, you can probably expect some form of update.zip to update your boot.img. Or possibly some boot partition update that runs out of Android, which would make it possible to, at least update the boot image from the application. Installation of root from the application won't ever happen, since without root, you can't install root.

If anybody here feels like contributing but is unsure about hardcore security and C programming, the UI could use some love, and should be an easy way to get into the project.
[Nexus 6  General] NOSTALGIA:
any possibilities of a flashable zip ??
[Nexus 6  General] _that:
:rolleyes:
[Nexus 6  General] PWn3R:
LOL - coming soon to a "cmon man" segment on ESPN.
[Nexus 6  General] pnwsr6:
Does this work with 5.1.1? Has anyone tried it? If so what are your experiences? I haven't made the jump to 6 because of root and xposed, waiting for the bugs to be worked out. Definitely prefer an open source root option.

Also another question just to make sure I understand, the encryption that is discussed, is the one in settings under security, encryption that says encrypted by default, unless you modified your phone to not be encrypted?
[Nexus 6  General] Adreaver:
Nexus 6 (and I believe 5x and 6p) force encryption in the kernelboot.img, specifically the ramdisk. Custom kernelsramdisk (typically included in a kernel's flashable zip) can elect not to force encryption, however this does not decrypt the device - the only way to decrypt is to wipe everything and install a not-forced-encryption kernelramdisk. The issue is that typically the kernel includes (as its principle element, actually) the boot.img, which is what is modified by this project.

Your best (in relative terms) option would be to fork this mod AND your kernel, combine the su bits from this mod into your kernel, and build it from source. This is well outside the comfort level of the typical poweruser.

My suggestion would be to wait until this is a bit more mature and starts to be adopted by rom and kernel devs, then go through the process of backing up and wiping your data.
[Nexus 6  General] istperson:
So, just to clarify things, it's not the kernel and it's the other way round, the boot.img contains the kernel, and the ramdisk.

The ramdisk is a small disk image that fits info memory and during boot the kernel mounts it and reads the basic initialisation data from there. The ramdisk contains the fstab file which tells the kernel what partitions it should use and how to mount them.

Originally it tells the kernel to mount the data partition with forcing encryption, but it can be edited to change it to just encryptable. But true, this doesn't remove the encryption, only a format does.
[Nexus 6  General] Adreaver:
Thanks for the clarification. To think I've been so wrong all this time (and I've built from source!).

That said, does this boot.img include the stock ramdisk? How difficult would it be to disable forced encryption here, or not overwrite whatever ramdisk is already in place when flashing?
[Nexus 6  General] doitright:
Surely you must be reading the thread...? If not, please go back and read again.

As far as a "flashable zip" to install the boot.img, that would be absolutely pointless, since it is easier and faster and safer to fastboot flash it.
[Nexus 6  General] doitright:
I can guarantee that the sepolicy and other ramdisk modifications will NOT apply cleanly to 5.1.1.

If your reason for holding back were root and xposed... well, time to 6.0, because there are now both.

I don't work backwards. 6.0 is out, so 5.x is dead to me.

Referring to userdata partition crypto.
[Nexus 6  General] doitright:
You should read the su.patch file in my repo linked to in the first post. It shows you exactly ALL of the changes made by the patch. The ramdisk is *built from source*. The *entire* point of the patch is to generate a customized ramdisk.

Which yes, changes the forceencrypt to encryptable on the data partition, among other things.
[Nexus 6  General] b8842dc0:
Ok, thanks for the clarification.

Sounds good. I can wait.

Thanks.
[Nexus 6  General] doitright:
I just have one correction;

We do *absolutely nothing* to the kernel.

If you take a look at the build process I've outlined, we actually use the prebuilt google kernel rather than actually building it from source. Not that we are being prevented from building it from source, just that it is easier to use the google process for building the boot.img. Since we aren't actually changing anything in the kernel, there is nothing to be gained by rebuilding it.
[Nexus 6  General] brockyneo:
i flashed latest stock marshmallow rom then flashed TWRP and did all wipes ect transferred chroma via TWRP and flashed that which rooted the phone is this a safe and good way to do it as everything seems to be fine

thanks
[Nexus 6  General] istperson:
Of course, but it was a general question, and this applies to other roots.
[Nexus 6  General] doitright:
1) Other "roots" are off topic.

2) NO root mechanism requires kernel changes, even if some do it anyway. What they are doing is cheating their way out of selinux by forcibly setting it to permissive.
[Nexus 6  General] craigacgomez:
I've started working on a updating the Superuser app UI to Material Design (the current design looks horrible compared to MD apps). It's still in the early stages (but looks better already [emoji14]) and there's a lot more that can be done, but here's what my first stab looks like (first 1 hour of work). I will be pushing all my changes to my GitHub (https://github.com/craigacgomez/Widgets & https://github.com/craigacgomez/Superuser) and anyone is welcome to fork it, cherry-pick or send pull requests
[Nexus 6  General] doitright:
I wonder if it would make sense to create a github organization where we can all work on a common upstream...? [MENTION=1915408]phhusson[/MENTION] -- what do you think?
[Nexus 6  General] doitright:
Done.

https://github.com/seSuperuser is our new organization.

And we have also switched licensing to GPLv3.

Edit: Some of us are not *entirely* satisfied with the name of the organization. Github does allow us to change the name, so if anybody can come up with a better name.... your suggestions would be most appreciated.

Finally got around to updating the binary boot images for those having problems with crypto.
[Nexus 6  General] Jaspreet84:
I've been following this thread since some time, have gone through almost each and every part, some of the technical details are over my head, but helped me learn a lot! Thank you doitright and phhusson and all the others for this incredible effort!

Below are a couple of suggestions on the name of new supersu:

1. DoItRightSu

2. OpenSuperSu
[Nexus 6  General] craigacgomez:
Not really a fan of any name so close to SuperSU...
[Nexus 6  General] abuttino:
I know this might not be the place to ask this.. Is xposed going to work with this root method?

---------- Post added at 09:45 PM ---------- Previous post was at 09:43 PM ----------

How about seRoot
[Nexus 6  General] carmatana:
RigthRoot

UltraRoot

SuperAndroid

Rootplus
[Nexus 6  General] Jaspreet84:
SafeRoot

AdvancedRood

SmartRoot
[Nexus 6  General] androcraze:
OpenRoot or OpenSU
[Nexus 6  General] doitright:
Neither of which actually imply open source. The problem is that "Open" is massively overused and abused.

It also doesn't do much in the way of implying security.

Thanks for the suggestions though!
[Nexus 6  General] doitright:
I just *love* #1. Problem is that I don't think everybody else would be so enthusiastic about it ;)
[Nexus 6  General] nicholseric:
I couldn't agree with a more appropriate name than SESuperuser!
[Nexus 6  General] craigacgomez:
I feel that having the word "Superuser" in the name sort of carries on the tradition of open source superuser
[Nexus 6  General] doitright:
I don't see why it wouldn't.

Does xposed actually even *require* root? I mean obviously some modules would, but in general, it is a frameworks hack.

Superuser is a bit of a misname to begin with. "su" is actually for Substitute User. Although the default is to su-to-root, su can actually target *ANY* valid user. So in that regard, I wouldn't actually feel right about actually putting "root" in the name.
[Nexus 6  General] abuttino:
But it's not super, it's substitute.
[Nexus 6  General] doitright:
They all (except for "SuperAndroid") have "root" in the name... see my previous comment.

As for SuperAndroid... it really doesn't speak for its purpose.
[Nexus 6  General] androcraze:
SuperU
[Nexus 6  General] craigacgomez:
Technically, yes it is Substitute User, but by default the su command without an supplied user id defaults to user id 0... Which is Superuser! So it's also accurate to call su "super user"
[Nexus 6  General] abuttino:
I would like to put my vote in again..

seRoot
[Nexus 6  General] doitright:
It sure is. Problem with that is that "Substituteuser" doesn't flow... at all.

In any case, Superuser is a bit of a play off of the "s" and "u", as well as the relation to the "root" user, aka the superuser account. Which is pretty unfortunate, since that we are *starting* with a program that is essentially named "root", despite that actually being a subset of its capabilities.

I'm inclined to leave Superuser in the name, since it at least ties in with the Android application, and maintains a connection with the history behind it.

I.e., rather than saying that this project is something *entirely* different, it is preferable to say that this project is the evolution of what came before it.
[Nexus 6  General] craigacgomez:
I completely agree with this. Context and connection to previous iterations plays a big role. And technically, this is the evolution of Superuser! I'd rather we leave Superuser in the name.
[Nexus 6  General] Jaspreet84:
The first one is more attributed to the way root has been implemented this time [emoji6]
[Nexus 6  General] abuttino:
[MENTION=6124077]doitright[/MENTION] Is it kind of exciting to see this product going to a naming phase?
[Nexus 6  General] stangri:
Exactly what I was thinking. Probably OpenSU is better just because all of these Root-named scripts/Windows apps floating around.
[Nexus 6  General] _that:
I think this is actually the most boring part. In the Free Software world, I want to use something because it works well, not because of a fancy marketing name.
[Nexus 6  General] Philip:
How about

DIRoot

with the DIR standing for DoItRight?
[Nexus 6  General] b8842dc0:
Good point. How about LibreRoot? Less emphasis on the open, and more on the FOSS. Or how about GnuRoot? That would fit with the GPLv3 nature of the project. I also like the previously mentioned seSuperuser and seRoot.
[Nexus 6  General] phhusson:
I like the "libre" keyword, not so much "gnu" which refers too much to the organization.

I don't really like "root" for many reasons:

- it is not unlikely i'll do a version which gives apps capabilities rather than root

- "root" to me refers more to the method to bypass oem's protection than the software which handles SU

That would make LibreSU, but it doesn't sound too good
[Nexus 6  General] xrayA4T:
As an Ubuntu user I use sudo, so sudoRight or sudoAndroid
[Nexus 6  General] b8842dc0:
Have one more suggestion. How about defining/differentiating it in the case of the name and/or logo?

superuSEr (Superuser for SE enabled Android)
[Nexus 6  General] Anonamoose:
What about something simple like...

OPEN

since its open sourced and it allows you to do things to your phone you other wise could not. It's your choice mate and I appreciate all you've done. I'm just throwing out ideas...
[Nexus 6  General] haibane:
Surprised no one suggested Chainfree or Antifire yet...
[Nexus 6  General] nicholseric:
How about USES

It's a reversed mutually recursive acronym. It uses Security Enhanced Substitute User
[Nexus 6  General] doitright:
While cute, those would position us as "an alternative to...", which automatically undermines our objectives.

Ideally, we will become the "standard", and when "they" try to obtain users, those users will have to ask them "that's nice that you have your own su program, but what does it give me that I don't already have that justifies the trust I would have to place in you?"
[Nexus 6  General] haibane:
yeah sorry... I was not trying to make a real suggestion. I was just surprised no one had said it. What about AOA or Android Open Admin? It gets rid of the Root issue, but it does keep the Open. Maybe just Android Admin?
[Nexus 6  General] doitright:
You mean to be confused with https://play.google.com/store/apps/details?id=com.google.android.apps.enterprise.cpanel&hl=en ?
[Nexus 6  General] stevetrooper:
Thanks for all of your work on this. I do have one question, I am encrypted and don't want to turn it off. Will superuser will work just fine or do I need to decrypt first?
[Nexus 6  General] haibane:
Hmm should have thought about that. What about Absolute Authority... I'd call it Android Authority, but you know that's another site.
[Nexus 6  General] haibane:
Has anyone figured out a way to easily move from Chainfire's SuperSU to this? I know I can simply do a clean install of everything and go from there, but I really don't feel like setting up my Daily Driver from scratch again. I think if I did a Nandroid Backup, that would carry the different remnants from SuperSU right? Just a thought. I would like to try this out, but I keep adding stuff I like to my Android.
[Nexus 6  General] nicholseric:
Use the supersu app to remove its su, there are two options in there. After reboot, ununstall supersu app. Then use phhussons superuser.zip, flash it in recovery. Then install phh superuser from play store.

Backup your existing boot partition first.
[Nexus 6  General] haibane:
Well that brings up another question. My existing boot.img is from Franco's Kernel. Will this work with that Boot.img? Should I flash the one shown on post 2?
[Nexus 6  General] nicholseric:
I would try the one here http://xdaforums.com/showpost.php?p=63289209&postcount=1 and post in that forum if it works.
[Nexus 6  General] baddison:
How about something like "SubAdmin" or "SUAdministrator" ? It definitely implies the administrative rights you need to perform certiain duties?? :) :)
[Nexus 6  General] helloworld1:
It works great with device encrypted. I have my phone encrypted and tried TitaniumBackup and works great.
[Nexus 6  General] westhaking:
In titanium backup I was unable to get auto restore functionality with the Auto, Direct or the Auto, Indirect app processing modes selected. It did work by selecting the Interactive App process mode which was less than ideal. This is usually circumvented by being able to unselect the 'mount namespace separation' option in the supersu app. I did not see an equivalent option in this superuser app. Also putting in a suggestion for SudoSu as a name for the app :)
[Nexus 6  General] Adreaver:
Has anyone spoken to Koush?

Why not just use the Superuser name - he released as open source way back when, and this is simply an extension of that same project.
[Nexus 6  General] solara1973:
1. "Superuser Prime - the next evolution". (Logo of Android Robot tricked out to look like a Transformer - like that :) : http://www.tmiasuperhero.com/3846

2. "Superuser Revealed - naked to the core". (Logo of Android Robot completely transparent showing it's internal gears, etc)

3. "Naked Root" (same Logo as above, will gets lots of hits with Naked in title :)) Naked of course referring to it's completely open/transparent nature.
[Nexus 6  General] NOSTALGIA:
how about just rootdoneright ? for me it sounds better
[Nexus 6  General] scryan:
I think he was already trying to point out that while he has done a lot to bring the effort forward.... He is basing it on someone else's code, and has significant contributions from others... Would be a bit ****ed up to name it after just him.