yashsingh1/xdaforums huggingface dataset:
[SuperSU] ExceterM:
Is this su adb shell command done in normal state or via recovery shell?

Also, did your fresh install involve a flashall or did you just adb flash the imgs minus the userdata?
[SuperSU] osm0sis:
If he's got busybox installed to /su/bin, that'll still break system remount. Stericson still hasn't updated his installer with the proper /su/xbin despite me firing off an email at him making him aware /su/bin is equivalent to installing over /system/bin in terms of breakage..
[SuperSU] skulldreamz:
If a rom has root through system, is there a difference in a su adb shell in booted Android vs. recovery shell?
[SuperSU] _that:
Recovery is a separate operating system, so its root is totally independent from the one in Android.
[SuperSU] skulldreamz:
Yeah i get all that, i should have asked when would one benefit from using a adb shell in recovery vs booted droid because recovery mirrors the booted Android system if that makes sense, thanks my dude
[SuperSU] egingell:
It does not mirror the booted Android system. Literally nothing "Android" is running. Only Linux and the recovery front-end, which, much like Red Hat or Ubuntu... or even Android, is just a shell. Using recovery allows you to modify, add, or delete files from the system, repartition drives, and flash disk images, modems, kernels, etc. without having Android processes interfere.

You try to flash a disk image while the phone is booted up and Android will trigger a panic reboot and the flash will fail catastrophically and possibly hard-brick your phone.

Sent from: SGS4 - JB 4.2.2 MF9
[SuperSU] skulldreamz:
I was reading chainfires and osmosis post above mine and i thought about why you can delete certain files in recovery but the same file will fail in android. I dd recovery and boot images all the time in booted android and never had a problem. But i see where your getting at with no "Android" processes running and that I'm sure is why i can delete a file in recovery but sometimes fails in booted Android. Thanks
[SuperSU] egingell:
Depends on the image. A boot image isn't going to trigger a panic because the phone's already booted.

Sent from: SGS4 - JB 4.2.2 MF9
[SuperSU] firefoxjds:
Question about Modified Boot Image

I am wondering about what exactly the modified boot image does? I found instructions to install system-less root without the modified boot image. I had to do this because I cant find a modified boot image for (Osprey) Moto G 2015 3rd generation. The system-less root works for the most part but sometimes when a program tries to access root it finds the root unstable, and then super su says that the binaries aren’t installed again and I have to flash it again and again which works but it is a little bit buggy. I am wondering as to a fix or if a modified boot image would help to make the root more stable. It would be really helful if someone could construct a modified boot image for (Osprey) Moto G 2015 3rd generation. My abilities are not yet up to par with building it my self or I would. I would love to , I just don't understand the instructions. Thank you to anyone who can help with this.

---------- Post added at 07:03 PM ---------- Previous post was at 06:59 PM ----------

Some (well one so far) Programs don't recognize the device as being rooted even after being granted SU access. I assume the are looking for the sytem root somehow idk.
[SuperSU] firefoxjds:
Might Have Found Something to Help

Apparently Super Su Patches the boot image so Ive answered my own question. ReInstalled Busy Box from su/xbin to system/xbin hoping this helps.

---------- Post added at 10:29 PM ---------- Previous post was at 10:26 PM ----------

Might Have Found Something to Help

Apparently Super Su Patches the boot image so Ive answered my own question. ReInstalled Busy Box from su/xbin to system/xbin hoping this helps.
[SuperSU] NYLimited:
Yes you can.
[SuperSU] 2x4:
Thanks for the quick response, just wanted to confirm that I wasn't going to break anything.

I flashed it and it installed itself as system less again, and then I reflashed my kernel after booting up and noticing that it was gone. No issues after that.

Thanks again!
[SuperSU] :
What is SElinux policy enforced? Should I enforce it if I want Xposed modules and root apps to work better?
[SuperSU] :
Just got a new 6p today and unlocked it, rooted it with 2.67, deleted xbind dir and AP works just fine but I cannot find a clear answer for this:

* Will creating or restoring nandroid backups cause AP to stop working? I am seeing some vague information about restoring a nandroid modifying /system and thus will cause safetynet to trigger but the information my searches come up with is really unclear.

Can anyone shed light on this

TIA
[SuperSU] nathanchance:
SELinux is a bunch of rules to keep applications from accessing parts of your storage. Leave it enforcing if you have the option but some apps require permissive to function.

