Good night, everyone.

Perhaps it was inevitable that eventually I would come to publicly talk about the numerous Zygisk forks that came to recently appear.

First of all: This is from a technical/logical point of view. Surely, I am not immune to bias, but facts are unbiased. If I made any mistakes here, please let me know.

Let's start with NeoZygisk's history, which is where most of this began:

NeoZygisk was created as a result of Jianyu's (AKA Jing Matrix) insatisfaction (around mid-december of 2024) to my opposal to the usage of C++ in ReZygisk. Due to that, he created NeoZygisk, to maintain himself, but saying he'd PR improvements.

NeoZygisk was more stable, as it did not include any of the rewrites ReZygisk went through to change the programming language it was written in. (That applied till recently, when we got more testers to help improve ReZygisk). This gave NeoZygisk a reason to exist: more stability for the same hiding.

ReZygisk got critical fixes for hiding. NeoZygisk followed way after. ReZygisk got a custom linker. NeoZygisk did not follow. ReZygisk got its second custom linker¹. NeoZygisk did not follow. ReZygisk got Tango support. NeoZygisk did not follow. ReZygisk got numerous hiding improvements². NeoZygisk still hasn't followed.

These things are prone to happen in any project, including ReZygisk. The point is not that they lack those, but rather that it has lost its point since quite some time ago, the dev hasn't been keeping up, and yet, still insist. Even if they end up fixing it, what will they be doing it for? Just to then wait for us to report indirectly to them, and ONLY after we fixed, only after we found it, go after it?

Also, some forks³ started to implement features that were not even meant for a Zygisk implementation to have. A Zygisk impl. must only act as a framework, not as a hiding module or anything alike.

Quality is important. If you go out of your way to:
1. Add hiding.
2. Add useless features.
3. Maintain a module that is behind similars.
4. Changes that don't even make sense (e.g. due to AI).
5. Never contribute the actual good changes.

If you are not doing it for the community, but just so that you get famous, or something alike, you lost the entire point of why we, of why I, decided to start maintaining Zygisk.

This post might not be appreciated by everyone. I am aware of that.
If you, Jianyu, is reading this, know that this is not about you, but rather the forks of forks. I do not wish to fight with anyone, including you. I want that people work together for a single goal, and what these other developers have been doing is not it, even if they thought so.
I've been suffering with the lack of testers since ever. Even if we got more recently, it is not nearly enough. The actual ones sometimes test the entire day. One person. That is not how I want to treat the people that entrusted me this task.
And to see people that could be helping/testing ReZygisk for actual changes go to other forks, just for appearance, is infuriating. This is an honest note about something that has been hurting me for a long time.

If any Zygisk fork developer can prove I am wrong, go ahead and do so. If I am wrong, then at least that I am wrong when trying to help the community, and if one day I cannot keep up, perhaps I should let someone else do it.

With all honesty,
ThePedroo.


1. The second custom linker was a measure taken so that was necessary to remove any SoList hiding code. It is called RCSOLoader (Remote CSOLoader).
2. As of the moment, we are aware of ~4 detections are known in NeoZygisk. 3 of them are included in public detectors, and 1 of them is ours. 3/4 of them are implemented in Meow Detector Native, our private research detector. Any user containing it is proof by itself. Code/detections will not be discloused.
3. Names won't be given. I want no fights with anyone