ALAKEEL

Mobile Application Pentesting

Android Penetration Testing ist ein Prozess zur Identifizierung von Sicherheitslücken in Android-Applikationen und -Geräten. Als Senior Penetration Tester müssen Sie sowohl statische als auch dynamische Analysemethoden beherrschen, damit eine umfassende Sicherheitsbewertungen durchgeführt werden.

Fundamentale Mobile-Spezifika
Android-Architektur
  • App-Sandboxing: Jede App läuft unter eigener UID, SELinux-Policies (Rechte) verstehen
  • Permission-System: Runtime vs. Install-time Permissions, Custom Permissions
  • IPC-Mechanismen: Intents, Content Providers, Broadcast Receivers, Services
  • App-Komponenten: Activities, Services, Broadcast Receivers, Content Providers exportiert/nicht-exportiert
iOS-Architektur
  • App Sandbox: Containerisierung, Keychain, App Groups. Jede App hat ein Container-Verzeichnis. Zugriff außerhalb nur über Entitlements (z. B. App Groups). Keychain speichert Secret. Optional geteilt über Access Groups.
  • Code Signing: Provisioning Profiles, Entitlements verstehen. iOS erzwingt Signierung jeder App; Provisioning Profile definieren, wo sie läuft; Entitlements schalten System-Fähigkeiten frei (z. B. iCloud, App Groups, Push).
  • IPC: URL Schemes, Universal Links, App Extensions, XPC Services (Prozess-zu-Prozess-Kommunikation)
  • Security Features: Touch/Face ID, Secure Enclave, Data Protection Classes.
Zwei Hauptarten von Tests
  • Statische Analyse (ohne die App laufen zu lassen):
    Man schaut sich den Code, die App-Dateien und Konfigurationen an. Ähnlich wie Baupläne lesen. Man findet z. B. schlecht geschützte Schlüssel, falsche Berechtigungen oder unsichere Speicherung von Daten.
  • Dynamische Analyse (während die App läuft):
    Die App wird gestartet und aktiv getestet. Hier beobachtest du das Verhalten, manipuliert Datenverkehr, testest Berechtigungen und suchst nach Laufzeit-Schwachstellen.
Ablauf in einfachen Schritten
  1. Ziel definieren & Genehmigung:
    • welche App/Gerät wird getestet und genau welche Tests sind erlaubt?
    • Immer schriftlich -> (Scope, Zeit, erlaubte Methoden, Notfall-Kontakt)
  2. Informationssammlung:
    • App herunterladen -> Erstes Scannen: Fakten über App/Version/Bibliotheken/Berechtigungen sammeln bzw. prüfen.
    • App-Berechtigungen im Manifest anschauen -> Siehe Manifest, ob App Kamera + Standort verlangt? – notiere, ob das nötig erscheint
  3. Statische Analyse (App „offline“ untersuchen):
    • APK entpacken (z.B. mit apktool)
    • Manifest durchsehen bzw. AndroidManifest.xml prüfen (Permissions, exported activities)
    • Code oder dekompilierte Klassen prüfen (z. B. mit JADX) -> nach festen Schlüsseln, hardcodierten URLs, unsicherer Speicherung suchen, etc.
  4. Dynamische Tests:
    • App ausführen -> App auf Testgerät oder Emulator installieren
    • Netzwerkverkehr mitschneiden (z.B. mit Burpsuite)
    • Eingaben manipulieren, Berechtigungen ändern, App-State verändern.
    • Datei-/Speicherzugriffe beobachten (z. B. Frida)
  5. Exploitation (kontrolliert):
    • Nachweis, dass eine Schwachstelle ausgenutzt werden kann (PoC erstellen) -> aber sicher und begrenzt.
  6. Bericht & Empfehlungen:
    • Gefundene Probleme beschreiben (Kurzbeschreibung, technische Details, PoC).
    • Risiko einschätzen (z. B. hoch/mittel/niedrig).
    • konkrete Fixes vorschlagen.