There is a thread here for AP and SuperSU questions just for the future. I'll answer it here and mention me in that thread if you want to reply. Restoring from an nandroid shouldn't cause AP to stop working as long as system wasn't modified when you backed up.
[SuperSU] :
Thanks Nathan ???? I'm guessing when I flash 2.67, it will be enforced by default. If I run into compatibility problems, can I set it to permissive? I hear lmt launcher has enforced issues so I might have to set permissive later.
[SuperSU] nathanchance:
SuperSU doesn't change your SELinux status but you can use an app like SELinuxModeChanger to do that.
[SuperSU] Chainfire:
I am afraid it isn't that simple.

There are two types of backups: file-based backups, and raw backups. The latter backup the raw partition, instead of dealing with its contents (individual files).

I think TWRP these days offers to make raw-style backups of /system if it detects you have not modified /system in any way. Either way, if you restore a file-based backup to /system, on various devices this breaks OTA capabilities, and kills 'dm-verity' verification.

As far as I know, SafetyNet doesn't check for this at the moment, but it certainly isn't inconceivable that they will in the future.

I would strongly recommend only using raw backups of your /system partition to prevent both OTA and AP issues in the future.
[SuperSU] robgee789:
hey guys im getting a nvidia shield k1 which will be on marshmallow, does the systemless root method work on that tablet?
[SuperSU] kolyan:
Question....it if safe to update from already installed systemless superuser 2.61 to the current one 2.67 just by flashing it in recovery?
[SuperSU] shoey63:
Not all TWRP recoverys offer raw backup of /system unless extra lines have been added to the ≤device≥.fstab and twrp.fstab declaring /system as emmc when building.

If there is no option to backup System Image, the alternative is to backup the raw system image in adb shell (or TWRP terminal) in recovery using dd command.

Eg. (depending on device)

dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/system.img

Then to restore

dd if=/sdcard/system.img of=/dev/block/platform/msm_sdcc.1/by-name/system
[SuperSU] :
OK, so I think I got it, after reading this and CF's post if I want to keep /system nice and clean but still be able to make/restore backups I would uncheck the "system" option and check the "System Image" option in the TWRP backup settings screen.

NOTE: I am using a nexus 6P with TWRP 2.8.7.2 and did not have do make any modifications or add any extra lines in order to see the System Image option

thanks!
[SuperSU] bunklung:
I have a N6 and have been using systemless root without issue. I too am generally only interested in limited SU. The most important is editing my build.prop for tethering. This is how I edit build.prop. Maybe this will help you:

Flash stock via fastboot

Flash customer recovery 2.8.7.1 Shamu TWRP

Boot directly into TWRP recovery while phone is plugged into computer

optional: adb shell then send these commands in the terminal window:

optional: echo SYSTEMLESS=true>>/data/.supersu (I *think* this is a moot point)

optional: echo BINDSYSTEMXBIN=false>>/data/.supersu (saves a few steps later. Read up on this option if you intend NOT to use it. This can break some lazy SU apps)

optional: exit adb shell

Flash systemless root while still in TWRP

Mount /system via the TWRP touch menu!

adb shell this below command from a ADB terminal session:

echo net.tethering.noprovisioning=true>>/system/build.prop

exit adb shell

unmouth system via TWRP touch menu.

optional: reboot to fastboot/bootloader (be sure to NOT flash root if TWRP prompts you) OR just restart to Android if you don't need to do the below to steps

flash stock recovery via fastboot

optional: fastboot erase cache (If you are upgrading your OS from an older OS)

Good Luck.
[SuperSU] wahyunopalisandi:
Bahasa jawa gx ada...
[SuperSU] ExceterM:
Holy crap. That's EXACTLY what I've been looking to do but had no idea how to do it. You're essentially modifying the build.prop using adb from the recovery shell via an echo command with /system mounted rw in custom recovery, right? Would this work just as well using Wugfresh's NRT to boot temp custom recovery? I dunno why, but I've never really bothered to install custom recovery permanently. Always did it through the Root Toolkit.

Thanks
[SuperSU] bunklung:
You can no longer BOOT a custom recovery in Fastboot/Nexus. It must be flashed. If Wufresh NRT is doing this, it's slight of hand basically.

*update this was reverted at some point "fastboot boot recoveryxxxx" works again*

I suspect Wufresh is flashing customer recorvery, then flashing stock back. You can do this all via fastboot manually.

