RASP — What It Is, How It Works, and Real-Time Protection

What is RASP?

Runtime Application Self-Protection (RASP) is a security technology integrated into the application at build time or through a runtime agent. RASP analyzes application behavior during execution and makes decisions to block attacks based on context: where the call came from, what data is being passed, what the stack state is. Unlike signature-based systems, RASP does not look for known attack patterns — it detects anomalous behavior that deviates from the expected code execution scenario.

The RASP concept was formalized by Gartner in 2011, with the first commercial implementations appearing in 2014–2015. For mobile platforms, RASP began to be actively used in 2017, when the market realized the inadequacy of traditional obfuscation. According to a MarketsandMarkets report (2025), the RASP solutions market is worth $2.8 billion USD with an annual growth of 24.5%. RASP implementation is recommended by the OWASP Mobile Top 10 and PCI DSS 4.0 standards for applications processing payment data.

RASP operates on two levels: interception and assessment. Interception is the hooking of system and library calls through hooks embedded into the code at build time or at runtime through dynamic instrumentation. Assessment is the analysis of the call context: checking input parameters, call stack, sandbox state, debugger presence. The decision is made based on the security policy set by the developer. The policy can be strict (block), soft (log), or adaptive (change behavior depending on the threat level).

How RASP Works: Architecture and Mechanisms

The RASP agent architecture consists of three components: instrumentation layer, analyzer, and policy. The instrumentation layer intercepts system calls and framework calls. The analyzer checks the context against expected patterns. The policy determines the response.

Code Instrumentation

For mobile applications, compile-time instrumentation is used: bytecode or native code is modified at build time — a check is inserted before each dangerous call. The RASP agent compiler modifies entry points FileOutputStream.write(), Runtime.exec(), Class.forName() and android.app.Activity.onStart(). For Android, DEX bytecode transformation is used via Gradle plugin; for iOS, Mach-O binary modification via post-link script.

Context Analysis

When intercepting a call, RASP analyzes: caller class and method (who is calling), stack trace (call chain), arguments (data being passed), return value (what is returned), timestamp and thread id. An anomaly is recorded when, for example, Runtime.exec() is called not from the UI thread and not from the application code, but from a library loaded via JNI with a non-standard path. Or when FileOutputStream.write() receives data containing executable bytecode instead of the expected PNG header.

Response Policies

RASP supports three types of response: Block — crash the application upon attack detection, Log — send incident details to the log collection server without stopping the application, Deceive — replace the return value with a fake one so the attacker gets incorrect data. A combination of Log and Deceive allows gathering intelligence about the attacker without revealing the fact of detection.

// Example: RASP check of Runtime.exec() call
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Checking caller
        String caller = stack[1].getClassName();

        // If the call is not from our package — suspicious
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Checking command against blacklist
        String[] blocked = {"su", "frida", "ptrace", "/data/local"};
        for (String pattern : blocked) {
            if (command.contains(pattern)) {
                SecurityPolicy.reportIncident(
                    "BLOCKED_CMD", command, stack
                );
                return new Process(); // deceiving: empty process
            }
        }

        return null; // allow execution
    }
}

RASP vs WAF and Other Security Tools

RASP is often compared with Web Application Firewall (WAF), but the key difference is in positioning. WAF is located at the network perimeter and only analyzes HTTP requests. RASP operates inside the application and sees the processing logic.

Unlike obfuscation (ProGuard, DexGuard), which makes code unreadable, RASP actively detects attacks during exploitation. Obfuscation is passive protection: if the attacker spends enough time on reverse engineering, the code will be read. RASP is active: it sees that the attacker is trying to debug the application and responds before even a single line of code is read. The combination of obfuscation + RASP provides multi-layered protection, where obfuscation slows down analysis and RASP interrupts the attack at the instrumentation stage.

RASP in Mobile Applications

Mobile RASP solutions are adapted to the specifics of Android and iOS. Unlike server-side Java applications, mobile RASP agents operate under limited memory and battery conditions, requiring lightweight instrumentation.

RASP on Android

