[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

phishfi

Senior Member
Jul 7, 2009
674
119
San Antonio, TX
Dang, so no CM13 + systemless root. Bummer...

I think it's HIGHLY likely that CM would implement this alternative method of obtaining root. It limits users' reasons for modifying the system partition, fixes ANY issues related to root by simply having the user conduct a factory reset, and making a small modification to the kernel image is much easier than maintaining an entire system modification.

EDIT: I guess it's not entirely true that any issue which results from root could be fixed with a factory reset, since it's possible that a root app could alter the system partition irreparably, but it's less likely to cause an issue.
 
Last edited:
  • Like
Reactions: natemup

provolinoo

Senior Member
Nov 19, 2010
1,030
243
Milano
Hi guys,
if I want to enable double-tap-to-wake on my N6 without compromising the systemless root what's the best way?

As far as I know since I flashed a modified boot I can't flash a custom kernel (with dt2w support) on top of it
 
Last edited:

kmandel

Senior Member
Aug 13, 2010
372
7
I have a Nexus 6 running stock 6.0, which means its encrypted. To use systemless it needs
to be unencrypted. Is there a way for me to unencrypt it?

---------- Post added at 12:01 PM ---------- Previous post was at 12:00 PM ----------

I have a Nexus 6 running stock 6.0, which means its encrypted. To use systemless it needs
to be unencrypted. Is there a way for me to unencrypt it?
 
I have a Nexus 6 running stock 6.0, which means its encrypted. To use systemless it needs
to be unencrypted. Is there a way for me to unencrypt it?

---------- Post added at 12:01 PM ---------- Previous post was at 12:00 PM ----------

I have a Nexus 6 running stock 6.0, which means its encrypted. To use systemless it needs
to be unencrypted. Is there a way for me to unencrypt it?

I'm encrypted and using systemless root without any problems.
 

ashyx

Inactive Recognized Contributor
Oct 14, 2012
15,055
9,943
Hi guys,
if I want to enable double-tap-to-wake on my N6 without compromising the systemless root what's the best way?

As far as I know since I flashed a modified boot I can't flash a custom kernel (with dt2w support) on top of it

As far as I know all the changes are in the Ramdisk, so dont see why you can't use a custom kernel.
 
  • Like
Reactions: provolinoo

gundal

Senior Member
Aug 10, 2010
525
313
VancouverIsland
@Chainfire
Ramdisk modifications
- include (post above this one)
- init.rc (devs: please open file for reference)
--- on init
------ mkdir /su ...
--- on post-fs-data
------ copy image from cache to data (for rooting without access to /data in custom recovery)
------ mount image to /su
--- service daemonsu
- init.environ.rc
--- export PATH, prepended with /su/bin
- file_contexts
--- /su(/.*)? u:/object_r:system_file:s0
I applied the following modifications, as well as the sepolicy, and also altered the supersu 2.56 installer shell script to allow sdk '22' to also check the override testing bit

I can /su boot root my note5 into enforcing with a stock /system that should pass dm verity
however.. SuperSU is asking me to update binary.. which installed partially back to /system/xbin and .ext/su

edit: on second attempt with twrp ro bit set, after restoring /system, it just says su binary not found, executing it from /su/bin/ in terminal and daemonsu have no effect,

was interested in keeping /system untouched
 
Last edited:

ashyx

Inactive Recognized Contributor
Oct 14, 2012
15,055
9,943
Haven't seen it mentioned, but can anyone fill me in the reason why this only works on MM and not LL?
 

Ch3vr0n

Senior Member
May 6, 2009
1,693
668
41
There is no reason. Beta should work just fine on lollipop

Verstuurd vanaf mijn Nexus 7 met Tapatalk
 

AnkitChowdhury

Senior Member
Jul 18, 2012
520
360
Nexus 7 (2013)
Xiaomi Mi A1
Hey @Chainfire, need a bit of help. On Marshmallow, even after patching a couple of policies using the supolicy tool, the app is denied access to the input event files. Although the Supolicy tool return message suggests that patching was successful with everything ok. These policies worked great on Lollipop.

Code:
"supolicy --live  'allow appdomain input_device dir { open read write search ioctl }'"
"supolicy --live  'allow appdomain input_device chr_file { ioctl read write getattr lock append open }'"

Patching the policies through your SuperSU android library. And Using JNI to access the events and not spawning a separate daemon file. Any help would be really appreciated. TIA.
 
  • Like
Reactions: rasiyansyah

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
16,629
39,961
Halifax
GT-i9250
Google Nexus 4
unSU Script zip -- Unroot with ease!

Originally this was a little zip to help with uninstalling the old system-modifying version of SuperSU. It properly restores all the original files the SuperSU installer backed up (so, file-based OTA friendly!) and removes any files added by the installer/app. I figured other people might find it handy as well so it's attached below. Be aware, if you flashed SuperSU twice mistakenly, the SuperSU installer wasn't written to recognize that and so you've lost your originals; a system.img flash WILL be necessary in your case.

Due to popular demand by the custom ROM community using this to unroot and pass SafetyNet checks/use Android Pay, etc., the script has been expanded to unroot Koush's SuperUser, ROM su binaries, as well as SuperSU Systemless (su.img and BINDSBIN), phh's Superuser (which is also systemless), and now Magisk and LineageOS addonsu.

Note: To completely remove all traces of the systemless roots, you still need to flash a different, unrooted boot.img, likely the default one that came with the ROM. You can extract it from the ROM zip (or a /data/stock*.gz backup from your root solution before flashing unSU) and flash it using TWRP's awesome "Flash Image" functionality, or, "dirty flashing" the ROM zip should also work.

My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!

P.S. If you found this handy then please check out my Odds and Ends thread for more flashable goodness. :D

Previous download counts: 58944; 158506; 59850; 226692
 

Attachments

  • UPDATE-unSU-signed.zip
    5 KB · Views: 122,107
Last edited:

notfaded1

Senior Member
Jun 18, 2011
215
44
Scottsdale, Arizona
Has anyone tried this on 6p that's encrypted userdata?

Correct if I'm wrong but since systemless root doesn't modify userdata or /system couldn't you boot twrp and:
- Flash the attached boot image
- Flash the attached SuperSU ZIP in TWRP sideloaded
then just reboot leaving stock recovery in place and now have systemless root with crypted userdata?

I saw post on this thread saying someone on Nexus 6 was running systemless root encrypted. Would the above method I listed work for the 6P with crypted userdata?
Also uniofs or overlayfs does sound like even better option but since this works it'll do nicely for easier updates.
 
Last edited:

claytonjn

Senior Member
Nov 3, 2011
1,561
836
claytonjamesphotography.webs.com
Correct if I'm wrong but since systemless root doesn't modify userdata or /system couldn't you boot twrp and:
- Flash the attached boot image
- Flash the attached SuperSU ZIP in TWRP
then just reboot leaving stock recovery in place and now have systemless root with crypted userdata?

I saw post on this thread saying someone on Nexus 6 was running systemless root encrypted. Would the above method I listed work for the 6P with crypted userdata?
Also uniofs or overlayfs does sound like even better option but since this works it'll do nicely for easier updates.


TWRP for the Nexus 6 can decrypt, TWRP for the Nexus 6P cannot (yet).
 
  • Like
Reactions: lePoMo

osm0sis

Senior Recognized Developer / Contributor
Mar 14, 2012
16,629
39,961
Halifax
GT-i9250
Google Nexus 4
Thanks for the update :)