Yes, to your first statement. You are basically appending 1 line to build.prop in TWRP via ADB terminal session. TWRP is handling the mounting and unmounting of /system and is elevated by default.

Most/some people who modify /system in the systemless world have had to make space on /system (deleting some ununsed system apps). I think since you are amending 1 single line in build.prop it works without significantly having to resize /system.

Please report back.
[SuperSU] corkiejp:
I was wondering the same thing, why flash TWRP and flash stock recovery at the end of the steps?

You can temporarily boot TWRP with "fastboot boot <twrp.img>" or use NRT to do it.

I just successfully booted TWRP from fastboot on a Nexus 9, maybe the newer nexus you can't?
[SuperSU] Ingenium13:
You can also create a su.d script to do this. The advantage is that you don't need to edit /system, and it persists across OTAs and flashing new system images with fastboot. I describe how to do it here: http://xdaforums.com/showpost.php?p=64733104&postcount=117

If you have a Nexus why bother making a backup of stock /system? You can download any version you want from Google and flash just /system with fastboot.
[SuperSU] Ch3vr0n:
My nexus 5 fastboot boot's into one just fine.

Verstuurd vanaf mijn Nexus 7 met Tapatalk
[SuperSU] SamuriHL:
Yea, my Nexus 6 boots TWRP no problem without flashing. I never flash TWRP. I always just boot to fastboot and then fastboot boot twrpxyz.img. No problems doing that.
[SuperSU] syintiphic:
I think you need to use the UnSu script by [MENTION=4544860]osm0sis[/MENTION] to switch. Meaning uninstall SuperSU 2.61 using the script and then install SuperSU 2.67.

Check out the linked post to get more details.

http://xdaforums.com/showthread.php?p=63615067
[SuperSU] nathanchance:
That script only works for SuperSU 2.52. You don't actually need to remove 2.61, you can just flash 2.67 over and it should be okay.
[SuperSU] ExceterM:
Executed the echo command.

Steps for posterity: adb fastboot erased boot, cache, recovery, and system, then fastboot flashed the respective .imgs from the system image. Rebooted then used Wugfresh NRT to boot to temp custom recovery, flashed 2.67 root, bypassed the optional commands echo commands and went straight to TWRP /system mount, used adb shell to do echo on build.prop, unmounted /system, did a cache/dalvik wipe and rebooted.

Worked as smooth as butter. A million thanks.

Wugfresh NRT works nicely if temp booting into custom recovery (TWRP). Pretty sure you're right with the slight of hand and it's probably just automating the temp flash then stock reflash. The NRT just does it with one button. lol

FOR SCIENCE, I reflashed stock to test the su script. Did exactly as follows:

Flashed stock through ADB (excluding userdata.img). Rebooted, used NRT to temp boot to TWRP, flashed root 2.67, wiped cache/dalvik, then rebooted to system. Opened adb shell command and executed lines EXACTLY:

su

settings put global tether_dun_required 0

echo "setprop net.tethering.noprovisioning 1;" > /su/su.d/0000tether.script

chmod 700 /su/su.d/0000tether.script

Checked build.prop for noprovisioning line, but it is not present. Tether works regardless. So I'm not fully comprehending what the script is doing, however I can say for sure it works like a charm! Thank you!!

Reader's Digest version: Both the su script and adb recovery shell methods work perfectly in bypassing 2.67's /system rw mounting problem (if anyone is having the problem like I was).

Oh, and Chainfire... I just tried running the mount -o rw,remount /system in an su adb shell with 2.67. Didn't work. I tried using Root Browser to modify the build.prop. It caused the issue of a write protect violation and turned my build.prop to 0.00kb. I did a stock flash (minus userdata) to restore stock build.prop, flashed 2.67, and executed the "settings put global tether_dun_required 0" followed by "chmod 700 /su/su.d/0000tether.script" command in su adb shell to test OTA/Stock flash survival. Again... worked like a charm. Thanks everyone for all the help. I've compiled all methods into a go-to document for future use!
[SuperSU] syintiphic:
Thanks Nathan! I appreciate the clarification. I wasn't sure if it applied to earlier versions of systemless SuperSU.
[SuperSU] Ingenium13:
It doesn't actually modify build.prop. It basically overrides what's in build.prop by changing the setting during boot.
[SuperSU] ExceterM:
Ah! Got it. Thanks for the explanation. Trying to actually LEARN the backend of Android instead of just memorizing the commands and procedures.
[SuperSU] :
good point I don't know why that never crossed my mind, that saves about 3GB of space in the backup too :good:
[SuperSU] bunklung:
They must have reverted this at some point. I justed tested this out on my N6 and it worked. Thanks for this correction.
[SuperSU] Icetea:
SuperSu 2.67

