RASP — was es ist, Arbeitsprinzip und Echtzeitschutz

Was ist RASP?

Runtime Application Self-Protection (RASP) ist eine Sicherheitstechnologie, die während der Build-Zeit oder über einen Laufzeit-Agenten in die Anwendung integriert wird. RASP analysiert das Verhalten der Anwendung während der Ausführung und trifft Entscheidungen zur Blockierung von Angriffen basierend auf dem Kontext: Woher der Aufruf kam, welche Daten übergeben werden, wie der Stapelzustand ist. Im Gegensatz zu signaturbasierten Systemen sucht RASP nicht nach bekannten Angriffsmustern — es erkennt anomales Verhalten, das vom erwarteten Code-Ausführungsszenario abweicht.

Das RASP-Konzept wurde 2011 von Gartner formalisiert, und die ersten kommerziellen Implementierungen erschienen 2014–2015. Für mobile Plattformen wurde RASP ab 2017 aktiv eingesetzt, als der Markt die Unzulänglichkeit traditioneller Verschleierung erkannte. Laut einem Bericht von MarketsandMarkets (2025) beträgt der Markt für RASP-Lösungen 2,8 Mrd. USD bei einem jährlichen Wachstum von 24,5 %. Die Implementierung von RASP wird von den Standards OWASP Mobile Top 10 und PCI DSS 4.0 für Anwendungen empfohlen, die Zahlungsdaten verarbeiten.

RASP arbeitet auf zwei Ebenen: Abfangen und Bewerten. Abfangen ist das Hooking von System- und Bibliotheksaufrufen durch Hooks, die während der Build-Zeit oder zur Laufzeit durch dynamische Instrumentierung in den Code eingebettet werden. Bewerten ist die Analyse des Aufrufkontexts: Prüfung von Eingabeparametern, Aufrufstapel, Sandbox-Zustand, Vorhandensein eines Debuggers. Die Entscheidung wird basierend auf der vom Entwickler festgelegten Sicherheitsrichtlinie getroffen. Die Richtlinie kann streng (blockieren), weich (protokollieren) oder adaptiv (Verhalten je nach Bedrohungsstufe ändern) sein.

Wie RASP funktioniert: Architektur und Mechanismen

Die Architektur des RASP-Agenten besteht aus drei Komponenten: Instrumentierungsschicht, Analysator und Richtlinie. Die Instrumentierungsschicht fängt System- und Framework-Aufrufe ab. Der Analysator prüft den Kontext auf erwartete Muster. Die Richtlinie bestimmt die Reaktion.

Code-Instrumentierung

Für mobile Anwendungen wird Compile-Time-Instrumentierung verwendet: Bytecode oder nativer Code wird während der Build-Zeit modifiziert — vor jedem gefährlichen Aufruf wird eine Prüfung eingefügt. Der Compiler des RASP-Agenten modifiziert die Einstiegspunkte FileOutputStream.write(), Runtime.exec(), Class.forName() und android.app.Activity.onStart(). Für Android wird DEX-Bytecode-Transformation über ein Gradle-Plugin verwendet; für iOS die Modifikation des Mach-O-Binärcodes über ein Post-Link-Skript.

Kontextanalyse

Beim Abfangen eines Aufrufs analysiert RASP: Aufruferklasse und -methode (wer aufruft), Stack-Trace (Aufrufkette), Argumente (übergebene Daten), Rückgabewert (was zurückgegeben wird), Zeitstempel und Thread-ID. Eine Anomalie wird aufgezeichnet, wenn beispielsweise Runtime.exec() nicht vom UI-Thread und nicht vom Anwendungscode aus aufgerufen wird, sondern von einer Bibliothek, die über JNI mit einem nicht standardmäßigen Pfad geladen wurde. Oder wenn FileOutputStream.write() Daten erhält, die ausführbaren Bytecode statt des erwarteten PNG-Headers enthalten.

Reaktionsrichtlinien

