Reverse Engineering in der mobilen Entwicklung: Was es ist, Werkzeuge und Analysemethoden

Was ist Reverse Engineering?

Reverse Engineering (Rückwärtsentwicklung) ist die Disziplin der Softwareanalyse, die darauf abzielt, die Eigenschaften, Logik und Struktur einer Anwendung aus ihrer binären Darstellung wiederherzustellen. Für mobile Anwendungen sind die Analyseobjekte APK-Dateien (Android) und IPA-Dateien (iOS), die kompilierten Code, Ressourcen, Manifeste und Zertifikate enthalten. Das Ergebnis von Reverse Engineering ist die Extraktion von Algorithmen, Protokollen, Verschlüsselungsschlüsseln, API-Schemata und Geschäftslogik.

Die Ziele von Reverse Engineering unterteilen sich in legitime und illegitime. Legitim: Analyse von Malware zur Erstellung von Sicherheitswerkzeugen, Audit eigener Anwendungen auf Schwachstellen, Gewährleistung der Kompatibilität mit geschlossenen Protokollen, Patentanalyse und Bildung. Illegitim: Diebstahl geistigen Eigentums, Umgehung von Lizenzbeschränkungen, Erstellung raubkopierter Versionen und Modifikation von Anwendungen zum Diebstahl von Benutzerdaten. Laut Google Play Protect (2025) werden 78 % der bösartigen Modifikationen von Banking-Anwendungen auf Basis der ursprünglichen APK erstellt, die durch Reverse Engineering verarbeitet wurde.

Die Methodik des Reverse Engineering umfasst zwei Hauptrichtungen: statische Analyse (ohne Ausführen der Anwendung) und dynamische Analyse (während der Ausführung). Jeder Ansatz bietet eine andere Informationsebene. Die statische Analyse liefert ein vollständiges Bild des Codes, jedoch ohne Laufzeitdaten. Die dynamische Analyse zeigt das tatsächliche Verhalten, den Datenfluss und Netzwerkaufrufe, jedoch nur innerhalb eines bestimmten Ausführungsszenarios. Professionelles Reverse Engineering kombiniert immer beide Ansätze.

Werkzeuge zur statischen Analyse

Die statische Analyse ist die erste Stufe des Reverse Engineering. Die ursprüngliche APK oder IPA wird entpackt, und jede Komponente wird separat analysiert. Die Hauptziele: DEX-Bytecode, Ressourcen, Manifest, native Bibliotheken (.so, .dylib) und Metadaten.

jadx — DEX-zu-Java-Dekompilierer

jadx ist das wichtigste Werkzeug für die statische Analyse von Android-Anwendungen. Es wandelt DEX-Bytecode mit minimalen Verlusten in lesbaren Java-Code um. jadx unterstützt: Multidex-Dekompilierung, Erkennung von Lambdas und Inline-Kotlin-Klassen sowie Export in Gradle-Projekte. Bei verschleiertem Code (ProGuard) zeigt jadx Code mit Namen a, b, c an, aber die Klassenstruktur und Aufrufsequenz bleiben erhalten. Unabhängigen Tests zufolge dekompiliert jadx selbst bei Verschleierung 85–92 % des Codes korrekt.

apktool — Entpacken von Ressourcen

apktool dekodiert APK in Smali-Code (DEX-Assembler) und stellt Ressourcen in lesbarer Form wieder her: AndroidManifest.xml wird von AXML in lesbares XML umgewandelt, Layouts werden zu XML-Markup, strings.xml zu Klartext. apktool ermöglicht das Ändern von Ressourcen und das Neuerstellen der APK. Nach dem Entpacken über apktool und dem Austausch von Ressourcen kann die Anwendung mit geändertem Inhalt installiert werden.

Ghidra — Analyse nativer Bibliotheken

Ghidra (NSA) ist ein Reverse-Engineering-Framework, das für die Analyse von .so-Bibliotheken unter Android und .dylib unter iOS unverzichtbar ist. Ghidra disassembliert ARM64-Code, rekonstruiert C-Pseudocode und erstellt Aufrufgraphen. Für mobiles Reverse Engineering wird Ghidra zur Analyse nativer Implementierungen von Kryptographie und DRM-Mechanismen verwendet. Ghidra unterstützt Scripting in Python und Java zur Automatisierung der Analyse.

# APK entpacken und dekompilieren
$ jadx -d output_dir app.apk

# Ressourcen via apktool entpacken
$ apktool d app.apk -o app_unpacked

# Native Bibliothek via Ghidra analysieren
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Zeichenkettenkonstanten in DEX suchen
$ strings classes.dex | grep -i api_key

Werkzeuge zur dynamischen Analyse

Die dynamische Analyse wird an einer laufenden Anwendung durchgeführt. Der Analysator verbindet sich mit dem Prozess und fängt Funktionsaufrufe, Argumente und Rückgabewerte in Echtzeit ab.

