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

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 <pkg> 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}}