diff --git a/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md b/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md
index d175588a8..8deb42524 100644
--- a/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md
+++ b/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md
@@ -2,16 +2,16 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Attività, Back Stack e Attività in Primo Piano
+## Task, Back Stack and Foreground Activities
 
-In Android, un **task** è essenzialmente un insieme di attività con cui gli utenti interagiscono per completare un lavoro specifico, organizzato all'interno di un **back stack**. Questo stack ordina le attività in base a quando sono state aperte, con l'attività più recente visualizzata in cima come **attività in primo piano**. In qualsiasi momento, solo questa attività è visibile sullo schermo, rendendola parte del **task in primo piano**.
+In Android, un **task** è essenzialmente un insieme di attività con cui gli utenti interagiscono per completare un lavoro specifico, organizzato all'interno di uno **back stack**. Questo stack ordina le attività in base a quando sono state aperte, con l'attività più recente visualizzata in cima come **foreground activity**. In qualsiasi momento, solo questa attività è visibile sullo schermo, rendendola parte del **foreground task**.
 
 Ecco una rapida panoramica delle transizioni delle attività:
 
-- **Attività 1** inizia come l'unica attività in primo piano.
-- L'apertura di **Attività 2** spinge **Attività 1** nel back stack, portando **Attività 2** in primo piano.
-- L'avvio di **Attività 3** sposta **Attività 1** e **Attività 2** ulteriormente indietro nello stack, con **Attività 3** ora davanti.
-- La chiusura di **Attività 3** riporta **Attività 2** in primo piano, mostrando il meccanismo di navigazione dei task semplificato di Android.
+- **Activity 1** inizia come l'unica attività in primo piano.
+- L'apertura di **Activity 2** spinge **Activity 1** nel back stack, portando **Activity 2** in primo piano.
+- L'avvio di **Activity 3** sposta **Activity 1** e **Activity 2** ulteriormente indietro nello stack, con **Activity 3** ora davanti.
+- La chiusura di **Activity 3** riporta **Activity 2** in primo piano, mostrando il meccanismo di navigazione delle attività semplificato di Android.
 
 ![https://developer.android.com/images/fundamentals/diagram_backstack.png](<../../images/image (698).png>)
 
@@ -19,11 +19,11 @@ Ecco una rapida panoramica delle transizioni delle attività:
 
 ## Attacchi di affinità del task
 
-`taskAffinity` indica ad Android a quale task un `Activity` *preferirebbe* appartenere. Quando due attività condividono la stessa affinità, **Android è autorizzato a fonderle all'interno dello stesso back stack anche se provengono da APK diversi**.
+`taskAffinity` indica ad Android a quale task un `Activity` *preferirebbe* appartenere. Quando due attività condividono la stessa affinità, **Android è autorizzato a fonderle all'interno dello stesso back-stack anche se provengono da APK diversi**.
 
 Se un attaccante può posizionare un'attività malevola alla **radice** di quello stack, ogni volta che la vittima apre l'applicazione legittima, l'interfaccia utente malevola sarà la prima cosa che l'utente vede – perfetta per phishing o richieste abusive di permessi.
 
-La superficie di attacco è più ampia di quanto molti sviluppatori pensino perché **ogni attività eredita automaticamente un'affinità pari al nome del pacchetto dell'applicazione** (a meno che lo sviluppatore non imposti `android:taskAffinity=""`). Pertanto, *non fare nulla* lascia già l'app aperta a hijacking del task su versioni di Android precedenti alla 11.
+La superficie di attacco è più ampia di quanto molti sviluppatori pensino perché **ogni attività eredita automaticamente un'affinità pari al nome del pacchetto dell'applicazione** (a meno che lo sviluppatore non imposti `android:taskAffinity=""`). Pertanto, *non fare nulla* lascia già l'app aperta a task hijacking su versioni di Android precedenti alla 11.
 
 ### Scenario classico "singleTask / StrandHogg"
 
@@ -67,29 +67,68 @@ android:taskAffinity="com.caller.id.phone.number.block" >
 </intent-filter>
 </activity>
 ```
-3. Non appena l'utente installa e apre l'app malevola **una volta**, esiste un task la cui affinità è uguale al pacchetto della vittima (ma rimane in background).
-4. Quando viene avviata l'applicazione reale Caller ID, Android riutilizza quel task e porta `HackActivity` in primo piano → finestra di phishing/abuso di permessi.
+3. Non appena l'utente installa e apre l'app malevola **una volta**, esiste un task la cui affinità è uguale al pacchetto della vittima (ma si trova in background).
+4. Quando l'applicazione reale Caller ID viene avviata, Android riutilizza quel task e porta `HackActivity` in primo piano → finestra di phishing/abuso di permessi.
 
-> NOTA: A partire da **Android 11 (API 30)**, il sistema *non* colloca due pacchetti che non fanno parte dello stesso UID nello stesso task per impostazione predefinita, mitigando questa particolare variante. Le versioni precedenti rimangono vulnerabili.
+> NOTA: A partire da **Android 11 (API 30)** il sistema *non* colloca due pacchetti che non fanno parte dello stesso UID nello stesso task per impostazione predefinita, mitigando questa particolare variante. Le versioni precedenti rimangono vulnerabili.
+
+---
+
+### StrandHogg 2.0 (CVE-2020-0096) – Hijack del task basato su reflection
+
+Il bollettino di sicurezza di Google di maggio 2020 ha corretto una variante più avanzata chiamata **StrandHogg 2.0**. L'exploit **non si basa affatto su `taskAffinity`**; invece utilizza *reflection* per inserire dinamicamente l'attività dell'attaccante in cima a *ogni* task in esecuzione, bypassando completamente la restrizione “shared-UID” introdotta da Android 11.
+
+Punti chiave:
+
+* Un'app malevola senza permessi può, una volta aperta, iterare sui task in esecuzione e chiamare API nascoste per **ri-parentare** la propria attività in qualsiasi task.
+* Poiché l'attività viene inserita dopo il runtime, né `launchMode` né l'analisi statica del manifest possono rilevare l'attacco in anticipo.
+* Corretto retroattivamente inserendo un controllo in **Android 8.0/8.1/9** (SPL di maggio 2020). **Android 10 e versioni successive non sono interessati.**
+
+La rilevazione su dispositivi pre-patch può essere eseguita con `adb shell dumpsys activity activities` e osservando attività sospette il cui nome del pacchetto differisce dall'*affinità* del task.
+
+La mitigazione per i dispositivi legacy è la stessa del classico Task Hijacking **più** verifica in tempo reale (ad esempio, chiamando [`ActivityManager#getRunningTasks`](https://developer.android.com/reference/android/app/ActivityManager#getRunningTasks(int)) e convalidando il proprio nome del pacchetto).
 
 ---
 
 ## Checklist di rilevamento e sfruttamento
 
-1. Estrai `AndroidManifest.xml` dall'APK target e controlla che ogni `<activity>` (o l'elemento globale `<application>`) contenga `android:taskAffinity=""` (vuoto) **o** un valore personalizzato.
-2. Se non lo è, crea un'app malevola:
-- `android:taskAffinity` = nome del pacchetto della vittima.
-- Fornisci un'intento `MAIN/LAUNCHER` in modo che l'utente possa aprirla una volta.
-- Facoltativamente chiama `moveTaskToBack(true)` per nascondere immediatamente.
-3. Lascia che la vittima apra la propria applicazione legittima → hijack.
+1. **Revisione statica** – Estrai `AndroidManifest.xml` dall'APK target e controlla che ogni `<activity>` (o l'elemento globale `<application>`) contenga `android:taskAffinity=""` (vuoto) **o** un valore personalizzato. Strumenti come:
+```bash
+# Usando apkanalyzer (Android SDK)
+apkanalyzer manifest print app.apk | grep -i taskaffinity
+
+# Usando AXMLPrinter2
+java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity
+```
+2. **Revisione dinamica** – Sul dispositivo apri l'app target e elenca i task:
+```bash
+adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"
+```
+Un task la cui affinità radice è uguale al pacchetto della vittima ma la cui attività superiore appartiene a un *pacchetto diverso* è un campanello d'allarme.
+3. Crea un'app malevola come descritto sopra, o usa **[Drozer](https://github.com/WithSecureLabs/drozer)**:
+```bash
+drozer console connect
+run app.activity.start --component com.victim/.MainActivity --action android.intent.action.MAIN
+run app.activity.info com.victim
+```
+
+---
 
 ## Mitigazione
 
 Gli sviluppatori dovrebbero:
 
