Eine strukturierte Methode, um mobile Apps in einem legalen, ethischen und defensiven Audit-Kontext zu analysieren.

Mobile Reverse Engineering: Methode, Tools und gute Praktiken

0

Eine strukturierte Methode, um mobile Apps in einem legalen, ethischen und defensiven Audit-Kontext zu analysieren.

Foto: Tima Miroshnichenko / Pexels
11 min read

Ziel und Grenzen

Mobile Reverse Engineering bedeutet, von einem kompilierten Artefakt auszugehen, zum Beispiel einer Android-.apk oder iOS-.ipa, um zu verstehen, wie die App funktioniert. Ziel kann Lernen, das Audit der eigenen App, die Prüfung von Sicherheitspraktiken oder die Dokumentation eines Verhaltens sein.

Diese Anleitung dient nicht dazu, Authentifizierung zu umgehen, private Daten abzurufen, undokumentierte APIs zu missbrauchen oder Nutzer ohne Erlaubnis zu verfolgen. Nutze diese Techniken nur für eigene Apps, Testumgebungen, absichtlich verwundbare Labs oder ausdrücklich autorisierte Audits.

Den rechtlichen Rahmen definieren

Vor jeder Analyse sollte der Scope dokumentiert werden:

Anwendung:
Version:
Plattform: Android / iOS
Ziel: Lernen / internes Audit / Bug Bounty / Pentest
Autorisierung: ja / nein
Testdaten:
Erlaubte Aktionen:
Verbotene Aktionen:
Security-Kontakt:

Eine öffentlich herunterladbare App erlaubt nicht automatisch das Extrahieren von Secrets, Automatisieren privater APIs, Umgehen von Schutzmechanismen oder Zugreifen auf fremde Daten. Arbeite bevorzugt mit eigenen Apps, Open-Source-Apps, OWASP-Mobile-Labs, Staging-Umgebungen oder Bug-Bounty-Programmen mit klaren Regeln.

Statische und dynamische Analyse

Statische Analyse untersucht die App, ohne sie auszuführen: Manifest, Berechtigungen, Konfigurationsdateien, Ressourcen, Strings, dekompilierten Code, Zertifikate und eingebettete Bibliotheken.

Dynamische Analyse beobachtet die App während der Ausführung: Logs, lokale Dateien, gespeicherte Einstellungen, lokale Datenbanken, Nutzerszenarien und, in einem autorisierten Rahmen, Netzwerkverkehr.

Statische Analyse liefert die Karte; dynamische Analyse zeigt das reale Verhalten.

Umgebung vorbereiten

Trenne die Analyseumgebung von deinem privaten Telefon. Ideal sind:

  • ein Linux-, macOS- oder Windows-Rechner;
  • ein Android-Testtelefon oder Emulator;
  • ein dedizierter Testaccount;
  • keine sensiblen persönlichen Daten auf dem Gerät;
  • fiktive Daten für Szenarien.

Nützliche Tools

Auf Android sind häufige Tools:

  • adb zur Kommunikation mit dem Gerät;
  • jadx zum Dekompilieren eines APKs in approximativen Java/Kotlin-Code;
  • apktool zum Dekodieren von Ressourcen und Manifest;
  • Android Studio für Emulator, Logs und Inspektion;
  • MobSF für eine automatisierte erste Analyse;
  • mitmproxy, Burp Suite, Proxyman oder Charles Proxy für autorisierte Traffic-Beobachtung;
  • Frida für dynamische Instrumentierung in einem streng definierten Testscope.

Auf iOS ist die Analyse oft eingeschränkter. Man nutzt etwa Xcode, Console.app, MobSF, Frida, Mach-O-Tools und manchmal class-dump oder moderne Alternativen. Für den Einstieg ist Android meist zugänglicher.

APK beschaffen und dokumentieren

Von einem Android-Testgerät lässt sich eine App lokalisieren:

adb shell pm list packages | grep app.name
adb shell pm path com.example.application

Dann wird die Datei kopiert:

adb pull /data/app/pfad/base.apk ./application.apk

Je nach Android-Version kann eine App in mehrere APKs aufgeteilt sein: base.apk, Sprach-Split, Architektur-Split oder Dichte-Split. Dokumentiere die Version:

