After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy
sepolicy patch is here: https://github.com/PureNexusProject...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
sorry to be that guy, but how does this affect the average joe?
does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
BeansTown106 said:
Thanks after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow
Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.
thanks in advance :good:
Click to expand...
Click to collapse
There is no such thing now as "all current root apps working".
If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.
What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.
As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")
Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.
Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):
Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.
In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.
Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.
A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy
as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Chainfire said:
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.
Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
the link in OP its no longer working...
Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
Link in OP its no longer working...
Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.
It reminds me of Korean dramas ,
Related
I am not responsible for any possible bad effects which may result from using included software! You flash it on your own risk!!!
STOCK RELOADED v1 fix 1
Kernel base: stock XXUANC3 (kernel 3.4.0-1131235)
Kernel ramdisk: modded
Features: a few...
Security level: low!
Purpose: giving everyone who loves free exploring of Android secrets and who doesn't consider security as an absolute priority and who wants to put some life in this, indeed, awesome device, a possibility of playing with his device without disturbing restrictions, forced by Samsung, at least until fully-custom kernels, compiled from sources, appear (and that may take some time, as source code available atm seems to be broken, causing all the compiled kernels to stuck at boot screen).
Features working out-of-the-box:
- su binary from SuperSU by Chainfire @ /sbin/su (binary only for scripting purposes! Flash cf-root to use SuperSU app!)
- busybox 1.22.1 binary compiled by Stericson @ /sbin/busybox
- init.d support - just put your favorite scripts into /system/etc/init.d using any file manager and chmod 755 (not 777! it's NOT smart to permit write access for "world" to any system file), chown root:root, they will run on every boot. Well, to be honest, above permissions are given to all the scripts automatically during boot, but it has not yet been tested
- SELinux: Permissive - Samsung's most recent policy of forcing SELinux Enforcing mode by pre-compiling it into a kernel binary part, found in latest KitKat builds since at least a few months, HACKED FOR THE FIRST TIME EVER using innovative method of injecting an information directly into kernel memory space and forcing overwriting potentially-persistent kernel symbol value on-line during boot!)
- unsecure adb access (not tested yet)
- ext4 tweak: 20 sec (instead of stock 5 sec) write commit delay for /data partition (significantly increases IO performance!)
- some further, minor modifications
WARNING!!!
- flashing this WILL undoubtly trip KNOX, avoiding your warranty (which atm cannot be reverted! in any way)
- flashing this WILL cause a warning message of avoided warranty to be displayed on every boot (ofc it disappears right after reverting to stock boot.img)
- flashing this WILL disable some of the very important security features provided with stock firmware!!!! For advanced and experienced users only!!! Use at your own risk!
Known issues:
- AllCast Share mirroring not working (typical for all Samsung devices running not-exactly-stock kernels since S3). WORKING FIX AT POST #16!!!
http://forum.xda-developers.com/showpost.php?p=54516532&postcount=16
Please consider solution from post #3 as not-always-working and depreciated!
Installation:
- compatibile with XXUANC3 firmwares but probably also with other (past and hope future too...) KitKat 4.4.2 Samsung branded firmwares;
- rooting by Chainfire's CF-Root first recommended as it will install SuperSU app in Android (this kernel contains su binary only giving su access without any policy settings!);
- enter download mode and plug the tablet via USB...
- ...select provided file in PDA section (and NOT touch anything except that)...
- ...and flash with Odin in a same way as CF-Root or like anything else...
- enjoy.
DOWNLOAD HERE:
Current version - STOCK RELOADED v1 fix 1
http://www63.zippyshare.com/v/87557346/file.html
FIXED: file name changed so it can be flashed directly by Odin without renaming! Sorry for this silly mistake!
=======
Changelog:
v1 fix1:
- fixed permissive mode due to trivial error;
- delayed init.d execution to a moment AFTER init process set cfq scheduler so it is not overriding mmcblk0 tweaks (if put in init.d) anymore;
- minor code cleanups
v1:
- initial release
- init.d support
- SELinux permissive
- unsecure ADB
- ext4 delayed commit for /data
=======
Stock XXUANC3 kernel (to revert changes)
http://www65.zippyshare.com/v/32441894/file.html
Revert using Odin, in the same way you've installed a Reloaded Version....
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
rgolnazarian said:
Awww man,...I wish i could flash this, but I'm on the exynos =(
Sent from my SM-P900 using Tapatalk
Click to expand...
Click to collapse
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
YAY!
Beautiful, absolutely beautiful. You made ma a very happy man with this. I'll flash this as soon as I get home from work. Can't wait to try it out, the stock kernel is giving me SOD and frozen wifi issues sometimes.
esgie said:
Sorry pal, Qualcomm only, not even a chance to run this same way as the devices (and mostly important: provided software, ie. system structure) DIFFER A LOT between themselves.
Update 1: uploaded fix #1 which is resolving some trivial issues found in initial version; sorry for that, now we can say that every described feature has been included hope for some feedback... thank you...
Update 2: FIX FOR NOT WORKING SCREEN MIRRORING CAN BE DOWNLOADED HERE:
http://www67.zippyshare.com/v/25492738/file.html
I have personally modified a library that is being used by screen mirroring feature, which forces video encryption using keys from stock kernel, and which prevents to run mirroring at all . This is an issue of any modified kernel, on any Samsung device. Attached library fixes this, by disabling HDCP at all. It has been reported that the library resolves the issue for any Qualcomm based Samsung device running 4.4.2 KitKat and for any custom kernel. It will NOT work for Exynos devices...
Installation:
- download attached libwfdsm.so file
- overwrite genuine one in/system/vendor/lib (important! NOT /system/lib!!!!)
- chmod 644 libwfdsm.so ||| chown 0.0 libwfdsm.so ||| restorecon -R /system/vendor/lib
- mirroring will work again after reboot!!
Click to expand...
Click to collapse
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
THEDEVIOUS1 said:
I was literally just about to post in the old thread with bad news about the modified "libwfdsm.so" file & screen mirroring with a custom kernel...if u remember i confirmed that the file u altered would work with a custom recovery on the 8.4 lte & i just assumed that it would work with an altered boot.img as well but unfortunately thats not the case after testing the other night (unless something else is wrong with my setup). So...my question is have u changed something else since then to allow it to work again & have u personally tested this yourself?
sorry to hijack the thread...didnt know if i should pm or post in the older thread
Click to expand...
Click to collapse
No problem, anyway, thanks for pointing the issue out! This may be an important information for mirroring users!
Since then I didn't change anything, yet. Really, I am also not sure if I have tested it with modified kernel, as the one posted here is the first kernel for P905 at all, and it's not even "fully" customized, as the kernel binary base was left unchanged.
So, I'd like to be sure: you are saying that modded lib:
- fixed the problem for custom recovery, but...
- ...didn't fix it for custom kernel
right?
I was looking for a solution to persistent enforcing mode since some time, so I was flashing test boot.imgs from time to time, then reverting to stock again, meanwhile I created above lib, I can't really be sure about if it is working when both bootimg and kernel are customized (this would also be an opposite to previous Sammy's Android releases, where a single fix was solving all the issues related to customizations of both kernel and recovery!).
We also have to be aware that the issues may not be a result of flashing different kernel at all, but a result of the changes themselves, ie. disabled knox, disabled encryption of i-dont-really-know-what, etc, etc.
And the most important thing! Since I have heard of AllShareCast/Screen Mirroring for the first time (it probably appeared for the first time in S3/Note2/Note10.1), it always required resetting the flash counter - which could be viewed in download mode and which is NOT the same as Knox flag - to ZERO and that requirement AFAIR remained totally independent from the requirement of having stock boot/kernel (or lib patch). Have you checked the counter state? Did you reset it to zero again using Chainfire's Triangle Away after flashing non-stock kernel (which, obviously, TRIPPED the counter)? Can you check if it is working? Note that at least on my P905, Triangle Away still works flawlessly and resets the counter without any problems and even without a need of reboot!
Please check above info and try if the issue is fixed after running Triangle Away. I am leaving for a short business trip soon, so I'll perform my own tests with AllShare cast until next of the week, however, neither today nor tomorrow...
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
Argh possibly too many dots in filename... will correct it tomorrow.
cavkic said:
I get an "md5 error! binary is invalid" when I choosse the file in Odin. I downloaded the file 6 times, and every time I get the md5 error.
What do I do?
EDIT: Renaming the file to "boot.tar.md5" seemed to solve the problem.
Click to expand...
Click to collapse
same here...
Hi,
I have a problem with screen mirroring.
Installed the patch and mirroring connects to the dongle, but the TV screen turns just black.
The dongle works perfect with HTC One M8, it must be a softwareproblem?
Thanks for help!!!
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Can anyone give me some advice please. When I enter the command in terminal emulator I get an error saying "Unable to open chown. No such file or directory". Am I missing something obvious lol.
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
cnote74 said:
Will this work on p907a AT&T version of note pro 12.2?
Sent from my SAMSUNG-SM-P907A using XDA Premium 4 mobile app
Click to expand...
Click to collapse
On the topic name it says [P905 LTE ONLY], and your device is some different..
tdetroit said:
Will this work on the P905V (Verizon Variant)? I need to downgrade the permissions in my Security in order to use Towelroot, because they're set to Medium and I believe that prevents Towelroot to work properly. Most of the other Note 12.2 variants have been rooted....except the Verizon version.
Click to expand...
Click to collapse
I would like this answered as well. I also have the "v" variant. Maybe saying LTE includes many? See my link I attached, found while investigating this specific question.
http://www.usatoday.com/story/tech/2013/07/07/sprint-att-verizon-phones-network-carriers/2486813/
Ever since I rooted my tablet it goes on random reboot kicks. I want to start over. Also TWRP will not stick when I try to flash it.
I have many issues which I'm currently posing in their appropriate forums. It would be nice to wipe to a rooted stock.
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Thanks. The Galaxy is connecting to theTV, but the screen is only turning black - no Display...
Any idea?
Thank you.
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
esgie said:
Guys!
I have probably found another solution for non-working Screen Mirroring / AllShare Cast when custom kernel is flashed (again, LTE devices only).
No need of modded lib
Seems that the only thing we need is to
1) run Terminal Emulator and type:
Code:
su -c setprop wlan.wfd.hdcp disable
(will work immediately; won't stick between reboots!), OR...
2) edit /system/build.prop file with any root file manager/text editor and add a line (no matter where):
Code:
wlan.wfd.hdcp=disable
(will work only after reboot; will stick between reboots).
Try this using kernel from op waiting for feedback!
Click to expand...
Click to collapse
I tried both methods and still get no devices found when I turn on screen mirroring.
ColBill said:
I tried both methods and still get no devices found when I turn on screen mirroring.
Click to expand...
Click to collapse
Hm.
This is weird, as the problems with allshare cast + custom kernels is not that "no devices are found" but that devices ARE found without any problem but the connection process fails after a few secs. This solution may help with the issue i described, but it will surely not solve the problem with no peers detected at all.
No peers detected = problems with wifi direct (are you able to send files between wifi direct between devices?)
Can you tell me what is your exact device config? And are you using allsharecast dongle or other third party hardware?
@fokus
Only one: also reset flash counter with Triangle Away and then try again. And make sure you spell the value in the command as "disable" not "disabled" - it's tricky and one can miss it...
Well, there are two additional things to add.
Guys, make sure you have updated Samsung's ScreenMirroring firmware update app to the latest version. And check out the samsung mirroring fix app in google play, which solves some issues for various devices (dunno which ones exactly as i have never been in need of using it).
The fix half worked for me lol. The tablet now connects fine to the Netgear PTV3000 but all I get is black screen. Step in the right direction though as at least it connects now. Just need to get a picture to show lol.
THIS IS CURRENTLY NOT WORKING
A newer version is available here: https://forum.xda-developers.com/apps/supersu/suhide-lite-t3653855
suhide is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary and package name) from other applications.
Pros
- Hides root on a per-app base, no need to globally disable root
- Doesn't need Xposed
- Even supports SuperSU's ancient app compatibility mode (BINDSYSTEMXBIN)
- Passes SafetyNet attestation by default on stock ROMs (last officially tested on 2016.10.07)
Cons
- Ultimately a losing game (see the next few posts)
- No GUI (at the moment) - Unofficial GUI by loserskater
Requirements
- SuperSU v2.78 SR1 or newer (link)
- SuperSU installed in systemless mode
- Android 6.0 or newer
- TWRP (3.0.2 or newer, with access to /data - link!) or FlashFire (link)
Xposed
Xposed is not currently officially supported, but if you want to use it directly, you must be using @topjohnwu 's systemless xposed v86.2 exactly (attached at the bottom). It seems to mostly work during my non-extensive testing, but there are still some performance issues (both boot-time and run-time). Proceed with caution, expect bootloop.
Alternatively, there are some reports that the latest Magisk version + the latest systemless xposed (for Magisk) also works. I have not personally tested this.
CyanogenMod
I've personally tested with CM13 on i9300 without issue, however, several users are reporting it doesn't work for them. Proceed with caution, expect bootloop. Also, aside from just flashing SuperSU, you need to make sure /system/bin/su and /system/xbin/su are removed, or CM's internal root will still be used.
Usage
Install/Upgrade
- Make sure you have the latest SuperSU version flashed in systemless mode
- Make sure you are using the latest TWRP or FlashFire version
- Remove any and all Xposed versions
- If you have been having issues, flash suhide-rm-vX.YY.zip first, and note that your blacklist has been lost.
- Flash the attached suhide-vX.YY.zip
- If you are upgrading from suhide v0.16 or older, reflash SuperSU ZIP, and note that your blacklist has been lost.
- Optionally, flash the Xposed version linked above, and pray
At first install SafetyNet is automatically blacklisted.
If you have just flashed a ROM, it is advised to let it fully boot at least once before installing suhide.
Uninstall
- Flash the attached suhide-rm-vX.YY.zip. The version may appear older, the uninstall script doesn't change very often.
Blacklisting an app
You need the UID (10000 to 99999, usually 10xxx) of the app, which can be tricky to find, or the process name. There may be a GUI for this at some point.
(Note that all commands below need to be executed from a root shell)
If you know the package name, ls -nld /data/data/packagename will show the UID - usually the 3rd column.
Similarly, for running apps, ps -n | grep packagename will also show the UID - usually the 1st column.
Note that the process name is often the same as the package name, but this is not always the case. UID is more reliable for identifying a specific app, and it is also faster than blocking based on process names.
When you know the UID or process name:
Add to blacklist: /su/suhide/add UID or /su/suhide/add processname
Remove from blacklist: /su/suhide/rm UID or /su/suhide/rm processname
List blacklist: /su/suhide/list
All running processes for that UID or process name need to be killed/restarted for su binary hiding. For SuperSU GUI hiding, the device needs to be restarted. I recommend just (soft-)rebooting your device after making any changes.
Please keep in mind that many apps store their rooted state, so you may need to clear their data (and then reboot).
Integration into SuperSU
This mod isn't stable, and probably will never be (see the next few posts). As SuperSU does aim to be stable, I don't think they're a good match. But who knows, it all depends on how things progress on the detection side.
Detections
This mod hides the su binary pretty well, and does a basic job of hiding the SuperSU GUI. The hiding is never perfect, and suhide itself is not undetectable either. This will never be a perfectly working solution.
Debugging bootloops
- Get your device in a booting state
- Make sure you have TWRP or a similar recovery
- Install LiveBoot (link)
- If you are not a LiveBoot Pro user, enable the Freeload option
- Enable the Save logs option
- Recreate the bootloop
- In TWRP, get /cache/liveboot.log , and ZIP+attach it to a post here.
Download
Attached below.
Any rm version should work to uninstall any suhide version.
There may be multiple versions of suhide attached, please look carefully which one you are downloading!
YOU ARE EXPLICITLY NOT ALLOWED TO REDISTRIBUTE THESE FILES
(pre-v0.51: 17410 downloads)
Hiding root: a losing game - rant du jour
Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.
While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.
SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.
Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.
While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".
The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.
Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.
More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.
It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.
Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.
Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.
--- reserved ---
Changelogs
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
As always thank you Chainfire! I will try and edit this post.
Edit @Chainfire this seems to work for enabling Android Pay! I didn't get the chance to actually pay yet. But it did let me add my card and did not display the message about a failed authorization of Android check! Before I couldn't even get past that first screen.
Edit 2: @Chainfire It seems to of had an adverse effect on Snapchat. I cleared cache on the app, uninstalled and reinstalled and restarted. It kept Force closing after a photo no matter what. I used suhide-rm and it seems to have fixed the app from any issues. Thanks again and hopefully we'll get you some more reports. Either way your solution works!
Tested on stock rooted 7.0 Nexus 6p.
@Chainfire
What was your reason for doing this project?
Sent from my Nexus 6P using XDA-Developers mobile app
Ofthecats said:
What was your reason for doing this project?
Click to expand...
Click to collapse
For building it, curious if the method I came up with would work well. For releasing, if others are doing it, join them or be left behind.
I'm assuming with custom ROM android pay still won't work right?
HamsterHam said:
I'm assuming with custom ROM android pay still won't work right?
Click to expand...
Click to collapse
I'd just give it a try. It's spoofing the specific app, not the entire ROM that matters. It's fairly simple to try.
Installed on LG G4 w/ V20g-EUR-XX update and rerooted with TWRP 3.0.2-0 and SuperSU-v2.76-2016063161323. seems to be working fine, for the moment. Thank you for the update.
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
djide said:
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
Click to expand...
Click to collapse
What was the UID or process you found to blacklist it with?
Sent from my ONEPLUS A3000 using Tapatalk
how to install it? which file should I flash ? Both?
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Joshmccullough said:
What was the UID or process you found to blacklist it with?
Click to expand...
Click to collapse
Android Pay comes blacklisted out-of-the-box
HamsterHam said:
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Click to expand...
Click to collapse
Are you in Android or TWRP ?
ls -l /data/adb/
Chainfire said:
Android Pay comes blacklisted out-of-the-box
Click to expand...
Click to collapse
Derp. That's what I get for not reading the entire sentence under 'Install' in the OP......thanks!
PedroM.CostaAndrade said:
how to install it? which file should I flash ? Both?
Click to expand...
Click to collapse
Please don't quote a large post like that just to ask a single question.
Please read the first post, so you know what to do.
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
thdervenis said:
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
Click to expand...
Click to collapse
You need to blacklist the UID for your bank. Directions are in the OP.
Note: This module won't work with v10-v11.6 since some syntax err in the mounting scripts. More info here. https://github.com/topjohnwu/Magisk/commit/624b7616d082feced71bff0474c64c1b4afd5cc0
If you're using a beta one newer than v11.6. Try this module.
Init.d Link (Magisk)
Intro
The module solves the situation when /system/etc/init.d doesn't exist, some app, let's say Kernel Auditor Beta, doesn't recognize the *.d folder provided by MagiskSU and tries to create the init.d folder by itself. So we'd better symlink one from an available *.d — post-fs-data.d, service.d or su.d.
- The module symlinks a *.d folder as init.d,
- or simply create one systemlessly.
- Init.d scripts will be run by an existing superuser — MagiskSU, phh's superuser or SuperSU — or the kernel,
- but NOT by the module itself, in case of collision with the func of kernel.
Symlink Priority:
1. /magisk/.core/service.d (Magisk v12)
2. /magisk/.core/post-fs-data.d (Magisk v11)
3. /magisk/phh/su.d
4. /su/su.d
5. /magisk/.core/post-fs-data.d (Magisk v12)
6. /magisk/.core/service.d (Magisk v11)
The last resort will be the creation of a systemless init.d folder.
NOTE: init.d will be symlinked only if available *.d foler exists.
Installation
Flash it in RECOVERY ONLY.
Credit
https://github.com/laggardkernel/init.d-link by laggardkernel
Changelog
v1.3
- Fix mount of su.img
v1.2
- Update to module template v3
- Add link target info into module.prop.
- Reorder init.d link priority for Magisk v12:
1. /magisk/.core/service.d (Magisk v12)
2. /magisk/.core/post-fs-data.d (Magisk v11)
3. /magisk/phh/su.d
4. /su/su.d
5. /magisk/.core/post-fs-data.d (Magisk v12)
6. /magisk/.core/service.d (Magisk v11)
- There is also a post-fs-data branch keep post-fs-data.d at high priority by force.
Reserved.
How to use this module?
ngtung84 said:
How to use this module?
Click to expand...
Click to collapse
Just download the zip and flash it in your recovery. Then the module will create a /system/etc/init.d link directing to /magisk/.core/post-fs-data.d SYSTEMLESS. This will solve the pain that some apps, like Kernel Manager beta, don't recognize Magisk's post-fs-data.d and create a init.d itself to put their init scripts.
laggardkernel said:
Just download the zip and flash it in your recovery. Then the module will create a /system/etc/init.d link directing to /magisk/.core/post-fs-data.d SYSTEMLESS. This will solve the pain that some apps, like Kernel Manager beta, don't recognize Magisk's post-fs-data.d and create a init.d itself to put their init scripts.
Click to expand...
Click to collapse
I have some scripts. Can I put them into /system/etc/init.d created by this module?
You make some really nice little modules. I really believe you should submit them to the repo... It's gonna need some updating to the latest template and maybe also some updates for v12 though. From the v12 release notes:
It is recommended to run most scripts in the service mode (service.d/service.sh), except a. mounting files; b. patching system props; c. time critical operations
Click to expand...
Click to collapse
Didgeridoohan said:
You make some really nice little modules. I really believe you should submit them to the repo... It's gonna need some updating to the latest template and maybe also some updates for v12 though. From the v12 release notes:
Click to expand...
Click to collapse
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
Hm... Thank's for pointing that out. I'm not at all fluent enough in scripting to have caught that without some serious scrutiny, and I've not had the time for that today.
Perhaps we'll get an explanation from @laggardkernel about what's going on.
Didgeridoohan said:
Hm... Thank's for pointing that out. I'm not at all fluent enough in scripting to have caught that without some serious scrutiny, and I've not had the time for that today.
Perhaps we'll get an explanation from @laggardkernel about what's going on.
Click to expand...
Click to collapse
Best guess i can come up with is that stuff is left over from other experiments. He seems to be using the same repo for multiple projects and separating them with branches. That seems to have caused some cross contamination in his branches.
As a general development rule you should have one project/solution per repo. Your branches usually represent new features for the project.
Jman420 said:
Best guess i can come up with is that stuff is left over from other experiments. He seems to be using the same repo for multiple projects and separating them with branches. That seems to have caused some cross contamination in his branches.
As a general development rule you should have one project/solution per repo. Your branches usually represent new features for the project.
Click to expand...
Click to collapse
If you look in config.sh you'll see that the module isn't even using post-fs-data.sh (POSTFSDATA=false). And the files on GitHub doesn't match the files in the module zip. Look at update-binary in the zip and then on GitHub. In the zip you'll find the symlinking, but not on GitHub...
So yeah, I guess we're talking about a bunch of code left over from previous experiments.
Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
I took all of that setenforce stuff out of my script. And in my release notes it clearly stated when I release v1.2 that I added the script to AudModLib. However I removed it because I found a workaround in v1.3.
With Audmodlib we have only audio server media server, and system prop contextd permissible for ONLY system and priv apps. Which is what I had to replace with the setenforce stuff.
He's not doing anything shady when looking at the code, it looks like he was following my example. I would submit a git issue to tell him to update the mod.
Hope this clears things up man.
Jman420 said:
Gotta disagree with you here. This module is ALL OVER THE PLACE. The code in the startup scripts is doing TONS of unadvertised stuff:
There is code related to @ahrion Dolby Atmos (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L108) that will potentially put your device into Permissive Mode without telling you.
No idea what this code is doing, but certainly doesn't relate to init.d symlinks (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L93).
Appears to attempt to install a non-existent APK called '*.apk' with package name '*.*.*' (https://github.com/laggardkernel/magisk-module-template/blob/init.d/common/post-fs-data.sh#L68).
And that's all on every startup.
I would be careful with this module...
Click to expand...
Click to collapse
1. Look into the config.sh;
2. Post-fs-data.sh, service.sh are NOT enabled;
3. Post-fs-data.sh, service.sh will NOT be copied to your device.
4. I use a template with some additional features myself. Maybe I'm too laggard to clean up unused codes. But I'm sure I commented out, disabled all unnecessary parts.
laggardkernel said:
Maybe I'm too laggard to clean up unused codes.
Click to expand...
Click to collapse
Ha ha!
But yeah, like it shows, you're gonna scare some people leaving it in there.
True, you'll only get scared if you don't look at the entire thing, but still...
laggardkernel said:
Maybe I'm too laggard to clean up unused codes.
Click to expand...
Click to collapse
hehehe, i see what you did there.
laggardkernel said:
1. Look into the config.sh;
2. Post-fs-data.sh, service.sh are NOT enabled;
3. Post-fs-data.sh, service.sh will NOT be copied to your device.
4. I use a template with some additional features myself. Maybe I'm too laggard to clean up unused codes. But I'm sure I commented out, disabled all unnecessary parts.
Click to expand...
Click to collapse
Yeah, deeper review does show that those scripts aren't installed or used. But leaving them there makes reviewing the module much harder since you have to go looking for that 1 flag which indicates they aren't used. As a developer if I see code in a script I expect that it's meant to be executed and a reviewer won't necessarily know which piece is correct (the flag disabling the script or the script itself).
The module is definitely benign, but on a quick surface review the dead code seems strange in the context of the module itself. Just a suggestion, but cleaning up that dead code would make the module easier to review and avoid having that code get executed accidentally or misinterpreted.
Didgeridoohan said:
But yeah, like it shows, you're gonna scare some people leaving it in there.
True, you'll only get scared if you don't look at the entire thing, but still...
Click to expand...
Click to collapse
Even a full review would raise some concerns with me. Mainly which is correct; having the script disabled or enabled. That concern can only be addressed through a discussion like this. A full review would make me feel a bit more secure since the script isn't executed, but would make me question whether the full functionality of the module is actually in place.
@laggardkernel This is all good work, so I hope you don't take any of this the wrong way. I just happen to do development (more accurately software engineering) as a career and see this kind of stuff all over the place in enterprise software and it makes my eyes bleed every time I see it. Now that I've gotten into a cyber security role I'm even more sensitive to this stuff since they end up constituting security holes (either maliciously or accidentally, usually the latter).
Flash it from recovery, it say Error... because there is already has init.D folder ?
So i have to delete the folder first ?
Vuska said:
Flash it from recovery, it say Error... because there is already has init.D folder ?
So i have to delete the folder first ?
Click to expand...
Click to collapse
If you already have init.d support you don't need this module.
And if you want proper help, where's your recovery log?
Does this module already support Magisk 13.1?
Magisker said:
Does this module already support Magisk 13.1?
Click to expand...
Click to collapse
Not yet. I haven't migrated to v13+ and I'm still waiting for the update of the all-in-one wiki.
laggardkernel said:
Not yet. I haven't migrated to v13+ and I'm still waiting for the update of the all-in-one wiki.
Click to expand...
Click to collapse
The template v4 is already there tho
https://github.com/topjohnwu/magisk-module-template
magisk 14 does not mount magisk.img. It creates a different set up. There is no magisk folder at root containing post-fs-data.d and service.d folders. If they are not there in magisk 14, where are the scripts to be placed for running at boot. Anybody could help on this.
Android Runtime Optimization
DISCONTINUED lol
Android Lollipop includes a new virtual machine called ART (Android Runtime.) ART uses AOT (ahead-of-time) compilation into native code, which performs better than JIT (just-in-time) compilation into bytecode. You can configure ART to perform this optimization in different ways. Android Lollipop includes the dex2oat tool for optimizing applications on deployment.
Click to expand...
Click to collapse
Compiler Filters
Since Lollipop, dex2oat takes a variety of --compiler-filter options to control how it compiles. Passing in a compiler filter flag for a particular app specifies how it’s pre-optimized. Here’s a description of each available option:
everything - compiles almost everything, excluding class initializers and some rare methods that are too large to be represented by the compiler’s internal representation.
speed - compiles most methods and maximizes runtime performance, which is the default option. ** default value on this module
balanced - attempts to get the best performance return on compilation investment.
space - compiles a limited number of methods, prioritizing storage space.
interpret-only - skips all compilation and relies on the interpreter to run code.
verify-none - special option that skips verification and compilation, should be used only for trusted system code.
This module sets a few dalvik.vm and pm.dexopt properties:
Code:
dalvik.vm.dex2oat-filter [B]**editable with the given compiler filters[/B]
dalvik.vm.image-dex2oat-filter
pm.dexopt.bg-dexopt
dalvik.vm.check-dex-sum
dalvik.vm.checkjni
dalvik.vm.usejit
dalvik.vm.heaptargetutilization
dalvik.vm.dex2oat-threads
Magisk Module (UI in Terminal Emulator)
How to use:
Open Terminal Emulator
Type su and then
Code:
art_magisk
Then choose your filter
Non-Magisk (command line)
How to use:
Code:
ART Optimization by veez21
setfilter [--compiler-filter] [file]
compiler filters:
everything
speed
balanced
space
interpret-only
verify-none
Ex:
Code:
setfilter everything
** this will find the file on common/default directories
Code:
setfilter everything /system/su.d/name.sh
** this will use the directory you entered, instead of the defaults
MORE INFORMATION ON THIS TOPIC HERE and here
UNIFIED INSTALLER IS PRESENT SINCE v1. IT INSTALLS IN A SPECIFIED ORDER (look below) . SO IF YOU DON'T HAVE MAGISK, YOU CAN STILL FLASH THE ZIP IN THE DOWNLOADS!
Order of Detection during Installation:
Code:
> Magisk > Systemless SuperSU > System SuperSU > Init.d
AFTER FLASHING, FOR THE FIRST TIME, WIPE DALVIK/ART CACHE. THIS IS NEEDED FOR IT TO TAKE EFFECT. YOU DON'T HAVE TO WHEN UPDATING THOUGH
THAT'S WHY YOU HAVE TO CHANGE THE --compiler-filter IF YOU WANT MORE APP PERFORMANCE. speed BEING THE DEFAULT IN ROMS (IF THE DEV HAVEN'T CHANGED IT), YOU CAN CHANGE IT TO everything IF YOU WANT MORE PERFORMANCE (BUT COSTS MORE SPACE). IDEAL VALUE WOULD BE balanced IF YOU ASK ME.
** This module can have problems with heavily modified OEM Roms (e.g. TouchWiz, MIUI). YOU HAVE BEEN WARNED. But this problem is inconsistent and just might work for you.
Read this Samsung ROM users: https://forum.xda-developers.com/showpost.php?p=72401085&postcount=594 ** possibly fixed on v1.3+
MOD Edit Links Removed Download here[/URL] or at Magisk Manager ** install in recovery
README and Changelogs
Uninstaller
Crash Fix
Source
Source (Magisk Repo)
MOD Edit Links Removed
DONATE? If you want to (ﾉ･ω･)ﾉﾞ
F.A.Q.
How to see if the changes are applied?
See Magisk log. ART Optimizations should be able to log there
Do this command and search for the properties given at the first post and if it there, it's working
Code:
su
getprop | grep dalvik
Bootloop! Help me!
Uninstall the module! Uninstaller
When in Magisk, RIL doesn't work, some apps crash, HELP!
Try flashing the crash fix. It might/might not work
Xposed not responding properly! Help me!
Can't do anything about it. Try wiping dalvik-cache, if that doesn't work uninstall the module
I don't use Magisk. How to can I use this?
Flash the zip at the OP. It installs to System if Magisk is not detected
I had some kind of trouble when using everything filter. Solution?
Try changing to speed. Several users have some trouble with everything too.
SuperSU + Magisk + This module is causing bootloop/some kind of problem. What do I do?
Uninstall the Magisk Module and install Non-Magisk instead
So by default this module should increase the speed of apps?
Enviado desde mi Aquaris X5 Plus mediante Tapatalk
Gonfebo said:
So by default this module should increase the speed of apps?
Enviado desde mi Aquaris X5 Plus mediante Tapatalk
Click to expand...
Click to collapse
Theoratically, yes, at first boot. After flashing wipe Dalvik/ART cache and see. :good:
Any Uninstaller to uninstall it ?
Does it work with Magisk ?
Sent from my YU5010 using Tapatalk
amihir said:
Any Uninstaller to uninstall it ?
Does it work with Magisk ?
Click to expand...
Click to collapse
Works with magisk since it's a magisk module ?. You can uninstall it in Magisk Manager
UPDATE TO v0.2!
Changelog:
- post-fs-data.sh and service.sh is additionally used to set properties
- fixed setting dalvik.vm.image-dex2oat-filter
Download
This module isn't needed on Nougat am I correct?
An XDA User said:
This module isn't needed on Nougat am I correct?
Click to expand...
Click to collapse
It can be used in nougat. I don't know the result of using it in it but try testing it and tell me the results if there's any problem
veez21 said:
It can be used in nougat. I don't know the result of using it in it but try testing it and tell me the results if there's any problem
Click to expand...
Click to collapse
Working fine on Nougat here.
I have a feeling that Plex (my media player) is MUCH snappier. And no, it hans't been updated lately.
Everything working... but I can't point a finger at anything else besides Plex.
Cheers!
If just edit system.prop with
dalvik.vm.dex2oat-filter=interpret-only
dalvik.vm.image-dex2oat-filter=speed
it should be work?
Hello m8 o/
Can you provide more download links?
"SYSTEM NOTICE: We apologize for any issues loading the site. We are working on a solution right now. Thanks for the understanding."
"Invalid response from the server: 502"
So when i can download this file i 1. Flash it in Magisk? 2. Flash it in TWRP?
Tesla said:
Hello m8 o/
Can you provide more download links?
"SYSTEM NOTICE: We apologize for any issues loading the site. We are working on a solution right now. Thanks for the understanding."
"Invalid response from the server: 502"
So when i can download this file i 1. Flash it in Magisk? 2. Flash it in TWRP?
Click to expand...
Click to collapse
2.Flash in TWRP
According to the OP, the mod requires wiping delvik/cashe after flashing the mod to work.
JERW28 said:
2.Flash in TWRP
According to the OP, the mod requires wiping delvik/cashe after flashing the mod to work.
Click to expand...
Click to collapse
:good:
Download works at the moment.
Edit: My phone (Note 4) is really fast as it is, but initial testing shows a bit faster launch of camera app.
Sure, it might be placebo. Hard to know just yet
Umm...
No... You've got this backwards...
Apps would launch slower... Not quicker... As your first boot is quicker... At least with the flags mentioned at the top of the post...
If you're looking for what would be faster app launch... You'd want to use the 'everything' flag as it builds a much larger cache file...
Sent from my Nexus 6 using Tapatalk
Tesla said:
Hello m8 o/
So when i can download this file i 1. Flash it in Magisk? 2. Flash it in TWRP?
Click to expand...
Click to collapse
I just installed it normally as a Magisk module. And wiped cache and dalvik on first reboot.
alroger said:
I just installed it normally as a Magisk module. And wiped cache and dalvik on first reboot.
Click to expand...
Click to collapse
That was my thought also, but it so simple to ge straight to TWRP so.
Thanks for the development and module for Magisk.
The effect is contrary with a Note 7 (MM) ported for SM N9005.
Installation according to indications, the smartphone is slower when starting up another 20 seconds.
There is no problem or fc but identically android lag enormously.
Perhaps a problem with the management of the kernel, ram ... etc
I tried to modify the filters without success for me.
A little feedback.
Thank you
This module sounds very interesting, but i have one question that isnt so clear to me... Does it speed up the start of apps in general or is it just the first start of the system after wiping dalvik/cache?
Just the first start thus it's pretty useless IMO. Mind you, it'll make apps perform worse.
This project has been discontinued. The final state of the module can be found at the GitHub Repo https://github.com/Jman420/magisk_selinux_manager.
Magisk SELinux Manager
A Magisk Module dedicated to the manipulation and analysis of SELinux.
Features
* Select SELinux mode to set at startup
Usage
The SELinux mode to set at startup must be specified during module installation. The SELinux mode can be selected either by specifying the mode (permissive or enforcing) in the install zip's filename (ie. magisk_selinux_manager_v1.0_permissive.zip) or using your phone's volume keys when prompted.
Disclaimer & Recommendations regarding Permissive Mode
This module should be used to enable SELinux Permissive Mode only as a last resort only if appropriate SELinux Permissions can not be generated and injected into the SELinux Policy using selinux-inject, supolicy or magiskpolicy. Putting your device into Permissive Mode will essentially disable all of the operating system level security built into Android and allow any app in any context to do whatever it wants. Actions requiring root access will still trigger your SU Manager App, but all apps have elevated privileges due to permissive mode and may be able to take malicious actions on your device without needing root access. If you find that this module fixes issues you are experiencing with an app I recommend contacting the app developer and trying to work with them to isolate the necessary SELinux Permissions and have them injected into the SELinux Policy at startup.
Here is a discussion of some of concerns to consider when running your device in Permissive Mode : https://forum.xda-developers.com/gen...risks-t3607295
GitHub Repo : https://github.com/Jman420/magisk_selinux_manager
Requirements
* SELinux enabled kernel
* Magisk v15.3+
Change Log
* v1.0.5 - Update Unity Installer Files to v1.5.4
* v1.0.4 - Update Unity Installer Files to v1.5.3
* v1.0.3 - Update Unity Installer Files to v1.5.2
* v1.0.2 - Update Unity Installer Files to v1.4.1
* v1.0.1 - Update Unity Installer Files to v1.4
* v1.0.0 - Initial Release
Special thanks!
* topjohnwu - For providing Magisk and the interesting insights that its source code gave into SELinux
* ahrion & zackptg5 - For providing the Unity Installer and Vol Key Input code
* Everyone who supported the old magisk_permissive_script module and giving me a bit of motivation to keep working on SELinux stuff
Release Distribution Plans
All Releases are available on the Magisk Module Repo. Releases will not be distributed here.
Jman420 said:
Magisk SELinux Manager
A Magisk Module dedicated to the manipulation and analysis of SELinux.
Features
* Select SELinux mode to set at startup
Usage
The SELinux mode to set at startup must be specified during module installation. The SELinux mode can be selected either by specifying the mode (permissive or enforcing) in the install zip's filename (ie. magisk_selinux_manager_v1.0_permissive.zip) or using your phone's volume keys when prompted.
Disclaimer & Recommendations regarding Permissive Mode
This module should be used to enable SELinux Permissive Mode only as a last resort only if appropriate SELinux Permissions can not be generated and injected into the SELinux Policy using selinux-inject, supolicy or magiskpolicy. Putting your device into Permissive Mode will essentially disable all of the operating system level security built into Android and allow any app in any context to do whatever it wants. Actions requiring root access will still trigger your SU Manager App, but all apps have elevated privileges due to permissive mode and may be able to take malicious actions on your device without needing root access. If you find that this module fixes issues you are experiencing with an app I recommend contacting the app developer and trying to work with them to isolate the necessary SELinux Permissions and have them injected into the SELinux Policy at startup.
Here is a discussion of some of concerns to consider when running your device in Permissive Mode : https://forum.xda-developers.com/gen...risks-t3607295
GitHub Repo : https://github.com/Jman420/magisk_selinux_manager
Requirements
* SELinux enabled kernel
* Magisk v15.3+
Change Log
* v1.0 - Initial Release
Special thanks!
* topjohnwu - For providing Magisk and the interesting insights that its source code gave into SELinux
* ahrion & zackptg5 - For providing the Unity Installer and Vol Key Input code
* Everyone who supported the old magisk_permissive_script module and giving me a bit of motivation to keep working on SELinux stuff
Release Distribution Plans
I have submitted a request to include this module in the Magisk Repo List. Once that request has been accepted the Magisk Repo List will be the ONLY source for up to date releases of the module. Until that time I will provide download links through this posting.
Click to expand...
Click to collapse
What are the differences with this zip and the old one?
dredq said:
What are the differences with this zip and the old one?
Click to expand...
Click to collapse
When installing the module you can choose if SELinux should be set to enforcing or permissive (it's written right there in the OP).
Didgeridoohan said:
When installing the module you can choose if SELinux should be set to enforcing or permissive (it's written right there in the OP).
Click to expand...
Click to collapse
Sorry. I saw that. I was wondering if there where any other differences.
dredq said:
Sorry. I saw that. I was wondering if there where any other differences.
Click to expand...
Click to collapse
Nope, if there were I'd have mentioned them.
I installed the module and set it to permissive, but when I restarted my phone now it is stuck in the boot animation. I tried uninstalling using the magisk uninstaller, but still the problem remains. Is there a way to undo the changes from Recovery? Thank you! Running lineage 14.
samplebird said:
I installed the module and set it to permissive, but when I restarted my phone now it is stuck in the boot animation. I tried uninstalling using the magisk uninstaller, but still the problem remains. Is there a way to undo the changes from Recovery? Thank you! Running lineage 14.
Click to expand...
Click to collapse
You can flash the zip again to uninstall, thanks to Unity Installer... but I don't expect that to do anything different than the Magisk Uninstall. You may need to debug your Magisk installation with Magisk Manager for Recovery (https://forum.xda-developers.com/apps/magisk/module-tool-magisk-manager-recovery-mode-t3693165).
samplebird said:
I installed the module and set it to permissive, but when I restarted my phone now it is stuck in the boot animation. I tried uninstalling using the magisk uninstaller, but still the problem remains. Is there a way to undo the changes from Recovery? Thank you! Running lineage 14.
Click to expand...
Click to collapse
Did you try installing the module again and choosing enforcing instead of permissive?
Update v1.0.1 has been released on Magisk Repo. No real functionality updates, just updated Unity Installer to latest (v1.4). See change logs for Unity Installer here : https://forum.xda-developers.com/android/software/module-audio-modification-library-t3579612
I've also migrated to using Semantic Versioning for this project (although it's probably not needed). See details here : https://semver.org/
The module doesn't seem to be part of the magisk repo yet. But v1.0.0 us working fine on my side anyway. :good:
PixelChris95 said:
The module doesn't seem to be part of the magisk repo yet. But v1.0.0 us working fine on my side anyway. :good:
Click to expand...
Click to collapse
Clear the repo cache (Manager settings) and reload the Downloads list (pull down).
Didgeridoohan said:
Clear the repo cache (Manager settings) and reload the Downloads list (pull down).
Click to expand...
Click to collapse
That did the trick. Thx!
Not working on Oreo b390 Huawei P10. SeLinunx remains on enforce:
watch this issue:
https://forum.xda-developers.com/p10/help/magisk-16-0-p10-orea-t3765921
mxn2000 said:
Not working on Oreo b390 Huawei P10. SeLinunx remains on enforce:
watch this issue:
https://forum.xda-developers.com/p10/help/magisk-16-0-p10-orea-t3765921
Click to expand...
Click to collapse
"Preserve Forced Encryption" doesn't have anything to do with SELinux. That's /data encryption...
Try running:
Code:
setenforce permissive
And if that still doesn't work, run this and use whatever options are available, or return with the result:
Code:
setenforce --help
Every time I setenforce 1 it always says Permissive after .. Even after reboot or in the Twrp terminal .. Anytime I type grtenforce it always says Permissive. What do I type in terminal emulator to access this mod? Am I missing something here?? Lol sorry - still learning.
Intelli69 said:
Every time I setenforce 1 it always says Permissive after .. Even after reboot or in the Twrp terminal .. Anytime I type grtenforce it always says Permissive. What do I type in terminal emulator to access this mod? Am I missing something here?? Lol sorry - still learning.
Click to expand...
Click to collapse
You don't have to do anything after installing the module. At installation your choose enforcing or permissive, and then that's what the module will set at each boot.
OK I thought that was it! Thanks!
so should use this one or old version?
or it is still the same function?
does this work on samsung?
lawong said:
does this work on samsung?
Click to expand...
Click to collapse
Yup, as long as you have magisk.