-* Impostare esplicitamente `android:taskAffinity=""` a livello di `<application>` (raccomandato) **o** dare a ciascuna attività un'affinità unica e privata.
+* Impostare esplicitamente `android:taskAffinity=""` a livello di `<application>` (raccomandato) **o** dare a ogni attività un'affinità unica e privata.
 * Per schermi altamente sensibili, combinare quanto sopra con `android:launchMode="singleInstance"` o moderne protezioni [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode).
 * Aggiornare il `targetSdkVersion` dell'app e applicare le modifiche comportamentali di **Android 11** in cui i task non sono condivisi tra pacchetti per impostazione predefinita.
+* Targetizzare **Android 12 (API 31) o superiore** in modo che l'attributo obbligatorio `android:exported` costringa gli sviluppatori a controllare ogni componente raggiungibile esternamente.
+* Considerare l'auto-difesa in tempo reale: interrogare periodicamente `ActivityTaskManager` per garantire che il pacchetto della tua attività superiore corrisponda al tuo.
+
+---
+
+## Tecniche correlate di UI-Hijacking
+
+Il task hijacking è spesso combinato con o sostituito da **tapjacking** (inganno dell'interfaccia utente basato su overlay). La ricerca del 2025 **TapTrap** ha dimostrato che attività *completamente trasparenti* guidate da animazione possono bypassare le restrizioni sul tocco dell'overlay introdotte in Android 12–14 e ingannare ancora gli utenti nel concedere permessi pericolosi. Sebbene TapTrap non sia strettamente *task* hijacking, l'obiettivo finale (clic di phishing) è identico – quindi le valutazioni moderne dovrebbero controllare entrambe le superfici di attacco.
 
 ---
 
@@ -99,5 +138,7 @@ Gli sviluppatori dovrebbero:
 - [https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html](https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html)
 - [Android Manifest Misconfiguration Leading to Task Hijacking in Caller ID app](https://github.com/KMov-g/androidapps/blob/main/caller.id.phone.number.block.md)
 - [https://medium.com/mobile-app-development-publication/the-risk-of-android-strandhogg-security-issue-and-how-it-can-be-mitigated-80d2ddb4af06](https://medium.com/mobile-app-development-publication/the-risk-of-android-strandhogg-security-issue-and-how-it-can-be-mitigated-80d2ddb4af06)
+- [Promon – StrandHogg 2.0 (CVE-2020-0096) technical write-up](https://promon.io/resources/downloads/strandhogg-2-0-new-serious-android-vulnerability)
+- [USENIX 2025 – TapTrap: Animation-Driven Tapjacking on Android](https://www.usenix.org/conference/usenixsecurity25/presentation/beer)
 
 {{#include ../../banners/hacktricks-training.md}}