On Android, the RASP agent is embedded via a Gradle plugin that modifies DEX bytecode at build time. The agent intercepts over 50 system calls, including: Runtime.exec() to detect execution of su or Frida, Class.forName() to identify loading of suspicious classes, System.loadLibrary() to control loading of native libraries from non-standard paths. Additionally, it checks /proc/self/maps for libraries frida-agent, frida-helper, libinject and substrate.

RASP on iOS

On iOS, RASP is implemented through post-processing of the Mach-O binary. iOS is more complex due to Apple’s strict requirements for binary modification. The agent intercepts calls to functions fork(), dlopen(), ptrace() and checks for CydiaSubstrate.dylib among loaded libraries. RASP for iOS cannot modify code in App Store builds — only for Enterprise distribution. For App Store, compile-time instrumentation via Swift Macro or Objective-C method swizzling is recommended.

Detection of Analysis Tools

Mobile RASP detects: Frida (via checking /proc/self/maps and /data/local/tmp/frida*), Xposed Framework (via checking de.robv.android.xposed.XposedBridge in ClassLoader), JDWP debugger (via Debug.isDebuggerConnected()), emulators (via checking Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) and the debuggable flag in AndroidManifest. According to the NowSecure Mobile Threat Report (2025), a RASP agent detects 89–97% of instrumented Frida sessions.

Implementing a RASP Agent in Practice

Integrating RASP into a mobile application requires configuring instrumentation, defining policies, and integrating with a SIEM system for collecting incident logs.

Implementation Choice: Compile-Time vs Runtime

Compile-time instrumentation — bytecode modification at build time, does not affect runtime performance. Runtime instrumentation (via Java Agent on the server or Frida on the client) is more flexible but adds 5–10% overhead. For mobile applications, the compile-time approach is recommended as it does not require a constant network connection and does not drain battery for analysis.

Integration with Existing Libraries

The RASP agent must work correctly with popular SDKs. Firebase Crashlytics, Google Analytics, and Appsee should not be blocked. Whitelist configuration for known libraries is mandatory. Agent configuration specifies exceptions: if a call comes from a class com.google.firebase — the check is skipped. The whitelist is updated with each SDK release.

Incident Handling Example

When Frida is detected through the RASP agent, the following occurs: context collection (stack trace, OS version, time), sending data to the logging server in encrypted form, executing the policy (crash, log-only, or deceive), incrementing a counter to identify a mass attack. Data from different devices is aggregated on the server to identify attack patterns.

class RASPManager {
    fun analyzeAndReact() {
        val threats = detectThreats()
        if (threats.isNotEmpty()) {
            val report = ThreatReport().apply {
                threats = threats
                timestamp = System.currentTimeMillis()
                deviceId = DeviceInfo.getHashedId()
                stackTrace = Thread
                    .currentThread()
                    .stackTrace
                    .take(10)
                    .toList()
            }

            val policy = SecurityPolicy.getPolicy(threats.maxBy { it.severity })

            when (policy) {
                Policy.BLOCK   -> throw SecurityException("Protection triggered")
                Policy.LOG     -> ServerLogger.sendReport(report)
                Policy.DECEIVE -> DeceptionLayer.activate(report)
            }
        }
    }
}

Limitations and False Positives

RASP is not a silver bullet. The technology has limitations that must be considered when designing protection.

Performance

Each intercepted call adds context checking. With aggressive configuration (intercepting all IO and exec calls), performance may drop by 5–15%. Startup time is critical for mobile applications: RASP initialization adds 200–500 ms at launch. Targeted instrumentation is recommended — only critical functions, not all possible ones. Profiling with the RASP agent is mandatory during testing.

False Positives

RASP may block legitimate behavior: Firebase Crashlytics sending an error stack via a network call could be mistaken for data exfiltration; Google Play Integrity API checking device integrity could be identified as a suspicious call. To reduce false positives, a learning mode period of 7–14 days is required, during which RASP only logs but does not block.

Bypassing RASP

If an attacker gains kernel-level access (via a kernel exploit), RASP cannot trust even its own checks — the agent operates in user space and sees only what the kernel allows it to see. To prevent bypass at the kernel level, Secure Boot Chain verification is used in combination with server-side attestation. Additionally, the RASP agent itself must be obfuscated and protected from debugging — otherwise the attacker will remove or disable RASP before launching the attack.