aapt dump badging application.apk
sha256sum application.apk

Der Hash verhindert Unklarheiten im Bericht.

Erste Analyse mit apktool

apktool dekodiert Ressourcen und Manifest:

apktool d application.apk -o application_decoded

Die Struktur sieht etwa so aus:

application_decoded/
├── AndroidManifest.xml
├── apktool.yml
├── res/
├── smali/
└── assets/

Das Manifest beschreibt Paket, Activities, Services, Receivers, Providers, Deep Links, Berechtigungen und Netzwerkkonfiguration. Die nützliche Frage lautet nicht nur "welche Berechtigungen werden angefordert?", sondern "passen sie zur beworbenen Funktion?".

Exportierte Komponenten und Berechtigungen

Eine exportierte Komponente kann von anderen Apps aufgerufen werden:

<activity
    android:name=".SomeActivity"
    android:exported="true" />

Das ist nicht automatisch eine Schwachstelle, sollte aber geprüft werden. Prüfe auch sensible Berechtigungen wie Standort, Kamera, Kontakte, Speicher, Mikrofon oder Benachrichtigungen. Jede Berechtigung braucht einen klaren Produktgrund.

Dekompilieren mit JADX

JADX liefert eine approximative Java/Kotlin-Darstellung:

jadx-gui application.apk
jadx -d jadx_output application.apk

Das Ergebnis kann unvollständig, obfuskiert oder vom Originalcode verschieden sein. Es hilft dennoch, Architektur, Modelle, Bibliotheken und sensible Bereiche zu verstehen.

Nützliche Suchbegriffe:

http, https, api, baseUrl, retrofit, okhttp, graphql,
firebase, sentry, amplitude, mixpanel,
token, auth, jwt, bearer, secret, client_id

Diese Suchen dienen der Risikokartierung in defensiven Audits, nicht der Wiederverwendung von Secrets.

Ressourcen und Konfiguration

Untersuche assets/, res/raw/ und res/xml/. Dort finden sich manchmal Umgebungs-URLs, Flags, JSON-Dateien, Firebase-Konfiguration, öffentliche Zertifikate oder Regeln zur Netzwerksicherheit.

Eine Android-Netzwerkkonfiguration kann so aussehen:

<application
    android:networkSecurityConfig="@xml/network_security_config">
</application>

Prüfe, ob Klartext-HTTP erlaubt ist, ob spezifische Domains konfiguriert sind, ob debug/release unterschiedlich sind, welche Zertifikate vertraut werden und ob Certificate Pinning genutzt wird.

Lokaler Speicher

In einer autorisierten Umgebung prüft man häufig:

/data/data/com.example.application/
├── shared_prefs/
├── databases/
├── files/
├── cache/
└── no_backup/

Suche nach Tokens, personenbezogenen Daten, Historien, sensiblen Einstellungen, temporären Dateien oder Sitzungsdaten. Gute Praktiken sind minimaler Speicher, Verschlüsselung sensibler Daten, Session-Ablauf, keine statischen Secrets und keine sensiblen Daten in Logs.

Logs und Netzwerkverkehr

Android-Logs liest man mit:

adb logcat
adb logcat | grep com.example.application

Eine Produktions-App sollte niemals Tokens, Passwörter, E-Mails, Standorte, Zahlungsdaten oder vertrauliche Geschäftsdaten loggen.

Netzwerkbeobachtung muss autorisiert bleiben: Testaccount, fiktive Daten, Testumgebung und explizit abgedeckte Endpoints. Dokumentiert werden können kontaktierte Domains, JSON-Formate, Statuscodes, Fehler, TLS-Nutzung und Konsistenz serverseitiger Kontrollen. Ohne ausdrückliche Autorisierung sollten TLS-Bypässe, Pinning-Bypässe, Request-Replay und Automatisierung vermieden werden.

Obfuskation

Mit R8 oder ProGuard kann Code so aussehen:

public final class a {
    public final String b;
    public final int c;
}

Zur Orientierung startet man bei Strings, folgt Netzwerkaufrufen, identifiziert Datenmodelle, sucht Retrofit- oder Serialisierungsannotationen und rekonstruiert schrittweise den Call Graph.

MobSF für eine erste Analyse

MobSF automatisiert einen ersten Bericht:

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Danach öffnen:

http://localhost:8000

MobSF kann Berechtigungen, Tracker, URLs, sensible Dateien, Zertifikate, Bibliotheken, Manifestdetails und schwache Konfigurationen erkennen. Ein automatischer Bericht ist keine endgültige Wahrheit, sondern ein Startpunkt.

Audit-Methodik

Eine saubere Analyse folgt einer reproduzierbaren Methode:

  1. App identifizieren: Name, Package, Version, Hash, Quelle, Datum.
  2. Manifest prüfen: Berechtigungen, exportierte Komponenten, Deep Links, Providers, Services, Netzwerkkonfiguration.
  3. Abhängigkeiten kartieren: Analytics, Crash Reporting, Netzwerk, Zahlung, Authentifizierung, Werbung, Verschlüsselung.
  4. Sensible Bereiche finden: Auth, Sessions, lokaler Speicher, Logs, WebView, Deep Links, temporäre Dateien.
  5. Dynamisch mit Testaccount prüfen.
  6. Klaren Bericht schreiben: Zusammenfassung, Impact, Bedingungen, Belege, Risiko und Empfehlung.

Fiktive Mini-Analyse

Für eine fiktive App DemoBike kann das Manifest enthalten:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

Das ist für nahe Fahrradstationen plausibel. In network_security_config.xml wäre ein gutes Zeichen:

<base-config cleartextTrafficPermitted="false" />

Im dekompilierten Code kann Retrofit sichtbar sein:

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .build();

In einem öffentlichen Bericht sollte man sensible Details vermeiden, wenn die reale URL privat ist. Dokumentiere stattdessen Kommunikationsart und Risiko.

Häufige Warnsignale

Typische Probleme sind:

  • Secrets im APK;
  • Sicherheitskontrollen nur clientseitig;
  • zu ausführliche Logs;
  • falsch konfigurierte WebView;
  • zu permissive Deep Links;
  • Tokens oder personenbezogene Daten im Klartext im lokalen Speicher;
  • permissive Netzwerkkonfiguration;
  • Sessions ohne klaren Ablauf.

Alles, was in einem APK liegt, kann früher oder später extrahiert werden. Kritische Secrets gehören auf den Server.

Was man vermeiden sollte

Vermeide die Nutzung privater Endpoints, die durch Reverse Engineering gefunden wurden, das Umgehen von Schutzmechanismen, Zugriff auf fremde Daten, Veröffentlichen von Secrets, Automatisierung ohne Erlaubnis, Tests in Produktion ohne Zustimmung oder übermäßige Last.

Einfache Regel: Wenn du die Handlung nicht ruhig in einem Auditbericht an den App-Betreiber erklären könntest, lass sie.

Sicher lernen

Nutze Lernziele, die dafür gedacht sind: absichtlich verwundbare Apps, OWASP-Mobile-Labs, Open-Source-Apps, eigene Projekte, mobile CTFs oder Bug Bounties mit klarem Scope.

Wichtige Fähigkeiten: Android Internals, Kotlin/Java, HTTP/TLS, OAuth/OIDC, sicherer Speicher, angewandte Kryptografie, Backend-Architektur und Berichtserstellung.

Schnelle Checkliste

[ ] APK legal erhalten
[ ] Version und Hash dokumentiert
[ ] Manifest analysiert
[ ] Berechtigungen geprüft
[ ] Exportierte Komponenten identifiziert
[ ] Deep Links inspiziert
[ ] Network Security Config geprüft
[ ] Dekompilierter Code geprüft
[ ] Hauptabhängigkeiten gelistet
[ ] Lokaler Speicher analysiert
[ ] Logs geprüft
[ ] Netzwerkverkehr nur im autorisierten Rahmen beobachtet
[ ] Sensible Daten gesucht
[ ] Bericht geschrieben
[ ] Schwachstellen verantwortungsvoll gemeldet

Fazit

Mobile Reverse Engineering liegt zwischen Entwicklung, Sicherheit, Architektur und technischer Investigation. Richtig eingesetzt verbessert es die Sicherheit von Apps und macht dich zu einem besseren Entwickler.

Falsch eingesetzt kann es aufdringlich oder illegal werden. Der Unterschied hängt oft an einer Sache: Autorisierung.