> ## Documentation Index
> Fetch the complete documentation index at: https://docs.insightsecure.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# RASP — Runtime Application Self-Protection

> How InsightAI's RASP layer works, what it detects, and why it's built the way it is

RASP (Runtime Application Self-Protection) is the on-device half of Device Intelligence — code that runs inside your app and inspects the device and runtime environment it's executing in, without needing a network round-trip to make an initial assessment. It's built against **NPCI2025-26IS003**, the mandatory mobile application security circular for UPI PSPs, ASPs, and TPAPs, and against CSIRT-Fin guidance for the controls that circular doesn't fully specify.

## Why RASP, specifically

Server-side fraud scoring answers "does this transaction look risky." RASP answers a prior, narrower question: **"can I trust the device this transaction is coming from at all?"** A rooted device with Frida attached can, in principle, be used to script around almost any client-side control — RASP's job is to detect that condition itself, as early as possible, rather than only inferring it indirectly from downstream transaction patterns.

## Detection categories

RASP is organized into detection categories, each independently scored and combined into a final decision (see [Scoring & decisions](#scoring-and-decisions) below).

<AccordionGroup>
  <Accordion title="Root / Jailbreak detection" icon="unlock">
    **Android**: su-binary presence across known paths, root-management app detection (Magisk, KingRoot, SuperSU and others), Magisk filesystem markers, `build.prop` tamper flags (`ro.debuggable`, `ro.secure`), and a system-partition write test.

    **iOS**: jailbreak-tooling path checks (Cydia, Sileo), sandbox-escape probing, and a `fork()` capability test — `fork()` only succeeds on a jailbroken iOS sandbox.

    A single root indicator is weighted; several together escalate quickly, since a genuinely rooted device rarely trips only one check.
  </Accordion>

  <Accordion title="Root cloaking resistance" icon="ghost">
    Root-management tools like Magisk's DenyList are specifically designed to hide root status from apps that check for it the usual way. RASP's countermeasure is a **native check below the Java/Kotlin (or Swift) layer**: reading the kernel's `TracerPid` field and probing `ptrace(PTRACE_TRACEME)` directly via JNI/C (Android) or `sysctl()` (iOS). This runs beneath the layer most root-hiding and instrumentation-hooking tools operate at, so cloaking that defeats a Java-layer check often doesn't defeat this one.
  </Accordion>

  <Accordion title="Emulator / simulator detection" icon="desktop">
    Build fingerprint and hardware-string analysis (`goldfish`, `ranchu`, `vbox86` — QEMU/emulator hardware identifiers that don't appear on real devices), CPU ABI checks (emulators are overwhelmingly x86/x86\_64; real phones are ARM), and accelerometer-absence detection (every real device has one; most emulator images don't simulate it).
  </Accordion>

  <Accordion title="Debugger and dynamic instrumentation (Frida)" icon="bug">
    Java-layer debugger attachment checks, a 4-port scan for Frida's default listening ports, Frida server binary presence, and a scan of loaded process memory/dylib maps for known instrumentation-framework signatures (Frida, Substrate, Xposed).

    The same native ptrace/`TracerPid` check from root-cloaking resistance doubles as the strongest signal here — a Frida script attaching to a process is, at the kernel level, indistinguishable from a debugger attaching, and neither can prevent that native check from seeing it.
  </Accordion>

  <Accordion title="App tamper and integrity" icon="file-shield">
    **Android**: runtime signing-certificate hash, compared against your app's known-good hash. A mismatch means the APK was repackaged with a different key — this is a **hard block**, not a weighted signal, because a repackaged app is categorically a different binary, not a riskier version of your app.

    **iOS**: no equivalent runtime signature API exists for third-party apps, so this is a sideload heuristic (App Store receipt presence + absence of an embedded provisioning profile) — meaningfully weaker than Android's cryptographic check, and documented as such rather than presented as equivalent.

    Also covers: install-source validation (Play Store/App Store vs. sideload), and `allowBackup` misconfiguration (Android).
  </Accordion>

  <Accordion title="Ecosystem threats — accessibility abuse, overlays, screen capture" icon="triangle-exclamation">
    Malicious-app detection against a server-maintained threat list (banking trojans and known fraud tooling), suspicious Android AccessibilityService detection (the dominant vector for on-device overlay/keylogging attacks), overlay-permission checks (tapjacking risk), and screen-recording/mirroring detection.
  </Accordion>

  <Accordion title="Network signals" icon="wifi">
    VPN detection via OS-level transport capabilities (not IP-reputation heuristics, which false-positive heavily on legitimate corporate VPN users), and proxy configuration detection.
  </Accordion>

  <Accordion title="SSL pinning" icon="lock">
    Certificate pinning enforced at the SDK's networking layer, capped at 3 pins (primary + two backups) per NPCI2025-26IS003 — independent of the OS certificate trust store, so a compromised or MITM-injected CA certificate doesn't defeat it.
  </Accordion>

  <Accordion title="Hardware-backed device binding" icon="key">
    A device-bound cryptographic key generated in Android Keystore (TEE or StrongBox-backed) or iOS Secure Enclave — the private key never leaves secure hardware, so it can't be extracted even from a rooted device's filesystem. Used to produce a stable, non-spoofable device signature for server-side verification.
  </Accordion>
</AccordionGroup>

## Scoring and decisions

Every evaluation produces a `rasp_score` (0–100) and a `rasp_action`:

| Score                             | Action   | Meaning                                                                                                   |
| --------------------------------- | -------- | --------------------------------------------------------------------------------------------------------- |
| \< 40                             | `PASS`   | No significant risk signal — proceed normally                                                             |
| 40–69                             | `REVIEW` | Elevated risk — route to step-up authentication (OTP, biometric re-confirm) rather than blocking outright |
| ≥ 70, or any hard-block condition | `BLOCK`  | Stop the action — a signature mismatch alone forces this regardless of every other signal                 |

Full field-level detail on what's in the scored payload is in [Webhooks & Payload Reference](/api-reference/webhooks-and-payload).

## Primary use cases

<CardGroup cols={2}>
  <Card title="UPI / payment apps" icon="indian-rupee-sign">
    The core NPCI2025-26IS003 compliance surface — root, tamper, and instrumentation detection at every payment initiation.
  </Card>

  <Card title="Banking app login" icon="building-columns">
    Device trust as a factor alongside credentials — a REVIEW verdict routes to step-up auth instead of a flat allow/deny.
  </Card>

  <Card title="Lending / KYC onboarding" icon="id-card">
    Detecting scripted, automated onboarding attempts and device farms during account creation.
  </Card>

  <Card title="Marketplace checkout" icon="cart-shopping">
    Card-testing and bot-driven checkout abuse detection ahead of payment gateway hand-off.
  </Card>
</CardGroup>