-
-
Notifications
You must be signed in to change notification settings - Fork 333
Basics & FAQ
此页面为英文版，中文版点此查看
The predecessor of ZygiskNext is ZygiskOnKernelSU. The built-in purpose of this project was to run Zygisk in KernelSU in the form of a Magisk module, that is, the function of injecting code into the Zygote process (the process generating all App processes).
The main work direction of ZygiskNext now is to explore better ways to inject zygote and implement the injection of processes more than zygote.
The abbreviation of ZygiskNext. "ZN" is refering to ZygiskNext in the following text.
ZN. Please do not invent unrecognizable abbreviations such as "zy" and "zyg" when discussing or giving feedback.
- Root implementation
Currently, ZygiskNext can run on KernelSU, Magisk and APatch as a Magisk module. Magisk users need to disable the built-in Zygisk to use ZygiskNext.
It may be presented in a form other than the Magisk module in the future.
- Processor architecture
Running ZN requires arm64, x86_64 or armeabi-v7a architectures. Therefore, ZN can run on arm64, x64, arm32(armv7l, armv8l) real machines and emulators. 32-bit x86 is unsupported.
Zygisk function supports arm64/arm32/x64/x86, which means that it supports injecting code into 64-bit and 32-bit zygotes.
Some pure 64-bit systems that use translation to simulate 32-bit can also be supported. It is currently known that tango translator is supported.
Currently, its main use is to implement better Zygisk features in the three major root implementations (Magisk, KernelSU, APatch). Popular Zygisk modules include LSPosed, PIF, etc.
Since ZN 1.2.0, the Zygisk Next module has been added, which can modify more system processes.
As an independent module, ZygiskNext is more flexible than Zygisk, and the developers of ZygiskNext are still exploring better injection methods and developing new features (such as ZN Module. In addition, ZygiskNext is more concealed than the built-in Zygisk.
In order to run the "denylist" function consistent with the built-in Zygisk in magisk, ZygiskNext needs to know whether the current root implementation is Magisk, KernelSU or APatch, and get their "denylist" depend on circumstances.
As we all know, Magisk's denylist is in Magisk's denylist. (In settings of magisk)
Although Magisk's denylist is designed for Zygisk, Zygisk Next can read this denylist even if Zygisk is not enabled.
The official Magisk may need to temporarily turn on the Zygisk switch to enter the configuration page of the denylist, and then turn off the Zygisk switch after completing the configuration. Magisk Alpha can configure the denylist when Zygisk is not enabled.
Since some magic tricks are used to get the denylist more efficiently, ZN may not be able to correctly get the denylist in some unofficial versions that are quite different from the official Magisk.
In the configuration of KernelSU for App, the "Unmount Modules" switch is the switch whether the App is in the "denylist".
At the same time, KernelSU also has a switch called "Unmount Modules by Default". Turning it on means that all Apps, as long as they do not grant root permissions, are in the denylist by default; conversely, turning off the switch means that they are not in the denylist by default.
Similar to KernelSU.
It is consistent with the "enforce denylist" behavior of Magisk, that is, Apps in the "denylist" will not be loaded with the Zygisk module, and the Magisk module will be unmounted in its process to "remove the effects of the Magisk module".
However, in fact, many effects cannot be simply eliminated by these methods, so it is incorrect to regard this feature as "hiding root", it only exists to be consistent with Magisk implementation.
You can enable or disable it through WebUI. For KernelSU and APatch, the WebUI function is built into the manager. For Magisk, you can use KsuWebUI Standalone to access the module's WebUI.
You can also enable it in the root terminal using the command znctl enforce-denylist enabled and disable it using the command znctl enforce-denylist disabled .
As mentioned above, after enabling "Enforce the denylist", Apps in the "denylist" will not be loaded with any Zygisk modules, and Xposed modules that depend on Zygisk will not be loaded, too. You can remove apps that need to load modules from the "denylist", or for KernelSU users, please check whether "Unmount Modules by Default" is enabled. Enabling it will cause apps to be in the "denylist" by default unless you set it manually.
If you think or find that enabling it can achieve your purpose (such as the so-called "Hide Root"), you can enable it.
This means that ZygiskNext has found that your device has multiple root implementations installed, such as Magisk and KernelSU installed at the same time.
Since ZygiskNext cannot determine which root implementation you have, the "denylist" will not take effect.
I am a Magisk / APatch user. I clearly did not install KernelSU. Why are there still multiple root implementations?
Your kernel maintainer may have integrated KernelSU in the kernel. This is common in third-party ROMs. Please contact your kernel maintainer to get a kernel without KernelSU .
Since ZN 1.2.2, ZN detects the existence of KernelSU only if KernelSU is installed in both the kernel space and user space. The criterion for the installation of KernelSU in user space is the existence of the file /data/adb/ksud, that is, deleting this file will prevent ZN from recognizing KernelSU. Therefore, users who do not use KernelSU but get a kernel which has integrated KernelSU should not encounter the above problems as long as they make sure not to install the KernelSU manager.
Because you have installed multiple root implementations or ZygiskNext has not detected your Magisk (maybe you are using a third-party Magisk).
In order for ZN to run correctly on Magisk, users need to turn off Magisk's built-in Zygisk. Since Magisk's built-in Zygisk is turned off, the Zygisk module will no longer be loaded, not only will Zygisk lib not be loaded, but also files and application system.prop will not be mounted. Therefore, ZN uses some tricks to handle these tasks for Magisk, which are collectively called magisk compat.
This problem should not occur in newer versions. If you are a Magisk user, please check whether your Magisk environment is normal, if not, please follow the prompts to repair it(whether it prompts to repair the environment when you open the Magisk app}. If so and you do not have the above problems, please submit an issue.
It may be that the zygisk modules you installed caused the zygote crash and triggered the safe mode of ZygiskNext. Please disable them one by one for troubleshooting. If it is not a module problem, please submit an issue.
Please do not modify the files in the ZygiskNext module directory.
It means that "Enforce denylist" is enabled.
Translator: Steve ZMT, Zap