yashsingh1/xdaforums huggingface dataset:
[SuperSU] kostur:
Please, can anybody check version showed inside SuperSU app in Settings? I installed SuperSU v2.56, but app still show me version 2.46. Systemless root on my device is fully functional, so I assume that version on Settings form wasn't updated to correct number only...
[SuperSU] ashyx:
It's 2.56, you probably let twrp root overwriting systemless root. If twrp doesn't offer to root when rebooting then that's probably your answer.
[SuperSU] GROGG88:
4.4.4 - 5.x.x. Guys, just refer to the WIP thread where it has already been spelled out by [MENTION=631273]Chainfire[/MENTION].
[SuperSU] kostur:
Thank you for your answer, but problem was somewhere else. I used SuperSU v2.46 app on my previous rooted Android 5. When I received OTA update to Android 6, I first manually uninstall root from phone and then successfully updated. But old SuperSU app still remains installed in system and when I installed new systemless root, SuperSU v2.56 app was'nt automatically updated. So I must updated it manually now.
[SuperSU] EvanVanVan:
At this point, should I be using the original root method or the systemless root method?

Thanks
[SuperSU] shoey63:
Has anyone else had the issue whereby after installing systemless root on MM, and subsequently restoring stock kernel and recovery, the "your device is corrupted and may not work properly " message appears on reboot?
[SuperSU] Wyneg:
Hi!

It's normal, see this.

;)
[SuperSU] shoey63:
Thanks, but it shouldn't be normal if you have untouched system, boot and recovery. I'm thinking the systemless root method is still "touching" /system somehow.

Edit: or something to do with twrp. Need to do some experiments to find out whats going on...
[SuperSU] bubbeld:
i'm using a CM13 alpha version and trying to get the systemless root on my phone any advice or help its a Xperia sp we are talking about ;)
[SuperSU] Joey2o11:
The latest security policy update on my galaxy note 4 910f has put my phone into a boot loop, i been using SuperSU 2.52 successfully for months before this. I was using the enforced kernel. Wiping cache and clearing data from security policy app in application manager doesn't resolve the issue. Reverting to stock COI3 kernel fixes the boot loop but at the cost of root...... I know of 1 other user with the same problem. Has anyone in this thread experienced the same issue?
[SuperSU] sefrcoko:
Yes same here...latest security policy update seems to have killed root (supersu 2.52) and cause bootloops on my N910W8 running Samsung 5.1.1 with modded stock enforcing kernel. Anyone have further details or a possible workaround?
[SuperSU] osm0sis:
As soon as a flashable zip mounts system in TWRP, even if it doesn't modify it, I've noticed TWRP can get confused and do it's thing with recovery-from-boot.p -> .bak and only fastboot flashing system.img gets it behaving and respecting the "mount only as ro" option again. :eek:
[SuperSU] gmillz:
I'm trying to get root on moto x pure marshmallow update. But when I boot the modified boot.img I have no baseband and no WiFi. Like the modem isn't being mounted or something. Any ideas?
[SuperSU] ashyx:
Is it the original sepolicy for your device?
[SuperSU] gmillz:
Yes. Even without modifying anything. Just repacking I have no modem
[SuperSU] binula jayasinghe:
I rooted my phone and again I unrooted my phone to update phone but I can't update the phone (the operation system on your phone modified in unauthorized way try kies....)
[SuperSU] Phil3759:
Try to update to COJ3

Maybe they modified some of the policy through knox... No issues on COJ3
[SuperSU] backslashV:
is there any point in using the system-less method if I want to flash xposed afterwards? xposed modifies the system partition, right?
[SuperSU] skulldreamz:
Yes it modifies system
[SuperSU] Joey2o11:
I'll give it a go, i really want root back :)
[SuperSU] backslashV:
Now we should wait for a system less xposed...
[SuperSU] ashyx:
Which is gonna be pretty difficult considering it has to replace some core system files to work, not without more ramdisk mods anyway , but never say never on xda.
[SuperSU] Joey2o11:
Updated to COJ3 and rooted successfully :)
[SuperSU] Alxoom33:
I did. Then flashed Xposed and got the Google's message.

