A curated index of Android root detection apps

A README and an APK, not a codebase

The detection repository has a description that reads as a collection of various root detection apps for Android, and the README opens by calling it a meticulously organized collection of Android applications for detecting root, Xposed, custom ROMs, bootloader state, SafetyNet, Play Integrity and other system modifications.

The repository contents reflect that description exactly. There are two entries at the top level: a README.md and a single binary, MemoryDetector_2.1.0.apk. There is no source code, no build system, no test suite and no continuous integration. The project has no declared licence in its metadata, and it publishes no GitHub releases.

So the artefact is the table, and the table is the product. What you get is a categorised list with, for each entry, an app name, aliases, the package name, official links, whether it is open source, a category, the latest version, the date of the last update, and a list of what it detects.

That format is more useful than it first sounds. The package name column alone lets you check what is actually installed on a device, and the detections column is a compact survey of what the current generation of root detection checks for, from Magisk and Zygisk through to hardware-backed key attestation.

One app is hosted in the repository itself. The Memory Detector entry points to this repository as its official link and notes that the APK is in the repo, with a version of v2.1.0 last updated in Jan 2025, and the binary sitting at the root of the tree.

The taxonomy of signals the list covers

The most valuable thing in the table is the shape of its categories, because it shows that root detection is not one problem any more.

The root-solution axis covers Magisk, KernelSU, APatch, Zygisk and ZygiskNext, and the table names the specific implementations that an app claims to catch, including Shamiko, TrickyStore and APatch. Some entries are named after a single solution, such as DetectZygisk with the package com.apkunpacker.detectzygisk and APTest for Magisk-specific detection, and DirtySepolicy for SELinux policy detection, which is described as detecting sepolicy patches used by userspace root solutions.

The hooking axis covers Xposed and LSPosed, with entries such as Ruru at com.byxiaorun.ruru and the XposedChecker, and a column value that mentions hook detection. The environment axis covers custom ROM identification, with Checker at com.akanet.checker listed for identifying ROMs such as MIUI, ColorOS and OneUI, and other entries covering simulators, virtual machines and hardware spoofing.

Then there are the attestation checks, which are a different kind of problem entirely, and the table separates them into their own categories: bootloader attestation, Play Integrity, and SafetyNet.

The last category in the list is the one that surprises people. Kknd_Root_Detector at com.juanma0511.rootdetector is described as having 71 native detection functions, plus SELinux attribute and current probes, DirtySepolicy checks and resetprop detection. Counting that many signals in one app suggests where the arms race has gone: not one check, but dozens.

Attestation and API verdicts versus local heuristics

The distinction the table draws between categories is the one that matters most for anyone designing an app's own integrity checks.

The KeyAttestation sample app, with the package io.github.vvb2060.keyattestation, is listed in the Bootloader Attestation category and is described as detecting bootloader state, key attestation and hardware-backed attestation. A fork under the VisionR1 name appears as a separate entry with a later version, and its detections are given as bootloader status and RKP, remote key provisioning. These checks ask the hardware and the bootloader to attest, rather than asking the running system about itself.

The Play Integrity entries work at a different layer again. The Play Integrity API Checker, with the package gr.nikolasspyr.integritycheck, is listed as producing Play Integrity verdicts, root detection and bootloader status, and SPIC, the Simple Play Integrity Checker, is described as using the Play Integrity API with verdicts such as MEETS_DEVICE_INTEGRITY. TB Checker, with the package krypton.tbsafetychecker, is listed as covering root, Xposed, SafetyNet attestation, Play Integrity and custom ROM.

The practical difference is trust. A local check can be fooled by something in the same environment it is inspecting. An attestation verdict is produced by hardware and by Google's servers, so it moves the decision outside the app, and it comes with its own dependency on Google services being present and reachable.

That is the trade-off a developer has to make explicitly, and the table is useful precisely because it lets you see which apps sit on which side of it.

Open source, closed source and where the apps come from

The table records the open source status of every entry, and the pattern is worth reading before you download anything.