RASP unterstützt drei Arten von Reaktionen: Block — sofortiges Beenden der Anwendung bei Angriffserkennung, Log — Senden von Incident-Details an den Protokollsammelserver ohne Stoppen der Anwendung, Deceive — Ersetzen des Rückgabewerts durch einen falschen, damit der Angreifer falsche Daten erhält. Eine Kombination von Log und Deceive ermöglicht das Sammeln von Informationen über den Angreifer, ohne die Tatsache der Erkennung preiszugeben.

// Beispiel: RASP-Prüfung des Runtime.exec()-Aufrufs
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Prüfe Aufrufer
        String caller = stack[1].getClassName();

        // Wenn der Aufruf nicht aus unserem Paket stammt — verdächtig
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Befehl gegen Blacklist prüfen
        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: leerer Prozess
            }
        }

        return null; // Ausführung erlauben
    }
}

RASP vs WAF und andere Sicherheitswerkzeuge

RASP wird oft mit Web Application Firewall (WAF) verglichen, aber der grundlegende Unterschied liegt in der Positionierung. WAF befindet sich an der Netzwerkperipherie und analysiert nur HTTP-Anfragen. RASP arbeitet innerhalb der Anwendung und sieht die Verarbeitungslogik.

Im Gegensatz zur Verschleierung (ProGuard, DexGuard), die Code unlesbar macht, erkennt RASP Angriffe aktiv während der Ausnutzung. Verschleierung ist passiver Schutz: Wenn der Angreifer genügend Zeit für Reverse Engineering aufwendet, wird der Code gelesen. RASP ist aktiv: Es sieht, dass der Angreifer versucht, die Anwendung zu debuggen, und reagiert, bevor auch nur eine einzige Codezeile gelesen wird. Die Kombination von Verschleierung + RASP bietet mehrschichtigen Schutz, bei dem die Verschleierung die Analyse verlangsamt und RASP den Angriff in der Instrumentierungsphase unterbricht.

RASP in mobilen Anwendungen

Mobile RASP-Lösungen sind an die Besonderheiten von Android und iOS angepasst. Im Gegensatz zu serverseitigen Java-Anwendungen arbeiten mobile RASP-Agenten mit begrenztem Speicher und Akku, was eine leichte Instrumentierung erfordert.

RASP auf Android

Auf Android wird der RASP-Agent über ein Gradle-Plugin eingebettet, das den DEX-Bytecode während der Build-Zeit modifiziert. Der Agent fängt über 50 Systemaufrufe ab, darunter: Runtime.exec() zur Erkennung der Ausführung von su oder Frida, Class.forName() zur Identifizierung des Ladens verdächtiger Klassen, System.loadLibrary() zur Kontrolle des Ladens nativer Bibliotheken von nicht standardmäßigen Pfaden. Zusätzlich wird in /proc/self/maps nach den Bibliotheken frida-agent, frida-helper, libinject und substrate gesucht.

RASP auf iOS

Auf iOS wird RASP durch Nachbearbeitung des Mach-O-Binärcodes implementiert. iOS ist aufgrund der strengen Anforderungen von Apple an die Binärmodifikation komplexer. Der Agent fängt Aufrufe der Funktionen fork(), dlopen(), ptrace() ab und prüft auf das Vorhandensein von CydiaSubstrate.dylib in den geladenen Bibliotheken. RASP für iOS kann Code in App Store-Builds nicht modifizieren — nur für Enterprise-Verteilung. Für den App Store wird Compile-Time-Instrumentierung über Swift Macro oder Objective-C Method Swizzling empfohlen.

Erkennung von Analysetools

Mobiles RASP erkennt: Frida (durch Prüfung von /proc/self/maps und /data/local/tmp/frida*), Xposed Framework (durch Prüfung von de.robv.android.xposed.XposedBridge im ClassLoader), JDWP-Debugger (durch Debug.isDebuggerConnected()), Emulatoren (durch Prüfung von Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) und das debuggable-Flag in AndroidManifest. Laut dem NowSecure Mobile Threat Report (2025) erkennt ein RASP-Agent 89–97 % der instrumentierten Frida-Sitzungen.

