su binary present · Android · react-native-device-integrity

At a glance

Platform: Android
Category: Root
Source: IntegrityChecks.kt · checkRootSuBinary
Default status: Makes status compromised
Seen firing: Seen firing in A01, A07. Based on validated scenarios whose observed result includes this signal; see below.
OWASP MASTG: MASTG-TEST-0045

How it works

What the code inspects.

Builds a directory set from a fixed list (/system/bin, /system/xbin, /sbin, /su/bin, /data/local/*, …) plus every entry in the PATH environment variable, then checks for a file named su in each. Also checks /system/app/Superuser.apk.

su is the switch-user binary that grants root; its presence anywhere on PATH is the canonical 'is this device rooted' signal.

The exploit it addresses

Why this matters.The threat.

Root removes the Android app sandbox: any process can read another app's private data and keychain-equivalent storage, attach a debugger, or inject code. The su binary is what root-management apps invoke to elevate a process.

How it can be bypassed

No single check is sufficient.Known evasions.

Magisk's systemless root historically installed su outside these paths and its DenyList / Zygisk hide the binary from targeted apps, so a File.exists check against the app's view returns false.

KernelSU and APatch gate su behind kernel-level access control and can deny visibility to unauthorized apps entirely.

An attacker can relocate or rename su so no known path matches.

Existing isn't enough — the app has to be able to see it: on Google's userdebug emulator /system/xbin/su exists (su_exec, mode 4750 root:shell) but the check stays quiet (scenario S11).

Validation scenarios