Device is Blacklisted at runtime, now what?

Have you ever wondered how the Runtime Application self/security Protection isolates the device once it identifies the Root traces?

During an Android application assessment, I encountered a runtime protection behavior in which repeated root detection events (observed within 3–5 attempts) triggered a RASP enforcement mechanism. The application subsequently blacklisted the device by correlating device fingerprint characteristics with unique device identifiers, effectively blocking further access from the same mobile environment.

This article does not discuss methodology for bypassing RASP protections. Instead, it focuses on post-bypass analysis scenarios where root detection has already been neutralized, but device-level blocking remains enforced by the service provider.

Technical exploitation

In Magisk’s Deny list, apply the check for the target application as shown in the below screenshot.

Now, in Hide my applist module, configure the template and presets for the target application.

As application has previously detected Root detection 3–5 times on the device, the runtime protection isolates the device and rather than layered dialog/toast messages for Busy box binary, SU Binary, etc., the app says “Rooting detected” as shown below. This means device has been blacklisted

How does RASP API call works for isolating a device?

The below diagram illustrates how the mobile app integrates the RASP SDK to collect multi-layer device signals, generate a signed device fingerprint, and transmit it to the backend for risk evaluation and policy enforcement (Permission/Decision such as allow, restrict, or blacklist).

┌──────────────────────────────┐
│        Mobile Application    │
│         (With RASP SDK)      │
└──────────────┬───────────────┘
               │
               │ ① Collect Signals
               ▼
┌─────────────────────────────────────────┐
│        On-Device Data Collection         │
│                                         │
│ • Build fingerprint / model / OS        │
│ • Hardware profile & sensors            │
│ • Baseband / telephony info             │
│ • Root / hook / debugger detection      │
│ • Emulator & environment indicators     │
│ • App integrity & runtime state         │
└──────────────┬──────────────────────────┘
               │
               │ ② Normalize + Hash + Sign
               ▼
┌─────────────────────────────────────────┐
│        Device Signature Object          │
│                                         │
│  deviceSignature {                      │
│     systemProfile                       │
│     integrityFlags                      │
│     environmentSignals                  │
│     appMetadata                         │
│  }                                      │
└──────────────┬──────────────────────────┘
               │
               │ ③ Secure API Transmission (TLS)
               ▼
┌─────────────────────────────────────────┐
│         Risk Evaluation Server          │
│                                         │
│ • Reconstruct fingerprint               │
│ • Compare with reputation database      │
│ • Detect anomalies / spoofing           │
│ • Apply policy rules                    │
│ • Calculate risk score                  │
└──────────────┬──────────────────────────┘
               │
               │ ④ Enforcement Response
               ▼
┌─────────────────────────────────────────┐
│           API Decision Payload          │
│                                         │
│ riskScore                               │
│ deviceStatus (trusted / blocked)        │
│ action (allow / restrict / blacklist)   │
└──────────────┬──────────────────────────┘
               │
               │ ⑤ App Enforcement
               ▼
┌──────────────────────────────┐
│      Runtime Protection       │
│ • Allow normal usage          │
│ • Restrict features           │
│ • Device blacklisting         │
└──────────────────────────────┘

To bypass this additional layer check, I had to modify and spoof the system properties one by one, listed in the below screenshot.

Also, primarily the RASP looks for Android Device ID for blocking the device.

Android Device ID is a 64-bit hex string generated when a device is first set up and tied to the device + user profile. Apps commonly use it as a stable identifier for analytics, fraud detection, and device fingerprinting.

Now, device ID was spoofed using https://github.com/sidex15/deviceidchanger and Reboot the device as shown below.

Boom, device blacklisting was successfully bypassed.

Key takeaways

• Device blacklisting is enforced using composite fingerprints, not a single identifier.
• ANDROID_ID spoofing alone does not ensure evasion due to multi-signal correlation.
• RASP solutions perform server-side risk evaluation, limiting client-side manipulation impact.
• Bypassing root detection does not equal bypassing device trust enforcement; as observed in your Android VAPT case.
• Effective mobile protection relies on correlated hardware, software, and behavioral signals rather than isolated props.

Thank you for taking the time to read this article. I hope it provided meaningful insights into modern Android pentesting practices and offered practical perspective on real-world mobile security assessments.

Device is Blacklisted at runtime, now what? was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.