On the same topic:
when I boot in recovery with TWRP as first screen it tells me it found an untouched system partition and asks me for keeping it read only or allowing modifications to avoid stock rom replaces recovery

what's the right answer here? :D

Depends. If you're using a device which launched with Lollipop or later (ie. has system.dat patch OTAs) you probably want to keep /system RO so that you can still flash OTAs (provided your root apps also don't alter /system). If you have a device that didn't launch with Lollipop or later (ie. has file patch OTAs) it doesn't matter, your choice; OTAs will flash fine as long as you don't modify the files it tries to patch.
 

elreydenj

Senior Member
Aug 12, 2012
956
183
So with the new factory images dropping as of today for the 6P and 5X we would have to wait for the systemless root kernel versions before flashing the system image if we want to upgrade and maintain root correct?
 

M Diddy

Senior Member
Dec 23, 2010
251
26
Can anyone tell me the steps needed to modify the stock boot.img to allow root using Android image Kitchen? I know how to disable encryption, just not how to make the other changes needed to root with the new factory image that was posted today.

Thanks!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2533
    This thread is for SuperSU releases that are still in testing, and are not yet available through the Play store. The main thread for stable SuperSU releases is located here: https://xdaforums.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703. The changelogs are in the old release thread.

    Please keep track of the version numbers in the thread titles, as the latest test release may not always be newer than the latest stable release.

    The latest test release is:
    SR5-SuperSU-v2.82-SR5-20171001224502.zip
    RELEASE NOTES
    That is a recovery flashable ZIP (I recommend FlashFire or TWRP). If you want to install via APK, it is also present inside the ZIP, in the common folder.
    617
    unSU Script zip -- Unroot with ease!

    Originally this was a little zip to help with uninstalling the old system-modifying version of SuperSU. It properly restores all the original files the SuperSU installer backed up (so, file-based OTA friendly!) and removes any files added by the installer/app. I figured other people might find it handy as well so it's attached below. Be aware, if you flashed SuperSU twice mistakenly, the SuperSU installer wasn't written to recognize that and so you've lost your originals; a system.img flash WILL be necessary in your case.

    Due to popular demand by the custom ROM community using this to unroot and pass SafetyNet checks/use Android Pay, etc., the script has been expanded to unroot Koush's SuperUser, ROM su binaries, as well as SuperSU Systemless (su.img and BINDSBIN), phh's Superuser (which is also systemless), and now Magisk and LineageOS addonsu.

    Note: To completely remove all traces of the systemless roots, you still need to flash a different, unrooted boot.img, likely the default one that came with the ROM. You can extract it from the ROM zip (or a /data/stock*.gz backup from your root solution before flashing unSU) and flash it using TWRP's awesome "Flash Image" functionality, or, "dirty flashing" the ROM zip should also work.

    My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!

    P.S. If you found this handy then please check out my Odds and Ends thread for more flashable goodness. :D

    Previous download counts: 58944; 158506; 59850; 226692
    578
    f2fs with Android story is always complicated.

    So why is SuperSU broken with many custom ROMs:
    systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
    The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
    This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

    This “fix” is rather dumb :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

    The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
    (The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
    So you have 2 choices :
    A. Cherry-pick that fix separately
    B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


    But there are more stories to be told, unfortunately.
    Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
    There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

    You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    Without this fix, the kernel will panic upon reading any data.


    So we took care of the method A.
    However, there is still an issue with method B : deadlock.

    As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
    It took about a month to bisect it, and I got the culprit commit :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

    I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
    Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


    TL;DR
    It’s not @Chainfire 's fault.
    You have to ask the kernel developer to fix the issue.
    2 methods for the kernel developers

    A. Incorporate only the necessary 2 fixes to fix loopback images :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
    (A little credit would be appreciated, as it took me a frustrating month to bisect this)

    Thanks.
    348
    --- reserved ---
    189
    @ everyone

    This post is likely an important one going forward, it could be the answer to various issues people have on 6.0 related to /system.

    The conversation below pertains specifically to Nexus 6 @ 6.0.1, which has an almost full /system, but I'll bet the issue exists on all Nexus devices.

    Do you mean that there's even less space than on 6.0?
    Titanium Backup reports that there 15.6 MB free. Shouldn't this be enough for a very small mod such as an edit to build. prop?

    So after some further investigation, something pretty odd is going on.

    ext4 (the filesystem) has various types of reserved blocks.

    I suspect the tools on booted Android do not count one type of reserved block. Indeed, when you use "df" utility (both toolbox and toybox), it shows 15mb or so free. Using the same "df" utility in recovery (busybox) shows 0b free. It does show that not all blocks are in use, but the remainder is likely reserved.

    If you use a root shell on either booted Android or in recovery, trying to write contents to a new file in /system will fail. To make matters worse, file creation succeeds, but writing content does not, so you end up with a 0 byte file. You need to delete a few extra megabytes of files, before you are able to write even 1 byte to a new file!

    Many editing tools remove the old file and write a new file at the same spot rather than truly editing a file. I'm not sure if the latter has any chance of succeeding, but the former would definitely fail in this scenario.

    While the issue is understandable technically, it is likely to trip up a lot of tools, as the error is generated at the least expected moment.

    This issue is a magnet for file corruption and bootloops. Beware this issue when modifying anything on /system!

    DEVS Immediate hunch is that the difference is explained by usage of struct statfs's bfree vs bavail member.

    TL;DR Yes, even though TiBu and whatever other tool are showing you megabytes free, adding/modifying files is likely to give unexpected results on a (near-)full /system partition, and an unlucky edit can definitely prevent the device from booting! Can't give you exact numbers right now, but before modifying files or adding files to /system, I would recommend deleting files until you have at least 30-ish mb free.