Praktische Implementierung eines RASP-Agenten

Die Integration von RASP in eine mobile Anwendung erfordert die Konfiguration der Instrumentierung, die Definition von Richtlinien und die Integration mit einem SIEM-System zur Erfassung von Vorfallsprotokollen.

Implementierungswahl: Compile-Time vs Runtime

Compile-Time-Instrumentierung — Bytecode-Modifikation während der Build-Zeit, beeinträchtigt die Laufzeitleistung nicht. Runtime-Instrumentierung (über Java Agent auf dem Server oder Frida auf dem Client) ist flexibler, fügt jedoch 5–10 % Overhead hinzu. Für mobile Anwendungen wird der Compile-Time-Ansatz empfohlen, da er keine ständige Netzwerkverbindung erfordert und keinen Akku für die Analyse verbraucht.

Integration mit vorhandenen Bibliotheken

Der RASP-Agent muss korrekt mit populären SDKs funktionieren. Firebase Crashlytics, Google Analytics und Appsee sollten nicht blockiert werden. Die Whitelist-Konfiguration für bekannte Bibliotheken ist obligatorisch. In der Agentenkonfiguration werden Ausnahmen festgelegt: Wenn ein Aufruf von der Klasse com.google.firebase kommt — wird die Prüfung übersprungen. Die Whitelist wird mit jeder SDK-Version aktualisiert.

Beispiel für die Incident-Behandlung

Wenn Frida durch den RASP-Agenten erkannt wird, geschieht Folgendes: Kontextsammlung (Stack-Trace, OS-Version, Zeit), Senden der Daten in verschlüsselter Form an den Protokollierungsserver, Ausführung der Richtlinie (Absturz, Nur-Protokollierung oder Deceive), Erhöhung eines Zählers zur Identifizierung eines Massenangriffs. Daten von verschiedenen Geräten werden auf dem Server aggregiert, um Angriffsmuster zu identifizieren.

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

Einschränkungen und Fehlalarme

RASP ist keine Silberkugel. Die Technologie hat Einschränkungen, die bei der Gestaltung des Schutzes berücksichtigt werden müssen.

Leistung

Jeder abgefangene Aufruf fügt eine Kontextprüfung hinzu. Bei aggressiver Konfiguration (Abfangen aller IO- und Exec-Aufrufe) kann die Leistung um 5–15 % sinken. Die Startzeit ist für mobile Anwendungen kritisch: Die RASP-Initialisierung fügt 200–500 ms beim Start hinzu. Gezielte Instrumentierung wird empfohlen — nur kritische Funktionen, nicht alle möglichen. Die Profilierung mit dem RASP-Agenten ist während der Tests obligatorisch.

Fehlalarme

RASP kann legitimes Verhalten blockieren: Firebase Crashlytics, das einen Fehlerstapel über einen Netzwerkaufruf sendet, könnte als Datenexfiltration fehlinterpretiert werden; die Google Play Integrity API, die die Geräteintegrität prüft, könnte als verdächtiger Aufruf identifiziert werden. Zur Reduzierung von Fehlalarmen ist ein Lernmodus-Zeitraum von 7–14 Tagen erforderlich, in dem RASP nur protokolliert, aber nicht blockiert.

Umgehung von RASP

Wenn ein Angreifer Kernel-Level-Zugriff erlangt (durch einen Kernel-Exploit), kann RASP nicht einmal seinen eigenen Prüfungen vertrauen — der Agent arbeitet im Benutzerraum und sieht nur, was der Kernel ihm zu sehen erlaubt. Zur Verhinderung der Umgehung auf Kernel-Ebene wird die Secure Boot Chain-Prüfung in Kombination mit Server-Attestierung verwendet. Darüber hinaus muss der RASP-Agent selbst verschleiert und vor Debugging geschützt sein — andernfalls entfernt oder deaktiviert der Angreifer RASP vor Beginn des Angriffs.