Translated ['src/mobile-pentesting/android-app-pentesting/reversing-nati

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:**
+### Schneller Triage-Workflow für eine frisch extrahierte `libfoo.so`
-- 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.
 
-### Ressourcen:
+1. **Extrahiere die Bibliothek**
+```bash
+# Aus einer installierten Anwendung
+adb shell "run-as <pkg> 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.
+### Dynamische Instrumentation (Frida ≥ 16)
-- **JNI & NDK Dokumentation:**
+
-- [Oracles JNI-Spezifikation](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html)
+Die 16er-Serie von Frida brachte mehrere Android-spezifische Verbesserungen, die helfen, wenn das Ziel moderne Clang/LLD-Optimierungen verwendet:
-- [Androids JNI-Tipps](https://developer.android.com/training/articles/perf-jni)
+
-- [Erste Schritte mit dem NDK](https://developer.android.com/ndk/guides/)
+* `thumb-relocator` kann jetzt *kleine ARM/Thumb-Funktionen* hooken, die durch LLDs aggressive Ausrichtung (`--icf=all`) erzeugt werden.
-- **Debugging nativer Bibliotheken:**
+* 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.
-- [Debuggen von Android-nativen Bibliotheken mit JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3)
+* 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}}