Typische Dinge, die man findet
  • Unverschlüsselte Kommunikation:
    • App schickt Daten über das Internet ohne sichere Verbindung bzw. unverschlüsselt (HTTP statt HTTPS)?
    • Die App prüft TLS-Zertifikate falsch?
    • Auswirkung: Angreifer im gleichen Netzwerk können Daten mitlesen oder verändern (z. B. Login-Daten, Tokens).
  • Schlechte Speicherung von Daten:
    • Passwörter/Token werden unverschlüsselt in SharedPreferences, Dateien oder Datenbanken gespeichert.
    • Auswirkung: Zugriff auf das Gerät/Backup genügt, Daten sind kompromittiert.
    • Decompiled Code durchsuchen nach SharedPreferences, SQLiteDatabase, getFilesDir() und harten Keys.
  • Unsichere Berechtigungen:
    • App fordert zu viele Rechte an, also mehr Rechte als nötig oder prüft sie nicht korrekt.
    • exported=true für Activities/Services ohne Schutz
    • Auswirkung:
  • Code-Injektionen / unsichere Intents: Andere Apps können Daten einschleusen oder Aktionen auslösen.
  • Schwache Zertifikatsprüfung: Die App vertraut jedem Server-Zertifikat — man kann den Verkehr manipulieren.
Tools & Setup
Android
  • Android Studio + SDK Tools -> Emulatoren starten, Zugriff auf SDK-Tools wie adb, emulator, avdmanager
  • adb (Android Debug Bridge) -> Kommunikation mit Gerät/Emulator: Dateien ziehen, Logs lesen, Befehle ausführen.
  • Frida / Objection für Dynamic Analysis -> Runtime-Analyse & Hooking (Funktionen überschreiben, Methoden manipulieren, Pinning umgehen).
  • Burp Suite/ZAP -> HTTP/S-Verkehr abfangen, modifizieren, fuzzing.
  • apktool -> APK entpacken in lesbare Ressourcen (Manifest, XML, smali-Code).
  • jadx/JEB -> Smali → lesbarer Java-Code.
  • MobSF für statische Analyse -> Automatisierte statische Analyse + CVE-Check + Risk-Rating.
iOS
  • Xcode + Command Line Tools -> Emulatoren, App-Signierung, Build-Analysen, Crash-Logs, ipa extrahieren.
  • iProxy für USB-Forwarding -> Port-Forwarding für USB-Geräte (z. B. Frida, SSH, Burp-Proxy).
  • Frida für Jailbroken/Non-Jailbroken -> Runtime Hooking, Methodenänderungen, Bypass (Pinning, Jailbreak-Detection)
  • Burp Suite mit iOS-Cert -> Traffic-Interception für iOS-Apps.
  • Hopper/Ghidra für Binary Analysis -> Disassemblieren, Reverse Engineering von nativen iOS-Binaries (Mach-O).
  • class-dump/dsdump für Header Extraction -> Objective-C-Klassenstrukturen und Methoden aus einer Binary extrahieren.
  • iOS App Signer für Re-Signing -> App modifizieren (z. B. Frida Gadget einbetten) und neu signieren für Testzwecke.
Cross-Platform Tools
ToolZweckPlattform
MobSFAutomatisierte statische AnalyseAndroid & iOS
FridaRuntime-HookingBeide
Burp Suite / ZAPHTTP/S-Proxy & ManipulationBeide
Ghidra / HopperNative Binary ReverseBeide
JADX / class-dumpDecompiling / Header ExtractionAndroid / iOS
sqlite3DB-AnalyseBeide
mitmproxyCLI-Alternative zu BurpBeide
Penetration Testing Methodology
Phase 1: Information Gathering
# Geräteverbindung prüfen
adb devices

# Systeminformationen sammeln
# Android-Version (z. B. 13, 14)
adb shell getprop ro.build.version.release 
# Geräte-Modell (z. B. Pixel 7, SM-G991B)
adb shell getprop ro.product.model         

# Installierte Apps auflisten
adb shell pm list packages     # alle Pakete (System + Drittanbieter)
adb shell pm list packages -3  # Nur Drittanbieter-Apps

# App-Details abrufen
adb shell dumpsys package <package_name>

Systeminformationen sammeln? Warum???
Alte Android-Version = oft bekannte Schwachstellen, andere Sicherheitsfeatures (z. B. kein Scoped Storage).

Installierte Apps auflisten? Warum???
Du findest den Package-Namen der Ziel-App (z. B. com.example.app)
Du siehst evtl. weitere interessante Apps:
– Test-/Debug-Builds
– interne Tools
– Apps, die mit deiner Ziel-App interagieren (IPC, SSO, SDK-Integration)

