> For the complete documentation index, see [llms.txt](https://docs.talsec.app/appsec-articles/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talsec.app/appsec-articles/articles/zygisk-and-shamiko-how-modern-root-hiding-works-and-how-talsec-detects-it.md). # Zygisk and Shamiko: How modern root hiding works, and how Talsec detects it Root detection used to be relatively straightforward: look for a `su` binary, check a few suspicious paths, maybe search for a known root manager, and you had a decent idea of whether the device was rooted. However, **that is no longer enough.** Modern tools such as Magisk can root Android on such level, that traditional root checks become useless.
## What is Zygisk Before going deeper into Zygisk, it helps to quickly explain Magisk as these two concepts are tied together. ### Magisk: Quick Recap Magisk is one of the most widely used Android rooting frameworks. Its main advantage, and reason why it's so popular, is that it's **systemless**. Instead of directly modifying the Android system partition, Magisk patches the boot environment and applies its modifications during startup. Among other things, this allows users to run applications and commands with root privileges while keeping the original system partition largely untouched. What makes Magisk also powerful are **modules**. #### Magisk Modules Modules are essentially plugins that use the capabilities provided by Magisk to modify Android in some specific way, for example: * Change system properties * Replace files * Run privileged services * Alter how parts of the system behave,... However, having root privileges on the device does not automatically mean that a module can execute code **inside another application's process**. That is where Zygisk comes in. ### What Zygisk do **TLDR: Zygisk allows to use modules within app processes.** One thing you need to know about android lifecycle: Android does not start every application process completely from scratch. Instead, most application processes are created (forked) from a special process called **Zygote**. Zygote starts early during Android boot and preloads large parts of the Android runtime, including ART and commonly used framework classes. When Android needs to start an application, it roughly does this: ```mermaid flowchart LR Z["Zygote"] P["New process"] A["Application process"] Z -->|"fork()"| P P -->|"specialization"| A ``` The new process is then specialized for a particular application by assigning its UID, security context, namespaces, runtime configuration, and other restrictions - that's the hearth of Android Sandboxing. Zygisk adjusts this pipeline by integrating Magisk into it. Modified pipeline then allows Zygisk modules to execute native code inside the newly created application process during this early stage of startup. ```mermaid flowchart LR Z["Zygote"] P["new app process"] S["process specialization"] A["application starts"] Z -->|"fork()"| P P -->|"Zygisk module code runs"| S S --> A ``` A module can now have code running in the same process as the application it wants to influence. For security-sensitive applications, that distinction matters a lot. ## What is Shamiko Normally, Zygisk wouldn't still be such problem, since we can still detect some proofs of Magisk being active on device. And that's where Shamiko comes to the scene. Shamiko is a Zygisk-based Magisk module (= it is able to run code inside an app process) designed to hide signs of root and Magisk from selected applications. The goal is not to remove root from the device, but to make rooted environment harder for an application to observe. This is why simple root checks can report a clean result on a heavily modified device. ## Why standard defenses miss it Traditional root detection usually relies on a handful of well-known indicators. Typical checks include: * Searching for `su` binaries, * Looking for Magisk-related files * Checking installed package names * Inspecting suspicious system properties * Looking for known rooting applications While these checks are still useful signals, we cannot rely on them as proof that a device is not rooted. **Path scans answer the wrong question.**\ `File("/system/xbin/su").exists()` asks "can I see the binary from here?" and not "is this device rooted?" Shamiko changes the answer to the first question without touching the second. **Package enumeration is trivially defeated.**\ Beyond Shamiko itself, modules such as `HideMyApplist` exist specifically to shape what `PackageManager` reports to a chosen app. And since Android 11, package visibility restrictions mean even an honest query sees a filtered list by default. **Play Integrity is not a root check.**\ **Play Integrity is an attestation** of device and app state. While it is a genuinely useful signal, it is a single verdict computed off-device, and the ecosystem around defeating it is mature. It is also restricted to devices with Google services. **Static analysis never sees it.**\ Nothing about the APK changes. The app is genuine, correctly signed, and unmodified. Everything interesting happens at runtime, in Zygote, before your first line of code executes. ## What Talsec detects The design principle is that hiding is *selective*. A module can suppress the artefacts it knows about; it cannot make a compromised runtime environment indistinguishable from a stock one across every axis at once. So the useful posture is many independent signals, weighted, rather than one authoritative check. ### freeRASP **freeRASP** provides the baseline. Its privileged-access detection combines filesystem, process and environment evidence and reports through the `privilegedAccess` threat callback. On the same device where a hand-rolled `su` check returns clean, a layered check has materially more to work with. freeRASP also covers the adjacent signals that matter here: * Hooking * App tampering * Debugger attachment * Emulator state. It is free, it ships for [Android, iOS, Flutter, React Native, Capacitor and more](https://docs.talsec.app/freerasp/integration), and for most teams it is the correct first move. ### RASP+ **RASP+** extends this where the stakes justify it: * Broader and more frequently updated environment coverage for Magisk, Zygisk, Shamiko and KernelSU-class tooling * Tunable response policy ratherthan a raw callback * Talsec App Security Portal for fleet-level visibility so you can seewhat share of your real user base runs a hidden-root configuration instead of guessing. {% hint style="info" icon="book-blank" %} You can find more detailed comparison of freeRASP and RASP+ in [this](https://docs.talsec.app/freerasp/freerasp/features-and-pricing-plans/the-key-difference-freerasp-vs-rasp) article. {% endhint %} ### AppiCrypt Where the risk decision is server-side rather than in-app, [AppiCrypt](https://docs.talsec.app/premium-products/product/appicrypt) gives your backend a cryptographic attestation of app and device integrity that does not depend on Play Integrity's availability or verdict semantics. ## Edge cases and caveats Root detection is a probabilistic exercise, and any article that tells you otherwise is selling something. **Hiding is an arms race with real cadence.** \ Magisk, Zygisk and Shamiko ship updates; so do detections. Any specific artefact described publicly has a shelf life. This is an argument for a maintained SDK over a hand-rolled check, not for perfect detection. **False positives are real.**\ Custom ROMs, developer devices, carrier-modified firmware, region-specific OEM builds and device farms can all trip individual root signals while being entirely benign. Treat root as a risk *input* with a weight, not a binary kill switch - a hard block on a noisy signal is how you lose legitimate users. **"Detected" and "blocked" are different decisions**\ Detection belongs in the SDK; response belongs in your risk policy, and it should usually be graduated — step-up authentication or a transaction limit before an outright block. **Rooting is not fraud.** \ Plenty of rooted-device users are developers and enthusiasts with no intent to abuse anything. The signal is that the device's security guarantees are weaker than stock, which matters for what you allow, not for how you judge the person holding it. **Some signals are version-gated or OEM-dependent** \ and will simply be unavailable on parts of your fleet. Design your policy so absence of a signal is not read as absence of risk. ## Security todo list {% stepper %} {% step %} ### Stop treating your root boolean as ground truth Instrument it: log the *rate* of rooted sessions and compare it against your fraud and chargeback rates. If they do not move together, your signal is being hidden from you. {% endstep %} {% step %} ### Replace path-list checks with a maintained runtime SDK [Integrate freeRASP](https://docs.talsec.app/freerasp/integration) and implement the `privilegedAccess` callback alongside `hooks` and `appIntegrity`. Remember: hidden root frequently travels with a hooking framework, and the combination is far more informative than either alone. {% endstep %} {% step %} ### Move the consequential decision server-side Client-side verdicts on a compromised client are advisory by definition. [AppiCrypt](https://docs.talsec.app/premium-products/product/appicrypt) is designed for exactly this handoff. {% endstep %} {% step %} ### Make the response graduated Rooted + hooked + a first-time device on a high-value transfer is a different decision from rooted alone. {% endstep %} {% step %} ### Know your audience before you set thresholds You cannot tune a policy against an audience you have never measured. {% endstep %} {% endstepper %} ## Further reading [Root Detection](/appsec-articles/glossary/root-detection.md) [Mobile API Anti-abuse Protection with AppiCrypt®: A New Play Integrity and DeviceCheck Alternative](/appsec-articles/articles/mobile-api-anti-abuse-protection-with-appicrypt-r-a-new-play-integrity-and-devicecheck-alternative.md) [How to Achieve Root-Like Control Without Rooting: Shizuku's Perils & Talsec's Root Detection](/appsec-articles/articles/how-to-achieve-root-like-control-without-rooting-shizukus-perils-and-talsecs-root-detection.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.talsec.app/appsec-articles/articles/zygisk-and-shamiko-how-modern-root-hiding-works-and-how-talsec-detects-it.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.