The purpose of this post is to describe with simple words how an efficient rooting works on an Android device today (August 2026).
This is not a tutorial to root a device but more an explanation on how Android can be rooted and the necessary Tools to achieve that goal.

The first step of rooting a modern (version >10) Android device is to first replace its boot image into the device storage.
This is done by replacing the device's boot image by a modified one enabling root activation (sometimes by replacing the kernel).

Three main variant families of root solutions exist as of today (August 2026), each with an associated application to manage root tools and modules:
- Magisk: the oldest solution. Remains universal, user-friendly choice with the largest module ecosystem, though losing efficiency with the latest Android security enhancements
- KernelSU: offers the highest security, stealth level and performance but requires a compatible kernel
- APatch: modern hybrid solution that almost provides the stealth of KernelSU but without requiring a custom kernel replacement
Each one of these solutions has multiple implementations which are more or less popular.

Because of the need to replace the boot image (boot.img or init_boot.img depending on the targeted device), the use of a computer with a USB data cable to connect the device is mandatory to flash the initial modified boot image.

After the device boots with its new boot image, the root is considered effective, but it is only the first step

To run sensitive applications (banking apps, Google Wallet, etc.) on a rooted Android device, four or five tools (often modules of one of the solutions above) work together within a complex ecosystem.
They operate at different system levels to hide the root status, intercept Google's checks, and spoof a secure device.
They will be described with their generic name although multiple different implémentations of these tools exist.

Here is how they fit together and interact:

## 1. Zygisk: The Foundation (The Injector)
Zygisk is a feature built into the Magisk root ecosystem tool and available as a module for all rooting solutions.

* **Its purpose:** It injects itself directly into "Zygote," the parent process that spawns all Android applications.
* **Interaction:** It acts as the gateway. Zygisk allows other modules (such as Play Integrity Fix or HMA-OSS) to inject their own code into target applications before they even launch.
Without Zygisk, the other tools cannot modify application behavior in real-time.

## 2. Play Integrity Fix (PIF): The Identity Spoofer
Google Play Integrity API checks whether your device system has been modified.
PIF uses a spoofed valid hardware model fingerprint to fool the Play Integrity API.

* **Its purpose:** PIF is a module that intercepts the security requests applications send to the Play Integrity API.
It injects a fake device fingerprint (the "pif.json" file from a certified, unmodified phone) to trick Google Play Integrity into believing the device is stock/unmodified.
* **Interaction:** PIF uses Zygisk to inject itself into Google Mobile Services (GMS) and modify integrity responses.
However, PIF does not handle hardware-backed encryption (the keystore).

## 3. Tricky Store: The Hardware Key Guardian
Since Google's recent updates, simple software-based modification (PIF) is no longer sufficient, as Google now requires hardware-backed verification via the device's secure processor (the Keystore, sometimes referred to as Keymaster in older Android versions).
On a device with an unlocked bootloader, Android Trusted Execution Environment (TEE) detects the break in the hardware chain of trust.
When a Key Attestation request is made by an app, the TEE returns a certificate containing a boot hash that is either empty or explicitly marked as insecure (appearing as ORANGE or RED status in verification tools).

* **Its purpose:** Tricky Store is a specialized module that intercepts Android's hardware key attestation and manipulates the device boot hash. If Google requests hardware-backed proof —which is impossible to forge on a rooted device— Tricky Store intentionally "breaks" the request.
This forces the system to fall back to software-based verification, which Play Integrity Fix can then spoof.
It operates in two ways, depending on the configuration:
- "Leaf Hack" mode (or simulation): When using Tricky Store to achieve the highest hardware integrity level (MEETS_STRONG_INTEGRITY), Tricky Store intercepts the attestation extension generated by the TEE.
It uses a valid Keybox (an authentic factory key not revoked by Google) to re-sign the certificate on the fly. During this rewriting process, it injects a valid or spoofed boot hash (often replaced by a generic string or the hash of an official, locked device) to deceive Google.
- Forcing the software fallback: If no functional Keybox is configured, Tricky Store intentionally alters communication with the hardware Keystore to trick Google's API into believing the TEE is faulty or outdated.
Google then switches to a purely software-based check, allowing Play Integrity Fix (PIF) to step in using its "pif.json" file.
* **Interaction:** Tricky Store and Play Integrity Fix form an essential duo. Tricky Store handles bypassing hardware security (Hardware Attestation), while PIF handles injecting the correct software signature.

## 4. HMA (Hide My Applist): Visual Camouflage
Even if the system passes Google's tests, some applications (especially banking apps) scan the device storage for apps they consider "suspicious" (such as Magisk, spoofing modules, or root managers).

* **Its purpose:** HMA creates whitelists or blacklists to selectively hide specific apps from other applications.
* **Interaction:** HMA also uses Zygisk to intercept system read requests (PackageManager).
It operates alongside PIF and Tricky Store: while the latter two deceive Google's servers, HMA prevents the targeted app from visually detecting rooting tools on the phone.

## 5. SusFS - File system Camouflage (optional)
Despite all the spoofing techniques described above, some apps scan the device storage deeply to find traces of potential tampering.

* **Its purpose:** To avoid root status to be discovered in the file system, it becomes necessary to work at kernel level to hide root evidence.
SusFS (Suspicious File System) is a set of Linux kernel patches and sometimes associated module which allow hiding of root access and system modifications at kernel level.
It is primarily used alongside KernelSI root solutions to bypass strict root detection mechanisms in certain applications.
It requires flash of a modified kernel on the device.
* **Interaction:** Kernel-level hiding: It conceals suspicious file paths, mount points, and metadata.
KernelSU complement: Works as an add-on module requiring a pre-patched kernel.
Anti-detection protection: Prevents apps from detecting a modified device.

## Bonus track. Orchestrators
To avoid the hassle of managing the multiple options and parameters of the above described tools, many integrated tools exist to manage them in a centralized UI.
The most popular are Specter (by dpejoh) and IntegrityBox (by MEOWna). They both integrate automatic valid Keybox download and system cleaning features to optimize the rooting experience and ensure all required spoofing settings are applied.

IntegrityBox is partially "vibe-coded" (coded by an AI) which is sometimes considered unnecessarily complex

------------------------------
## Summary of the Action Chain

When you open a sensitive app:

1. Zygisk activates upon app startup and loads the other root modules into memory.
2. HMA-OSS prevents the app from detecting that Magisk, KernelSU, or other modules are installed.
3. SusFS (if present in the kernel) adds a deeper layer of root evidence hiding in the file system.
4. The app requests a security attestation from the system, which queries the TEE (Trusted Execution Environment).
5. The TEE generates an attestation (revealing the unlocked bootloader and an invalid boot hash).
6. Tricky Store intercepts that TEE response before its use: it rewrites the attestation certificate, spoofing the boot hash using a valid Keybox to simulate a locked bootloader state (GREEN).
7. Play Integrity Fix then takes over, crafting a response by injecting the remaining software properties (build fingerprint, security patch level) that match the signature expected by Google Play Integrity API, and returns a "valid" attestation to the app.

I hope this small explanation will be useful to beginners and others.
I will try to update this post with the availability of new tools and when the tools described will be deprecated to reflect rooting techniques evolution.

Cheers and happy rooting to all!