App-Details abrufen? Warum???
Du bekommst einen riesigen Dump mit Infos zur App:
– Version, UID, Installationspfad
– Berechtigungen (granted/denied)
– Aktivitäten, Services, Receiver, Provider inkl. exportiert/nicht
– Flags wie debuggable, allowBackup usw.
-> Das ist deine Faktenbasis für Angriffsfläche (exported Components) und mögliche Misskonfigurationen.

Phase 2: Statische Analyse

APK Extraktion:

# APK vom Gerät ziehen
# Du bekommst den Pfad zur APK
adb shell pm path com.example.app
adb pull /data/app/com.example.app-xxx/base.apk

# APK dekompilieren
apktool d base.apk -o output_folder

# Java-Code dekompilieren
jadx -d output_jadx base.apk

apktool Ergebnis:

  • AndroidManifest.xml gut lesbar
  • res/ mit Layouts, Strings, Ressourcen
  • smali/ mit Bytecode im Smali-Format

jadx Ergebnis:

  • Du kannst gezielt nach Klassen, Methoden, Strings suchen
  • Java-ähnlicher Code, den man deutlich leichter lesen kann als Smali

Manifest-Analyse:

# AndroidManifest.xml untersuchen
cat output_folder/AndroidManifest.xml

Wichtige Prüfpunkte:

  • Exported Activities/Services/Receivers
    • android:exported="true" → kann evtl. von anderen Apps aufgerufen werden
  • Berechtigungen (Permissions)
    • uses-permission → fordert die App zu viel an?
  • debuggable="true"
    • Wenn in Release-Build gesetzt → großes Risiko (einfacheres Debugging, run-as, Frida etc.)
  • allowBackup="true"
    • App-Daten können über ADB-Backup gesichert werden → evtl. Datenabfluss
  • usesCleartextTraffic="true"
    • App erlaubt HTTP ohne TLS → potenziell unsichere Kommunikation

Code-Review Schwachstellen:

  • Hardcodierte API-Keys/Credentials
  • Unsichere Kryptographie (MD5, SHA1, AES im ECB-Mode, Eigenbau-Krypto?)
  • SQL Injection -> SQL-Statements zusammengebaut mit String-Konkatination (statt Prepared Statements)?
  • WebView JavaScript Interface Exposition -> addJavascriptInterface → kann Code-Ausführung erlauben, wenn nicht sauber abgesichert
  • Unsichere Datenübertragung (HTTP statt HTTPS)
  • Root-Detection Bypass-Möglichkeiten
# Strings durchsuchen
strings base.apk | grep -i "password\|api\|key\|secret\|token"

# Nach URLs suchen
grep -r "http://" output_folder/
Phase 3: Dynamische Analyse

Ziel: Sehen, was die App über das Netz schickt – und manipulieren, was ankommt/zurückkommt.

Netzwerk-Traffic Interception:

# Burp Suite Proxy konfigurieren
# 1. Burp CA-Zertifikat auf Gerät installieren
adb push burp-cert.der /sdcard/
# 2. Proxy einstellen
adb shell settings put global http_proxy <host>:<port>

# SSL Pinning Bypass mit Frida
frida -U -f com.example.app -l ssl-pinning-bypass.js --no-pause

Runtime Manipulation mit Frida:

// SSL Pinning Bypass Script
Java.perform(function() {
    var TrustManager = Java.use('javax.net.ssl.X509TrustManager');
    TrustManager.checkServerTrusted.implementation = function(chain, authType) {
        console.log('[+] Bypassing SSL Pinning');
    };
});

// Root Detection Bypass
Java.perform(function() {
    var RootBeer = Java.use('com.scottyab.rootbeer.RootBeer');
    RootBeer.isRooted.implementation = function() {
        console.log('[+] Root Detection Bypassed');
        return false;
    };
});

SSL Pinning Bypass Script -> was passiert?
– Eigentlich soll checkServerTrusted prüfen, ob das Zertifikat vertrauenswürdig ist.
– Du überschreibst die Funktion so, dass sie einfach nichts mehr prüft → jedes Zertifikat wird akzeptiert.

Root Detection Bypass -> was passiert?
– RootBeer ist eine Library, die Root erkennen soll.
– Du zwingst isRooted() immer false zurückzugeben -> App glaubt, Gerät sei sauber.

Frida Befehle:

# Laufende Prozesse auflisten
# Zeigt alle Prozesse des verbundenen Geräts (USB)
frida-ps -U

