diff --git a/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md b/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md index ff2b62628..9a4475e1f 100644 --- a/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md +++ b/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md @@ -1,44 +1,95 @@ -# Rückwärtsanalyse von nativen Bibliotheken +# Reversing Native Libraries {{#include ../../banners/hacktricks-training.md}} **Für weitere Informationen siehe:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html) -Android-Apps können native Bibliotheken verwenden, die typischerweise in C oder C++ geschrieben sind, für leistungsintensive Aufgaben. Malware-Ersteller nutzen ebenfalls diese Bibliotheken, da sie schwieriger rückwärts zu analysieren sind als DEX-Bytecode. Der Abschnitt betont die Fähigkeiten zur Rückwärtsanalyse, die auf Android zugeschnitten sind, anstatt Assemblersprachen zu lehren. ARM- und x86-Versionen von Bibliotheken werden zur Kompatibilität bereitgestellt. +Android-Apps können native Bibliotheken verwenden, die typischerweise in C oder C++ geschrieben sind, für leistungskritische Aufgaben. Malware-Ersteller missbrauchen ebenfalls diese Bibliotheken, da ELF Shared Objects immer noch schwieriger zu dekompilieren sind als DEX/OAT Bytecode. Diese Seite konzentriert sich auf *praktische* Workflows und *aktuelle* Verbesserungen der Werkzeuge (2023-2025), die das Reversing von Android `.so`-Dateien erleichtern. -### Wichtige Punkte: +--- -- **Native Bibliotheken in Android-Apps:** -- Werden für leistungsintensive Aufgaben verwendet. -- In C oder C++ geschrieben, was die Rückwärtsanalyse herausfordernd macht. -- Im `.so` (shared object) Format gefunden, ähnlich wie Linux-Binärdateien. -- Malware-Ersteller bevorzugen nativen Code, um die Analyse zu erschweren. -- **Java Native Interface (JNI) & Android NDK:** -- JNI ermöglicht es, Java-Methoden in nativen Code zu implementieren. -- NDK ist ein Android-spezifisches Set von Werkzeugen zum Schreiben von nativem Code. -- JNI und NDK verbinden Java (oder Kotlin) Code mit nativen Bibliotheken. -- **Bibliotheksladung & Ausführung:** -- Bibliotheken werden mit `System.loadLibrary` oder `System.load` in den Speicher geladen. -- JNI_OnLoad wird beim Laden der Bibliothek ausgeführt. -- In Java deklarierte native Methoden verknüpfen sich mit nativen Funktionen, was die Ausführung ermöglicht. -- **Verknüpfung von Java-Methoden mit nativen Funktionen:** -- **Dynamische Verknüpfung:** Funktionsnamen in nativen Bibliotheken entsprechen einem bestimmten Muster, was eine automatische Verknüpfung ermöglicht. -- **Statische Verknüpfung:** Verwendet `RegisterNatives` zur Verknüpfung und bietet Flexibilität bei der Benennung und Struktur von Funktionen. -- **Werkzeuge und Techniken zur Rückwärtsanalyse:** -- Werkzeuge wie Ghidra und IDA Pro helfen bei der Analyse nativer Bibliotheken. -- `JNIEnv` ist entscheidend für das Verständnis von JNI-Funktionen und Interaktionen. -- Übungen werden bereitgestellt, um das Laden von Bibliotheken, die Verknüpfung von Methoden und die Identifizierung nativer Funktionen zu üben. +### Schneller Triage-Workflow für eine frisch extrahierte `libfoo.so` -### Ressourcen: +1. **Extrahiere die Bibliothek** +```bash +# Aus einer installierten Anwendung +adb shell "run-as cat lib/arm64-v8a/libfoo.so" > libfoo.so +# Oder aus der APK (zip) +unzip -j target.apk "lib/*/libfoo.so" -d extracted_libs/ +``` +2. **Architektur & Schutzmaßnahmen identifizieren** +```bash +file libfoo.so # arm64 oder arm32 / x86 +readelf -h libfoo.so # OS ABI, PIE, NX, RELRO, etc. +checksec --file libfoo.so # (peda/pwntools) +``` +3. **Exportierte Symbole & JNI-Bindungen auflisten** +```bash +readelf -s libfoo.so | grep ' Java_' # dynamisch verlinktes JNI +strings libfoo.so | grep -i "RegisterNatives" -n # statisch registriertes JNI +``` +4. **In einen Decompiler laden** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper oder Cutter/Rizin) und die Auto-Analyse ausführen. Neuere Ghidra-Versionen haben einen AArch64-Decompiler eingeführt, der PAC/BTI-Stubs und MTE-Tags erkennt, was die Analyse von Bibliotheken, die mit dem Android 14 NDK erstellt wurden, erheblich verbessert. +5. **Entscheide über statisches vs. dynamisches Reversing:** gestrippter, obfuszierter Code benötigt oft *Instrumentation* (Frida, ptrace/gdbserver, LLDB). -- **ARM-Assembly lernen:** -- Empfohlen für ein tieferes Verständnis der zugrunde liegenden Architektur. -- [ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/) von Azeria Labs wird empfohlen. -- **JNI & NDK Dokumentation:** -- [Oracles JNI-Spezifikation](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) -- [Androids JNI-Tipps](https://developer.android.com/training/articles/perf-jni) -- [Erste Schritte mit dem NDK](https://developer.android.com/ndk/guides/) -- **Debugging nativer Bibliotheken:** -- [Debuggen von Android-nativen Bibliotheken mit JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3) +--- + +### Dynamische Instrumentation (Frida ≥ 16) + +Die 16er-Serie von Frida brachte mehrere Android-spezifische Verbesserungen, die helfen, wenn das Ziel moderne Clang/LLD-Optimierungen verwendet: + +* `thumb-relocator` kann jetzt *kleine ARM/Thumb-Funktionen* hooken, die durch LLDs aggressive Ausrichtung (`--icf=all`) erzeugt werden. +* Das Auflisten und Neuzuweisen von *ELF-Import-Slots* funktioniert auf Android und ermöglicht das Patchen von `dlopen()`/`dlsym()` pro Modul, wenn Inline-Hooks abgelehnt werden. +* Das Java-Hooking wurde für den neuen **ART Quick-Entry-Point** behoben, der verwendet wird, wenn Apps mit `--enable-optimizations` auf Android 14 kompiliert werden. + +Beispiel: Auflisten aller Funktionen, die über `RegisterNatives` registriert sind, und Dumpen ihrer Adressen zur Laufzeit: +```javascript +Java.perform(function () { +var Runtime = Java.use('java.lang.Runtime'); +var register = Module.findExportByName(null, 'RegisterNatives'); +Interceptor.attach(register, { +onEnter(args) { +var envPtr = args[0]; +var clazz = Java.cast(args[1], Java.use('java.lang.Class')); +var methods = args[2]; +var count = args[3].toInt32(); +console.log('[+] RegisterNatives on ' + clazz.getName() + ' -> ' + count + ' methods'); +// iterate & dump (JNI nativeMethod struct: name, sig, fnPtr) +} +}); +}); +``` +Frida funktioniert sofort auf PAC/BTI-fähigen Geräten (Pixel 8/Android 14+), solange Sie frida-server 16.2 oder höher verwenden – frühere Versionen konnten das Padding für Inline-Hooks nicht finden. citeturn5search2turn5search0 + +--- + +### Jüngste Schwachstellen, die in APKs zu suchen sind + +| Jahr | CVE | Betroffene Bibliothek | Anmerkungen | +|------|-----|-----------------------|-------------| +|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Heap-Pufferüberlauf, der von nativen Code erreicht werden kann, der WebP-Bilder decodiert. Mehrere Android-Apps bündeln verwundbare Versionen. Wenn Sie eine `libwebp.so` in einer APK sehen, überprüfen Sie die Version und versuchen Sie eine Ausnutzung oder Patchen.| citeturn2search0| +|2024|Mehrere|OpenSSL 3.x-Serie|Mehrere Probleme mit Speichersicherheit und Padding-Oracle. Viele Flutter- und ReactNative-Bundles liefern ihre eigene `libcrypto.so` mit.| + +Wenn Sie *drittanbieter* `.so`-Dateien in einer APK entdecken, überprüfen Sie immer deren Hash gegen upstream-Beratungen. SCA (Software Composition Analysis) ist auf Mobilgeräten unüblich, sodass veraltete verwundbare Builds weit verbreitet sind. + +--- + +### Anti-Reversing & Härtungstrends (Android 13-15) + +* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 aktiviert PAC/BTI in Systembibliotheken auf unterstütztem ARMv8.3+ Silizium. Decompiler zeigen jetzt PAC-bezogene Pseudo-Anweisungen an; für die dynamische Analyse injiziert Frida Trampolins *nachdem* PAC entfernt wurde, aber Ihre benutzerdefinierten Trampolins sollten `pacda`/`autibsp` aufrufen, wo nötig. +* **MTE & Scudo gehärteter Allokator:** Memory-Tagging ist optional, aber viele Play-Integrity-bewusste Apps werden mit `-fsanitize=memtag` erstellt; verwenden Sie `setprop arm64.memtag.dump 1` plus `adb shell am start ...`, um Tag-Fehler zu erfassen. +* **LLVM Obfuscator (opake Prädikate, Kontrollfluss-Glättung):** Kommerzielle Packprogramme (z. B. Bangcle, SecNeo) schützen zunehmend *native* Codes, nicht nur Java; erwarten Sie falschen Kontrollfluss und verschlüsselte String-Blobs in `.rodata`. + +--- + +### Ressourcen + +- **ARM-Assembly lernen:** [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/) +- **JNI & NDK-Dokumentation:** [Oracle JNI Spec](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) · [Android JNI Tipps](https://developer.android.com/training/articles/perf-jni) · [NDK-Anleitungen](https://developer.android.com/ndk/guides/) +- **Debugging nativer Bibliotheken:** [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3) + +### Referenzen + +- Frida 16.x Änderungsprotokoll (Android-Hooking, tiny-function relocation) – [frida.re/news](https://frida.re/news/) citeturn5search0 +- NVD-Beratungen für `libwebp` Überlauf CVE-2023-4863 – [nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2023-4863) citeturn2search0 {{#include ../../banners/hacktricks-training.md}}