Root detection is a set of checks that an app uses to judge whether a device is rooted. A rooted device gives the user more control over the system. That control can also weaken security guarantees that an app depends on. Banking and payment and enterprise apps often use root detection to decide whether to allow sensitive actions.
Security researchers test root detection on their own apps to find weaknesses before attackers do. That testing involves trying to evade detection in a controlled environment. The goal is to improve detection and to design a safer fallback when detection fails. It is not to help users cheat a service or to access an app that they should not use on a rooted device.
This guide explains how root detection works and how to test evasion honestly on your own apps. Work only on apps that you own or on apps that you have clear permission to test. Use a dedicated test device. Report findings to the app owner through a proper channel when you test an app that belongs to someone else with permission.
Common root detection checks
A common check looks for files and binaries that root tools install. A rooted device may have a su binary in a system path. An app can check for that file and for known root management apps. That check is easy to implement and easy to evade by hiding a file. It should never be the only check in a serious app.
Another check looks at system properties and build tags. A test build or a custom build may report test keys rather than release keys. An app can read those properties and treat a test build as a warning sign. That check helps but it also flags legitimate development devices. Developers should expect that result on test devices.
A stronger check uses native code and system calls to test for root behaviour. It may try to write to a protected directory or check for a debugger or check for hooking frameworks. Native checks are harder to evade than simple file checks. They still cannot prove a negative with certainty. A determined test can often hide root from one check while another check catches it.
Why evasion testing matters for defence
Evasion testing reveals which checks are weak. A check that fails against a simple hiding tool gives little protection in practice. A check that survives several evasion attempts gives stronger protection. Knowing the difference lets a team invest in strong checks rather than in many weak checks that look impressive in a list.
Evasion testing also reveals the right fallback behaviour. An app that detects root should not simply crash with a vague error. It should limit sensitive actions and explain the situation clearly. A user on a rooted device may still need basic features. A graded response protects sensitive actions without punishing every user on a modified device.
Testing should cover the full app flow after evasion. An evasion that bypasses a startup check may still fail at a payment step that uses a stronger check. A defence in depth design checks at several points rather than only at startup. Test each sensitive action separately to confirm that the defence holds where it matters most.
A safe evasion test workflow for your own app
Start by documenting the detection checks in your own app. List each check and the action that follows a positive result. That list is the test plan. For each check design an evasion attempt that targets that check alone. Record whether the attempt succeeded and what the app did after the attempt.
Use a rooted test device that holds no personal data. Install only the test app and the evasion tools that you need for the experiment. Run one evasion attempt at a time and record the result. Several attempts at once make it hard to tell which attempt defeated which check.
After each attempt restore the device to a known state before the next attempt. A leftover hiding tool can affect the next test and create a false result. A clean state for each test gives trustworthy results. Document the device state for each result in your test notes.
- Document every detection check in your own app.
- Test one evasion attempt at a time.
- Restore a clean device state between attempts.
- Record the result for each check separately.
Building stronger detection after testing
Combine several independent checks rather than relying on one check. A file check plus a native check plus a server side attestation check gives a stronger result than any single check. An evader must defeat all checks at once to succeed. That requirement raises the cost of evasion even when no single check is perfect.
Move critical decisions to the server when possible. A server can check attestation and account history and device reputation together. A client check alone can be modified because the client runs on a device that the user controls. A server decision based on attestation is harder to fake honestly and it gives a clearer audit trail.
Design a clear response for detected root. Limit sensitive actions and explain why in plain language. Offer a path for users who believe the detection is wrong such as a support contact. A clear response reduces support load and it treats users fairly. A vague block message frustrates users and increases complaints.
Code you can adapt
// Defence in depth check in your own app
// Combine a file check with a server attestation check
fun isRootSuspected(): Boolean {
val suPaths = listOf("/system/bin/su", "/system/xbin/su")
val fileFound = suPaths.any { File(it).exists() }
// A server attestation verdict should confirm this signal.
// Never rely on this client check alone for a payment decision.
return fileFound
}The snippet above is an original example written for this guide. It shows a simple client check that must be combined with server attestation for any sensitive decision.
The comment in the example is part of the design. It reminds future developers that a client check alone is not enough for a payment decision. Documentation inside code helps a team avoid weakening a defence during a later refactor. A defence that is not understood is a defence that will be removed by accident.
Server attestation adds a layer that client code cannot provide alone. It checks hardware and build state through a trusted service. That layer does not make root detection perfect. It makes evasion harder and it gives the server a signal that the client cannot easily forge.
How this topic connects to nearby work
Root detection and hardware attestation reinforce each other as explained in the guide to Play Integrity hardware attestation.
Hook based evasion uses the module structure built in the guide to custom LSPosed modules from scratch.
Detection code itself needs protection and the common weaknesses are listed in the guide to APK obfuscation mistakes.
Putting it into practice
Legacy SafetyNet confusion still causes support questions for developers who migrate to Play Integrity. SafetyNet attestation and Play Integrity verdicts use different APIs and different labels. A team that mixes the two systems in documentation will confuse support staff. Update internal guides to use Play Integrity terms only after migration. Keep a short migration note that maps old SafetyNet concepts to new verdict labels for staff who remember the old system.
Server side device reputation adds context that client checks cannot provide. A server can track how often a device requests sensitive actions and whether those requests follow a suspicious pattern. A single root check gives a snapshot. A reputation history gives a trend. Use reputation as an additional signal for high risk actions rather than as a replacement for attestation. A trend based signal catches abuse patterns that a snapshot misses.
A final root detection check should test the app on a device that was unrooted after being rooted. A device that was previously rooted may retain files or properties that a check still flags. That residual state can cause a false positive for a user who restored the device. Test the unrooted restored state and decide whether your app should treat it as rooted or as clean. Document that decision so support staff can explain it to affected users.
Common mistakes
A common mistake is to rely on a single file check for root detection. A simple hiding tool can defeat that check in minutes. Combine several checks and add server attestation for sensitive actions. A single check is a warning sign rather than a security boundary.
Another mistake is to test evasion on an app that you do not own without permission. Unauthorised testing can violate terms and law. Test only your own apps or apps with clear permission. Report findings through proper channels when permission testing reveals a weakness.
A third mistake is to block all features when root is detected. A total block punishes users who need basic features on a rooted device. Grade the response by risk. Allow basic use and restrict only sensitive actions such as payments and account changes.
Frequently asked questions
Can root detection ever be perfect?
No. A rooted device gives the user control over the system that runs the checks. Detection raises the cost of evasion and it catches common cases. It cannot prove with certainty that a device is unrooted. Combine detection with server checks for sensitive actions.
Why do legitimate developers test root evasion?
To find weak checks before attackers do. Evasion testing on your own app reveals which checks need improvement. It also helps design a fair fallback when detection triggers. Testing improves defence when done with permission and on your own apps.
Should I publish evasion methods for a popular app?
No without permission and a responsible disclosure process. Publishing a working evasion for a live app can harm users and the app owner. Report the finding privately and allow time for a fix before any public discussion.
Conclusion
Root detection works best as a layered defence rather than a single check. File checks and native checks and server attestation together raise the cost of evasion. Evasion testing on your own apps reveals weak checks and guides stronger design. A graded response protects sensitive actions while treating users fairly.
Your concrete next step is to list the root detection checks in your own app today and test one evasion attempt against the weakest check on a test device. Record the result and use it to plan a stronger combined check before your next release.