# Script injizieren
frida -U -f com.example.app -l script.js --no-pause
# -f → App wird von Frida gestartet
# -l script.js → dein JavaScript-Hook wird geladen
# --no-pause → App läuft direkt weiter

# REPL-Mode für Debugging - Attach an laufende App
# Interaktiver Modus, in dem du live JavaScript/Frida-APIs ausführen kannst
frida -U com.example.app

# Objection - Frida Wrapper
objection -g com.example.app explore
  • Objection ist ein CLI-Tool oben auf Frida, das dir viele Tasks abnimmt.
  • Du bekommst eine interaktive Shell mit Befehlen wie:
    • android sslpinning disable
    • android root disable
    • android sharedprefs print
    • env / memory / file-Commandos etc.

Vorteil:

  • Du musst nicht jedes Frida-Script selber schreiben, sondern kannst viele Standard-Aktionen mit einem Befehl ausführen.
Phase 4: Komponenten-Testing

Ziel: Alle App-Komponenten (Activities, Services, BroadcastReceiver, ContentProvider) gezielt antriggern und schauen:

Activity Testing:

# Activity direkt starten
adb shell am start -n com.example.app/.MainActivity

  • Startet gezielt eine Activity per Name (Package + Klassenname).
  • Du umgehst damit den normalen Startfluss (z. B. Login-Screen).
  • Warum das?
    • Du kannst testen, ob es direkten Zugriff auf interne Screens gibt (z. B. Settings, Admin-Bereich), ohne dass Login/Checks greifen.
    • Wenn eine Activity exported="true" ist, können andere Apps (oder du via ADB) sie auch starten.


# Activity mit Intent-Extras
adb shell am start -n com.example.app/.SecretActivity -e key1 value1 -e key2 value2

  • -e key value → setzt Extras in den Intent (String-Extras)
  • Du simulierst hier das Verhalten einer anderen App, die diese Activity aufruft.
  • Warum das?
    • Prüfen, ob die Activity nur anhand der Intent-Extras vertrauliche Daten lädt („wenn key=admin…“).
    • Versuchen, versteckte Modi zu aktivieren (z. B. -e debug true, -e role admin).


# Exported Activities finden
grep -r "exported=\"true\"" output_folder/AndroidManifest.xml

  • Listet alle Komponenten, die für andere Apps sichtbar sind.
  • Darf diese Activity wirklich von außen aufrufbar sein? -> Wenn nein: Angriffsfläche.

Content Provider Testing:

  • ContentProvider sind wie kleine Datenbanken, die andere Apps über URIs abfragen können.

# Content Provider abfragen
adb shell content query --uri content://com.example.provider/users

  • Fragt alle Datensätze aus users ab. -> Wenn das ohne Fehler funktioniert und Daten zurückkommen, obwohl deine „App“ keine Berechtigung hat -> massiv kritisch.

# SQL Injection testen
adb shell content query --uri "content://com.example.provider/users" --where "name='admin' OR '1'='1'"

  • Du manipuliert den WHERE-Teil der Anfrage
  • Wenn du plötzlich mehr Daten bekommst als gedacht → Hinweise auf SQLi.

# Daten einfügen
adb shell content insert --uri content://com.example.provider/users --bind name:s:hacker --bind password:s:test123

  • Versucht, einen neuen Datensatz in den Provider zu schreiben.
  • Wenn das funktioniert, ohne Authentifizierung oder Berechtigung -> Manipulation von App-Daten.

Broadcast Receiver Testing:

# Broadcast senden
adb shell am broadcast -a com.example.ACTION_NAME -e param1 value1
# Sendet einen Intent mit Action com.example.ACTION_NAME.

# Sticky Broadcasts abfangen
adb shell dumpsys activity broadcasts
# Zeigt aktive/sticky Broadcasts an.

Service Testing:

  • Services führen oft Hintergrundarbeit aus (Sync, Daten löschen, Upload, etc.).
# Service starten
adb shell am startservice -n com.example.app/.BackgroundService

# Service mit Intent-Extras
adb shell am startservice -n com.example.app/.DataService -e command "delete_all"
  • Wenn ein fremder Aufruf delete_all ausführen kann → Data Wipe Vulnerability.
Phase 5: Lokaler Datenspeicher
  • Ziel: Was liegt alles (ggf. unverschlüsselt) auf dem Gerät rum? -> Tokens, Passwörter, persönliche Daten, Konfigurationen.
  • Achtung: Viele dieser Schritte erfordern Root oder run-as-Zugriff (oder einen Debug-Build).