Frida — universelles Instrumentierungswerkzeug

Frida ist das führende Werkzeug für die dynamische Analyse mobiler Anwendungen. Frida injiziert eine JavaScript-Engine in den Anwendungsprozess (Android ART oder iOS-App) und ermöglicht das Abfangen von Aufrufen sowohl von Java/Objective-C- als auch von C/C++-Funktionen. Mit Frida können Reverse Engineers: alle Aufrufe der AES.decrypt()-Methode mit Parametern protokollieren, Rückgabewerte beliebig ersetzen, SSL-Pinning über Universal Android SSL Unpin deaktivieren und native Aufrufe über Stalker verfolgen. Frida funktioniert ohne Modifikation der APK/IPA, was es für Penetrationstests unverzichtbar macht.

Objection — Frida-Wrapper

Objection bietet vorgefertigte Befehle für häufige Reverse-Engineering-Aufgaben ohne Schreiben von JavaScript-Skripten: disable-pinning (Deaktivierung von SSL-Pinning), dump-keychain (iOS), explore (Durchsuchen der Klassenhierarchie), memory search (Suche nach Zeichenketten im Speicher). Objection ermöglicht eine vollständige dynamische Analyse ohne eine einzige Codezeile. Für iOS-Anwendungen findet und protokolliert Objection automatisch Aufrufe von NSURLSession, CFNetwork und NSKeyedArchiver.

Xposed Framework

Xposed ist ein Framework für Android, das durch Ersetzen der app_process-Datei in Zygote funktioniert. Im Gegensatz zu Frida benötigt Xposed nach der Installation keinen Root-Zugriff. Xposed-Module können Methodenaufrufe in jeder Anwendung abfangen. Für Reverse Engineering ist Xposed für Langzeitanalysen praktisch: Das Modul wird installiert und läuft kontinuierlich, wobei es das Verhalten der Anwendung in verschiedenen Szenarien protokolliert. Xposed unterstützt Android bis Version 8.1; für Android 9+ wird EdXposed auf Basis von SandHook verwendet.

// Frida: decrypt()-Methode in einer Anwendung abfangen
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

Prozess der Rückwärtsentwicklung einer Android-Anwendung

Der Standard-Workflow von Reverse Engineering besteht aus aufeinanderfolgenden Schritten, die jeweils eine bestimmte Informationsebene liefern.

Schritt 1: Informationssammlung

Der Analyst untersucht die APK auf Metadatenebene: targetSdk, uses-permission (welche Berechtigungen angefordert werden), intent-filter und exportierte Komponenten. Anhand der Berechtigungen kann ermittelt werden, welche APIs verwendet werden (android.permission.CAMERA → Kamera, android.permission.RECORD_AUDIO → Audio). Exportierte Aktivitäten identifizieren Einstiegspunkte ohne Authentifizierung. Diese Phase wird über aapt oder ApkAnalyzer durchgeführt und dauert 1–2 Minuten.

Schritt 2: DEX-Dekompilierung

Die APK wird entpackt und classes.dex (oder Multidex) wird an jadx übergeben. Die Ausgabe ist Java/Kotlin-Code, der in Paketen organisiert ist. Der Analyst sucht nach Schlüsselklassen: CryptoUtils, ApiClient, AuthManager, DatabaseHelper, und prüft, welche Algorithmen verwendet werden. Wenn der Code Zeichenketten wie AES/CBC/PKCS5Padding enthält, verwendet die Anwendung Verschlüsselung und der Schlüssel muss gefunden werden. In dieser Phase werden fest codierte Schlüssel, API-URLs, OAuth-Tokens und Geheimnisse identifiziert. Ohne Verschleierung liest sich der gesamte Anwendungscode wie ein normales Java-Projekt.

Schritt 3: Verkehrsanalyse

Nach dem Einrichten von Frida oder Objection zum Deaktivieren von SSL-Pinning startet der Analyst die Anwendung und fängt den Netzwerkverkehr über Burp Suite oder mitmproxy ab. Die Verkehrsdaten offenbaren das API-Schema: welche Endpunkte, welche Parameter und in welchem Format. Wenn möglich, modifiziert der Analyst die Anfragen und prüft die Serverreaktion auf fehlerhafte oder bösartige Daten. Fehlende serverseitige Validierung ist eine direkte Schwachstelle, die in diesem Schritt entdeckt wird.

Schritt 4: Aufzeichnung in data.json

Die Analyseergebnisse werden in strukturierter Form aufgezeichnet. Für jeden gefundenen Schwachpunkt werden angegeben: Klasse und Methode, Beschreibung der Schwachstelle, Ausnutzungsvektor und Korrekturempfehlung. Dieser Datensatz wird an das Entwicklungsteam übergeben oder zur Erstellung eines Penetrationstestberichts verwendet. In automatisierten Umgebungen (MobSF) wird der Bericht automatisch auf Basis der Ergebnisse der statischen und dynamischen Analyse generiert.

