Android
Test-keys buildRoot
Detects a build signed with Android's public test-keys instead of release-keys.
At a glance
- Platform
- Android
- Category
- Root
- Source
- IntegrityChecks.kt · checkRootTestKeys
- Default status
- Makes status compromised
- Seen firing
- Not yet seen firing in a validated run. Based on validated scenarios whose observed result includes this signal; see below.
- OWASP MASTG
- MASTG-TEST-0045
How it works
What the code inspects.
Reads android.os.Build.TAGS and looks for the substring test-keys.
Official production ROMs are signed release-keys. test-keys means the system image was built and signed with the publicly available AOSP keys — typical of custom ROMs and many rooted / developer builds.
The exploit it addresses
Why this matters.The threat.
A test-keys system image is not the manufacturer's verified build: anyone can produce and sign one, so the OS's own code-integrity guarantees (Verified Boot) do not hold. Custom ROMs commonly ship pre-rooted or with relaxed security.
How it can be bypassed
No single check is sufficient.Known evasions.
Build.TAGS is just a system property an attacker with root can set to release-keys; it is a weak, easily-spoofed signal on its own.
Some legitimate custom ROMs spoof release-keys precisely to pass this kind of check.
Validation scenarios
Where this check is exercised.2 scenarios.
References & further reading
- MASTG-TEST-0045: Testing Root Detection (Android)Open ↗
https://mas.owasp.org/MASTG/tests/android/MASVS-RESILIENCE/MASTG-TEST-0045/
- android.os.Build#TAGSOpen ↗
https://developer.android.com/reference/android/os/Build#TAGS
- Android signing builds (release-keys vs test-keys)Open ↗
https://source.android.com/docs/core/ota/sign_builds
- Android Verified BootOpen ↗
https://source.android.com/docs/security/features/verifiedboot