ThePedroo

(And ReZygisk 1.0.1, too.Two ones, two two ones!)

(off-topic: Treat Wheel 0.0.11 soon!)

Hello, everyone. Another day, another ignorance.

When it comes to RASP (Runtime Application Self-Protection) developers, and even some ignorant (to put it lightly) developers, we know they care more with their apps than us, the Android community. Needless for me to reiterate how inappropriate that is.

Knowing that, I wanted to display a recent AOSP bug tracker report that has been made. In a nutshell: restrict Android because it hurt apps. Seemly written fully with AI, threatens the community, since we know Google isn't the sanest of them all.

https://issuetracker.google.com/u/1/issues/492218540

We don't deserve to be treated as second class citizens. Android has always been a place of freedom, and even if recent actions of Google doesn't seem to represent that anymore, we must mark our territory. Show your dissatisfaction.

(Thought I must say, I'm very grateful for their ReZygisk propaganda)

Sincerely,
ThePedroo.

(Some credits for me. I've been testing and writing at 2am)

(Perhaps I'm going to make some very interesting posts soon..)

Hello, everyone! Long time no see.

I'm always looking for publishing informative content here, and that includes third-party modules, as you may know. That said, I'm here to talk about the comeback of Tricky Store OSS.

A project by beakthoven, Tricky Store OSS is the foundation to many widely used TS forks nowadays. It had the goal to continue the Tricky Store (closed source), improving its codebase and fixing detection points. Its developer maintained it for numerous months, till, due to university, he stopped.

In the meantime, "successors" appeared as temporary solutions, since many, like me, finds the usage of closed source modules rather uncomfortable. However, that is no longer true for this day and on. He is back and I'm very happy to talk about a module of a developer who has many goals similar to mine.

I suggest that you check out, and if it doesn't work, or something goes wrong, make an Issue in its GitHub. Open Source is made by the community. So be it.

Kindly,
ThePedroo.

A quick reminder of @RainyXeon 's birthday.

Someone that here on Telegram might not be widely known, but The one that brought, since the beggining, hope, happiness, trust.

To The one that has ever made my days more bright, I dedicate a poem:

Hastily passed, but never superficial.
Since the beggining, always un-artificial.
Blood's thicker than the running water,
But never beating someone alike brother.

Morning, everyone. Quite some time, but now we're (we? Who? Me) back here.

Treat Wheel. Or Threat Wheel, or Tricky Wheel. Whatever you call it, it is a hiding module of age already. It dates back to the beginning of 2025. It has been recently FOSS-ed, so we can take a look on it. For the sake of simplicity, let's see the simplest ones

1. Zygote mountinfo leak

This detection happens early on Zygote. On initialization, Zygote does several operations regarding mounts. Creating a new mount namespace, marking rootfs as MS_SLAVE, mounting tmpfs, and... umounting /storage mounts.

While plain umount is fine by itself, Zygote utilizes a very specific libc function to grab the active mounts: getmntent. The special characteristic of that function is that it is backed by a global buffer in libc (getmntent.c#L25). When Zygote uses it, it ends up leaving the last mount on /proc/mounts on that buffer.

Root implementations and modules usually mount late. That leads to their mounts being the last ones there. When they umount, the mounts will disappear from procfs, but the trace of the last mount will be cached in that global buffer, and it can be observed.

Treat Wheel fixes this by forking a new process to run setmntent and getmntent (bypassing procfs related detections), grabbing its address and new buffer value, passing to parent, and having the parent write to the address the children's buffer value. Since they share the same mount namespace, they should have equal values when up-to-date. This fixes this detection.

2. AtExit handles

Bjarne did not approve this detection — but let's focus on C++ for this one. When developing any software, especially on C++, the standard library needs to be initialized. However, not only that, it also needs to be de-initialized. That's the issue AtExit handles solve.

libc keeps track of all AtExit handles, so that before it exists, it can call them. However, the problem is that when they are not utilized, instead of being removed, they're simply zero-d. In a list that all of the entries will point to valid addresses, and usually non-zero, having a zero address is abnormal.

Treat Wheel fixes that by directly manipulating the list. However, detecting which ones are from the system, and which ones are created by Zygisk modules is not an easy task when they're already zero. Treat Wheel uses heuristics for that. All entries before libminikin.so happen before most system libraries — but after Zygisk modules. By removing those, we can safely patch this detection.

3. Frida

Frida is extremely detectable as-is. However, those standard Frida detections is not what we go after. Something that got my attention is how Frida left detections on SoList too, similarly to old Zygisks.

This detection involves doing the same as what we used to do in Zygisk before custom linkers came — set the size of the VMAs to 0, then call soinfo_unload, which removed its SoInfo entry from SoList, evading most generic injection detections.



This was simply a post I made rapidly out of boredom and willingness to spread more information about the detections Treat Wheel fixes. While I would love to include URL to sources, Telegram didn't find the same so attracting, by persisting the image of a bird in my clipboard. Enjoy the text and the bird, then.

Sincerely,
ThePedroo.

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

Night/Morning, everyone.

Today we're here to talk about the dead — ReLSPosed. As you may know, ReLSPosed development has been discontinued. However, with that, numerous forks of ReLSPosed appeared.

The question of "which one should I use?" became frequently asked. Hence, I am here to make my personal recommendation.

Shall I present Silvzr/Silver's LSPosed IrenaX. It is a LSPosed that includes the same hidings as ReLSPosed (and some additional fixes) in a more stable base (Irena). However, still using API version 100, which you likely will only need to downgrade modules and after that, not feel any difference: https://github.com/Silvzr/LSP-IrenaX

* Quick note: I am not here to lie. As most you may know, I've hated LSPosed since ever. However, I am aware that replacing it is not an easy task, hence of why ReLSPosed existed, and why I am doing this post. If you can NOT use LSPosed, this is the best path to go after.

* Another note: I'll likely start contributing to it, with improvements here and there, but no promise will be made.

If you have any issues, collaborate with the project, and make an Issue in its GitHub repository.

Sincerely,
ThePedroo.



In dark times, use a candle to guide your path.

Hai, everyone!

As the usage of ReZygisk grows in the community, so does the need for stability and reliability. Having that in mind, ReZygisk testing became a more serious work to us, ensuring it works across a *really* wide range of devices.

However, we found ourselves limited in providing an even higher compatibility and stability by the lack of testers.

This message is to advertise the possibility more people joining ReZygisk/TW Testing.

Builds will be sent (daily, or not), and all you have to do is to flash, test general functionality or specific functionality, and upload logs.


The requirements are simple, and you must check at least one of them:
- Have a device with Android 6 or lower
- Have a device with kernel version 3.x.x (but not 3.10.x) or lower.

While that is the main type of device we're looking, we are also looking for:
- The intended primary testing device have any root implementation BUT KernelSU or any of its forks.

However, you:
- Must know how to use MDA
- Must not leak any information that comes from the group


We hope to deliver more stable ReZygisk and Treat Wheel. We love what we do.

DM @ThePedr00 for joining, with details of the device.

Happy Easter! Shall that remind of the bright future even if we are in total darkness at the moment.

I love y'all!

Good day, everyone.

Mounts are awesome. Aren't they? Through its usage, we accomplished numerous capabilities in root scenario, by temporarily altering files and folders.

But... its 2026. We found news ways to replace where we used to need mounts, and root detection wasn't left to catch dust — numerous detections for mounts were made since then, some that required kernel help to be fixed, or to be very careful with those mounts.

Since its existence, ReZygisk created a mount from its temporary module.prop to the original one, so that it could modify it, and if a reboot is made, all changes will be reverted. The biggest problem of all this was that it was a global mount. KernelSU utilizes ksud to list module information, so a mount in the app mount namespace would not work.

Until... recently. We had problems regarding module.prop leak due to installd after a commit trying to simplify its umount. However, to fix that, it involved making 64-bit-only devices have it leak unless umount was turned on for the application.

To fix that and all other detections regarding mounts we decided to find a way to remove that mount — but keeping the "erase module status when disabled" behavior was a bit tricky to think without the trouble makers.

That's when we remembered about global scripts: They were always executed, regardless of module state. By leveraging them, we could make it always reset ReZygisk's module.prop with sed (Thanks Ok for the idea!) and that way, have a clean module.prop when ReZygisk's disabled without numerous traces.

https://github.com/PerformanC/ReZygisk/commit/28021b1716174c664e3d48e98a337a89673bb795

Mountless for the win!

From the depths within my heart,
ThePedroo.



Less fun in playing with this doll,
Trying to hide emotions post fall.
Deceive your eyes to remember,
The smiles we had last December.

I love you.

Hey, everyone.

Some long time ago, I made a post here, in this channel, about best practices/a guide for/of making a Zygisk module. While most of its information is still valid, some links don't match what it was meant to, and the code didn't quite follow changes in ReZygisk.

Because of that, I decided to update it. However, Telegram is not the best channel to document such things, because of that, I decided to create a gist for this guide, now with even more information and some small updates in general. Hope Zygisk module developers enjoy.

Out of all my heart,
ThePedroo.

Heya, everyone.

Another LSPosed disaster.. Hide My Applist, more widely known by its acronym — HMA — that later got closed source. However, before that happened, it became an essential part of the community as LSPosed usage grew. Then HMA-OSS appeared, fixing detection that targeted the LSPosed's creation rapidly, becoming an appealing alternative to the closed-source module.

But HMA-OSS, unlike the original, was developed towards hiding more properties at the system_server level. Features are fun, but they come with a hefty price; wider surface for detection. Regardless of how careful they were, a detection appeared — and of course, in the *silliest* ways.

With that, I'm here to document some more detections I found regarding HMA-OSS and HMA.

1. Keyboard apps and app list mismatch

Keyboard apps report themselves as one by using BIND_INPUT_METHOD permission in their manifest. This allows the system to recognize such and display them as possible keyboards for the user to select and use.

HMA-OSS introduced a feature that allowed users to hide non-system apps, as some apps have introduced detections against third-party keyboards. However, the applist was not taken in account.

This resulted in a mismatch between InputMethodManager list and the app list, as an application with BIND_INPUT_METHOD permission would not appear as a input method/keyboard app.

2. getPackageInfo timing

Both HMAs intercept getPackageInfo with the purpose of spoofing an app as nonexistent. Hooks, however, are always problematic — well, not directly. Not because they leave traces — which here, they barely do, as we are in system_server, but because the code that you add will always add some overhead to the target function.

By requesting getPackageInfo 20000x, one for HMA(-OSS) app, and one for a nonexistent app, this allowed us to observe (with high-quality performance counters, when HMA is intercepting, a +20% overhead to the function.

OBS: getPackageInfo timing detection was recently discovered by third-parties. However, it was known to us back to December of 2025, and reported to HMA-OSS in January (which is the reason behind it not being detected through it).



I know this wasn't the best one I could make. However, making a post for an almost foreign project, for a detection I made months ago, is hard. My goal here is to inform rather than make a "How To", hence, for this one, no URLs will be provided.

Learn not to be greedy. For the community, help Open Source. Closed-source? Hm..

Sincerely,
ThePedro.

I need a ris- rest.



Go around the clock, hear every tick.
No matter what, it goes on on quick.
Do not be useless, make it be worth.
Leave love behind, leave it for Earth.

Cough cough cough... *slides sign that says "It's my birthday!"*

Hey, everyone.

Everyone that has been around for quite a while, knows my love for making poems. Because of that, I'm starting an experimental project of making a channel to post them there, that I may make daily or not.

If you're a fan of making poems with cryptic themes like me, feel free to post in my DMs too, I'd love to read them once I'm free.

Honestly, programming the entire day left me in a very tired position, but hopefully small things like poems can help me get back on trace, after all, life circles around something bigger whan what meets the eye.

Moreover, please don't mute this channel, those type of posts will be rare, and soon I will be posting interesting news, hopefully.

https://t.me/+NwUVzWVmCgMyMjAx


Sincerely,
ThePedroo.

Hello humans, ReLSPosed v1.0.2 released.

The following builds won't require you to go into the GitHub releases to update, and will be available through your preferred root manager.

Thanks for our collaborators and contributors for this release.

https://github.com/ThePedroo/ReLSPosed/releases/tag/v1.0.2

Sincerely,
ThePedroo.


Find the hidden truth within your mind,
Questions will be made to take control.
Open your wings, my fabulous phoenix,
Let you be known by courage, Dienekes.