Root checks use more than one signal
OWASP documents checks for files, processes and system properties linked to root access or custom Android builds. Apps can also test package lists, writable paths, command results and native system calls. Protection products often spread these checks across startup and later app actions.
We map each check to the code that consumes it. A true result may close the app, disable a function, change a header or create a risk event sent to the backend.
Emulators differ from physical devices
OWASP notes that emulators do not fully reproduce hardware-backed features such as TEE, StrongBox, biometrics and some identifiers. Apps can also inspect build properties, sensors, telephony data, files and timing. A server may combine those app signals with Play Integrity or a registered device key.
We test the same flow across the environments needed to separate app logic from device behavior. That reveals whether the server needs a simple declared value, a generated fingerprint, a hardware-backed signature or an integrity token.
Keep device checks inside the complete workflow
Root and emulator detection often sits beside login, device enrollment and request signing. Treating it as a single popup misses the server state created before and after the check. We reconstruct the full sequence and test it from a new session.
What you receive
The full APK becomes a callable API in Python and JavaScript/TypeScript with a Postman collection. It includes all app workflows, device registration, authentication, sessions, signature generation, encryption and decryption. Required Android-backed values are exposed through one documented service boundary.
Sources
Reviewed 30 August 2026 · SReverse research desk