First great news, post and work @OuinOuin!
I hate to be that guy, but maybe we should start an article to better explain the different “su” programs.
If I understand it correctly, there is not code available for SuperSU, is that correct?
1 Like
Hey, this sounds great. Will try it as soon as I have time for.
Please feel free to add it to the wiki article. Did you got the chance to try with encrypted userdata?
1 Like
Thanks for the compliment !
You’re right about SuperSU, the code of the program isn’t open but it’s the most used for rooting Android devices.
Now, if you want a Open Source way to root your phone, you can follow the excellent tuto from @Max_S here.
1 Like
Thanks !
Unfortunately my device isn’t encrypted so I can’t make test but if someone want to test. If I have enough time this weekend, I’ll encrypt my device and make a try.
Hi,
I’ve made this changes to erase this error encounter by @Max_S build : type=1400 audit(1453078388.170:5): avc: denied { write } for pid=33 comm="toolbox" name="enforce" dev="selinuxfs" ino=4 scontext=u:r:recovery:s0 tcontext=u:object_r:selinuxfs:s0 tclass=file permissive=1
For what I see, SELinux protection is still active when TWRP run but the program needs to change SELinux enforcement in the init procedure. See in domain.te :
# Only init prior to switching context should be able to set enforcing mode.
# init starts in kernel domain and switches to init domain via setcon in
# the init.rc, so the setenforce occurs while still in kernel. After
# switching domains, there is never any need to setenforce again by init.
But in fact, it doesn’t work in my case so I add -recovery to authorize it for modifying SELinux enforcement.
I think the line who produce this error is in the init.rc of recovery :
service set_permissive /sbin/permissive.sh oneshot seclabel u:r:recovery:s0
However, as recovery can change SELinux enforcement, it can do it at every time when it run so to be sure there is no risk, a code inspection is needed but I haven’t time and knowledge for doing that. 
Keep also in mind that in order to TWRP working, it must run in permissive mode which mean that SELinux errors are just logged but not applied. This is doing by adding this line :
# Allow recovery to set permissive mode permissive recovery;
in recovery.te
I can make, if you want, a version without the authorization for recovery to modify SELinux enforcement but I think it will change nothing but show SELinux errors as recovery already run in permissive mode.
Just a short feedback on this topic.
As I mentioned here ✏ Porting TWRP recovery
I had to replace my Fairphone.
Used TWRP from @Max to backup the old one.
The restore on the new one worked.
The only think I had to do was, make a new backup to have a folder with the serialnumber of the new phone and copy the the old backup in this folder.
After restore wipe cache and dalvik cache. Thats it!
4 Likes
I tried the xposed-v80-sdk23-arm.zip and I had an error. I then installed the xposed-v80-sdk22-arm.zip and it works 
sdk23 is for Marshmallow and sk22 is for Lollipop.
1 Like
That might be the reason, indeed ^^'
Thanks for the info
Thanks for your work.
I tried to flash SuperSU but it doesnt download the new SU Binarys.
Maybe you have a hint for a solution?
There are Root Apps, which only works with chainfires SuperSU.
Following this procedure here does not wipe or erase any user data correct? Fastboot flashing a new recovery does not require any fp2 unlock procedure that would wipe the phone (as read somewhere else)?
Is the linked SuperSU.zip the one that should be used and was tested, or does the latest version also work? Just saw that this is the stable version, never mind: https://download.chainfire.eu/921/SuperSU/UPDATE-SuperSU-v2.65-20151226141550.zip
Well I haven’t tried it yet - still cautiously preparing. 
Flashing a recovery does not touch anything else. Especially does also not touch user data.
Klaus
How exactly is SuperSU failing for you? Flashing the zip in recovery works? Do you see the app later and can run it? Where do you get stuck? Did you check adb logcat when it fails?
I can flash it and open it without problems.
It fails downloading the SU Binarys. Even after several reboots.
So thats just an update then inside SuperSU or aren’t those files in the original zip file that you flashed? I don’t remember SuperSU downloading files after flashing it on another phone…
Yes its in Update inside SuperSU.
Doesn’t matter which Version i take. At the first start of SuperSU it have to make this update.
@neolovich Install Superuser and then call Amaze and try to look into /data/app. This should start superuser and you will see, if you have a rooted device. No need for supersu to download anything …
Spielmops
1 Like