i use it to root a HUAWEI HONOR 7 - Android 5.0.2 - EMUI 3.x - with TWRPPRK. Everything is alright! I have changed from v.2.66 to 2.67 without any trouble! THX to [MENTION=631273]Chainfire[/MENTION] for doing a good job!
[SuperSU] angeloshiro:
this works to root a moto E on Android 6.0?
[SuperSU] CyDroid43:
Fully working on lollipop, that is recommended for lollipop os and up

:)
[SuperSU] Khaon:
[MENTION=631273]Chainfire[/MENTION]

I am using marshmallow master branch

Latest version working for me was 2.52. I patched the ramdisk accordingly you said to make supersu works.

However, since your package, now, handles itself editing the ramdisk. Flashing 2.6x++ results in a fail.

I reverted my changes ofc before flashing.

I don't know where is the fail as you use some binaries to patch the boot image , drm, etc.
[SuperSU] nixie2121:
searching on my phone is tough, I apologize in advance for this question... I'm going to flash a new rom, what step do a take to flash su as systemless? if I read right, it will default to normal and I want systemless. thanks so much
[SuperSU] nathanchance:
These:

1. Flash your ROM + GApps.

2. Flash UnSU if your ROM is prerooted with SuperSU 2.52.

3. Go into Advanced > Terminal Command.

4. Select current folder via button in right hand corner and type the two lines below, one at a time:

echo SYSTEMLESS=true>>/data/.supersu
echo BINDSYSTEMXBIN=false>>/data/.supersu

The first line forces systemless root and the second line removes /su/xbin_bind (only type the second line if you care about Android Pay, just do the first one if not).

5.. Flash SuperSU 2.67.
[SuperSU] Khaon:
you just need some Marshmallow.

