Skip to content
KitploitKITPLOIT
StrumentiBlog
Log in
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Strumenti/GitHubGitHub/canyie/transitionplayer
Sicurezza AndroidEscalation di PrivilegiExploitInformatica ForenseSicurezza MobileApprendimento e FormazioneBinary Exploitation
GitHubcanyie/transitionplayer

TransitionPlayer

CVE-2026-0091, sfrutta un problema nella gestione delle finestre di Android per eseguire codice arbitrario nel processo Launcher da adb

Vedi Repository
32491 mese faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Questo problema è stato risolto per Android 14+ nel June 2026 Android Security Bulletin. Clicca qui per vedere la patch

Writeup

TODO

Completerò il writeup quando avrò un po' di tempo libero

Ma prima devo combattere contro i compiti scolastici e gli esami

Ho deciso di completare la sezione prima che gli esami finiscano

Buona fortuna a me 😇

Introduzione a IApplicationThread

IApplicationThread è un callback privato fornito dal sistema alle app in modo che il sistema possa usarlo per inviare comandi (caricare l'app specificata, notificare cambiamenti del ciclo di vita dei componenti, ecc.) all'app

È pensato per essere utilizzabile solo dal sistema, quindi non ci sono controlli delle autorizzazioni, e la sicurezza è garantita esclusivamente dal fatto che l'oggetto non viene ottenuto da un processo malevolo. Questo ricorda in qualche modo il concetto di "cookie" o "token" nel web. Questo modello di controllo degli accessi è chiamato Capability-based Security

Se qualcun altro riuscisse a ottenere un IApplicationThread da altri processi, potrebbe inviare comandi arbitrari e l'app vittima elaborerebbe i comandi falsificati come se fossero stati generati dal sistema. In un precedente exploit di CVE-2022-20452 il trucco è stato utilizzato per eseguire codice arbitrario

RemoteTransition

Mentre IApplicationThread dovrebbe essere passato solo al processo di sistema, può essere inaspettatamente inviato fuori da system_server

Nessuno implementerebbe un'API getIApplicationThreadForApp(String packageName) esposta a chiunque, è una palese violazione della sicurezza

Ma se IApplicationThread viene avvolto in un altro oggetto e l'oggetto wrapper esterno viene inviato, è uno scenario più probabile

RemoteTransition è un tale wrapper che contiene un IApplicationThread per aumentare la priorità dell'app che esegue un'animazione

Un utilizzatore di questa API è Launcher3, l'applicazione home predefinita su AOSP e dispositivi Pixel, che crea un ActivityOptions usando un RemoteTransition e poi lo passa a startActivity()

Mentre Launcher3 stesso non espone l'oggetto a fattori non affidabili, a volte lo fa system_server

CVE-2022-20419 si è verificato perché system_server ha inoltrato ActivityOptions passati dal chiamante all'app lanciata ma ha dimenticato di rimuovere RemoteTransition, permettendo all'app lanciata di riceverlo e caricare codice arbitrario all'interno del processo del launcher

TransitionPlayer

Durante l'animazione di transizione degli elementi condivisi, molto lavoro deve essere fatto e le comunicazioni devono avvenire tra WMCore e WMShell, dove WM sta per Window Manager

Puoi leggere questo articolo per capire WMShell

Poiché WMCore e WMShell girano in processi diversi (WMCore gira in system_server e WMShell gira in SystemUI), utilizzano il meccanismo Binder per comunicare tra loro

WMCore espone un Binder registerTransitionPlayer API e WMShell lo usa per registrare il proprio binder

Quando l'animazione viene avviata, WMCore chiama requestStartTransition e TransitionRequestInfo viene passato al remoto, che include il RemoteTransition iniziale

Quindi se possiamo sostituire il player di transizione, saremo in grado di recuperare l'IApplicationThread di Launcher e ottenere l'esecuzione di codice arbitrario all'interno di un processo privilegiato

Tuttavia, registerTransitionPlayer è protetto dal permesso MANAGE_ACTIVITY_TASKS che le app di terze parti non possono ottenere

Ma adb shell può anche eseguire codice utente non fidato, e alla shell è concesso il permesso MANAGE_ACTIVITY_TASKS, quindi fortunatamente possiamo lanciare l'attacco dalla shell adb

Impatto

È una domanda divertente cosa possano fare gli aggressori attraverso questa vulnerabilità

Poiché la maggior parte dei permessi concessi a Launcher sono anche detenuti dalla shell adb, gli aggressori che sono già in grado di eseguire codice sotto l'identità della shell non hanno bisogno di sfruttare questa vulnerabilità per compromettere il dispositivo

Questo è più un progetto di esempio educativo per imparare IApplicationThread che un exploit che può essere usato da un'app malevola

Tuttavia, qualcuno potrebbe ancora essere interessato a questo

Ad esempio, può essere usato per estrarre i file privati di Launcher, il che può essere utile nell'analisi forense per app Launcher malevole senza rootare il dispositivo. In precedenza questo è stato ottenuto sfruttando CVE-2024-31317, e la mia scoperta rivela un altro metodo dopo che il precedente è stato risolto

Questo permette anche agli utenti di usare Fabricated Runtime Resources Overlay (FRRO) senza prima rootare il loro dispositivo, quindi i temi personalizzati senza root sono tornati dopo che CVE-2021-39630 è stato risolto. Il mio exploit lo ha dimostrato impostando android:integer/config_multiuserMaximumUsers a 100

Scarica lo strumento