ReZygisk: a C rewrite of Zygisk Next that you can actually read

Why the fork exists: closed-source releases upstream

ReZygisk is a fork of Zygisk Next, and the reason is stated plainly in the README: the latest Zygisk Next releases are not open source, with the code reserved entirely for its developers. The project argues that this blocks contributions and makes auditing impossible, and that audit matters more than usual here because a Zygisk module runs with root privileges and can reach the whole system.

The README is careful not to make this an accusation. It says the Zygisk Next developers are famous and trusted in the Android community and that PerformanC understands they have their reasons for keeping the code closed, then argues the opposite position anyway. That framing matters for how you read the project: the case for ReZygisk rests on inspectability, not on a claim that the original is malicious or vulnerable.

The topics on the repository line up with the scope: android, apatch, injection, kernelsu, magisk, root, zygisk and zygote. GPL-3.0 is what the repository metadata reports as the licence, while the README states the project is licensed under AGPL 3.0 and links the OSI text for it. Two different licences are recorded for one tree, and if licence compliance matters to you that conflict is worth resolving by reading the `LICENSE` and `NOTICE` files at the repository root directly. The `NOTICE` file, plus `TRANSLATOR.md` and a `READMEs/` directory holding seven translated READMEs, is also where attribution questions get answered.

Rewritten in C, with custom linkers for hiding

The technical claim is that the codebase was rewritten entirely in C, which the README says brings a cleaner codebase that is easier to follow, plus lighter and faster binaries. Compare that with the composition of the tree and it is credible: `loader/`, `zygiskd/`, `module/` and `webroot/` are four clear responsibilities, with `scripts/` holding the signing step and `common.mk` at the root shared by the sub-makes.

The more interesting engineering decision is the custom linkers. The README states they were introduced to future-proof ReZygisk against future detections, and that under normal circumstances it does not use the system linker at all, which it frames as defeating linker-based detection. This is the part of the project that competes with other root modules on the same device. `loader/` is the component that has to survive that competition, and the `.gitmodules` file suggests parts of it come from elsewhere.

Two C dependencies are declared: PLTI, described as a simple PLT hook for Android, and CSOLoader, described as a state-of-the-art Linux custom linker. The Android NDK is the only build tool listed. So this is a native build with a small, explicit dependency set rather than a Gradle project, and building it yourself is a reasonable first step if you intend to run it at all.

Picking a build: release for use, debug for issues

The installation section is unusually clear that the build you choose changes how the module behaves. The `release` build is the one to pick for most cases: it removes app-level logging and ships more optimized binaries. The `debug` build is the opposite, with heavy logging and no optimizations, and the README says to use it only for debugging and when gathering logs to open an issue. On branches, use `main` unless the developers say otherwise, or unless you specifically want upcoming features and understand the risk.

That framing makes the choice feel riskier than a typical build picker, and it is: the README says the selection determines how hidden and stable ReZygisk will be.

Flashing is the standard module flow. Download the zip, open the `Modules` section of your root manager, select the zip, then check the installation logs for errors before rebooting. One step is specific to Magisk users, who must disable the built-in Zygisk option in Magisk settings because it conflicts with ReZygisk.

Verifying the daemons actually started

After the reboot, the check happens in the module description in your root manager. It should indicate that the necessary daemons are running, and on a device supporting both architectures it lists the monitor and the 64-bit and 32-bit daemons with a checkmark each, followed by the words Standalone implementation of Zygisk.

This is the step people skip, and it is the one that catches the most common failure: two Zygisk implementations loaded at once, which is exactly what happens if Magisk's built-in Zygisk was left enabled. If the description does not list both architectures, one of the daemons did not start.

If you are building from source rather than flashing a release, the `Makefile` shows how far the automation goes. Debug and release targets both delegate to a build that produces a single zip, and install targets exist for KernelSU, Magisk and APatch, with matching reboot variants. Where ADB is available the Makefile pushes the artifact and reboots the device for you:

ADB_CMD := adb push $(ZIP_FILE) /data/local/tmp && adb shell
INSTALL_PATH := /data/local/tmp/$(ZIP_NAME)
REBOOT_CMD := adb reboot

Under Termux the same targets use `su -c reboot` instead of ADB. The zip name is built from the module name, version, version code, commit hash and build type, which is what makes it possible to tell from a filename which binary you are running.

Where the risk actually sits

This is a module that loads into the zygote and runs with root, and the README says so without hedging. The practical risks are the ordinary ones for that class of software. An unstable build can boot-loop a device, and the `debug` build is explicitly the unoptimized one, so shipping it to a daily driver is a bad trade. Detection is the second concern: the custom linker work exists to make the module harder to find, and the README acknowledges that by telling you the release build is more hidden.

A third factor is upstream drift. ReZygisk is a fork, and its value rests on tracking a Zygisk API and Android releases that Zygisk Next also has to track. The release history shows v1.0.0-rc.8 on 2026-04-26, v1.0.0-rc.9 on 2026-05-03 and v1.0.0 on 2026-05-10, so reaching a stable 1.0 took several release candidates within a few weeks, and the tree carries a `NOTICE` file that is the usual place for upstream attribution requirements to surface.

Community support runs through Discord and two Telegram channels plus a Signal group, all listed in the README. Contributions are not open invitation: the README says following PerformanC's contribution guidelines is mandatory, along with their security policy, code of conduct and syntax standard.

Editorial conclusion

ReZygisk earns its place for anyone who needs the Zygisk API on Magisk, KernelSU or APatch and wants the code in front of them, since v1.0.0 shipped on 2026-05-10 and commits landed as recently as 2026-09-21. Two things to settle first: the licence, because the README says AGPL 3.0 while the repository metadata reports GPL-3.0 and both cannot govern a single tree, and the base, because a fork of Zygisk Next inherits the ongoing question of what upstream detection does. Install the `release` build, leave Magisk's built-in Zygisk off as the README insists, and verify the module description before assuming the daemons are up.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. PerformanC/ReZygisk on GitHub
4. README
5. Releases