A few weeks ago I wrote about finally passing Play Integrity 3/3 on a 2018 OnePlus 6T after switching from LineageOS to DerpFest, dropping Magisk for KernelSU Next, and swapping the usual PIF/Tricky Store/Shamiko stack for Specter + TEESimulator-RS + HMA-OSS.
The recipe worked. Integrity check: 3/3. Every field green.
The UPI apps still refused to run.
I've now given up, MSM-flashed back to stock OxygenOS, relocked the bootloader, and I don't regret it. Here's what I learned that the first post didn't cover.
The short version of what I ran, for context
If you didn't read the first post: I was on Android 16 (DerpFest for fajita), rooted with KernelSU Next, and using a modern module stack that consolidates around four things:
- Specter for orchestration — one WebUI button that pulls a fresh keybox, rotates the PIF fingerprint, and handles Play Store cache flushing
- TEESimulator-RS to emulate hardware attestation, since the 6T's TEE is broken
- HMA-OSS as the Shamiko replacement for hiding root from specific apps via a per-app denylist
- PIF Inject (the KOWX712 fork after chiteroman archived the original) for the actual fingerprint spoofing into DroidGuard
That combo passed Play Integrity BASIC + DEVICE + STRONG. HMA-OSS hid root from every app I added to its denylist. Banking apps that only check Play Integrity, worked fine. Google Wallet in most regions, worked fine. Netflix HD, YouTube Premium, all the usual root-detection casualties, worked fine.
Then I tried to send someone ₹200 on UPI.
What UPI actually checks that Play Integrity doesn't
Play Integrity 3/3 is a Google-side verdict. It tells the app "Google's servers believe this is a genuine unmodified device." Most apps that care about integrity stop there and trust the verdict.
UPI apps don't. On May 19, 2025, NPCI issued a circular mandating a much stricter security framework for every UPI Payment Service Provider, Application Service Provider, and Third-Party Application Provider in India. It's called the UPI Information Security Compliance Framework 2025, and compliance certification by a CERT-In empanelled auditor is mandatory annually. Non-compliance means the app doesn't ship.
The framework requires four things beyond Play Integrity:
- Mandatory root detection at the app layer, independent of Play Integrity's verdict. Not "Google says the device is fine," but "the app itself, right now, cannot find any trace of root, Magisk, KernelSU, Xposed, or common hiding modules."
- RASP (Runtime Application Self-Protection) to detect tampering, hooks, and debuggers during actual execution, not just at launch.
- Hardware-backed device binding using KeyMint / StrongBox to sign a per-device attestation key. This is the one that kills you. Google's Play Integrity API can be satisfied with software-attested keys (which is what TEESimulator-RS provides). NPCI's device binding cannot. It wants a genuine hardware-backed key signed by the phone's own TEE, verified against Google's attestation root. On a device with a broken TEE, that key does not exist and cannot be faked, because the verification happens against Google's public root, not the app's own logic.
- SIM binding with a live active SIM/eSIM, verified via telco, before device binding even begins. Airplane mode? Rejected. SIM in another slot? Rejected.
So even in the best case where root hiding is perfect and every trace of Magisk/KSU is invisible, the device binding step just fails silently because the hardware attestation key isn't there. Your app never gets past initial setup.
There's a great Medium writeup by Joseph James on the underlying Play Integrity trust model that explains why the STRONG verdict spoofing works at all — Google has to accept downgraded validation criteria for legacy devices that physically lack modern attestation hardware, and that's the seam that TEESimulator-RS exploits. NPCI's framework closes that seam.
What actually worked, briefly, before it didn't
For the record, here's what the module stack got me past:
- Play Integrity 3/3, first attempt after configuration
- Google Wallet setup in test regions (people in Brazil, EU, and the US have reported the same stack working for their payment apps)
- Every non-UPI Indian app I tried: Zomato, Swiggy, IRCTC, MakeMyTrip, banking apps for balance checks and non-UPI transfers
- Netflix, Prime Video, YouTube Premium
- Every app that only checks Play Integrity
HMA-OSS specifically is worth noting because it's genuinely better than Shamiko for this use case: it's actively maintained, doesn't require Zygisk denylist toggling for every new app, and its per-app hiding survives Play Store's periodic "let me revalidate your device" checks that used to leak identity through Shamiko.
Where it all fell over was any app calling KeyMint.generateKey() with setAttestationChallenge() and then verifying the resulting certificate chain against Google's attestation root CA. That's a five-line check for the app developer, and it defeats every module in existence on a broken-TEE device.
Why I stopped
Cost-benefit stopped making sense.
Cost: ongoing maintenance treadmill. Keyboxes get revoked (my Xiaomi_Lei_Jun keybox was rotated twice in three weeks). PIF fingerprints get burned. Every module in the stack updates on its own schedule. Every DerpFest weekly update is a small gamble on whether the SUSFS integration still holds. Every reboot is a small prayer that Specter's action pipeline still resolves cleanly.
Benefit: most of the apps that made me want to root in the first place worked fine on stock. AdGuard DNS is DNS-level, doesn't need root. Custom launchers don't need root. The one thing I actually gained from root over stock — custom kernel governors and the ability to freeze OEM bloat at the package level — was not worth losing UPI over.
And the UPI thing wasn't going to fix itself. It's not a bug or an oversight in the module stack. NPCI's framework is doing exactly what it was designed to do, and it's aimed squarely at the class of setup I was running.
The retreat: MSM back to stock
If you're in the same boat and want out, here's the working path in 2026:
-
Grab the MSM tool from onepluscommunityserver.com. AndroidFileHost links in old XDA threads are dead — the site is up but downloads have been broken since 2025. The community server, run by the same folks who indexed the original tools, is the current maintained mirror. Grab
Q/OnePlus_6T_OxygenOS_10.3.8.zipfor the international variant. - The XDA thread for context and troubleshooting comments. Ignore the AFH links inside it.
- 10.3.8 is the ceiling. OnePlus never leaked an OOS 11 MSM package for this device. If you want the actual final build (11.1.2.2), you MSM to 10.3.8 first, then sideload official OTA zips through stock recovery to work your way up.
-
MSM wipes everything and relocks the bootloader in one pass. No separate
fastboot oem lockstep. The "unlocked bootloader" warning at boot does go away once relocked cleanly — the common forum claim that it never does is only true for half-flashed relocks, not clean MSM flashes.
Fair warning about the tool itself: the Sahara handshake stage is finicky. If you hit "Sahara Communication Failed (FH:258)" — and you probably will at least once — the fixes in rough order of likelihood are (a) actual USB 2.0 port on physical hardware, not a hub, (b) adb reboot edl from a working OS instead of the volume-button combo, (c) fastboot reboot edl from fastboot if the OS won't boot, and (d) a genuinely different computer if none of those work. This is well-documented pain, not something you're doing wrong.
Is this coming for everyone eventually?
Probably yes, though not tomorrow.
Right now, the module stack that failed me on UPI works for Brazilian Pix, EU banking apps, and US Google Wallet, because those payment networks trust Google's Play Integrity verdict without adding their own hardware attestation layer on top. India got there first because NPCI moved fastest and hardest, and because UPI processes ~19 billion transactions monthly, which is a lot of blast radius per compromised device.
The direction of travel elsewhere:
- Google's own Play Integrity documentation since 2024 has been actively steering developers toward
MEETS_STRONG_INTEGRITY(hardware-backed) rather than the softer verdicts - EU's PSD3/PSR proposals include stronger device binding language that maps cleanly onto hardware attestation
- US banking apps have been quietly getting more aggressive with root detection year over year
Realistic guess: 2 to 4 years before the current module stack stops working for most banking apps in most markets. Not next quarter, but not distant either.
There's a counter-argument worth being honest about. The community has been predicting "the root scene is dead in 18 months" continuously since around 2018, and the counter-measures have kept up. Magisk 2018 → Zygisk 2021 → PIF 2023 → Specter/TEESimulator-RS 2025. Every generation of attestation tightening has been met with a new generation of workarounds, and they've mostly kept working in most markets. The doom prediction has a bad track record.
What's different this time is that hardware attestation is a genuinely harder problem than the previous rounds. TEESimulator-RS is an impressive piece of engineering but it's fundamentally emulating something that Google's revocation infrastructure can catch at scale once it decides to. Once emulated attestation shows up on a revocation list, the runway shortens fast.
So: if you're in a market where banking apps still work with modules, enjoy it while it lasts, and don't build your workflow around the assumption that it'll work in three years. If you're in India, save yourself the afternoon and stay stock.
What I'd tell 2021-me
Rooting is still worth it for the customization and the control. That hasn't changed.
What's changed is that "root your daily driver" is no longer a coherent recipe if that daily driver also needs to do banking. You have to pick. In India in 2026, the pick is forced. Everywhere else, it's a matter of when, not if.
I picked stock. Smooth, stable, boring, banking works. Zero regrets.
The 6T is running its original 2018 factory operating system in 2026 and it's honestly fine. That, more than anything from the module stack chapter, is what I'll remember.
Tags: #android #rooting #upi #playintegrity #oneplus
Top comments (0)