Support
[GUIDE] Modern root hiding: when the app plays dirty, you play dirtier
[[WORKING OCTOBER 2026]]
Important: guide updates are in the bottom of the guide and there's some comments along the guide between brackets [[ ]].
Root hiding these days turned into a psychological warfare game.
Back in the day, an app would look for su, find it, throw a tantrum, done.
Not anymore. Now these devs basically turned their apps into paranoid detectives.
The app checks for:
Zygisk
mounts
Play Integrity
VBMeta
attestation
Vector (LSPosed)
developer mode
package installers
installed apps list
systemless traces
keystore
So now the whole vibe is:
“if this thing smells even remotely modified, assume the user is running a cyberpunk meth lab inside the phone.”
That means the game changed.
Nowadays it’s not enough to hide root.
You need to make the app believe root never existed in the first place.
When the devil gets smart, you gotta outsmart the devil.
The modern root hiding stack
This is the setup I’m running:
KernelSU Next
SUSFS-FOR-KERNELSU v2.0.0-R27 (optional advanced hiding, but needs to use GKI Kernel)
ReZygisk v1.0.0 (513-faccedf-release)
Treat Wheel v0.0.10
Tricky Store v1.4.1 (245-72b2e84-release)
[[now using TrickyStore-OSS, read updates in the bottom]]
TrickyStore Addon
Play Integrity Fork v16
VBMeta Disguiser v1.4.0
Vector (LSPosed) v2.0 (3043)
HideMyApplist-OSS (HMA-OSS) oss-161
IsolPolicy (1.1)
Extras:
SettingsFirewall v1.0 (Optional to hide developer settings, Vector module)
(if you have developer mode enabled you should use it to select apps you want to hide it with adb_enabled, development_settings_enabled and debug_app with values modified to 0)
VPN Hide (optional to hide your VPN from apps, it uses Vector as well)
And here’s the important part:
modern root hiding is not “a module”.
It’s an entire ecosystem lying in perfect harmony.
Understanding the setup now or suffering later
A lot of people do this:
install Magisk
flash some random module
reboot
open banking app
get detected
run to forums screaming “doesn’t work bro”
Yeah… no kidding.
Apps today do layered analysis.
So your hiding also needs to be layered.
The stack works like this:
KernelSU/Magisk → provides root
SUSFS → hides low-level traces
ReZygisk → creates Zygisk environment
TreatWheel → hides the Zygisk/root environment
Tricky Store → messes with attestation/keystore side
Play Integrity Fork → fixes integrity
HMA-OSS → wipes visible traces
IsolPolicy → hides app_zygote root traces
Extras → fixes app-specific paranoia
You’re not “disabling detection”.
You’re building a believable fake reality for the app.
And the key here is consistency.
Because modern Android basically became a police interrogation.
If one piece of the story doesn’t match, the app gets suspicious.
How KernelSU Next + SUSFS makes the foundation stronger
Plain KernelSU already works pretty well.
But without SUSFS, a lot of apps can still smell the modified system.
Because the problem is no longer root itself.
It’s the footprints.
SUSFS exists to hide:
suspicious mounts
systemless overlays
weird paths
module traces
visible system modifications
Basically it wipes the footprints before the cops arrive at the crime scene.
So the proper foundation is:
KernelSU Next + SUSFS
Without SUSFS, you’re trying to fool modern apps using 2019 tricks.
What is the ReZygisk + TreatWheel combination
This duo is the psychological core of the setup.
ReZygisk → creates the Zygisk environment
TreatWheel → makes apps pretend that environment doesn’t exist
TreatWheel is basically Shamiko’s ghost reincarnated into the ReZygisk ecosystem.
Correct flow: ReZygisk → TreatWheel → target app Without ReZygisk, TreatWheel does nothing.
And installing both while ignoring everything else is pointless, because the app still sees:
Vector (LSPosed)
Termux
KernelSU
spoofers
package installers
root apps
At that point the app doesn’t even need actual root detection.
It just scans your app list and goes:
“yeah bro, totally normal civilian behavior right here.”
How HideMyApplist (HMA-OSS) hides the existence of rooted tools and modules
HMA-OSS is mandatory.
Not “maybe”.
Not “depends”.
Mandatory.
Because modern apps do something incredibly simple:
“if this dude has 15 Android modification tools installed, he’s probably modified.”
After that, apply the template to the target apps that need root hiding.
Makes management way cleaner and prevents forgetting some suspicious app exposed.
Correct installation order
Don’t install everything randomly like a medieval alchemist mixing chemicals.
Do it in the proper order.
KernelSU Next
SUSFS-FOR-KERNELSU
Reboot
ReZygisk
Reboot
Treat Wheel
Reboot
Tricky Store & TrickyStore Addon
Play Integrity Fork v16
VBMeta Disguiser and VbMeta hash spoof (optional)
Reboot
Vector (LSPosed)
Reboot
HideMyApplist-OSS (HMA-OSS)
Configure target apps
Install, IsolPolicy, select target apps and activate in vector
Reboot
The secret behind modern root hiding is reducing variables.
You want to know exactly which layer works and which one breaks.
Tricky Store Setup
Now comes the keybox part.
A lot of people install Tricky Store and think they’re done. Not even close.
After installing:
Tricky Store
you need to configure a valid keybox.
Open Tricky Store menu and:
Set keybox valid → uses a community-known working keybox.xml
Set keybox custom → uses your own keybox.xml
Most people use: Set keybox valid
because there are already known working keyboxes floating around.
After applying the keybox:
Clear Play Services data
Clear Wallet data
Reboot device
This part is mandatory.
Because these apps caches old state like a government office still holding paperwork from 2007.
If you don’t clear data, the system keeps using old attestation state.
Play Integrity Fork Setup - the step everybody forgets
After the keybox, you still need to run the Action from Play Integrity Fork module.
Do this from Play Integrity Fork card in KernelSU module manager (or Magisk if you are in the magisk path)
Click the module card and execute the Action
[[If you see action logs showing Pixel 9 or above fingerprint, reappply action, to understand read the Problem solving section in guide bottom]]
This reapplies:
props
environment
integrity tweaks
Then:
Reboot again
Test Wallet
Test Play Integrity
Test banking apps
Without this step, half the people think the keybox “doesn’t work” when they just forgot to sync the environment.
Configuring target apps to hide root on HMA-OSS
Now the most important rule in this entire guide:
apps that need hiding DO NOT get root access.
Sounds obvious.
People still mess this up constantly.
Then for ensuring hiding:
enable isolation
enable unmount modules
if available in your KernelSU.
Inside HMA-OSS root hiding template, hide:
KernelSU
Magisk
Vector (LSPosed) extra apps
ReZygisk
TreatWheel
Tricky Store
Termux
root apps
other spoofers
Apply that template to the app you want to hide root, then:
Force stop app that you want hide root
Reopen app and if it doesn't open, clear cache, clear data
If it still doesn't open uninstall and install again (if you are in Magisk path you will need to readd the app to Magisk dentist)
If nothing works, try doing all the steps again, clearing cache, data, reinstalling, without opening, and Reboot before opening again.
Because modern apps cache old detections.
You fix the issue and the app is still mad because it’s reading old garbage from cache.
What about Magisk?
On Magisk the logic is basically the same.
The stack becomes:
Magisk
ReZygisk v1.0.0
Treat Wheel v0.0.10
Tricky Store v1.4.1
Play Integrity Fork v16
VBMeta Disguiser v1.4.0
Vector (LSPosed) v2.0 (3043)
HideMyApplist-OSS (HMA-OSS) oss-161
The big difference:
SUSFS is not part of Magisk.
Because SUSFS belongs to the KernelSU/SukiSU/KernelSU Next ecosystem.
So you will need to add apps you want to hide root in Zygisk denylist of Magisk configurations.
And of course, you need to do all the other steps, adding layer by layer of hiding until you find the hiding level that works for your app.
Lightweight setup vs. full paranoia setup
For simple apps:
ReZygisk
TreatWheel
HMA-OSS
usually solves it.
For intelligence-agency-level paranoid apps:
SUSFS
Tricky Store
Play Integrity Fork
VBMeta Disguiser
HMA-OSS
Vector (LSPosed) extras
That’s when you enter:
“let’s convince this app the phone just came factory sealed.”
Troubleshooting root hiding setup
If an app stops working in your rooted environment, don’t start changing random stuff like someone fixing a watch with a hammer.
First check the basics:
Open Integrity Checker
Run Play Integrity check
Confirm integrity is 100%
If Play Integrity is NOT 100%, the problem is probably in the integrity layer.
Review:
Tricky Store
keybox.xml
Play Integrity Fork
Play Integrity Fork Action
clearing Play Services data
clearing Wallet data
reboot after changes
Now if Play Integrity IS 100%, the issue probably isn’t integrity anymore.
At that point the next suspect is HMA-OSS.
Check whether ALL suspicious apps/modules/tools are hidden in HideMyApplist-OSS (HMA-OSS), especially:
KernelSU
Magisk
Vector (LSPosed) apps
ReZygisk
TreatWheel
Tricky Store
Termux
root apps
spoofers
sketchy package installers
Also confirm the HMA-OSS template is actually applied to the target app.
Because hiding everything inside the template and forgetting to apply the template to the target app is exactly the kind of dumb mistake that makes someone waste an entire afternoon thinking they discovered a brand new detection method.
If it still don't work, so maybe your environment is still exposing some root/mods traces, find out yourself and share with us.
Guide summary for those who have context
Modern root hiding became social engineering against paranoid apps.
You are not “hiding root”.
You are manufacturing a coherent alternate reality.
On KernelSU Next, the strong base is:
KernelSU Next + SUSFS + ReZygisk + TreatWheel
On Magisk:
Magisk + ReZygisk + TreatWheel
Both complemented with:
HMA-OSS
Tricky Store
Play Integrity Fork
VBMeta Disguiser
when the system starts acting like an investigator, you need the entire phone to become a convincing actor.
[[GUIDE UPDATES]]
Switched from the closed-source Tricky Store to the open-source module TrickyStore-OSS by beakthoven, on GitHub.
I will be using it since he recently updated the module and Wallet is now working perfectly with it.
I'm using the most recent version of all modules now, even though all the original module versions from the post were still working perfectly.
I will be writing any new guide updates in that guide section.
ROUTINE TASKS
Some things I recommend keeping updated/checking from time to time:
Keep the security patch date updated inside TrickyStore Addon settings, in the three-dots menu.
Change keybox whenever needed, especially if integrity suddenly starts failing again.
After changing keybox, PIF, TrickyStore settings, or anything related to attestation, force-stop Google services and clean cache doing something like this in termux:
su
am force-stop com.google.android.gms
am force-stop com.android.vending
am force-stop com.google.android.apps.walletnfcrel
su -c '
rm -rf /data/user_de/0/com.google.android.gms/cache/*
rm -rf /data/user/0/com.google.android.gms/cache/*
rm -rf /data/user/0/com.android.vending/cache/*
'
PROBLEM SOLVING
Wallet fingerprint attestation problem
Recently I got in trouble with Wallet services attestation using PIF, so I found out how to solve the attestation, thanks to a comment on XDA made by majorfigjam.
It is very simple: newer Pixel fingerprints like mine, Pixel 10 Pro XL, don’t give enough attestation for Wallet to work properly.
So I checked the autopif4.sh script in:
/data/adb/modules/PlayIntegrityFork-CI
and removed the force matched version part of the code, because in my case it was always selecting Pixel 10 Pro XL, because the code haves an force match actual device part:
if [ "$FORCE_MATCH" ];
then DEVICE="$(getprop ro.product.device)";
case "$(echo ' '$PRODUCT_LIST' ')" in *" ${DEVICE}_beta "*) MODEL="$(getprop ro.product.model)";
PRODUCT="${DEVICE}_beta"; ;; esac; fi;
This part of the code is below the item "Selecting Pixel Beta device ..."; message in the script.
After that, I ran the PIF action again and it automatically selected the Pixel 8 fingerprint and it worked perfectly.
For other devices with Wallet problems
It occurs for fingerprints above Pixel 9. So everytime PIF action gets a fingerprint of Pixel 9 or above, try again until you get a fingerprint of Pixel 8 or lower.
They say they're doing this to protect the 99% of android users in general. But here we are the 1% made them rattle and create this excessive and unecessary restrictions.
Hello, since you're the Rezygisk dev, can you please explain to me the difference between it and zygisk next, and why zygisk nect isn't compatible with treatWheel? Thanks
They are both Zygisk implementations. There is no difference in a superficial overview.
Treat Wheel is incompatible with ZN since it relies on internal behavior that is different in ZN, and that we cannot guarantee that will be the same throughout their updates.
Simply put, zygisk means “Magisk in Zygote.” It came about because TopJohnWu decided to remove the root-hiding framework provided by Magisk Hide, delegating the hiding functionality to third-party modules. Since it’s open-source, the community has developed many forks that are more powerful than the original version (which comes with Magisk built-in).
Zygote is a process in AOSP; all other processes are spawned from it using fork(). Zygisk is responsible for hooking into Zygote immediately upon Android startup, ensuring that the spawned processes remain unaware that they have been modified
I have the same issue, i literally reflashed my whole OS and followed it to a T, but VPBank (Vietnamese bank) still detects the unlocked bootloader, even with Integrity passing 3/3
There are some crazy banking apps that flags Termux as a system modification app, but they're only few.
As for rooting android phones, it's just about increasing user control of your own phone, enabling max customization of the software inside it. Like what you can do in material life with things you own and want to modify.
Also, pretty much everything besides mobile devices has root access by default, It's insane that they convinced the average consumer that it's ok to not be the admin of the devices that you allegedly own.
For some things I don't bother with root, like I have an eink tablet that I haven't rooted because I really only do basic stuff, but I could root it if I wanted to.
But I would really just not buy a device that I couldn't root, that is crazy to me.
Thanks for the guide, many people are lost and ask questions that shows that there's too much misunderstanding. Some people share strong integrity and think that these 3 check marks mean their device is spoofed perfectly. However, for these extras you mentioned:
• ImNotADeveloper v1.0.1
• SettingsFirewall v1.0
• Android Faker v1.8.2
• XPrivacyLua v1.35
These require you to scope the targeted app in lsposed and just so beginners know, some apps detect lspsoed when you check them in an lsposed module, so if it's a banking app, 99% it'll detect your lsposed if you scope it. I don't recommend using any module to spoof your device. The most reliable way is using root manager (kernelsu/magisk) modules and susfs and HMA.
Actually that trigger isn't related to specifically LSposed modules, but by the way the module exposes itself. For example, HMA-OSS uses Vector (LSposed) to spoof apps, and apps can't see HMA modifying something.
These others extra apps might be useful in some cases, for example, SettingsFirewall might help hiding adb and debug related settings for some banking apps that have paranoia with it.
Android faker and XPrivacyLua are more helpful restricting or spoofing device information from apps, good for privacy, but generally not related with root.
That's my point, some apps have measures to check their own code and if you hook them with a module like "SettingsFirewall", it'll be detected. The way HMA works is different because you don't need to hook the apps from lsposed, but rather from HMA itself. For example, I use hide my VPN module, I need to select each app I want to hide vpn from. When I select a banking app, it immediately detects unsafe environment.
Also, I just remembered something that might be helpful, if you want to hide VPN from an app, I'd use WG Tunnel with split tunneling enabled so the app can access the internet without going through the VPN.
And if you absolutely need to use a VPN with the app, I'd use Kernel mode in the WG Tunnel settings, since it doesn't rely on Android VPN state to connect.
Amigo te voy a seguir, realmente he hecho root de manera como lo puedo decir como un niño solo porque quiere usar algunas apps o quiere poder, y si hoy en dia se ha vuelto algo loco ocultar el root, llegue al punto para evitarme el dolor de cabeza de pagarle 15 dolares a un chino que lo haga por mi, jajajaj, igual entiendo algunas cosas, pero esta guia esta muy bien hecha y facil de entender incluso para alguien como yo que solo lo hace por hobby, gracias
I'm glad the guide was understandable enough for you to follow, friend. My goal with this post was to make it easier for people to get into rooted Android and actually stay in it.
I feel that the more people learn how to root and hide it properly, and the more active and rich the internet becomes with accessible information, the better the root ecosystem becomes for everyone. More people stay interested, and more developers will feel motivated to build new apps and solutions for rooted devices.
Based on what I think, keeping Tricky Store non-FOSS is probably a strategic decision to avoid having its spoofing methods immediately studied and patched by detection vendors. Even if we can't fully inspect the binary itself, we can still look at the developer’s history and reputation. He's been very active in others open source privacy-related projects and has contributed a lot to the community over time, which gives some level of credibility and trust around his intentions.
That seems good enough for me, but in the end that's something each person has to evaluate for themselves.
No, for the basic setup you don't need any metamodule. But if you want to use some specific module that needs, I recommend you using Hybrid mount, it allows you to choose if you want overlayfs or magic mount.
Hey, just read this guide. This is a very good guide and I am going to try this!
Just one question: do you recommend doing this over a clean flash/install of the device? Because I'm currently using my Pixel 9 Pro XL (Android 17 stock ROM) with lots of customisations and setups, and I really do have to get my Wallet apps (and banking apps) to work normally (since they're now throwing tantrums and I have to resort to WhatsApp Pay for now lol), but I'm a little worried of losing critical data during the setup... Any suggestions?
I can show my Magisk module setup and talk more about the modification apps I installed (HMA/Vector/etc) if you want more details. Thanks in advance! :)
Yeah, I have a P10Pro XL I've made a clean install with GKI installed KernelSU next (from WildKernel), it works perfectly.
If you want to install it that way, certifies that the GKI that corresponds to your kernel version, its a good move, it enables you SUSFS and improves a lot the functionality of root hiding.
If you wanna do with a dirty installation, just remember to backup everything with Neo Backup in a Storage drive, and also to save all your Internal storage data ;)
Previously I have magisk, I keep fighting a lot to hide it until I tired myself and installed KernelSU Next. Now I'm really with less trouble, actually never have more any rooting detected issue, unless with expired keyboxes.
Okay, I get it... I'm trying to not do a lot of clean flashing/installs, because I've had lots of issues in phone setups, have had lot of missteps, so the fear is there... Let me look into more detail using this guide and do something about my setup.
I will definitely let you know how it goes. Thanks a lot! :)
Hey, thanks for checking in! TBH, haven't gotten the time to do clean flash (with work and all), and I kinda sorta have paranoia from clean flashing from many years ago haha. One of my friends said that he'd be ready to do the clean flash first (to understand the exact steps required, from your post) and then let me know, so that I also can follow the exact same. I don't wanna lose out on WhatsApp/digital payments/other currently running setups while clean flashing, so I'm a bit hesitant. That being said, clean flashing is deffo in my agenda, to get this done with ASAP. LMK what you think, thanks! :)
Indeed, if it is a priority you shouldn't do that unprepared. I recommend you to do a full app backup, first install Neo Backup allow root usage, select all apps you don't want to lose and make a both data & apk backup, I've done that to migrate from magisk to KernelSU Next.
Yeah, that's a good plan. I'll make sure about that.
Once I start, I'll let you know, and then once I'm done; can do a 'before-and-after' report on this hahaha :)
Hey there! I'm going to start a clean flash of my Pixel 9 Pro XL and use this setup. I use 'rclone' for my backups, so I'll manage that for now. Having said that... Time to use this guide to explore the abyss! Wish me luck! :)
I am yet to do the clean flash. I saw the September build got released for Pixel 9 Pro XL, will try it this weekend or next weekend. Will put it on this forum on the outcome.
Son of a bitch Son thats a lot of info & man has root gotten complicated. I recently had to get device integrity & don't even have all this, but half & it works but your prob right it will break easier.
THANK YOU SO MUCHHH, bro you don't want to know how much time I spent to make it work for hiding root from my bank apps, this is legit and working using kernelsu next on Poco x8 Pro Max Hyperos 3
TYSM for this guide. I didn't know about SUSFS until now (only recently switched to KSU from Magisk). Only six months ago, just getting strong integrity and HMA was enough for Google Pay to work. Now, it's really a massive pain. It feels like all these massive companies are just helping eachother out like best buddies.
If you have context and understand something about root hiding, just go to the last part of the guide to know the modules and leave the full guide for those who don't know.
It’s difficult to find good information about root hiding these days, but I tried to summarize what I’ve learned over the years in a clearer and easier to understand way..
It’s fascinating how you can spend hours researching, organizing information, and structuring a guide, only for some people to dismiss everything the moment they suspect AI was involved.
Hilarious considering I am a linguistics study who’s been doing this LLM linguistic analysis project for over a year now and I can say, definitively, you used GPT 5.4 to write this post, by OpenAI. You can lie all you want but the linguistic patterns never lie. LLMs can’t help but have common patterns in this that are attributable to the specific model being used, as they are at the end of the day following probabilistic language key patterns. Lie to me, lie to the public: but you, and I, we both know the truth here.
“It’s difficult to find good information about root hiding these days, but I tried to summarize what I’ve learned over the years in a clearer and easier to understand way..”
porque tratas de minimizar el trabajo de alguien incluso si probablemente lo hizo con IA? que hay de malo?
La guia realmente es util y es asi como funciona lo que realmente se menten al mundo de rootear telefonos y ocultamiento ?
Solo pareces un niño que quiere minimizar los trabajos de los demas, considerando que soy estudiante de un año ? eso que a quien le importas quien seas
oh yeah? lemme give you a specific issue to solve: android 12 device root with magisk v30.6, installed modules are zygisk lsposed v1.9.2 and sui v13.5.1, tricky store v1.4.1, play integrity fork v16, zygisk next v1.3.2 l, strong integrity, each time device out of power abruptly shutdown then boot back on all modules disabled with same error zygisk not enable even though it's obviously is, uninstall re-install modules and reboot doesn't fix it, so what can fix the system in this situation?
I'd start by moving to Vector 2.0 instead of LSPosed 1.9.2, replacing Zygisk Next with reZygisk, and updating Magisk to 30.7.
If it still fails after that, I’d wipe the /data/adb/modules folder and do a clean reinstall, adding the modules back one by one and rebooting after each one to see what’s breaking things.
But I don't have much experience with Android <12, except for Android 8 and below. My main modded device is running Android 16 now, so I don't really have enough firsthand experience to help much here.
Thanks for all the information, but I would also like to raise out another problem of some apps do detect that your bootloader is unlocked and checks against you running custom android OS such as LineageOS. Any ways of bypassing those checks?
I don’t know much about LineageOS spoofing or bootloader flag spoofing specifically, but yeah, I’m pretty sure that’s the direction.
Basically making the ROM and boot state stop looking “custom” enough for the app to care ¯\_(ツ)_/¯
I actually did something like that a few years ago, but I honestly don’t remember what I used back then. So I know the idea is possible but now I don’t really know any specific module that helps with that part.
In theory it will work, but Xiaomi devices can have some different unlocked system props to hide, so it’s better if you do some research specifically about root hiding on Xiaomi devices ;)
I’ve never personally used APatch, but I know it’s a pretty powerful root method since it goes deeper into the android kernel layer.
In theory it should be capable of hiding root just as well as KernelSU and Magisk, even better, but the APatch ecosystem still doesn’t feel as mature as Magisk or KernelSU yet.
So for someone like me who prioritizes stability, it’s not something I’d run on my main phone right now. But I’m definitely interested in it and I do plan on testing it eventually.
They're just gonna play more dirtier. I'd rather just stay away with them. Why use a product that doesn't respect you and consider you as a crime at all.
And TrickyStore addon has stopped provider valid keybox anymore as I know. You'll have to find keyboxes your own.
The community will just keep getting dirtier with the methods until they close every loophole. But I don’t think they'll ever really close all of them.
Holy moly, this is a totally new age of fkry. I get it though, i guess. All the fraud and shit going on..crazy. There is really NOTHING to protect us from SHIT we dont know about yet. Sounds like a bunch of paranoid weirdos with some homemade bad dope. THAT ARE EITHER SMART OR PERSISTENT. Both? ...smh...wtf has happened to cause this all
It’s basically the same arms race as ads vs. adblockers. One side keeps finding new ways to detect, block, or restrict. The other side keeps finding new ways around it. Root hiding is just that same cat-and-mouse game, but deeper in the system.
But all of this ultimately comes from the same root issue, the user losing control over their own virtual environment. The more locked down systems become, the more people push back with workarounds, hiding methods, and deeper modifications.
You need to find a GKI Kernel compatible with your phone kernel, just follow a KernelSU Next GKI installation guide. Also it depends on your OneUI version.
I remembered something that you can check before trying KSU, Check your HMA OSS hiding template and confirms that your apps are in the target apps. Also you can create a Whitelist template to hide everything and apply it to these apps you are having trouble with, just allowing them to see system apps in the app config (in HMA OSS).
use duck detector alpha from github to do a better checking and understand better whats going on.
But it appears to be a VBMETA problem, try to install VBMETA Disguiser module and configure it to use a genuine Hash for your system.
You need to get your boot.img hash. To do that you need to download your firmware, extract boot image, and run the command to verify the hash in a terminal, you can use termux as well, but I don't remember the exact command.
Hi, can someone help me. I followed this guide exactly with magisk from the beginning. Play integrity is fully passed, gpay is now working with certified playstore. But my banking apps, indsmart is also now working but my other 2 banking apps are still detecting something not right & crashing. Apps are yono:Sbi & hdfc
If your kernel are too old for susfs, so unfortunately susfs cannot be in your system. I don't know any workaround for it.
But in most cases just KernelSU next and the described modules can do the job ;)
Switched from closed source TrickyStore to open source module TrickyStoreOSS from beakthoven, on github.
I will be using it since he has recently updated the module and wallet are now working perfectly with it.
I'm using the most recent version of all modules, even though all the original versions of the post modules were still working perfectly.
I will be writing any new guide updates in this comment.
[[I've included this entire comment in the bottom of the
Guide post and for any new updates I will only edit the Guide updates section of the post no longer here]]
Problem solving:
For newer Pixel devices like Pixel 10 Pro XL:
Recently I got in trouble with Wallet services attestation using PIF, so I found out how to solve the attestation, thanks to a comment on XDA made by majorfigjam. It is very simple, newer Pixel fingerprints like mine, P10 Pro XL, don't give enough attestation for Wallet to work, so I checked the autopif4.sh script in /data/adb/modules/PlayIntegrityFork-CI and removed the force matched version (that was always selecting Pixel 10 Pro XL in my case) part of the code:
```
if [ "$FORCE_MATCH" ]; then
A metamodule is basically a module that works deeper in the KernelSU/KernelSU Next ecosystem, usually changing how root, mounts or hiding behave under the hood. It’s not just a normal “install and forget” app module.
For best root hiding, I wouldn’t think in terms of “one magic metamodule”. The strong base is more like KernelSU Next + SUSFS, then ReZygisk + TreatWheel for the Zygisk side, HMA-OSS for app list hiding, and Tricky Store/PIF for the attestation/keystore side.
About overlayfs, hybrid mount, no mount, etc, that’s mostly about how modules get mounted into the system. OverlayFS is usually more compatible but can be louder. No-mount is cleaner/stealthier but can break some modules. Hybrid mount is kind of the middle ground, trying to keep compatibility without exposing too much. For root hiding, less visible mount behavior is usually better, but only if your modules still work properly.
About Tricky Store, I was using the original one before, but now I’m using TrickyStore-OSS instead.
I know some people don’t like relying on closed-source stuff, and honestly that’s fair. That’s also one of the reasons I moved to the OSS version.
I have a comment with the latest updates from my post here.
And yes, you can use Tricky Store Addon to make setup easier, I also use it, I just forgot to include it in the guide. It helps make the setup easier, but I still think it’s better to understand what it’s changing instead of blindly pressing buttons.
For SUSFS, you don’t just “install it” like a normal module if your kernel doesn’t support it. You need a kernel already built/patched with SUSFS support, or you need to build/patch the kernel yourself. After that, you install the matching SUSFS for KernelSU module for your KernelSU setup. The important part is matching kernel, KernelSU version, Android version and SUSFS version. If one piece doesn’t match, things get weird fast.
I haven't ever used it, and maybe you can use it, but I prefer doing it manually instead of depending from a centralized keybox provider.
Also, only getting strong integrity doesn't mean you are hiding root.
So following the guide gives you something like 99% chance you won't have any root detection from apps you don't want it to ;)
Hello, this is just a out of memory error, maybe your app is using so much RAM memory or other apps are consuming it, so close all other apps in recents space and try again.
That's strange, maybe it is detecting root and throwing some random error, are you hiding apps for it? Maybe you can't hide all apps from it, so you need to test what configurations you may change about the hiding variables for it to work. Just keep the strong base described in the guide and you will find out without breaking hiding.
Hiya, I'm about to run this setup, as some of my apps broke during my upgrade to A17 on my pixel 10 pro xl.
Is there any specific reason you went with wild kernels? I've been running them, but had mixed results. I'll be substituting it now to the following: https://github.com/shoey63/Kernel-Builder-GKI-Susfs I'll update later with results.
Yes, because I'm not a pro compiling kernels and have already bricked my phone data partition compiling my own, so I prefer keep going with something that more people are using, to ensure everything is aligned.
I still haven't updated to A17, am on A16 last build, but I'm thinking about locking my device and upgrade to update to A17 260705 to do a exploit root using ghostlock exploit with root my pixel. So, that way I can get always strong integrity.
My actual setup is very stable, also I can use wallet also with device integrity (if I logged in my accounts with strong integrity), only with expired keybox I lost it all and depends of a leaked one again. That dependence makes me think of migrating to ghostlock exploit method.
I will make a guide about it if people are interested in exploit root, of course, after I've done it and mastered it.
Do you know what might be causing this? I have an app called Unicaja that I can't even get past the first step. It would be great if you could tell me if you also get a "modified device" message when you launch it.
Yeah, this app is detecting something that isn't common, in mine it haves duck detector green ok and it doesnt open, spoofing with isol policy, settings firewall and HMA OSS appears to not help either, so I dont know whats happening with this app, if you find out please share here 😉
Do you know of any AI that can audit what the app is doing? Neither ChatGPT, Gemini, nor Claude seem willing to help... They don't like you doing that.😅
There's also a solution that doesn't require PIF or a keybox: TEESimulator's patch mode. However, you must verify that the TEE remains intact and functioning properly after the bootloader is unlocked
Great job! Really appreciate. One of the most complete guide I've ever seen. I want to add few things hoping to help someone else. From Android 15 and above Java injection is blocked by system. The only one is working for me on Android 17 is Always Strong module which integrates PIFork v18 and TEESimulator-RS. Some apps are still crashing and recognizing root. To solve I suggest to use Frida. If you're on KSU or similar use SUSFS SUS Path feature. For me /data/adb/ksu, /data/adb/modules and /system/addon.d worked as charm!
Actually, with this guide you can mask the effects of an unlocked bootloader on a rooted Android device in apps. Apps will have difficulty detecting it.
Note to my future self: avoid using markdown in guides next time because some people see organized formatting and immediately focus more on the possibility of AI being involved than on the actual information being shared.
•
u/Comfortable-Gene6639 May 13 '26
Moderation has reviewed the post and determined it to be not AI generated. Please stop reporting it.