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.