Bottom line, Xposed poses a real security risk. I have decided that I am better off without it.
[SuperSU] unit_vector:
I am having the exact same problem on my Galaxy S5 (G900W8) with 5.1.1 (COI4), but I do not have a newer firmware to flash to try to fix it. Is there a way to undo security policy updates or otherwise allow flashing SuperSU 2.52 without causing bootloops?
[SuperSU] Joey2o11:
The newer firmware resolved things for me, maybe a factory reset? Drastic i know, but it might work, though if your anything like me that would be a last resort option......
[SuperSU] unit_vector:
A factory reset did work actually, the first time I encountered it :). But that was before I figured out what the problem was (and clicked "Update Security Policy" for the second time like a doofus), and now that I've gone through the process of setting everything else up from scratch again, and narrowed it down this far, I was hoping there was a less painful way.
[SuperSU] Phil3759:
could be related to knox. Having it disabled, i am no longer prompted with security updates

However, I will try to dig and reproduce it when I have time. At least to be sure if Samsung decided that SuperSU beta way is a security hole. What a shame it would be since the current root needs a custom kernel anyway...

Hope we're not done soon with only one option: compile the kernel
[SuperSU] backslashV:
how can I root the old fashion way after doing it this way?
[SuperSU] shoey63:
Reflash the modified boot.img, then flash 252 beta for regular root.
[SuperSU] aderuhya:
I cant get my nexus 5 rooted. i already try flashing modified boot.img then SuperSU 2.52. I'm using cleancore rom MRA58K. Can anyone help give me a good way to get root?

Thanks in advance
[SuperSU] cstratz:
The same with Note 10.1 2014 (P605): suddenly without root - and then bootloops! - Have restored backup with TWRP, from 29.10.2015 and, because my WLAN SSIDs have changed, and mobile data was off during backup, it boots with no problems after restoration. - But as soon as I activate a WLAN connection (after some seconds) SuperSU reports missing Superuser file, and somewhere in the taskbar is a message: "Sending report...". - Nothing helps: as soon as I reboot, I am in a loop.

I then have installed stock, have reflashed the kernel and flashed SuperSU with TWRP: still bootloop!... Also I have restored again, have completely uninstalled all Knox apps (with Titanium) and then all root apps, before going online again: some seconds after: = SuperSU file missing, no root, reboot = bootloop!... Seems Samsung has killed all permissive kernels, because enforced ones still seem to work with SuperSU v2.52 Beta. (Like the one on my Note 4.)
[SuperSU] cocchiararo:
Just got my new nexus 6p (coming from a nexus 5).

I downloaded the latest factory image, which is mdb08m.

Can we use the current kernels for rooting, or should we wait for chainfire to release mdb08m?
[SuperSU] jcsww:
I am on 8M and am rooted with the 8K kernel.
[SuperSU] lePoMo:
systemless:Idea for preventing system from getting touched

[MENTION=631273]Chainfire[/MENTION] and [MENTION=4544860]osm0sis[/MENTION] (and anyone else knowledgable and interested in systemless root)

Goal: prevent classic root apps from touching /system (without the user wanting it)

Idea (tl;dr): intercept calls to mount and let the user confirm/deny

How (idea):

/system/bin/mount is a symlink to /system/bin/toolbox

One could:

1. create such a symlink sonehwere in /su (in a folder that's not covered by path)

2. create a script that does the user asking (like supersu app, or part of it), and on user confirmation, calls our symlink in /su (from point 1)

3. map that script to /system/bin/mount using bind

Thoughts and discussion:

Points 1 and 2 seem simple and likely to work (though not tested, hoping toolkit only checks its name and not its path when called as 'mount'), but no clue on how to do point 2.

Also, is there a clear point when to do such a bind? (at what point in the boot process). If not, the script needs to find out in what stage of the boot process it is, so as to not block mounts done by the system at a time when no UI is possible.

Alternate approach if point 2 is too difficult: replace mount with a script that ignores all calls to mount. (though this then needs even more certainty about at what point in the bootprocess this is safe)

And to make it clear, this is just an idea. Ideas are cheap, dismiss them at will. This is not meant as security, just to catch a few apps that have no concept of systemless root and would otherwise mount system mountable because that's the only way they know to achieve what they need, even though that may no longer apply to systemless root (like some mentioned some version of Busybox).

Feel free to run with this. Also opinions are welcome. Also this is not meant to hijack this thread ;)
[SuperSU] BeansTown106:
[MENTION=631273]Chainfire[/MENTION] was finally able to get supersu running on selinux enforcing for aosp roms. commit is here https://github.com/PureNexus/androi...mmit/d502eb337d26692f33b7fd0f0f168081e89375bf
[SuperSU] osm0sis:
That's a neat idea! My main thought is that toolbox wouldn't necessarily be the only thing receiving mount commands since there could be busybox mount in /su/bin /system/xbin for path or really anywhere it could be executed as root like /data/local or app dirs as well, so that probably wouldn't be the way to lock down that command. Something to catch it via selinux would make more sense to catch it globally. Then there could be a toggle in SuperSU to enable system writes at all, and the option to allow with a PIN. :cowboy:

[MENTION=631273]Chainfire[/MENTION]
[SuperSU] lePoMo:
Ah, I didn't think about that.

In a sense though, that's also opening a new option.

Under the assumption that:

* with that information, app developpers are more likely to call mount by relying on path, and less likely to hardcode the absolute path to mount (because like you said it could reside at lots of places)

* we're already happy catching regular root apps (as in "easily bypassable")

* we're happy with a manual on/off toggle (vs. asking the user what to do on each mount call)

Then just putting a script called "mount" in /su/bin (first entry in path) already covers it mostly, and doing the toggling by renaming. (plus renaming any existing mount file in that folder, and renaming it back when toggling)

Admittedly that's now less water tight than my original thought. Yet it's also easier (can be done by hand), and certainly better than nothing ;)

Caveats:

* while i hope and believe that no app developper would hardlink to one of the many places a busybox mount could reside in, I could see apps hardcode to /system/bin/mount (seeing as that's the default.. unless that varys by device). so possibly still bind mount that one

* apps messing with the path could be a problem

* not sure how busybox behaves when installing it to /su/bin when there's already a fipe called mount

Nice. If achievable, that would be a way better solution (less chance of breaking).

The thought of selinux crossed my mind too, but in a wrong way so I quickly dismissed it.

(the thought was blocking calling mount, but then you wouldn't be able to call mount for binding either. whereas with a script that can always be called, it can just let through calls to mount with a bind param)

my selinux is rusty (to nonexistent), I guess the label would have to be attached to the raw blockdevice.
[SuperSU] EvanVanVan:
Any suggestions?
[SuperSU] Alxoom33:
Anyone have access to am MR858R Systemless boot.image for Shamu? I cold only find the K version posted by [MENTION=631273]Chainfire[/MENTION]
[SuperSU] vt0r:
Please use the search next time. It was posted once and then reposted by me a few pages back. Here is the link again: https://www.androidfilehost.com/?fid=24269982086994468
[SuperSU] aderuhya:
I've tried systemless method for N5 MRA58K but didn't work. Still didn't get root. My procedure when doing it :

- Flash rom (Cleancore MRA58K)

- Flash boot.img for N5 MRA58K

- Flash SuperSU v2.56

- Wipe dalvik & cache

Is there anything wrong from what i'm doing? Do i need to Full wipe before flashing the rom? I did dirty flash.

Please someone gimme enlightment to this, i really want my root back.

Thanks in advance
[SuperSU] osm0sis:
Here's another nice forum trick:

http://xdaforums.com/misc.php?do=showattachments&t=2868133
[SuperSU] TJKV:
Dayum that's useful. Where in a thread would a link for that be? I don't want to have to remember the syntax :P
[SuperSU] efrant:
In the forum, where you see a list of all the threads, click on the paperclip icon beside the thread name and it will pull up the list of all the attachments.
[SuperSU] chenxiaolong:
[MENTION=631273]Chainfire[/MENTION]: Is there currently a way to prevent TouchWiz's init from loading /data/security/spota/sepolicy? I'm on TouchWiz 5.1 (using a patched /sepolicy file), but Samsung's sepolicy OTA effectively undid all the changes. It seems to load just /data/security/spota/sepolicy and ignores /sepolicy (or maybe does a reload?). I got an sepolicy update last night that rendered the system unbootable until I deleted the update. Thanks!
[SuperSU] Alxoom33:
Cool, but don't think it shows up in Taptalk. Unfortunately!

---------- Post added at 04:17 PM ---------- Previous post was at 04:15 PM ----------

Actually, I always search first. Unfortunately, more difficult in Taptalk than in a web browser. Thanks for the link.
[SuperSU] lePoMo:
I may be going in entirely thre wrong direction, and what I say may be entirely useluss (or wrong), but could using mount bind help you? (to me it's currently a hammer that makes everything look like a nail ;p)

like would this in a su.d script do you any good

mount -o bind /sepolicy /data/security/spota/sepolicy

though not sure what happens if it writes to it (possibly overwriting your patched sepolicy). in that case, maybe have a script on boot that copies your patched sepolicy to a tmp file, and bind mounts that over it. (meaning a restart would always use a fresh copy of your sepolicy).

granted this would need to happen early on (i guess).

And since I'm clueless on Samsung specifics: are those sepolicy OTAs something that happens during normal running (without reboot). In that case could it also be an option to mount bind the command that is used, like restorecon, with an own script (if a command is used at all).

or even crazier, if selinux.reload_policy (taken from another post of yours, assuming it's related) resides in a file (or is a virtual one), you may even get away with bind mounting that file with a copy/dummy. maybe the thing reading has the file permanently open (original file descriptor) while the thing writing writes to the overlayed copy/dummy, so the original thing will never see the change and not act upon it.

or in that other thread your'e talking about /init. if that's a path, maybe somerhing in there be bind mount hammered. (I admit i still lack way to much context)

Anyone please treat this for what it is: random ideas thrown in, with the off chance that one sticks. many of my assumptions may be wrong, even some of my facts may be wrong, etc. If even one thing was close enough to help or spark a usefull idea, it was worth it ;)
[SuperSU] SamuriHL:
I don't know if this subject has been discussed in this thread. I just created a patched kernel for my Note 10.1 2014 OK1 5.1.1 build. Rooted fine and apps are getting root no problem. However, the OS is pissed off. LOL. It pops up a security violation warning non-stop. Is there a way to suppress that warning so it doesn't keep popping up? Thank you!
[SuperSU] ashyx:
Delete/freeze Knox 'security log agent'
[SuperSU] quick_:
EDIT: Seems as though re-downloading supersu 2.52 and picking to clear cache after flashing it in twrp, fixed it... (I did also use an updated boot image for MRA58N Link Here ty [MENTION=3667193]GROGG88[/MENTION]

I don't know what I'm doing wrong here, I can't get past the boot animation after flashing 2.52 in twrp

(Nexus 5 factory 6.0 flashed, flashed modified boot image)

I'm hesitant to try this systemless root, sounds like its not fully compatible with root apps like titanium backup, what about xposed.

Sorry if this is been repeated a hundred times, I've been reading this thread for 1-2 hours, searching endlessly.....
[SuperSU] Wyneg:
Hi! You need v2.56, not 2.52!!!! Here v2.56
[SuperSU] clefster:
There's a new Nexus 6P OTA (MMB29N) for Australia ..

could someone be so kind as to generate a modified boot.img for us? (NOT systemless. just the traditional sepolicy mods)

Attached is a backup of my boot.img from TWRP.. I tried playing around with the tools to do it myself but it got a bit much for me.

Would be greatly appreciated! Thanks.

Thanks to this post: http://xdaforums.com/showpost.php?p=63878014&postcount=2852

I think I created one OK.. however after flashing it and installing SuperSU 2.5.2 I do not have working root. Perhaps Google have changed something in the new build that prevents this root method from working.
[SuperSU] SamuriHL:
Yea I found that info after I posted. Thanks for thst though!
[SuperSU] martinomac:
I experienced the same issue but I'm not sure if its because of Samsung updating the security policy? Could you let me know how you went about deleting the update in case this happens again to me? I was on SU 2.46 at the time, now I'm on SU 2.56 but I'm not sure if that will prevent the device from booting after the policy update. I had to ODIN stock to get it booted again :( Do you think its kernel or ROM specific?
[SuperSU] chenxiaolong:
Thanks for the suggestions! I'll give the bind mounting a try, but I'm not sure if it'll work as there may be some signature checking going on (in particular, I'm not sure what the "sepolicy_version_sign" file is for). I might try:

mount -t tmpfs -o mode=0000 tmpfs /data/security/spota

as well, but that won't work if their OTA system runs as root. I haven't reverse engineered /init yet, but the way I understand the mechanism is that some OTA software first downloads the sepolicy to /data/security/spota/sepolicy, then it sets the property "selinux.reload_policy=1". /init picks up the property change and reloads:

/data/security/spota/sepolicy

/data/security/sepolicy

/sepolicy

with the top one having the highest priority. As far as I'm aware, /init does not keep an open fd to the sepolicy file.

If worse comes to worst, I'll just open up /init in a hex editor and replace "/data/security/spota/sepolicy" with a dummy string :)

I've attached my spota directory in case you want to take a look.

Sure, I just rebooted into recovery and deleted the entire sepolicy OTA directory:

adb shell rm -r /data/security/spota

I'm not sure how often it checks for these OTAs so it might come back again. The sepolicy OTAs happen on the fly without a reboot so you could potentially end up with a broken system while you're still booted (that's what happened to me). I believe these updates happen regardless of what ROM or kernel you're using unless the update mechanism was removed or is not supported in your particular version of TouchWiz.
[SuperSU] destructionj:
http://xdaforums.com/showpost.php?p=63987302&postcount=1021
[SuperSU] nitro_89:
Install System Root write over Systemless?

So I have systemless root but I need system root for some apps etc. Can I just install system root over systemless or do I have to revert back first? I thought I read somewhere it will detect the two different roots which can cause issues. I tried searching for answers but I didn't find anything. Thanks!
[SuperSU] osm0sis:
You need to flash 2.52 instead of 2.56 (which was only intended for systemless), and probably also flash the proper boot.img to go with it.
[SuperSU] nitro_89:
Ya but can I flash 2.52 over 2.56? Or do I need to start from scratch and install 2.52?
[SuperSU] osm0sis:
Over top should work. The only thing you'll have to do manually to remove all traces of systemless afterward is delete /data/su.img
[SuperSU] ashyx:
Systemless root doesn't mean you can't install root apps that modify system. It simply means you lose the benefit of systemless root being an unmodified system partition.

No need to change anything imo.
[SuperSU] stangri:
I believe he meant he needed to revert to the system-modifying root because the app he wants to use doesn't support systemless root.
[SuperSU] :
I flashed 2.52 for my 6P. Will i ever have to flash a new version thru twrp? Or do i just keep the app updated?
[SuperSU] force70:
I always keep a SuperSU zip on all my devices...you never know...

sent from my Nexus 6P, Note 5, Nexus 6 or Note 4
[SuperSU] :
But the question is should i install the newest version thru twrp? Is it good practice?

Does updating the app thru Google play do that for me?

My guess here is that i should be downloading and installing the zip file when there's a new one........
[SuperSU] force70:
I tend to run the latest version the majority of the time and yes updating via play or flashing via twrp same diff.

However i still advise keeping the latest zip on your device.

sent from my Nexus 6P, Note 5, Nexus 6 or Note 4
[SuperSU] :
Okay thanks. I'm on the beta 2.52. The app is 2.46. When the app catches up to my build i should be getting the update correct?
[SuperSU] Pkt_Lnt:
There are usually beta releases always version or two ahead of stable. Stable will be found in Play Store or that thread. You have to decide what you want, stable or beta. As new devices release, only beta will solve issues that arise, and once stable, will release to the Play Store.

And you might be aware that many don't like cross posing the same question in multiple forums.
[SuperSU] force70:
Yes it should.

sent from my Nexus 6P, Note 5, Nexus 6 or Note 4
[SuperSU] :
I want stable releases. I don't like betas of anything but for the nexus 6P that's all there is for now. How do i change to the stable release when there is one in the future?

I deleted the other double post. Thanks.
[SuperSU] Pkt_Lnt:
Don't flash any more beta zips.. When the next stable release comes out, you will get the update notification from the Play Store.
[SuperSU] :
Okay i won't. Thanks for the help.
[SuperSU] tsadev:
I read back a few pages, but haven't seen any inclination to an answer, so here goes:

I have a LG G3 (vs985), running CM13. I made a modified boot.img and installed the 2.56 beta to no avail. While installing the zip it output a line basically saying the kernel didn't support the required features. My question is, what kernel features are required? I can build the kernel from source and provide it to fellow vs985 users on MM, but I'm not sure what features need enabling. Anybody know? Thanks in advance.

EDIT: Attached screenshot of install attempt
[SuperSU] Lrs121:
Read the beta thread on the changes required in the init and other files that define how the su.img is mounted as well as the sepolicy changes necessary to have root work on Android m

---------- Post added at 08:13 AM ---------- Previous post was at 08:07 AM ----------

It also may have something to do with how cm13 handles the creation of the bootimg and su
[SuperSU] ashyx:
You ALWAYS get that message regardless. Its not a check. Its just telling you, you need kernel support, I. E. ramdisk changes for it to work.
[SuperSU] Samin Mondal:
is it works on all android Phone ?

is it works on all android Phone ?
[SuperSU] tsadev:
If I understand correctly, it's the modified sepolicy & the 2.56 zip that takes care of the init changes. I haven't looked at the updater script in the zip yet to be sure, but I'd assume that's what they're doing. I don't know that CM is loading the sepolicy or not, haven't dug through any logs yet either lol.

Have you tested on a compatible Nexus device to see if it displays the same message? For me, the zip installs to /system/bin, creates su.img, but it's never mounted so I'd imagine that's due to lack of required kernel flags.