I have recently been assigned a new security fix for my Android App. The Vulnerability Assessment and Penetration Testing (VAPT) team used Magisk and Magisk hide to bypass the Android root detection implementation.

The description given by the VAPT team:

"Root detection is checked based on package name and availability of su binary."

What they did to bypass Root detection:

  1. Set Magisk application package name to random.
  2. Apply Magisk hide settings. It will hide su binary from Application. So, Application work as normal. The means Magisk Hide lets you use apps without letting it know that it is a rooted device.

Root detection implementation on App:

  1. We have "Root Bear" and "Root Tool" libraries integrated for Root detection on Android device.
  2. All App data are stored in encrypted database on Android App.

I have also checked possible ways to fix like SafetyNet’s Hardware Attestation but I found that it is also not enough.

I found links which say they are able to bypass Safety net detection also:

  1. https://nooberinfo.com/magisk-hide-not-working-on-banking-apps-2021-magisk-hide-not-working-2021-android-11/#19-method-6-updating-magisk-to-magisk-canary-version-to-fix-safetynet-issue-in-android-11
  2. https://www.thecustomdroid.com/fix-safetynet-hardware-attestation-guide/

Questions regarding this scenario:

  1. In case if root detection is bypassed, as database is encrypted there should be no chance of any app data leak. If root detection is bypassed, is an encrypted database secure enough to prevent app from leaking data?

  2. Is there any currently known mitigations available to detect Magisk and Magisk hide on Android app?

  3. If there is a new method to bypass and hide root then there is a need to integrate new Root detection library on Android App which in turn increases Android APK size each time. Is it always a good idea to integrate new libraries for root detection?

  • 1
    Are you trying to protect against malicious third parties, or against the user? Lots of people root their own devices for their own reasons; if you consider those people to be the attacker, your threat model needs work. If it's outsiders you're worried about, then it must be asked whether your app data is so sensitive that you can't afford the marginally higher risk from running on rooted devices. Consider simply warning the user instead of refusing to run on their device?
    – CBHacking
    Commented Sep 5, 2021 at 5:10

1 Answer 1


SafetyNet's hardware-backed attestation hasn't been defeated yet and the way it works, it is infeasible to defeat it by software. Universal SafetyNet Fix Magisk module downgrades evaluation type to BASIC which is software based evaluation that is defeated by Magisk.

All Google apps licensed android 8+ devices are provisioned with TEE so all of them support hardware-backed attestation. You don't have to implement your own detection techniques. Use SafetyNet API and check on your web service if evalType is hardware-backed in the attestation response. You can deny the service to the client if the android version is 8+ and evaluation type is basic.

You have to make exception for the lower android versions because those devices either may not have TEE or their TEE's public key is not certified by Google root certificate authority. Also make an exception for OnePlus7, despite android 8+, it's hardware backed attestation is broken so SafetyNet fallsback to basic evaluation type.

An app with root access can extract secrets of your app by using code injection, memory dump and impersonating your app. TEE cannot prevent compromise of the host OS.

  • I came across your answer here while attempting to find information related to publishing a detection algorithm which detects Magisk Hide. OWASP has an open GitHub issue on this with no solution. @defalt would you be willing to chat privately on the best way to publish a detection solution to OPs Question #2? Thanks Commented Dec 20, 2021 at 6:59
  • @Jared Rummler Sure, we can discuss this in chat.
    – defalt
    Commented Dec 20, 2021 at 10:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .