Nel mondo Android sbloccare il bootloader è una sorta di rito di passaggio per gli utenti più avanzati. È infatti il primo passo per installare ROM personalizzate, ottenere i permessi di root e, in sostanza, avere il pieno controllo sul proprio telefono.
Ma negli ultimi anni i produttori hanno alzato le barriere in modo sempre più sofisticato, rendendo questa operazione difficile o addirittura impossibile su molti dispositivi. Eppure, una catena di vulnerabilità scoperta nei chip Qualcomm di ultima generazione sta cambiando le carte in tavola.
In particolare, il protagonista della vicenda di oggi è lo Snapdragon 8 Elite Gen 5, il processore di punta di Qualcomm, che è presente sui telefoni più potenti del momento: dalla serie Xiaomi 17 al modello OnePlus 15, fino al recentissimo Galaxy S26 Ultra. È proprio su questi dispositivi che un gruppo di ricercatori ha individuato una vulnerabilità nell’architettura del bootloader, aprendo una breccia potenzialmente pericolosa.
Segui TuttoAndroid su Google Discover
Cos’è la GBL e perché è importante
Per capire la falla e la portata di quello che potrebbe accadere, bisogna però fare un passo indietro. La GBL, ovvero la Generic Bootloader Library, è un componente introdotto con Android 16 che gestisce le prime fasi di avvio del sistema operativo. Qualcomm ha progettato il proprio Android Bootloader (ABL) per caricare la GBL da una partizione specifica del dispositivo, chiamata efisp. Il problema è che durante questo processo il bootloader si limita a verificare la presenza di un’applicazione UEFI in quella partizione, senza però controllarne l’autenticità o la firma digitale. In altre parole, accetta qualunque cosa venga trovata lì, firmata o meno.
Ebbene, questa svista consente di scrivere codice non autorizzato nella partizione efisp, che verrà eseguito senza alcuna verifica al prossimo avvio. È questo il nucleo dell’exploit.
Naturalmente, il tutto non è così semplice come sembra. Scrivere liberamente in quella partizione è normalmente impedito da SELinux, il sistema di sicurezza obbligatorio di Android, che in modalità Enforcing blocca le operazioni non esplicitamente autorizzate. Per poter sfruttare la vulnerabilità del GBL sarebbe necessario portare SELinux in modalità Permissive, ma per farlo servirebbero i permessi di root, che si ottengono solo dopo aver sbloccato il bootloader.
Insomma, un vicolo cieco apparentemente senza uscita.
Ed è qui che entra in scena il secondo tassello della catena. Il bootloader di Qualcomm accetta infatti un comando fastboot chiamato fastboot oem set-gpu-preemption, pensato per gestire impostazioni grafiche. Il comando, però, non effettua alcun controllo sugli argomenti aggiuntivi che riceve. Di conseguenza, è possibile passargli un parametro non previsto (androidboot.selinux=permissive) che disabilita silenziosamente la protezione SELinux.
La variante Xiaomi ha una terza vulnerabilità
Per completare l’operazione di sblocco su un dispositivo reale, i ricercatori hanno dovuto aggiungere un terzo elemento alla catena, questa volta specifico per i telefoni Xiaomi. L’app di sistema MQSAS, parte del sistema operativo HyperOS, espone un servizio con permessi elevati che può essere sfruttato per scrivere un’applicazione UEFI personalizzata nella partizione efisp. A quel punto, al riavvio, il bootloader carica il codice non firmato e questo imposta i flag di sblocco esattamente come farebbe il normale comando ufficiale.
Patch in arrivo, ma il danno è fatto?
C’è un motivo per cui questa notizia ha avuto così tanta risonanza nella comunità degli appassionati Android: Xiaomi aveva costruito attorno allo sblocco del bootloader un sistema di ostacoli che riteneva essere piuttosto solido. Tempistiche rigide, questionari da compilare, limiti sul numero di dispositivi sbloccabili: tutto pensato, almeno ufficialmente, per scoraggiare l’uso improprio. Il risultato pratico era che la maggior parte degli utenti cinesi aveva semplicemente smesso di provarci. L’exploit ha reso tutto questo improvvisamente superfluo.
La risposta dei produttori è già in moto. Xiaomi avrebbe già corretto la vulnerabilità nell’app MQSAS attraverso gli aggiornamenti HyperOS 3.0.304.0 distribuiti in Cina. Qualcomm, dal canto suo, ha già chiuso la falla nel comando fastboot incriminato, estendendo la correzione anche ad altri comandi simili che avrebbero potuto essere sfruttati nello stesso modo. Resta aperta la questione più importante: la vulnerabilità di base nel GBL è stata corretta? E se sì, gli aggiornamenti sono già stati distribuiti ai produttori e poi agli utenti finali?
Un ultimo dettaglio interessante è che i dispositivi Samsung non sono interessati da questa vulnerabilità. La ragione è che Samsung utilizza il proprio sistema di avvio proprietario (S-Boot) invece del bootloader di Qualcomm. Una scelta spesso criticata, perché rende ancora più difficile lo sblocco dei Galaxy, ma che in questo caso si rivela un buon vantaggio.