Zygisk Assistant: a Zygisk module for hiding root on KernelSU, Magisk and APatch

What Zygisk Assistant hides, and for whom

Zygisk Assistant addresses a narrow problem: an app on the device checks whether the phone is rooted or whether Zygisk is loaded, and refuses to run if either is found. The project describes itself as "a Zygisk module that aims to hide the existence root and Zygisk." The Android version floor is stated as 5.0 and above, which is unusually low for a module in this category and matters if you maintain older hardware.

The audience is people who already run a root solution. The README splits instructions into two groups: KernelSU and APatch users, and Magisk users. If you do not have one of those three installed, this module has nothing to attach to, because it is a Zygisk module rather than a standalone rooting tool. KernelSU and APatch users are told to install ZygiskNext first, which means the actual Zygisk provider is a separate project. Magisk users need Zygisk switched on in Magisk settings.

That dependency shapes what the module is. It is not a root manager, not a boot image patcher, and not a Play Integrity fix. It is a layer that sits inside an existing Zygisk environment and changes what a target app can observe. Users searching for a download of the zip, or for a Magisk module, are looking at the right project; users searching for an APK are not, because the distribution format here is a flashable module zip, not an app.

How the module fits between Zygisk and the target app

The mechanism follows from the Zygisk model. Zygisk injects code into every app process at fork time, before the app's own code starts. A Zygisk module therefore gets a chance to run inside the target process and adjust what that process sees. Zygisk Assistant uses that position to work on two fronts named in its own description: the presence of root and the presence of Zygisk itself.

The repository is structured as a Gradle project with a top-level build.gradle.kts, settings.gradle.kts, gradlew, and a module/ directory, plus update_metadata/ for release metadata. The primary language is C++, which is consistent with a module that does in-process work rather than a manager UI. The README does not document the internal hook list, the specific paths it hides, or how it interacts with mount namespaces, so any claim about which detection vectors it covers would go beyond what the project states.

What the README does make explicit is that the module expects the surrounding tools to be configured a certain way. KernelSU and APatch users must enable the option `Umount modules/Exclude modifications` for the target app, and must disable `Enforce DenyList` in ZygiskNext settings if that setting exists. Magisk users must turn off `Enforce DenyList` in Magisk settings and add the target app to the deny list, unless they use a Magisk fork with a whitelist instead. In other words, the module is designed to do the hiding itself, and the denylist features of the surrounding tools are meant to be off so they do not conflict with it.

Installing Zygisk Assistant and running a first check

The README does not give a step-by-step flash procedure, but it does specify the prerequisites and the configuration that must follow. The commands below cover the part the README is explicit about: getting the source and building the module zip with the Gradle wrapper that is checked into the repository. The README states that the release build is recommended over the debug build, so treat a debug build as something to use only when preparing a bug report.

git clone https://github.com/snake-4/Zygisk-Assistant.git
cd Zygisk-Assistant
./gradlew :module:assembleRelease

On Windows the repository also ships gradlew.bat, so the wrapper works from cmd or PowerShell as well. The output is a module zip under the module build directory; the README points users at the releases page for the published build, which is the path most people should take rather than building locally.

Once you have the zip, the surrounding setup depends on your root solution. For KernelSU and APatch, the README's order is: install ZygiskNext, then enable the exclude option for the target app, then disable Enforce DenyList in ZygiskNext settings if present. For Magisk, the order is: update Magisk to 27.0 or newer for better hiding (marked optional), turn on Zygisk in Magisk settings, turn off `Enforce DenyList`, and add the target app to the deny list unless you use a fork with a whitelist.

For a first real use, pick one app that currently detects root, apply the configuration for your root solution, then launch that app. If it still detects root, the README's own checklist points at the two settings people most often leave wrong: Enforce DenyList still on, or the target app not excluded from module unmounting.

Where Zygisk Assistant stops working

