Related
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 ,
Deprecated - Use the New ViPER4Android v2.7:
GO TO THE THREAD LINKED ABOVE. You don't need to flash any zips. Just install it as a regular apk, allow it to install the drivers, and you're good to go.
For magisk users: I made a zip on the repo that includes the original vdc's and my profile converter (will convert your old profiles to the new and better format).
For rootless users: I made a zip to install drivers and such
Zips can be found here
ALL SUPPORT QUESTIONS FOR 2.7 SHOULD BE AT THE THREAD ABOVE.
This is ViPER4Android FX and Xhifi Unity installers
These installers utilize my Unified installer that can install on Magisk OR System if Magisk is not detected (with Pixel support).
Credits of Originality:
- @zhuhang (Official Thread)
- @Osm0sis
- Viper's Audio (Official blog)
- @ViPER520
- @Team_DeWitt
Special Instructions:
If you already know which original v4a you want to use, just add 'old' for 2.3.4.0, 'mid' for 2.4.0.1, 'new' for 2.5.0.5, or 'mat' for material to the zipname prior to flashing.
If you already know if you want it installed as a user or system app, add "uapp" for user app or "sapp" to system app to zipname.
If you already know if you want to apply the libstdc++.so lib workaround, add "lib" or "nlib" to zipname (note that there are some devices that are already known to require it and so they'll apply workaround regardless of choice)
If you already know if your device/rom requires the v4a open/close/fc audioserver workaround, add "ocw" to zipname. Otherwise, add "nocw" to zipname
To skip volkeys (if your device isn't compatible with them), add "novk" to the zipname. Note that if you don't specify the above, defaults will be applied which are: sapp, new
Make sure there are no spaces in the zipname
Audio Mod Troubleshooting Guide
Downloads
XDA:DevDB Information
ViPER4Android FX Legacy/XHiFI [Unity], App for the XDA Community Apps
Contributors
ahrion, Zackptg5
Version Information
Status: Stable
Current Stable Version: v4.4
Stable Release Date: 2019-08-11
Created 2019-01-18
Last Updated 2020-01-01
great!
Hi, tried your two modules you've posted on my Nexus 6P stock ROM. March update. Both causing bootloop and using the uninstaller provided doesn't help. Have to use mount Magisk then go to file explorer in TWRP recovery and delete the modules from Magisk folder.
kartikb said:
Hi, tried your two modules you've posted on my Nexus 6P stock ROM. March update. Both causing bootloop and using the uninstaller provided doesn't help. Have to use mount Magisk then go to file explorer in TWRP recovery and delete the modules from Magisk folder.
Click to expand...
Click to collapse
Hmm. This is probably a kernel or magisk limitation with your rom. Are you running 11.6? Try to run it without the deep_buffer Remover because this is probably what bootloops your phone. It's only necessary when you've NEED it, otherwise it may cause adverse effects. Just install V4A and see if it works.
Currently magisk still has limited boot.img compatibility which causes so.e mods to not work properly or bootloops when it's not the mod itself.
ahrion said:
Hmm. This is probably a kernel or magisk limitation with your rom. Are you running 11.6? Try to run it without the deep_buffer Remover because this is probably what bootloops your phone. It's only necessary when you've NEED it, otherwise it may cause adverse effects. Just install V4A and see if it works.
Currently magisk still has limited boot.img compatibility which causes so.e mods to not work properly or bootloops when it's not the mod itself.
Click to expand...
Click to collapse
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
kartikb said:
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
Click to expand...
Click to collapse
Magisk limitation. @topjohnwu is always improving magisk. I do recommend may e trying another kernel for your device which may help compatibility.
Gave this module a go, and: it's a no go... Will not boot on my Nexus 6 running Vanilla ROM 7.1.1_r26, Franco Kernel r65 and Magisk v.11.6 - MagiskSU.
After flashing uninstaller the device still doesn't boot. Had to manually remove audmodlib from /magisk in TWRP to make it boot again. And it's in audmodlib the problem is. I did a quick test where I removed audmodlib after installation (kept v4afx in place) and it booted right up (with a non-functioning module, obviously).
Attaching installation and uninstallation recovery logs. Unfortunately I'm not at a computer with ADB, otherwise I would have captured a logcat of boot for you. Maybe later...
Didgeridoohan said:
Gave this module a go, and: it's a no go... Will not boot on my Nexus 6 running Vanilla ROM 7.1.1_r26, Franco Kernel r65 and Magisk v.11.6 - MagiskSU.
After flashing uninstaller the device still doesn't boot. Had to manually remove audmodlib from /magisk in TWRP to make it boot again. And it's in audmodlib the problem is. I did a quick test where I removed audmodlib after installation (kept v4afx in place) and it booted right up (with a non-functioning module, obviously).
Attaching installation and uninstallation recovery logs. Unfortunately I'm not at a computer with ADB, otherwise I would have captured a logcat of boot for you. Maybe later...
Click to expand...
Click to collapse
The only real thing in audmodlib is could be is service.sh or system.prop otherwise it would be the vendor file, which would mean that for some reason 11.6 is bugged for vendor file mounting. Try installing and remove those ONLY and and see if it fixes it.
If that fixes it then it's one of those two. And if you're cool can you see which one it is exactly.
ahrion said:
The only real thing in audmodlib is could be is service.sh or system.prop otherwise it would be the vendor file, which would mean that for some reason 11.6 is bugged for vendor file mounting. Try installing and remove those ONLY and and see if it fixes it.
If that fixes it then it's one of those two. And if you're cool can you see which one it is exactly.
Click to expand...
Click to collapse
There has been an issue with vendor mounting in Magisk, but I believe that was for devices with separate vendor partitions (Nexus 6P, Nexus 5X, etc). I haven't seen any commits on GitHub about it though (although I haven't been keeping that close attention), so I don't know if it's been fixed.
I did find the culprit though: it's system.prop. With that file removed from /magisk/audmodlib my device booted up just fine.
kartikb said:
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
Click to expand...
Click to collapse
If you wanna try this is my module for Nexus phones. I use this in my Nexus 5X Stock and PureNexus
https://www.androidfilehost.com/?fid=529152257862713260
Sry ahrion for use your thread
Seyaru said:
If you wanna try this is my module for Nexus phones. I use this in my Nexus 5X Stock and PureNexus
https://www.androidfilehost.com/?fid=529152257862713260
Sry ahrion for use your thread
Click to expand...
Click to collapse
You are literally advertising your mods in everyone's threads. Stop this and make your own thread.
This is a magisk forum, not a system mod forum.
Didgeridoohan said:
There has been an issue with vendor mounting in Magisk, but I believe that was for devices with separate vendor partitions (Nexus 6P, Nexus 5X, etc). I haven't seen any commits on GitHub about it though (although I haven't been keeping that close attention), so I don't know if it's been fixed.
I did find the culprit though: it's system.prop. With that file removed from /magisk/audmodlib my device booted up just fine.
Click to expand...
Click to collapse
I will remove it with next release. Thank you man. This **** only started happening with 11.6. this was the reason Atmos was boot looping as well so I removed system.prop in Atmos.
Can you do me a favor and remove a few lines to see if it's just the specific lines? I think that certain lines don't play nice with your phone.
Remove the first part, low power audio tweaks, reboot and see if it works. If it doesn't then that's the culprit. If not then remove the first two on the other audio tweaks.
Seyaru said:
If you wanna try this is my module for Nexus phones. I use this in my Nexus 5X Stock and PureNexus
https://www.androidfilehost.com/?fid=529152257862713260
Sry ahrion for use your thread
Click to expand...
Click to collapse
Hi there, thanks for the suggestion. I've tried it already and it didn't work. Asked for drivers to be installed when I opened the app after installing the module and restarting the phone.
kartikb said:
Hi there, thanks for the suggestion. I've tried it already and it didn't work. Asked for drivers to be installed when I opened the app after installing the module and restarting the phone.
Click to expand...
Click to collapse
Enable permissive.
Turn off audiofx
ahrion said:
Enable permissive.
Turn off audiofx
Click to expand...
Click to collapse
I'll try again when I get a chance to. Thanks for the suggestion.
[UPDATED] ViPER4Android FX <2.5.0.5>
v1.1:
- Updated to Audio Modification Library (Magisk) v1.1
This should fix the boot loop issues seen in only Magisk v11.6
Download: Link - Mirror
Previous Changelogs (Unified installer):
HTML:
V1.0:
- Initial release
- Smali edits to automatically enable storage permissions
- Audio Modification Library v1.0 is included
- Unified installer that will install mod for both Magisk and System
- Pixel support included
- Magisk Template v3 support
kartikb said:
Hi, I'm on 11.6. I've tried both modules on their own and they both have caused boot loops unfortunately.
Thanks anyway..
Click to expand...
Click to collapse
Didgeridoohan said:
There has been an issue with vendor mounting in Magisk, but I believe that was for devices with separate vendor partitions (Nexus 6P, Nexus 5X, etc). I haven't seen any commits on GitHub about it though (although I haven't been keeping that close attention), so I don't know if it's been fixed.
I did find the culprit though: it's system.prop. With that file removed from /magisk/audmodlib my device booted up just fine.
Click to expand...
Click to collapse
Try 1.1.
ahrion said:
Try 1.1.
Click to expand...
Click to collapse
Thanks, I'll give it another go and report back.
Update: my phone reboots into Android fine now however it doesn't process audio on phone speaker.
kartikb said:
Thanks, I'll give it another go and report back.
Update: my phone reboots into Android fine now however it doesn't process audio on phone speaker.
Click to expand...
Click to collapse
Flash my deep buffer remover. Look in the magisk forum.
ahrion said:
Flash my deep buffer remover. Look in the magisk forum.
Click to expand...
Click to collapse
Thanks, it all finally works on my Nexus 6P. Now to try on my OnePlus 3..
PetNoire's SafetyNet Spoofer
This module tries to pass SafetyNet on devices/roms that don't.
This started when i put LineageOS on my phone and couldn't play Pokemon GO anymore. much sadness was had.
i searched around for a fix and found universal-safetynet-fix. Awesome! it let me play pokemon again but it broke everything else root related while it was enabled.
So, i worked on updating it to be compatible with magisk 17. and i got it! (download at the bottom)
but, well.. there was a lot in that code that didn't need to be there anymore. (does anyone even use magisk 12?!)
and worse still, my phones stock image used a thumbprint, not a fingerprint. with it in usnf, it didnt even pass basic integrity!
so i got to work and PetNoire's SafetyNet Spoofer was born!
Disclaimer:
I am not responsible for bricked devices, dead SD cards,
thermonuclear war, or you getting fired because the alarm app failed.
I also do not support hacking/altering any other apps with your root powers.
i made this purely to legitimately play a game on a customized system.
Information
Features:
Resets system props to a factory state
spoofs the device fingerprint or thumbprint
has a friendly command tool to change finger/thumbprint settings
Use:
Flash it with TWRP or MM.
by default, it spoofs the same device that unsf did which is enough for most uses. Congrats, you're done!
you can also use the pnss command as root to change, reset, or disable the fingerprint spoofing.
run the 'pnss' command from terminal for usage information
example command:
Code:
su
pnss set thumb MyDeviceThumbprint/8.1/etc/etc
Requeriments
Magisk v17
Installation
Flash the .ZIP from TWRP or MM Module page
Reboot
Known issues
thumbprint mode is only passing BasicIntegrity, not CTS
Donations
If you feel I helped you, you can buy me a coffee here
Credits
@Deic - the original creator of universal-safetynet-fix here
@PetNoire - porting it to magisk 17, breaking it further, and adding thumbprint support
Download
Please DO NOT share the module itself or the download link, share the thread only.
vv
@PetNoire May I ask a favour (as I've done to other users that hav updated @Deic's module to the current template in the past)? If you're going to re-release the module with the current template, at least please fix it so that it no longer replaces Magisk's internal Busybox with it's own. Really bad practice and we never did get @Deic to fix that before he disappeared...
If you need a specific module Busybox, place it in the module folder instead and call the commands from there, or make sure that the users know that they have to install @osm0sis Busybox, or if you're really in a pinch just use the internal Magisk Busybox then, but at least don't replace it with one that have the possibility to mess up Magisk's internal functions.
Also, it would be a good idea if you gave @Deic a bit more credit than you're doing right now (a tiny, tiny link at the top of your post just isn't enough), no matter that he's MIA. All you've really done is to transfer his module to the current template and added a check for the current Magisk version and it's paths. I'd suggest you make that more apparent so you don't risk being accused of passing someone else's work off as your own.
Didgeridoohan said:
@PetNoire May I ask a favour (as I've done to other users that hav updated @Deic's module to the current template in the past)? If you're going to re-release the module with the current template, at least please fix it so that it no longer replaces Magisk's internal Busybox with it's own. Really bad practice and we never did get @Deic to fix that before he disappeared...
If you need a specific module Busybox, place it in the module folder instead and call the commands from there, or make sure that the users know that they have to install @osm0sis Busybox, or if you're really in a pinch just use the internal Magisk Busybox then, but at least don't replace it with one that have the possibility to mess up Magisk's internal functions.
Also, it would be a good idea if you gave @Deic a bit more credit than you're doing right now (a tiny, tiny link at the top of your post just isn't enough), no matter that he's MIA. All you've really done is to transfer his module to the current template and added a check for the current Magisk version and it's paths. I'd suggest you make that more apparent so you don't risk being accused of passing someone else's work off as your own.
Click to expand...
Click to collapse
Thanks for the tip on busybox. I thought it was pretty weird that it replaced it like that for 2 commands but was more concerned about getting it to work at all. I'll look into fixing that soon.
update: i think i almost have it working on magisk's busybox but still working out some bugs.
And I'll edit it to give him some more credit right away.
PetNoire said:
Thanks for the tip on busybox. I thought it was pretty weird that it replaced it like that for 2 commands but was more concerned about getting it to work at all. I'll look into fixing that soon.
Click to expand...
Click to collapse
That would be great.
I thought I'd give some insight into what the module actually does, for those that are wondering, since it might get lost in translation between the different updates to the module by others than @Deic.
The USNF module is made up of two parts. For one, it changes the device fingerprint to a certified one to pass the ctsProfile check (the in-built one is a Xiaomi print, but IIRC you can also use the device stock fingerprint if it's already certified). This is also something that can be done with a Magisk boot script (post-fs-data.d or service.d) and the resetprop tool:
Code:
resetprop ro.build.fingerprint <certified fingerprint value>
There are also Magisk modules available that do the same thing (apart from USNF).
Device Spoofing Tool by @Dreamer(3MF) is one (although it also changes a whole lot of other props to simulate a OnePlus 2).
And there's also my MagiskHide Props Config that changes the build fingerprint to one of your choice.
Or, if you don't care about the systemlessness, you can directly edit your build.prop file and change the current ro.build.fingerprint to a certified one.
So, for the device fingerprint and passing the ctsProfile there are a few options.
The second part of USNF is the custom MagiskHide (as described in the OP). The thing here though, is that for the majority of devices it is not necessary anymore, since (as it also says in the OP) @topjohnwu have fixed most of those issues. From what it seems, from user reports in different threads, this is only necessary on some MIUI releases (Xiaomi devices). The module actually started out as a "Xiaomi SafetyNet fix" (check the module id), but the build fingerprint part turned out to be useful for other devices, so @Deic changed the name to "Universal". All other devices should be good with only changing the device fingerprint.
So far, it doesn't seem like the custom MagiskHide from the module is interfering in any way with the real thing. But, considering that it hasn't been updated in over a year, who knows.
Class dismissed.
Is there any reason to keep the code for old magisk? Does anyone still use 12-14?
Seems to have helped on my S8 with KingROM
My Magisk updated to 17.1 and then GooglePay started getting upset that I had rooted, mucked around with various things including the 'MagiskHide Props Config' module which my S8 never seems happy with (random reboots when installed) but this seems to do the trick.
I installed via Magisk Manager but it seemed to kill the Magisk install when I rebooted, reinstalled Magisk and now all seems ok so a big thumbs up from me
I wonder how the magiskhide part (at least the "add", etc. scripts) can work, because you use the old outdated "/magisk"-folder, that is no longer supported since 16.3 (or so).
Oberth said:
My Magisk updated to 17.1 and then GooglePay started getting upset that I had rooted, mucked around with various things including the 'MagiskHide Props Config' module which my S8 never seems happy with (random reboots when installed) but this seems to do the trick.
I installed via Magisk Manager but it seemed to kill the Magisk install when I rebooted, reinstalled Magisk and now all seems ok so a big thumbs up from me
Click to expand...
Click to collapse
For some reason it doesn't always work the first time. Usually just rebooting fixes it.
jenslody said:
I wonder how the magiskhide part (at least the "add", etc. scripts) can work, because you use the old outdated "/magisk"-folder, that is no longer supported since 16.3 (or so).
Click to expand...
Click to collapse
I thought I changed it all. You sure there isnt some kind of version check? I'll look at it later
Again first goal was to get it working. Next goal is to make it awesome
Hmm.. this doesn't work with my phone (HTC one M8). After I flashed it, wiped cache (TWRP), it said "complete" on the log, then it will never boot to my OS, stuck on the HTC logo, no boot animation. I use TWRP
winzzzzz said:
Hmm.. this doesn't work with my phone (HTC one M8). After I flashed it, wiped cache (TWRP), it said "complete" on the log, then it will never boot to my OS, stuck on the HTC logo, no boot animation. I use TWRP
Click to expand...
Click to collapse
In-Case Of Facing A Bootloop/Bootscreen Issue Due To Flashing A Module, Download CoreOnlyMode4Magisk From This Thread https://forum.xda-developers.com/apps/magisk/module-core-mode-bootloop-solver-modules-t3817366 Then Flash It Thru TWRP Recovery.
winzzzzz said:
Hmm.. this doesn't work with my phone (HTC one M8). After I flashed it, wiped cache (TWRP), it said "complete" on the log, then it will never boot to my OS, stuck on the HTC logo, no boot animation. I use TWRP
Click to expand...
Click to collapse
Does it boot after disabling the module?
From twrp>advanced>terminal:
HTML:
Mount -o loop /data/adb/magisk.img /mnt
Touch /mnt/universal-safetynet-fix/disable
The reboot
so.. i kind of deleted the whole magiskhide clone from the module and just left the prop configs and its totally passing safetynet now. so i guess the normal magiskhide is enough and is just missing some prop resets.
@PetNoire I still failed to pass safetynet, When I flashed the module, my magisk was erased, but then I just saw from this thread that a reboot is needed. After reboot my magisk came back, but It' says "Requires Additional Setup" I ignore it and then checked if safetynet will pass, It failed.
I'm using stock CM FLARE S4 ROM android 5.1.
Sorry for my English.
Thankyou for the reviving this module. :good:
Godbless you.
PetNoire said:
so.. i kind of deleted the whole magiskhide clone from the module and just left the prop configs and its totally passing safetynet now. so i guess the normal magiskhide is enough and is just missing some prop resets.
Click to expand...
Click to collapse
That was kind of the point of my longish text above... All you need to pass on a device that doesn't fully pass SafetyNet (ctsProfile fails while basicIntegrity passes), is usually just to change ro.build.fingerprint to a certified fingerprint (and there are several ways to go about that, but the Magisk way always involves the resetprop tool somehow). Custom ROMs, developer versions of OEM firmwares (Oneplus 6 beta, for example), and otherwise uncertified devices can usually pass SafetyNet like this.
Didgeridoohan said:
That was kind of the point of my longish text above... All you need to pass on a device that doesn't fully pass SafetyNet (ctsProfile fails while basicIntegrity passes), is usually just to change ro.build.fingerprint to a certified fingerprint (and there are several ways to go about that, but the Magisk way always involves the resetprop tool somehow). Custom ROMs, developer versions of OEM firmwares (Oneplus 6 beta, for example), and otherwise uncertified devices can usually pass SafetyNet like this.
Click to expand...
Click to collapse
This was just the first one that gave me any success so I initially assumed it was because of the hiding. I wasn't even able to pass basic integrity without this one and most others didn't help either. I tries yours at one point with no success. Do you change all the "dangerous props" that this one does?
PetNoire said:
This was just the first one that gave me any success so I initially assumed it was because of the hiding. I wasn't even able to pass basic integrity without this one and most others didn't help either
Click to expand...
Click to collapse
Basic integrity passing has nothing to do with the device fingerprint or other props. With Magisk, that usually means that MagiskHide isn't working (for whatever reason, most of the times it just needs a restart) or you have something installed that MagiskHide can't hide (like Xposed, remnants of other kinds of root, etc).
Edit: Scroll down a little here for a table of examples of what will cause a true or false cts profile or basic integrity response.
https://developer.android.com/training/safetynet/attestation#compat-check-response
iamcurseal said:
@PetNoire I still failed to pass safetynet, When I flashed the module, my magisk was erased, but then I just saw from this thread that a reboot is needed. After reboot my magisk came back, but It' says "Requires Additional Setup" I ignore it and then checked if safetynet will pass, It failed.
I'm using stock CM FLARE S4 ROM android 5.1.
Sorry for my English.
Thankyou for the reviving this module. :good:
Godbless you.
Click to expand...
Click to collapse
I don't know what Tue additional setup does, but I always do it and its been working. Also your device may have thumbprint props instead of fingerprint.
Run this in a terminal and let me know what you get
Code:
getprop | grep print
PetNoire said:
I tries yours at one point with no success. Do you change all the "dangerous props" that this one does?
Click to expand...
Click to collapse
My module changes all the common fingerprint props, but as far as I know, it's only ro.build.fingerprint that is important for the ctsProfile check.
Didgeridoohan said:
Basic integrity passing has nothing to do with the device fingerprint or other props. With Magisk, that usually means that MagiskHide isn't working (for whatever reason, most of the times it just needs a restart) or you have something installed that MagiskHide can't hide (like Xposed, remnants of other kinds of root, etc).
Edit: Scroll down a little here for a table of examples of what will cause a true or false cts profile or basic integrity response.
https://developer.android.com/training/safetynet/attestation#compat-check-response
Click to expand...
Click to collapse
I wiped all partitions, installed lineage 15, installed magisk and enabled hide and it wouldn't pass basic at any point. Even still its never passed it without this module. It didn't even pass it on the clean install, before magisk
I am hoping that someone can help me. I have had an LG V40 with Android 9, Magisk, TWRP, and some Xposed Mods. At first all seemed fine in all respects. Then I noticed that the date/time in TWRP was not correct at all (2018 instead of 2020, etc). But I am 100% sure that at some point in the recent past it was correct (or at least close enough for me not to notice). So I am looking for the cause of this and how to fix it.
I noticed here that TWRP has some special code (cannot claim to fully understand it) that processes date/time differently on Qualcomm 800 series chips - which my phone has. In looking around at the code, I see that it is looking at ats* files so I have gone looking for them on my device. I find them in several places (nothing is ever easy):
/mnt/vendor/persist/time
/sbin/.magisk/mirror/data/vendor/time
/sbin/.magisk/mirror/persist/time
/data/vendor/time
In /mnt/vendor/persist/time I see:
ats_12 with modify at 2/9/2018 @ 10:39am
ats_13 with same
ats_15 with same
ats_16 with same
In /sbin/.magisk/mirror/persist/time I see the same as above.
in/sbin/.magisk/mirror/data/vendor/time I see:
ats_1 with modify at 5/1/2020 @ 6:09pm
ats_2 with same
ats_12 with modify at 5/13/2020 @ 11:49am
ats_13 with same
ats_15 with modify at 5/13/2020 @ 10:49am
ats_16 with same
And in /data/vendor/time I see the same as above.
What I am not understanding here is if these multiple sets are the result of Magisk and, if so, which are/were "original" and which are "mirrors" and in general what is Magisk doing with all this? I read here, under the heading MagicMount, that Magisk is doing things with /system and possibly with /vendor and /product. So I cannot really explain to myself what I am seeing here or why it is happening.
I apologize for the length of this and for veering off into TWRP a bit. But it is the only way I can describe my situation and conundrum.
I also have no idea how TWRP interacts with Magisk - if at all and how that might play into the date/time problems I am facing.
So thanks for your patience and help.
The files in the mirror directories are used by Magisk for Modules (magic mounting) and MagiskHide.
I'm guessing you found those files while booted up and not in TWRP. Thing is that those Magisk mirror directories won't be there when you boot into TWRP (they're mounted by Magisk during a normal boot) and thus they can't have any effect on what you are describing.
Magisk does not load at all when you boot to TWRP.
Didgeridoohan said:
The files in the mirror directories are used by Magisk for Modules (magic mounting) and MagiskHide.
I'm guessing you found those files while booted up and not in TWRP. Thing is that those Magisk mirror directories won't be there when you boot into TWRP (they're mounted by Magisk during a normal boot) and thus they can't have any effect on what you are describing.
Magisk does not load at all when you boot to TWRP.
Click to expand...
Click to collapse
Thanks for the help. You are correct, I was looking while booted into the system.
Do you happen to know if, while Magisk is doing the mirroring and merging, it fiddles any folder/file permissions/ownerships? Or should these remain identical to the "originals"? Cheers!
Hi,
I've installed Magisk Manager 23014 and flashed the latest canary build.
When I go to settings and enable Zygisk it keeps perpetually telling me to "Reboot to apply changes", of course, I did but Zygisk remains disabled.
I'm on a Note 9, running DevBase v7.4 based on the S9FUH1 rom (Android 10)
Are you entirely sure that you have the 23014 Magisk binaries installed, and not just the app? This is the kind of behaviour we've seen when there's a mismatch between app and binaries versions.
What is the version info displayed in the Magisk app?
The Magisk version is: 7e9d4512 (23014)
Magisk App: 7e9d4512 (23014)
I just tried a full uninstall of the old Magisk install and then a fresh install of canary to make sure no previously installed modules could interfere, but no change unfortunately.
I'm also not seeing any errors in the log viewer of the magisk app
Could you post those logs?
Didgeridoohan said:
Could you post those logs?
Click to expand...
Click to collapse
Sure, please find the /cache/magisk.log and one saved from within Magisk Manager attached
So I run into the same problem. As I can't see anything useful in the magisk logs, I figured I'd check the dmesg.
This is one line that kind of triggers me, but I can't tell if it's significant:
Code:
[ 8.879227] init: Command 'start zygote_secondary' action=persist.sys.zygote.early=true (/init.rc:2197) took 0ms and failed: service zygote_secondary not found
This is on a Samsung J600fn.
Not sure if it makes a difference, but after disabling verity and encryption (either could be the culprit) it worked for me.
I had the same issue on my note 9. Disabling verity and encryption worked for me too as per FreakyJoosts post.
I used this (flashed via TWRP): https://mega.nz/file/6YszWYoB#dAQcttv6AvFK6HxY2oVuaGy-iouRG9uR77AnbXOqcWM
Which I got from this guide:
[Guide] Root Note 9 (Exynos) Android 10 (Q) With/Out Custom Recovery
How to Root Note 9 with Magisk on Android 10 (Q) without Custom Recovery (Eg.. TWRP) This method will work with most of the latest Samsung devices running Android 9/10. (Tested and Working on Galaxy Note 9 (Exynos) with Android 10 Q). WARNINGS...
forum.xda-developers.com
FreakyJoost said:
So I run into the same problem. As I can't see anything useful in the magisk logs, I figured I'd check the dmesg.
This is one line that kind of triggers me, but I can't tell if it's significant:
Code:
[ 8.879227] init: Command 'start zygote_secondary' action=persist.sys.zygote.early=true (/init.rc:2197) took 0ms and failed: service zygote_secondary not found
This is on a Samsung J600fn.
Click to expand...
Click to collapse
You may be right. But why don't you post it to GitHub before the stable release?
Anyway, try this build:
yujincheng08 said:
You may be right. But why don't you post it to GitHub before the stable release?
Anyway, try this build:
Click to expand...
Click to collapse
I found the problem on this forum.. not github. Also this thread didn't mention a github issue this would be linked to.
As for trying the other build. I already have it fixed. As mentioned before, I disabled encryption and verity.
Maybe @Adrixan can still try?
FreakyJoost said:
I found the problem on this forum.. not github. Also this thread didn't mention a github issue this would be linked to.
As for trying the other build. I already have it fixed. As mentioned before, I disabled encryption and verity.
Maybe @Adrixan can still try?
Click to expand...
Click to collapse
you can open a new issue on github at any time though.
Anyway, disabling encryption is not a gentle fix. You can try to re-enable the encryption for the try.
Today I faced the same problem. I had encryption off already but flashed so I figured that one of my modules causes this. So basicly just remove all old modules to enable Zygisk. Probably some outdated module blocks Zygisk.
I finally found a solution guys if your zygisk is not enabling even if you enable and you reboot or you install a GSI like pixel experience/pixel experience plus etc it has a solution
1: you have to be rooted
2: enable zygisk
3: download and flash pixel launcher mod here you can download it from a telegram link : Mod edit: Inactive TG link removed.
Install and flash and check zygisk should be enabled if it’s still not enabling send me logs