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 76ecd4feb..263aaf88c 100644 --- a/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md +++ b/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md @@ -4,41 +4,92 @@ **Per ulteriori informazioni controlla:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html) -Le app Android possono utilizzare librerie native, tipicamente scritte in C o C++, per compiti critici per le prestazioni. Anche i creatori di malware utilizzano queste librerie, poiché sono più difficili da ingegnerizzare a ritroso rispetto al bytecode DEX. La sezione enfatizza le competenze di reverse engineering specifiche per Android, piuttosto che insegnare linguaggi di assemblaggio. Sono fornite versioni ARM e x86 delle librerie per compatibilità. +Le app Android possono utilizzare librerie native, tipicamente scritte in C o C++, per compiti critici in termini di prestazioni. Anche i creatori di malware abusano di queste librerie perché gli oggetti condivisi ELF sono ancora più difficili da decompilare rispetto al byte-code DEX/OAT. Questa pagina si concentra su flussi di lavoro *pratici* e *recenti* miglioramenti degli strumenti (2023-2025) che rendono più facile il reversing dei file `.so` di Android. -### Punti Chiave: +--- -- **Librerie Native nelle App Android:** -- Utilizzate per compiti intensivi in termini di prestazioni. -- Scritte in C o C++, rendendo il reverse engineering una sfida. -- Trovate in formato `.so` (oggetto condiviso), simile ai binari Linux. -- I creatori di malware preferiscono il codice nativo per rendere l'analisi più difficile. -- **Java Native Interface (JNI) & Android NDK:** -- JNI consente di implementare metodi Java in codice nativo. -- NDK è un insieme di strumenti specifici per Android per scrivere codice nativo. -- JNI e NDK collegano il codice Java (o Kotlin) con librerie native. -- **Caricamento ed Esecuzione delle Librerie:** -- Le librerie vengono caricate in memoria utilizzando `System.loadLibrary` o `System.load`. -- JNI_OnLoad viene eseguito al caricamento della libreria. -- I metodi nativi dichiarati in Java si collegano a funzioni native, abilitando l'esecuzione. -- **Collegamento dei Metodi Java alle Funzioni Native:** -- **Collegamento Dinamico:** I nomi delle funzioni nelle librerie native corrispondono a un modello specifico, consentendo il collegamento automatico. -- **Collegamento Statico:** Utilizza `RegisterNatives` per il collegamento, fornendo flessibilità nella denominazione e nella struttura delle funzioni. -- **Strumenti e Tecniche di Reverse Engineering:** -- Strumenti come Ghidra e IDA Pro aiutano ad analizzare le librerie native. -- `JNIEnv` è cruciale per comprendere le funzioni e le interazioni JNI. -- Sono forniti esercizi per praticare il caricamento delle librerie, il collegamento dei metodi e l'identificazione delle funzioni native. +### Flusso di lavoro rapido per un `libfoo.so` appena estratto -### Risorse: +1. **Estrai la libreria** +```bash +# Da un'applicazione installata +adb shell "run-as cat lib/arm64-v8a/libfoo.so" > libfoo.so +# Oppure dall'APK (zip) +unzip -j target.apk "lib/*/libfoo.so" -d extracted_libs/ +``` +2. **Identifica architettura e protezioni** +```bash +file libfoo.so # arm64 o arm32 / x86 +readelf -h libfoo.so # OS ABI, PIE, NX, RELRO, ecc. +checksec --file libfoo.so # (peda/pwntools) +``` +3. **Elenca simboli esportati e binding JNI** +```bash +readelf -s libfoo.so | grep ' Java_' # JNI dinamicamente collegato +strings libfoo.so | grep -i "RegisterNatives" -n # JNI registrato staticamente +``` +4. **Carica in un decompilatore** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper o Cutter/Rizin) e avvia l'analisi automatica. Le versioni più recenti di Ghidra hanno introdotto un decompilatore AArch64 che riconosce gli stub PAC/BTI e i tag MTE, migliorando notevolmente l'analisi delle librerie costruite con l'NDK Android 14. +5. **Decidi sul reversing statico vs dinamico:** codice strippato e offuscato spesso necessita di *strumentazione* (Frida, ptrace/gdbserver, LLDB). -- **Apprendimento dell'Assembly ARM:** -- Suggerito per una comprensione più profonda dell'architettura sottostante. -- [Nozioni di base sull'Assembly ARM](https://azeria-labs.com/writing-arm-assembly-part-1/) da Azeria Labs è raccomandato. -- **Documentazione JNI & NDK:** -- [Specifiche JNI di Oracle](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) -- [Suggerimenti JNI di Android](https://developer.android.com/training/articles/perf-jni) -- [Iniziare con l'NDK](https://developer.android.com/ndk/guides/) -- **Debugging delle Librerie Native:** -- [Debug delle Librerie Native Android Utilizzando JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3) +--- + +### Strumentazione Dinamica (Frida ≥ 16) + +La serie 16 di Frida ha portato diversi miglioramenti specifici per Android che aiutano quando il target utilizza ottimizzazioni moderne di Clang/LLD: + +* `thumb-relocator` può ora *agganciare piccole funzioni ARM/Thumb* generate dall'allineamento aggressivo di LLD (`--icf=all`). +* L'enumerazione e il riutilizzo degli *slot di importazione ELF* funzionano su Android, abilitando il patching `dlopen()`/`dlsym()` per modulo quando gli hook inline vengono rifiutati. +* Il hooking Java è stato corretto per il nuovo **punto di ingresso rapido ART** utilizzato quando le app sono compilate con `--enable-optimizations` su Android 14. + +Esempio: enumerare tutte le funzioni registrate tramite `RegisterNatives` e dumpare i loro indirizzi a runtime: +```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 funzionerà immediatamente su dispositivi abilitati PAC/BTI (Pixel 8/Android 14+) purché tu utilizzi frida-server 16.2 o versioni successive – le versioni precedenti non riuscivano a localizzare il padding per gli hook inline. citeturn5search2turn5search0 + +--- + +### Vulnerabilità recenti da cercare negli APK + +| Anno | CVE | Libreria interessata | Note | +|------|-----|----------------------|-------| +|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Overflow del buffer heap raggiungibile da codice nativo che decodifica immagini WebP. Diverse app Android includono versioni vulnerabili. Quando vedi un `libwebp.so` all'interno di un APK, controlla la sua versione e tenta di sfruttare o patchare.| citeturn2search0| +|2024|Multiple|OpenSSL 3.x series|Diverse problematiche di sicurezza della memoria e padding-oracle. Molti bundle Flutter & ReactNative includono il proprio `libcrypto.so`.| + +Quando noti file `.so` *di terze parti* all'interno di un APK, controlla sempre il loro hash rispetto agli avvisi upstream. L'SCA (Software Composition Analysis) è rara sui dispositivi mobili, quindi le build vulnerabili obsolete sono diffuse. + +--- + +### Tendenze Anti-Reversing & Hardening (Android 13-15) + +* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 abilita PAC/BTI nelle librerie di sistema su silicio ARMv8.3+ supportato. I decompilatori ora mostrano pseudo-istruzioni relative a PAC; per l'analisi dinamica Frida inietta trampolini *dopo* aver rimosso PAC, ma i tuoi trampolini personalizzati dovrebbero chiamare `pacda`/`autibsp` dove necessario. +* **MTE & Scudo allocatore rinforzato:** il tagging della memoria è facoltativo, ma molte app consapevoli di Play-Integrity vengono costruite con `-fsanitize=memtag`; usa `setprop arm64.memtag.dump 1` più `adb shell am start ...` per catturare errori di tag. +* **LLVM Obfuscator (predicati opachi, appiattimento del flusso di controllo):** i packer commerciali (ad es., Bangcle, SecNeo) proteggono sempre più il codice *nativo*, non solo Java; aspettati flussi di controllo falsi e blob di stringhe crittografate in `.rodata`. + +--- + +### Risorse + +- **Apprendimento dell'Assembly ARM:** [Azeria Labs – Fondamenti di Assembly ARM](https://azeria-labs.com/writing-arm-assembly-part-1/) +- **Documentazione JNI & NDK:** [Specifica JNI di Oracle](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) · [Suggerimenti JNI per Android](https://developer.android.com/training/articles/perf-jni) · [Guide NDK](https://developer.android.com/ndk/guides/) +- **Debugging delle librerie native:** [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3) + +### Riferimenti + +- Change-log di Frida 16.x (hooking Android, rilocazione di funzioni piccole) – [frida.re/news](https://frida.re/news/) citeturn5search0 +- Avviso NVD per overflow `libwebp` CVE-2023-4863 – [nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2023-4863) citeturn2search0 {{#include ../../banners/hacktricks-training.md}}