MagiskDetection: a shelf of root-detection proof-of-concept APKs

A repository of binaries rather than a detection library

MagiskDetection is described by its own README as a collection of publicly available proof-of-concept apps for detecting root and Magisk presence. There is no code to integrate, no Gradle dependency and no supported API. What the repository root actually holds is a shelf of APK files, including DuckDetector releases, several versions of Hunter, three Native-root-detector builds, a ZygiskDetector archive, a JingMatrix demo, and the source zip for the Duck Detector refactoring. Each entry in the README names the app, its package identifier and the checks it performs, and links to the original project on GitHub where source is available. For someone learning how detection is done, that mapping is the valuable part. For someone trying to protect a shipping application, this is a sample archive with the confidence and support that implies.

Detection coverage ranges from a single Magisk check to a full anti-analysis suite

The breadth across entries is striking. At the narrow end, DetectMagisk and the MagiskDetector app list just two items, Magisk Detection and Magisk Hide Detection. At the wide end, the CrackME sample lists nineteen capabilities, including anti-hooking, dynamic tamper detection, anti-FRIDA, anti-emulation, root detection, certificate signature integrity, emulator and virtual machine detection, memory patch detection, Dalvik code patch detection, screen protection, fake GPS detection, string encryption and control flow obfuscation at the Java layer, HTTP capture detection and certificate SSL pinning. Momo goes further into environment state, covering developer mode, bootloader, SELinux state, package manager abnormality, Magisk module presence and system files modified by Magisk. Each sample is a different author's implementation of an overlapping problem, which is exactly what makes the collection useful for comparison.

Some entries list source repositories, others are closed binaries

The README is explicit that the maintainer is not the owner or original creator of these files unless stated, and it lists upstream source links for a subset. Duck Detector points at the Duck-Detector-Refactoring repository and offers a fork under the apkunpacker organisation in case the original is deleted. DirtySepolicy is credited to the LSPosed project, DetectZ points to a DetectZygisk repository and references the ReZygisk, ZygiskNext and NeoZygisk projects, and JingMatrix is credited to a Demo repository with a fork as backup. Others are listed as source not available, such as the Native Root Detector entry, which notes the original is private. That mixed provenance is the practical constraint: you can audit a few of these detection approaches in source form, while the rest are binaries you would have to trust or reverse.

The list of SHA256 hashes is what makes the archive usable

The README publishes a block of SHA256 digests, one per file, framed as a way to trace each artifact back on VirusTotal, Koodous or a similar sample repository. That single decision changes how the collection should be handled. An archive of redistributed binaries with no hashes is a supply chain problem; an archive where every file can be checked against a published digest is at least verifiable. The digests are printed in a plain shell block so they can be copied directly, and the first entries look like this.

8a39869f0ace5a2e624f2392b0b15d813306d0589a43bed99090e9e0dbf2d086
93dd81e76790c9ce3709ad6871fb00e0b759858fffd0a51c6cce23a1d62b6c23
ae1b8e12ebdbc09181c47a1dff52b35f8b5d9d5541bcbdacaacb92f0879c953a

The ZygiskDetector archive in the root is a password-protected zip, and the README states the archive password where applicable is "infected", which is a strong signal that these packages are expected to trip virus scanners and should be treated accordingly rather than whitelisted.

Running a sample means installing an unknown APK, not calling an API

There is no install script, no Gradle build and no configuration file in this repository. The samples are standalone APKs that you put on a device or emulator and open, and the README itself points back to each original project for anything more. The Duck Detector source zip is the one artifact in the root you can read rather than run, and it exists because the original repository may be deleted, in which case the README tells you to fall back on the fork under the same apkunpacker organisation. The practical workflow is therefore download, verify the digest against the published list, then install on a throwaway device. There is no supported distribution channel and no signing information to check, so nothing in the repository tells you whether a given build matches the upstream project it claims to come from.

Where a detection library and a sample archive diverge

The practical alternative to a PoC collection is a maintained detection library that an application embeds, where detection results are returned through a documented API and the vendor ships updates as the rooting landscape changes. The difference in approach is architectural, not a matter of coverage. A library runs inside your process, lets you decide what to do on a positive result, and comes with a release history. The samples here do none of that. They are standalone apps that display a verdict, designed to be run and observed, and each implements checks independently, so their results can disagree about the same device state. If the goal is to see whether a given rooting method is caught today, running two or three of these side by side is more informative than reading any one of them.

No release history, no declared licence, updates come from a Telegram channel

The repository publishes no GitHub releases, and the README does not declare a licence for the redistributed files, which leaves the terms for the binaries and the archived source unclear. It does point to a Telegram channel for the most frequent updates of the various proof-of-concept samples, so the channel, not a versioned release feed, is where you learn about new builds. The last push to the repository was on 2026-05-10, so the archived set of files itself has not changed in a while even if upstream projects continue to move. The README asks that use, download and redistribution be strictly at your own risk, and frames the material as provided as-is for educational and archival purposes. That framing is a warning label, not a permission grant, and it is worth taking literally when the files are encrypted archives named for a malware password.

Editorial conclusion

MagiskDetection fits reverse engineers and detection researchers who want concrete samples to study, since each entry points back to its original project and carries a hash for tracing on sample-sharing services. It does not fit an application team that needs a supported detection library, because there is no maintained API, the licence is unknown, and the repository explicitly disclaims ownership of the binaries it republishes. Verify first that the SHA256 value of any file you take matches the list in the README, and treat the samples as hostile artifacts to run in an isolated emulator rather than on a device holding real accounts.

Frequently asked questions

Official sources

1. apkunpacker/MagiskDetection on GitHub
2. Issues
3. README