The most important limitation is written into the project's own one-line description. It aims to hide root and Zygisk. It does not claim to hide an unlocked bootloader, a custom kernel, or a failed hardware-backed attestation, and the README says nothing about Play Integrity verdicts or SafetyNet. Apps that rely on those signals rather than on a simple root check are outside the scope of what this module states it does.

A second limitation is the dependency chain. On KernelSU and APatch, ZygiskNext must be installed, and the module's behaviour depends on settings inside ZygiskNext. On Magisk, Zygisk must be enabled and Magisk 27.0 or newer is recommended for better hiding. That means a Zygisk Assistant bug report can easily turn out to be a misconfiguration in a different project, and the README's troubleshooting content is essentially a list of those settings.

The debug build is another trap. The README explicitly recommends the release build and says to use debug builds only for bug reports, which implies the debug build is not the one you want on a daily driver. Finally, the README does not document a rollback path for a module that misbehaves after flashing, so anyone installing it should already know how their root manager recovers from a bad module. If you want a single tool that handles both root hiding and integrity attestation, this project is not that tool, and the README never suggests it is.

Shamiko, ZygiskNext and the difference in approach

The comparison users ask about most is with Shamiko, and the search data around this project is full of it. Both are Zygisk-side hiding layers, and both expect the denylist enforcement of the host manager to be turned off. The practical difference visible in this repository is scope and configuration surface: Zygisk Assistant's README reduces setup to a short ordered list per root solution and states that it hides root and Zygisk, while Shamiko's configuration model is not described anywhere in this material, so a fair comparison of feature depth cannot be made from what the project itself documents.

ZygiskNext is a different kind of comparison, and the confusion is understandable because the two appear in the same instructions. ZygiskNext is the Zygisk implementation for KernelSU and APatch; Zygisk Assistant is a module that runs inside it. They are not alternatives. Installing one does not replace the other, and the README's KernelSU and APatch steps require both, in that order.

The third comparison, against Zygisk itself, is a category error for the same reason. Zygisk is the injection framework that Magisk provides and that ZygiskNext reimplements; Zygisk Assistant is a consumer of that framework. If you are choosing between them, you have misread the dependency graph.

Maintenance, licensing and what an upgrade costs you

The repository is not archived, and the last push was on 2026-05-04. The most recent tagged release listed is v2.1.4 from 2025-02-23, preceded by v2.1.3 on 2024-08-17 and v2.1.2 on 2024-08-03. The gap between the last release and the last push is worth noting: commits have continued after the most recent tag, so anyone pinning to v2.1.4 is not running the current state of the main branch. The README does not describe a release cadence or a support window, and it does not document an upgrade procedure beyond installing a newer module zip through the manager.

The practical upgrade cost is low in one sense and awkward in another. Because the module has no user-facing configuration of its own, upgrading means replacing the zip and rebooting; there are no settings to migrate. The awkward part is that its behaviour depends on ZygiskNext settings, Magisk version and the exclude option in the KernelSU or APatch manager, so a change in any of those can alter results even when Zygisk Assistant itself is unchanged. A Magisk update to 27.0 or newer is described as optional but recommended for better hiding, which means the surrounding stack is expected to move.

The licence is MIT, as stated in the README and the LICENSE file. MIT permits use, modification and redistribution with the licence and copyright notice retained, which is permissive enough that forks are expected; the search data shows people looking for forks already. This is not legal advice, and anyone redistributing a modified module should read the LICENSE file in the repository rather than rely on a summary.

Editorial conclusion

Zygisk Assistant fits users already running KernelSU, APatch or Magisk 27.0 or newer who need root hidden from a specific app and are willing to change their manager's denylist settings. It is the wrong choice for anyone who wants bootloader-level or hardware attestation bypass, since the README only claims to hide root and Zygisk, not to defeat Play Integrity. Before installing, check that ZygiskNext or Magisk Zygisk is present, confirm the release build rather than the debug build, and verify that Enforce DenyList is off and the target app is excluded from module unmounting.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. snake-4/Zygisk-Assistant on GitHub