Most entries link to a GitHub repository and are marked open source, such as Ruru, Securify, SPIC, the FOSS Root Checker at foss.chillastro.root.checker, and GarudaDefender at v4.8.0 with a Jul 2026 update, whose detections include root, Shamiko, ZygiskNext, Frida, app tampering and debugger detection.

A smaller group is marked closed source and is distributed through Telegram channels rather than a store or a repository. Momo, with the package io.github.vvb2060.momo, is linked to a Telegram post and covers root, Magisk, Zygisk, LSPosed, code injection, custom ROM and SELinux. Native Test is linked to a channel as well. Luna has an unknown package name and links to a website and a channel. Disclosure, with the package com.disclosure.root, is also channel distributed and its listed detections are unusual: root detection loopholes, HMA-resistant app detection, SUSFS, SELinux context leak and custom kernel.

Two entries come from the Play Store, TB Checker and the Play Integrity API Checker, both closed source.

That mix is the reason the repository has a Download Notes section. The closed-source entries cannot be inspected, so their claims cannot be checked, and a channel-distributed APK is a different trust decision from a store listing. Any team that adopts one of these into a security sensitive flow is trusting the author, not the code.

The staleness problem in the update columns

The last updated column is where the list becomes uncomfortable to read, and it should be read before anything else.

The entries span a wide range of dates. The Xposed Checker entry shows v1.1 with a last update of 2021 and is annotated in the table as outdated. Securify, at com.rabahx.securify, shows v1.0 with a 2023 update. The Play Integrity API Checker is dated Aug 2024. Momo, Native Test, Disclosure, DetectZygisk and APTest are all marked 2024.

Against that, the Checker app is at 1.0.9 from Jan 2026, the VisionR1 KeyAttestation fork is at v2.0.2 from Apr 2026, Native Detector is at v7.7.0 from Apr 2026, Kknd_Root_Detector is at v3.1 from May 2026, the FOSS Root Checker is at v36.23.2.0 from Apr 2026, and GarudaDefender is at v4.8.0 from Jul 2026. The version column is labelled as of Aug 2026, which is when the whole table was compiled, and the repository's last push was on 2026-08-08.

The pattern is that the entries with the broadest detection coverage tend to be the ones still being updated, while the narrow single-signal checkers tend to be the ones that stopped. That makes sense: a detector for one specific root solution has nothing to do once that solution changes, while a detector that checks dozens of signals is maintained precisely because the environment keeps moving.

It also means the table is a picture of a moving target, and a picture of an adversarial field goes out of date on a schedule the project cannot control.

How to actually use the list

The repository is a reference, and the value depends on how you treat it as one.

The first use is reconnaissance. If you are writing an Android application that needs to decide whether it is running on a modified device, the detections column is a menu of signals you could check yourself, and the categories give you the vocabulary. Reading across the column for several apps tells you which signals are common, which are rare, and which are specific to a single tool.

The second use is selection. If you want a detector rather than writing your own, the table narrows a search space of dozens of apps to a handful, and the package name column lets you confirm which one is installed on a test device. Combining two or three detectors with different categories is a reasonable pattern, since the categories are largely independent, and the table is what tells you which combinations are not redundant.

The third use is study. Each open source entry has a repository, and the list is an index into implementations of techniques you can read, from native probes to attestation calls.

The last section of the README is a call for contributions, since the project asks people who know of an app that is not listed to send it in. The How to Contribute and Download Notes sections come after the main table, which suggests the maintainer expects the list to grow.

What the repository is not is a framework, an API or a service. There is no code to integrate, and the only binary it hosts is one of the listed apps.

Editorial conclusion

Use this repository as a shortlist when you are choosing detectors to combine, or as a map of what the Android root detection scene currently checks, since the table names the specific frameworks and signals each app covers. Do not treat it as a drop-in security control, because it is a list of other people's apps with versions and update dates that vary between 2021 and 2026, and several of the listed apps are closed source and distributed through Telegram channels. Before you rely on any entry, check the last updated column for that app, compare the detections it lists with the root solutions you actually need to catch, and verify the download source, since the repository itself ships only a README and one APK.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. rushiranpise/detection on GitHub