From what I heard, you dont need to patch supersu however with cm-13.0 based rom(i am not sure about that tho)
[SuperSU] luigidk:
- delete -, moved
[SuperSU] luigidk:
Apologies to all - thought I was being careful :(

Deleted from this and posted in the appropriate thread.
[SuperSU] garyd9:
Bug (?) with 2.67:

Installed on a samsung galaxy note 5 in systemless, with the binding turned off. If I go into the supersu app and disable supersu, it works. But when I go back into the app, it claims it wants to update 'su'. I ignore that and select the option to re-enable supersu. The app claims that re-enabling fails (but /su/bin/su is restored.) Until I reboot, SuperSU continues to complain that it needs to update 'su' (but any attempts to allow it will fail.)

Correction: SuperSU still complains that the 'su' binary needs to be updated even after a reboot.

[MENTION=631273]Chainfire[/MENTION], if you're unable to repeat this, let me know and I'll collect logs, etc.

The ability to disable and re-enable supersu while in systemless is important now that "the topic of another thread" now detects su installs in /su/bin.

Take care

Gary

Edit: More info: The only way I could find to get supersu to stop complaining about an "outdated su binary" (which it wasn't able to update) was to boot to TWRP and reinstall supersu from there.
[SuperSU] luigidk:
Note: just hearing that SafetyNet is now detecting systemless root - so systemless root is causing AP to fail now...
[SuperSU] ben_pyett:
Can you'll please back up "just hearing" with url or quote of source.

Not that I don't believe you but, on what evidence...
[SuperSU] :
yep, its been disabled for everyone with root. was working yesterday but not today so they did something sneaky behind the scenes... *uninstall* :( was only a matter of time i guess

EDIT: disabling root in the supersu app seems to work, please note I cannot test a transaction right now but at least it lets me add a card after disabling root. if anyone tests buying something please share results :good:

EDIT2: I guess you cant just disable and re-enable root from the supersu app when you are systemless? have to re-flash the zip? ugh
[SuperSU] garyd9:
Please pardon my introduction using an off-topic example... (jump to the "---" below to get past my rambling and move directly to my suggestion which is the point of the post.)

It's obviously coming that Google CTS checks and 'su' (in any form) are soon going to be engaged in a cat and mouse game... We move to systemless root, and now CTS checks are checking for that. I'm not sure if the game is even worth playing. (I'm also wondering why google is specifically checking for the existence of "su" instead of supersu.apk or superuser.apk when they must be very well aware that supersu can easily hide that "su" executable but leaves the apk in place.)

I have to ask myself why I root my phone - what exactly I use "root" for. In my case, I use it for making some minor changes at the /data level level such as disabling bloatware and minor changes at the /system level such as tweaking samsung CSC's. I really don't need to KEEP root installed for these things once the changes are made.

I also use root for better battery stats, but once I get my device set the way I want, I'd be happy just being able to check the deep sleep timer, without needing the detail all the time.

I use root for a couple of "setprop" calls on boot, but I could move those items to run in some form of init.d... (more on this later...)

Finally, I use root in a tasker plugin called "secure settings", but I don't think supersu has to be always enabled for secure settings to function.

---

What I'm getting at here is that I, and perhaps many other people, don't need "root" to always be available. In fact, if su.d functionality was there (for my bootup scripts), AND if superSU could somehow be configured to re-enable itself on bootup, I could probably disable supersu after each time my phone boots and everything I need would still work.

Of course, I'd like the ability to re-enable it on demand... just in case I want to edit one of those boot up scripts or run a titanium backup (or restore.)

Would it be possible to do something like that with a future SuperSU? First, that supersu would detect if it's disabled on startup and re-enable itself. Second, that either an external program could use an intent to disable supersu, OR that supersu could be configured to disable itself after some timeframe.
[SuperSU] NYLimited:
Some have a more defined set of requirements. My firewall (AFWall+) would not work without it. My hosts file would not get updated (I don't like ads). Titanium Backup and Root Explorer both use root regularly. There are others (xposed requires root and even if I'm not using it many are) which are to me less important.
[SuperSU] NLBeev:
Many users are rooting to customize the phone.

When using layers for an other theme than the default Google's white, permanent root access is needed.
[SuperSU] garyd9:
Certainly, my idea wouldn't work for everyone, but I'm trying to find a half-way point where at least some aspects of root functionality can still function without breaking google's security checks. That will involve a user having to make decisions. At some point, likely, all root functionality will have to be forfeited in order to have full google functionality.

I just hope that google never goes to the extreme that samsung has on their newer phones (with their "knox" fuse and it disabling samsung pay permanently. Imagine if "fastboot oem unlock" on a nexus device completely and permanently disabled aspects of the android system...)
[SuperSU] yekollu:
How do i root the phone? I have unlocked the bootloader and replaced it with CWM and have CM 13 running now. If i try to install a app that requires root, it shows an error and so do most root checkers.

Have i missed something?
[SuperSU] garyd9:
Yes.
[SuperSU] NYLimited:
I understand where you're coming from. I was only presenting another view. I don't know what might be involved in making such a switch - that is a Chainfire decision, of course.
[SuperSU] bobby janow:
Waiting for systemless root 2.0. If anyone can do it he can. If not then either avoid AP or don't root if you want it. No brainer for me. Credit cards back in the wallet.
[SuperSU] nathanchance:
He has said multiple times before he isn't trying to circumvent SafetyNet so I highly doubt he isn't going to change his methods (especially since what he is doing works well).
[SuperSU] bunklung:
When you unroot temporarily from the supersu.apk where does the su binary go?

Also, when I temporarily unroot, it seems that su.d scripts still execute. Does that seem like it's working as intended?
[SuperSU] garyd9:
"su" is just a vector for user run programs to gain access to root. Nothing more. As for where the su binary is, I know of a couple places that copies of it are left around, and it might also be embedded in the apk. (I never checked.)

I'll give a hint: If you delete ./bin/su, something must be running as root in order to put it back. That "something" would not only need normal linux "root" access, but also permissions to do it's job in seandroid.
[SuperSU] bobby janow:
Edit: before this gets moved I just found the SafetyNet thread by Chainfire. I'll move this post there.
[SuperSU] yekollu:
Could you enlighten me please.
[SuperSU] NLBeev:
.

What I am seeing here on XDA is rooting together with customizing.

Samsung/Google/Apple wants to earn money with their paying apps. Big/rich companies wants us to be stupid users that does not root and will accept their ugly white themes and bloatware.

When I cannot change the ugly white Google themes and the pesky search bar I will not buy a Nexus. And also no phone with an amoled display.

Maybe the 'customizers' are the minority. But as long as we have XDA rooting will be there. And XDA is still a growing community.

Freedom is not something you can get or buy. You need to struggle, learn, root, work, be smart, support dev's etc. and for it.