# App-Datenverzeichnis durchsuchen
adb shell
cd /data/data/com.example.app/
ls -laR

  • /data/data/<package> ist das private App-Verzeichnis:
    • shared_prefs/
    • databases/
    • files/
    • cache/

Was du suchst:

  • Klartext-Passwörter
  • Tokens/API-Keys
  • sensible Dateien (z. B. PDFs, Backups, Logs)

# Shared Preferences analysieren
cat /data/data/com.example.app/shared_prefs/*.xml

Typische Funde:

  • auth_token, sessionId, refresh_token
  • rememberMe=true mit Passwort im Klartext
  • Flags wie isAdmin=true
  • Regel: Keine sensiblen Daten im Klartext in SharedPreferences.

# SQLite-Datenbanken untersuchen
adb pull /data/data/com.example.app/databases/app.db
sqlite3 app.db
.tables
.schema users
SELECT * FROM users;

  • Du ziehst die DB und schaust direkt hinein
  • Typische Funde:
    • User-Tabellen mit PII (Mail, Telefonnummer)
    • Offline-Caches, Chat-Verläufe, Logs
    • Tokens und Keys
  • Ist alles im Klartext? Werden sensible Daten überhaupt verschlüsselt?

# Logfiles prüfen
adb logcat | grep -i „password\|token\|api“
adb logcat *:E # Nur Errors

  • Logs sind oft unterschätzte Datenquellen.
  • Typische Fails:
    • Log.d("AUTH", "User token: " + token);
    • Fehler-Logs mit SQL-Queries oder API-Antworten
Phase 6: Kryptographie-Analyse

Schwachstellen identifizieren:

  • Ziel: Sicherstellen, dass richtige Algorithmen und richtige Modi verwendet werden – und keine eigenen Bastel-Lösungen.

# Nach unsicheren Crypto-Implementierungen suchen
grep -r "DES\|MD5\|SHA1" output_folder/
grep -r "ECB" output_folder/

Warum schlecht?

  • DES, MD5, SHA1 → kryptographisch unsicher/veraltet
  • ECB-Mode bei AES → Muster im Klartext erkennbar

Was du daraus machst:

  • Markiere Stellen, wo diese Algorithmen genutzt werden (z. B. Passwort-Hashing, Dateiverschlüsselung).
  • Im Report: Erklärung mit Risiko + Empfehlung (z. B. SHA-256, bcrypt, GCM-Mode).

# Überprüfen der KeyStore Nutzung
grep -r "KeyStore" output_folder/

  • Sucht nach Nutzung von AndroidKeyStore.
  • Werden Schlüssel wirklich sicher im Keystore erzeugt/gespeichert? Oder sind sie trotzdem im Code/Prefs hart codiert?
Phase 7: WebView Vulnerabilities
  • Ziel: Prüfen, ob die App über WebViews Code-Ausführung zulässt oder lokale Dateien/Assets unsicher einbindet.

# JavaScript Interface Exploitation
# In dekompiliertem Code suchen:
grep -r „addJavascriptInterface“ output_folder/

  • addJavascriptInterface(obj, "name") bindet ein Java-Objekt in JS ein.
  • Risiko:
    • Wenn untrusted Web-Content geladen wird (z. B. Remote URLs), kann JS dieses Interface nutzen, um native Methoden aufzurufen → manchmal RCE.
  • Check:
    • Wo kommt der WebView-Content her? Lokale Assets? Externe URL?
    • Welche Methoden bietet das Interface? Sind sie gefährlich (File-Access, Crypto, Intents)?

# XSS Testing in WebView
# File Access Testing
grep -r „setAllowFileAccess“ output_folder/
grep -r „setAllowUniversalAccessFromFileURLs“ output_folder/

Warum gefährlich?

  • setAllowFileAccess(true) → WebView kann lokale Dateien lesen.
  • setAllowUniversalAccessFromFileURLs(true) → von file://-URLs auf http(s) zugreifen → kann kombiniert mit XSS kritisch sein.

Tests:

  • Versuchen, eigene HTML/JS-Seite laden zu lassen.
  • Prüfen, ob du von dort aus lokale Dateien oder sensitive Ressourcen erreichst.
Phase 8: Advanced Exploitation

Drozer – Comprehensive Security Testing:

# Drozer installieren
pip install drozer
adb install drozer-agent.apk

# Drozer Session starten
adb forward tcp:31415 tcp:31415 # Leitet Port vom Gerät zum Rechner weiter.
drozer console connect

# Attack Surface ermitteln -> Zeigt: Exportierte Activities, Services, Receiver, Provider
run app.package.attacksurface com.example.app

# Activities enumeration -> Listet Activities, Permissions, Export-Status
run app.activity.info -a com.example.app

# Content Provider exploitation
run scanner.provider.finduris -a com.example.app
run scanner.provider.injection -a com.example.app
run scanner.provider.traversal -a com.example.app

Smali Code Patching:

# APK dekompilieren
apktool d base.apk

# Smali-Code modifizieren (z.B. Root-Check entfernen)
nano output_folder/smali/com/example/RootCheck.smali
# Du suchst die Methode, z. B. isDeviceRooted() und änderst sie so, dass sie immer false zurückgibt.

# APK rekompilieren / wieder bauen
apktool b output_folder -o modified.apk

# Signieren
# Schlüssel erzeugen
keytool -genkey -v -keystore my-key.keystore -alias app-key -keyalg RSA -keysize 2048 -validity 10000
# APK signieren
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-key.keystore modified.apk app-key
# Hinweis: Für moderne Builds wäre apksigner besser, aber für Test-Setups reicht das

# Zipalign - Optimiert das APK für Android-Loader.
zipalign -v 4 modified.apk modified-aligned.apk

# Installieren
adb install modified-aligned.apk

Was bringt das?

  • Vollständige Kontrolle über App-Logik im Lab:
    • Root-/Emulator-Checks aus
    • Debug-/Logging an
    • Pinning entfernt
  • Du kannst Verhalten testen, dass sonst durch Sicherheitsmechanismen versteckt wäre.
Wichtige Sicherheitslücken & Tests
OWASP Mobile Top 10 Checkliste:
  1. M1: Improper Platform Usage
    • Werden wirklich nur die Permissions angefordert, die nötig sind?
    • Sind exported Activities/Services/Receiver korrekt abgesichert? -> z.B. Exported Activities ohne Authentifizierung?
    • Platform Features missbraucht?
    • Android:
      • AndroidManifest.xml prüfen: uses-permission, exported, allowBackup, usesCleartextTraffic.
      • grep -i „uses-permission“ AndroidManifest.xml
      • grep -i „exported=\“true\““ AndroidManifest.xml
      • adb shell am start -n com.app/.AdminActivity
      • Prüfen, ob BroadcastReceiver/Services ohne Permission von außen angesprochen werden können.
    • iOS: Entitlements prüfen, App Groups, Keychain-Access Groups.
    • Praxis:
  2. M2: Insecure Data Storage
    • Unsichere Speicherung lokaler Daten.
    • Prüfen von:
      • Shared Preferences
        • /data/data/<package>/shared_prefs/*.xml → Tokens, Flags, Credentials?
      • SQLite Datenbanken
        • /data/data/<package>/databases/*.db mit sqlite3 öffnen -> PII im Klartext?
      • Internal Storage & External Storage
        • files/, cache/, external Storage -> liegen dort Backups oder Export-Dateien?
      • Logs
        • adb logcat | grep -i "token\|password" -> secrets in Logs?
      • Sensible Daten (Passwörter, Tokens, persönliche Daten) liegen im Klartext oder nur schwach geschützt auf dem Gerät?
      • Praxis:
        • adb shell run-as com.app cat /data/data/com.app/shared_prefs/*.xml
        • adb pull /data/data/com.app/databases/app.db
        • sqlite3 app.db
        • adb logcat | grep -i „token“
    • iOS:
      • UserDefaults, Plist-Dateien, on-disk Caches.
      • Keychain-Einträge: Werden sie korrekt genutzt oder liegen Credentials zusätzlich im Klartext?
      • App-Container & App-Groups: sind sensitive Daten dort unverschlüsselt?
  3. M3: Insecure Communication
    • Daten werden über das Netzwerk unsicher übertragen oder die TLS-Validierung ist fehlerhaft implementiert.
    • SSL/TLS Pinning vorhanden?
    • Certificate Validation korrekt?
    • Cleartext Traffic erlaubt? Cookies und Header prüfen (Secure, HttpOnly, SameSite).
    • Manifest: usesCleartextTraffic="true"? Network Security Config?
  4. M4: Insecure Authentication
    • Schwache oder falsch implementierte Authentifizierung.
    • Ist Biometrie nur UI-Lock, oder schützt sie wirklich Schlüssel/Token (Android Keystore / iOS Keychain + Secure Enclave)?
      • frida -U -f com.app -l bypass-biom.js
    • Session Management sicher?
    • Tokens sicher gespeichert?
    • Kannst du Rate Limiting umgehen?
    • Werden Accounts nach zu vielen Fehlversuchen gesperrt oder zumindest verzögert?
  5. M5: Insufficient Cryptography
    • Falsche, veraltete oder falsch eingesetzte Kryptografie. Es wird zwar „verschlüsselt“, aber mit unsicheren Algorithmen, festen Schlüsseln oder schlechten Zufallszahlen.
    • Starke Algorithmen verwendet? -> Suche nach MD5, SHA1, DES, RC4, AES/ECB. Eigene Crypto-Funktionen (selbstgeschriebene Implementierungen).
      • grep -r „AES/ECB“ out/
      • grep -r „MD5“ out/
      • grep -r „DES“ out/
    • Keys sicher gespeichert?
    • Hardcoded Keys im Code/Strings.
    • Keys in SharedPrefs oder Konfigurationsdateien.
    • Nutzung von AndroidKeyStore / iOS Keychain mit korrekten Flags.
  6. M6: Insecure Authorization
    • Fehler in der Rechte-/Rollenprüfung. Der Nutzer ist zwar authentifiziert, aber die App/Schnittstelle prüft nicht genau, ob er auch berechtigt ist, eine bestimmte Ressource/Aktion zu nutzen.
    • IDOR-Schwachstellen?
    • Privilege Escalation möglich? z.B. Clientseitige Flags ("isAdmin": true) – kann man sie manipulieren?
  7. M7: Client Code Quality
    • Allgemeine Codequalität. Fehler auf der Ebene der Implementierung (C/C++-Code, JNI/NDK), die klassische Schwachstellen wie Buffer Overflows erlauben.
    • Suche nach unsicheren Funktionen wie strcpy, sprintf, etc.
    • Werden Exceptions sauber behandelt oder crashen Inputs?
    • Buffer Overflows?
    • Memory Corruption?
  8. M8: Code Tampering
    • Manipulation des App-Codes. Wie leicht lässt sich die App modifizieren (Smali-Patching, Hooking) und ob sie das erkennt/verhindert.
    • Repackaging: APK mit apktool dekompilieren, minimal ändern (z. B. String oder Methode), neu signieren und installieren → läuft sie?
    • Anti-Tampering Mechanismen? -> Prüft die App ihre eigene Signatur, Checksumme, Debug-Status?
    • Code Obfuscation?
    • Integrity Checks?
    • Praxis:
      • apktool d base.apk
      • apktool b out -o mod.apk
      • jarsigner mod.apk
      • adb install mod.apk
  9. M9: Reverse Engineering
    • Wie leicht kann man deine App analysieren und verstehen?
      • jadx-gui base.apk
    • Obfuscation Level prüfen -> Sieht der dekompilierte Code „schön lesbar“ aus oder sind Klassennamen/Methoden obfuskiert?
      • Lesbare Klassen: LoginManager, ApiClient, SecretConfig
    • String Encryption vorhanden? -> Sind sensible Strings (Tokens, Endpoints, interne Flags) im Klartext auffindbar?
  10. M10: Extraneous Functionality
    • Funktionen, die nur für Entwickler/Tester gedacht waren, sind in der Produktiv-App gelandet.
    • Debug-Code in Production? -> Suche nach DEBUG, test, staging, dev, TODO, internal.
      • grep -r „debug“ out/
      • grep -r „staging“ out/
    • Test-Endpunkte erreichbar?
Reporting & Dokumentation

Proof of Concept erstellen:

# Screenshots erstellen
adb exec-out screencap -p > screenshot.png

# Video-Aufnahme
adb shell screenrecord /sdcard/demo.mp4
adb pull /sdcard/demo.mp4

# Logs sammeln
adb logcat -d > app_logs.txt
Zusätzliche Tools
  • Nuclei: Automatisierte Vulnerability Scanning
  • QARK: QARK ist gut für Schnellanalysen von Android-Apps (Erzeugt Reports + PoC)
    • qark –apk app.apk –exploit
    • Was bekommst du?
    • Bericht über:
      • Exported Activities / Services
      • Hardcoded Strings / Secrets
      • Unsichere Kryptografie
      • Weak Manifest Configurations
    • POC-Skripte, die du direkt nutzen kannst:
      • „Start admin activity without login“
      • „Access content provider without permission“
    • Typische Funde:
      • exported="true" ohne Permissions
      • allowBackup="true"
      • debuggable="true"
      • Hardcodierte Passwörter/API-Keys
      • qWebView mit addJavascriptInterface
  • AndroBugs: Automatische Schwachstellensuche
    • Perfekt für erste „Schnell-Diagnose“
    • python androbugs.py -f app.apk
    • Typische Funde:
      • Insecure Crypto (MD5, SHA1, DES)
      • Hardcoded Secrets
      • Exportierte Components
      • SSL/TLS-Probleme
      • Unsichere WebViews
      • Unsichere File Permissions / World-readable Files
      • Screenshot vulnerability (FLAG_SECURE fehlt)
    • Sehr viele Treffer, aber du musst viel rausfiltern -> gut für erste Übersicht, schlecht für finalen Report.
  • APKiD: APK Identifier für Obfuscation Detection
    • apkid –analysis dupe app.apk
    • Was du bekommst:
    • Erkennt:
      • Obfuscator (ProGuard, DexGuard, Allatori etc.)
      • Anti-Tamper
      • Anti-Debug
      • Native Protectors
    • Typische Funde:
      • „Obfuscator: None“ → App ist komplett lesbar → Reverse Engineering sehr einfach
      • „Packer detected: Jiagu“ → App schwer analysierbar → Frida/Smali müssen mit Workarounds
      • „Anti-Debug: true“ → App erkennt deine Analyse
    • Hilft dir zu entscheiden, ob du direkt mit JADX arbeiten kannst oder tiefere Techniken brauchst.
  • Ghidra: NSA’s Reverse Engineering Tool
    • Für alles, was in .so (Android) oder Mach-O (iOS) vorliegt:
      • Native Crypto
      • Root-Detection
      • Anti-Frida
      • Obfuscation in C/C++
      • Performance-kritische Logik
    • Praxis-Workflow:
      • 1. Native libs extrahieren:
        unzip app.apk lib/arm64-v8a/libsecure.so -d libs/
      • 2. In Ghidra importieren
      • 3. Decompile -> Funktionen analysieren
      • 4. Strings prüfen:
        strings libsecure.so | grep -i "root"
    • Typische mobile Findings:
      • check_root() Funktionen → ganz einfach per Frida-Hook ausschalten
      • custom crypto → Entwickler hat selbst „verschlüsselt“
      • Anti-Hooking detection
      • Hardcodierte Keys in native code
      • Debug-Strings, die im Java-Code fehlten
Automatisierter Gesamt-Workflow
  • APKiD → Is the app obfuscated? Anti-Frida? Native protections?
  • QARK → Manifest, Components, POCs
  • AndroBugs → Crypto, Storage, WebView, Backup, Logs
  • Nuclei → API/Backend vulnerabilities
  • Lib Extraction → für Ghidra/Frida-Bypass
  • URL-Liste → für weitere Fuzzing/Recon
#!/bin/bash

APK=$1
OUT="scan-$(date +%s)"
mkdir $OUT && cd $OUT

echo "[+] Copy APK..."
cp ../$APK app.apk

echo "[+] Running APKiD..."
apkid --analysis deep app.apk > apkid.txt

echo "[+] Running QARK..."
qark --apk app.apk --report-type txt --output qark-report > qark.txt

echo "[+] Running AndroBugs..."
python3 /path/to/androbugs.py -f app.apk > androbugs.txt

echo "[+] Extract URLs..."
strings app.apk | grep -Eo "http[s]?://[^ \"']+" | sort -u > urls.txt

echo "[+] Running Nuclei Scan..."
nuclei -l urls.txt -t http/ > nuclei.txt

echo "[+] Extracting Native Libs..."
unzip app.apk "lib/*" -d libs > /dev/null 2>&1

echo "[+] Finished. Results in $OUT/"

# Start the Scan
chmod +x mobile_scan.sh
./mobile_scan.sh app.apk

Mobile Sicherheit braucht klare Prozesse. Mit dieser Methodik hast du eine kompakte, praxisorientierte Anleitung, um mobile Anwendungen gründlich zu testen.

In

, , , , , , , , , , , , ,