Besonderheiten von Reverse Engineering bei iOS-Anwendungen

Reverse Engineering von iOS-Anwendungen ist schwieriger als bei Android aufgrund der strengeren Sicherheitsarchitektur von Apple und des fehlenden direkten Dateisystemzugriffs auf Standardgeräten. Für die iOS-Analyse ist ein Jailbreak erforderlich.

Statische Mach-O-Analyse

Ein IPA-Archiv enthält ein Mach-O-Binärprogramm — das universelle ausführbare Dateiformat von Apple. Für die Dekompilierung werden Hopper Disassembler oder IDA Pro verwendet. Im Gegensatz zu Android DEX, das mit minimalen Verlusten in Java dekompiliert wird, enthält Mach-O nativen ARM64-Code, der mit geringerer Genauigkeit in C-Pseudocode rekonstruiert wird. Hopper erreicht 60–70 % Rekonstruktion; der Rest muss auf Assembly-Ebene analysiert werden.

Dynamische Analyse mit Frida für iOS

Frida auf iOS erfordert Jailbreak und Installation von frida-server. Nach der Verbindung fängt Frida Objective-C-Methoden über API-Message-Routing ab. Für iOS-Anwendungen umfasst ein typisches Szenario: Abfangen von NSURLSession.dataTaskWithRequest zum Protokollieren von HTTP-Anfragen, Abfangen von NSKeyedUnarchiver zur Analyse serialisierter Daten und Verfolgen von CoreData-Abfragen über frida-trace. Frida wurde für iOS 15–17 mit der Veröffentlichung des Dopamine-Jailbreaks verfügbar.

IPA-Modifikation

Reverse Engineering kann die Modifikation der IPA mit anschließendem Neupacken und Installation auf dem Gerät umfassen. Zu den Werkzeugen gehören: ipatool zum Entpacken, MachOView zum Anzeigen von Abschnitten und optool zur Code-Injektion. Nach der Modifikation wird die IPA über ldid oder fastlane sigh zur Installation auf einem jailbroken Gerät signiert. Für iOS 16+ wird die Codesignatur auf Secure-Enclave-Ebene überprüft, und eine modifizierte IPA wird auf einem nicht gejailbreakten Gerät nicht ausgeführt.

// Frida: HTTP-Anfragen in einer iOS-Anwendung abfangen
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Methoden zum Schutz vor Reverse Engineering

Der Schutz vor Reverse Engineering folgt dem Prinzip der mehrschichtigen Sicherheit: Keine einzelne Methode bietet 100%igen Schutz, aber eine Kombination macht Reverse Engineering wirtschaftlich unpraktikabel.

Code-Verschleierung

Die Basisstufe ist ProGuard für Android, das Klassen- und Methodennamen durch einsilbige Namen ersetzt. Für erhöhten Schutz fügt DexGuard Überladungsinduktion (mehrere Methoden mit unterschiedlichen Signaturen und demselben Namen) und AES-256-Zeichenkettenverschlüsselung hinzu. Die Verschleierung erhöht die Code-Analysezeit je nach Stufe von 5 Minuten auf 5–20 Stunden. DexGuard verschleiert zusätzlich den Kontrollfluss und macht den Code für jadx unlesbar.

Konstantenverschlüsselung

Alle Zeichenkettenkonstanten — URLs, Schlüssel, Tokens, SQL-Abfragen — werden zur Build-Zeit verschlüsselt und zur Laufzeit entschlüsselt. Dies schützt vor statischer Analyse von Zeichenketten in DEX-Dateien. Ein Angreifer, der strings auf app.apk ausführt, wird keinen einzigen API-Endpunkt sehen. Selbst nach der Dekompilierung erscheinen alle Zeichenketten als Binärdaten. Jede Zeichenkette kann einen separaten Schlüssel verwenden, was die Entschlüsselung erschwert.

RASP und Integritätsprüfungen

Ein RASP-Agent innerhalb der Anwendung erkennt Frida und Debugging zur Laufzeit. Integritätsprüfungen über SHA-256-Hash der APK verhindern die Ausführung einer modifizierten Version der Anwendung. Wenn der APK-Hash nicht mit dem Referenz-Hash (in der nativen Schicht gespeichert) übereinstimmt, wird die Anwendung beendet. Dies blockiert Angriffe basierend auf APK-Modifikation, einschließlich Repackaging.

Serverseitiger Schutz

Kritische Geschäftslogik sollte auf dem Server ausgeführt werden, nicht auf dem Client. Selbst wenn ein Angreifer die Anwendung vollständig dekompiliert, bleibt der Servercode unzugänglich. Die serverseitige Validierung aller Anfragen und Parameter verhindert die Ausnutzung von Schwachstellen, die während des Reverse Engineering gefunden wurden. Server-Attestierung über Play Integrity API oder App Attest bestätigt, dass die Anfrage von einer echten, unmodifizierten Anwendung stammt.