unisoc-su

Un metodo per CVE-2025-31710 e per connettersi al socket astratto cmd_skt per ottenere una shell root su modelli unisoc non patchati

Prima che tutti urlino, Unisoc stesso mi ha autorizzato a pubblicarlo dopo il bollettino CVE-2025-31710, quindi state tranquilli.

Iniziamo con una battuta

9u4d2i

Sì, non state sognando, oggi voglio presentarvi un exploit per una shell di sistema sull'app com.sprd.engineermode e, dato che è uno dei client fidati di cmd_skt, sono riuscito ad accedervi anch'io. Questo socket astratto fa parte di un servizio in esecuzione come root (cmd_services), quindi sì, sono felice di presentarvi unisoc-su. Qui potete vedere un elenco dei client fidati di cmd_skt estratti dal binario cmd_services con ghidra, che mostra che com.sprd.engineermode è presente:

cmd_services apps

Per questo exploit viene utilizzata l'app com.sammy.systools di pascua28 e cli-pie di TomKing062. Esistono due versioni di questa app: una contiene vari binari da utilizzare dalla shell di sistema, l'altra solo il cli-pie e alcune CLI per connettersi ad altri socket vari (per engpc potete ora ottenere questo dalla shell di sistema, suggerisco di eseguire prima il source di tools.sh), poi per entrambe esiste una versione per Android 9 (per dispositivi più vecchi; in ogni caso potete ricompattare l'app con Apktool M selezionando la versione desiderata).

Come funziona questo metodo: prima eseguite come adb o shizuku rish UnisocEngSyshell_Enabler_Script.sh per abilitare l'app com.sprd.engineermode (necessario solo sui modelli nuovi), poi seguendo le istruzioni digitate nel dialer *#*#83781#*#* per avviare l'attività principale, quindi da lì entrate nell'attività Adb shell. Poi inserite su una riga il percorso completo del cli-pie (incluso l'applet), sull'altra "setprop persist.sys.cmdservice.enable enable", quindi premete start il più velocemente possibile prima su setprop e poi sulla riga del cli-pie, e boom mostrerà "connesso". Quindi premete end sull'attività setprop ed eliminate il testo, inserite "nc -s 127.0.0.1 -p 1234 -L sh -l" o ciò che usate per eseguire la reverse shell. Poi andate al terminale e riconnettetevi con il binario appropriato; se non viene eseguito, fate il source dello script appropriato o semplicemente connettetevi con "nc 127.0.0.1 1234", dopodiché "source /sdcard/Documents/unisoc-su.sh" (o dove avete posizionato lo script, ma deve essere accessibile dalla shell di sistema). Questo è tutto, avete ottenuto una shell root se tutto è corretto.

Ora parliamo di questo exploit: il contesto è fortemente protetto da selinux, abbiamo root ma ogni protezione è ancora attiva. Questo root è enorme perché non abbiamo disabilitato nulla per ottenerlo, a differenza di altri exploit simili. Sfortunatamente questo contesto non ha abbastanza poteri per disabilitare selinux e inoltre l'esecuzione sembra funzionare solo sul PATH di sistema. Riguardo al servizio stesso, su Android 9 (quindi prima della patch CVE-2022-47339) non ha gruppi nel suo rc di servizio, quindi di default sono root; successivamente invece sono stati aggiunti gruppi (e root come gid/gruppi è stato rimosso), quindi è ovvio che il servizio è diventato più restrittivo, ma con selinux attivo è comunque quest'ultimo a comandare. Riguardo a come si comporta il servizio: sui dispositivi più recenti, il servizio sembra funzionare finché qualcosa lo utilizza o vi è connesso; se non c'è un client connesso o un comando inviato, il servizio si spegne e sarà necessaria la proprietà setprop per riattivarlo. Il servizio lo fa quasi immediatamente, ecco perché in questo metodo eseguiamo il setprop e ci connettiamo rapidamente. Su Android 9 il servizio sembra attendere un comando dopo l'invio del setprop; questa sembra essere la differenza tra dispositivi vecchi e nuovi. Dopo l'esecuzione si spegne, ovviamente è possibile semplicemente connettersi con socat o con il cli-pie (o eseguire il bridge), in tal caso il servizio rimarrà attivo poiché occupato da questa connessione; se non viene fornito alcun comando, il servizio rimarrà in attesa indefinitamente.

