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 below).

Root / Jailbreak detection

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.

Root cloaking resistance

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.

Emulator / simulator detection

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).

Debugger and dynamic instrumentation (Frida)

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.

App tamper and integrity

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).

Ecosystem threats — accessibility abuse, overlays, screen capture

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.

Network signals

VPN detection via OS-level transport capabilities (not IP-reputation heuristics, which false-positive heavily on legitimate corporate VPN users), and proxy configuration detection.

SSL pinning

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.

Hardware-backed device binding

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.

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.

Primary use cases

UPI / payment apps

The core NPCI2025-26IS003 compliance surface — root, tamper, and instrumentation detection at every payment initiation.

Banking app login

Device trust as a factor alongside credentials — a REVIEW verdict routes to step-up auth instead of a flat allow/deny.

Lending / KYC onboarding

Detecting scripted, automated onboarding attempts and device farms during account creation.

Marketplace checkout

Card-testing and bot-driven checkout abuse detection ahead of payment gateway hand-off.