cmd_services.rc da una rom utente Android 13 e una rom eng Android 9 per mostrare le differenze cmd_services_android13 (user) rc cmd_services_android9 (eng) rc

CVE che hanno ispirato questo metodo: CVE-2022-47339 (cmd_services) di Lewei Qu(曲乐炜) e CVE-2025-31710 (com.sprd.engineermode system shell) da me, anche se Lewei Qu(曲乐炜) aveva una CVE simile su com.sprd.engineermode a quanto pare, ma l'ho scoperta dopo aver ottenuto la mia.

Inoltre, tre casi speciali emersi successivamente, che non fanno parte dell'elenco delle CVE ispiratrici: il primo è una vulnerabilità reintrodotta, lo aggiungo qui per rendere le cose più chiare: CVE-2025-67264 (patch difettosa di Doogee su com.sprd.engineermode per nuovi modelli unisoc, trattata qui) anch'essa da me; il secondo caso riguarda i nuovi modelli ZTE, non è chiaro se si applichi a tutti o solo ad alcuni, l'attività Adb shell di com.sprd.engineermode è stata mantenuta. Su ZTE Blade V70 Vita si verifica lo stesso problema di CVE-2025-67264 ma successivamente ZTE lo ha patchato bloccando l'attività su userdebug/eng (nessuna CVE poiché se ne sono accorti da soli) invece di rimuoverla; di conseguenza l'attività appare nella UI dell'app ma avvisa che non può essere aperta sulle build utente. Il dispositivo è vulnerabile su (probabilmente prima di questa modifica): ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20241231.044538:user/release-keys ed è stato patchato su ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20250527.224618:user/release-keys. Una cosa simile accade su ZTE Blade A55; questi modelli eseguono Android 14, dove cmd_services è stato riscritto e il nome cambiato in tool_service (e i servizi che possono accedervi sono stati ridotti: com.sprd.engineermode, com.sprd.autoslt, com.sprd.runtime, com.spreadtrum.sgps, com.sprd.validationtools). Questa nuova versione è sempre attiva e non richiede alcun setprop. Il terzo caso, una vulnerabilità simile a quella di questo repository che colpisce vecchi modelli unisoc, è trattato qui.

Qui sono forniti vari script per unisoc-su: uno senza tutorial: unisoc-su.sh; uno che guida all'ingresso nella shell root con la sola shell di sistema (questo metodo è più semplice, funziona offline e senza shizuku/adb): unisoc-su-syshell-only-tut.sh; uno che guida all'ingresso nella shell root usando shizuku/adb, utilizzato solo per eseguire la parte setprop: unisoc-su-adb-shizuku-tut.sh; inoltre una versione per connettersi a vari socket. Eseguite il source di quello che preferite dal vostro terminale; solo unisoc-su.sh e quest'ultimo richiedono di essere eseguiti con source dalla shell di sistema. È disponibile anche uno script tools.sh nella cartella ghostroot per aggiungere varie directory al PATH, compatibile con adb/sistema e root; inoltre uno script multi per eseguire la shell di sistema se non sapete quale nc avete sul sistema, che proverà a usare nc da vari binari possibili fino a quando la connessione non avrà successo.

Aggiunta ora anche una piccola app poc, è solo un'app con quattro pulsanti: uno per connettersi alla shell root di cmd_services, un altro per connettersi alla shell di sistema, un pulsante di aiuto, un pulsante per pulire l'output e un mini terminale. La preparazione deve essere eseguita manualmente, quindi è sicura da usare.

Informazioni su GhostRoot (Canale Root Post-Exploit) Un canale di comando post-exploit furtivo che sopravvive in RAM e accetta input da qualsiasi app non privilegiata tramite I/O basato su file.

L'exploit funziona fino ad Android 13 poiché nelle versioni successive Unisoc ha rimosso il tag sharedUserId dall'app EngineerMode, che ora è un'app utente normale; questo fa sì che selinux neghi l'esecuzione del cli-pie su Android 14 e successivi.

SharedUid-NormalUid_Compare-Patch Immagine fornita da TomKing062