Exploit BootROM su iPhone XS: la prima catena e il progetto usbliter
Nel mondo dell’informatica forense, esiste un livello di accesso che i vendor delle principali piattaforme di acquisizione full file system utilizzano per estrarre dati che nessuna procedura di backup logico può raggiungere: le chat cancellate, i keychain, i database SQLite delle app di terze parti, i file di configurazione, gli attributi di sistema.
Per gli iPhone dotati di SoC dalla famiglia A11 in giù, la porta d’ingresso a questo livello passa da una vulnerabilità hardware immutabile presente nella BootROM Apple. Per l’A12 – il chip degli iPhone XS, XR e delle prime generazioni di iPad Pro 2018 – la vulnerabilità esiste, ma la sua catena di sfruttamento è considerevolmente più complessa.
Il team Forenser ha recentemente ricostruito la prima parte di questa catena su un iPhone XS di test. In questo articolo raccontiamo cosa siamo riusciti a fare, quale metodologia abbiamo seguito, quale contesto internazionale si sta muovendo intorno a questo genere di ricerca e – soprattutto – cosa questo apre in termini di prospettive per l’acquisizione forense di dispositivi mobili di generazione recente.
Il punto di partenza: BootROM e checkm8
Ogni iPhone, all’accensione, esegue un piccolo pezzo di codice fisicamente scritto sul silicio del processore: la BootROM. È il primo software che gira sul dispositivo, letteralmente immutabile perché scolpito nel chip durante la fabbricazione. Non può essere aggiornato con un aggiornamento di iOS; non può essere modificato nemmeno da Apple. Se contiene un difetto, quel difetto resta lì per tutta la vita del dispositivo.
Nel 2019 il ricercatore axi0mX ha pubblicato checkm8, un exploit che sfrutta proprio una vulnerabilità nella BootROM di tutti gli SoC Apple dall’A5 all’A11. Da allora, checkm8 è diventato la base di tutti i principali strumenti di jailbreak permanente (checkra1n, palera1n) e delle metodologie forensi impiegate dai vendor commerciali per l’acquisizione full file system. Nulla di ciò che Apple ha rilasciato successivamente – nemmeno le patch di iOS 18 – può neutralizzarlo su quei dispositivi.
Nota importante: la vulnerabilità nella BootROM non è risolvibile a livello di hardware perché il codice è fisicamente immutabile. Apple può tuttavia introdurre, nelle release successive di iOS, mitigazioni a livello di kernel, iBoot, Secure Enclave e stack di boot che rendono lo sfruttamento pratico della vulnerabilità progressivamente più complesso – richiedendo catene di exploit più articolate per raggiungere gli stage successivi. La porta d’ingresso della BootROM resta quindi aperta in perpetuo, ma l’accesso effettivo ai dati sulle release iOS più recenti non è né automatico né immediato.
Gli iPhone XS/XR/iPad Pro 2018 utilizzano il SoC A12 (T8020). Sono affetti dalla stessa famiglia di vulnerabilità, ma con condizioni di sfruttamento diverse e considerevolmente più delicate. Per anni non è esistito uno strumento pubblico stabile che funzionasse su A12 con la stessa semplicità di checkm8 sui chip precedenti.
Il progetto usbliter
Alcuni mesi fa, il gruppo di ricerca Paradigm Shift ha pubblicato un progetto denominato usbliter (dal nome del suo componente principale, usbliter8): una catena di exploit simile a checkm8 specificamente adattata all’A12/A13, distribuita insieme al codice sorgente su GitHub e accompagnata da un articolo tecnico sul loro sito. Il progetto includeva:
- Un firmware da caricare su un microcontrollore Raspberry Pi Pico, che si comportava come ponte USB tra PC e iPhone
- Il codice dell’exploit vero e proprio, che sfrutta un difetto nel controller USB DWC2 della BootROM A12
- Uno shellcode che, una volta iniettato, trasforma la modalità DFU standard dell’iPhone in una modalità pwned (PWND DFU), stato che espone capacità estese non altrimenti disponibili
- Un ramdisk SSH precompilato per il boot successivo su versioni iOS meno recenti
Nella giornata di ieri, 25 luglio 2026, l’intero materiale è stato rimosso: sia l’articolo pubblicato sul sito del gruppo, sia il repository GitHub. Le motivazioni non sono state comunicate pubblicamente ma è chiaro che le copie del codice sono rimaste disponibili presso chi le aveva già scaricate prima della rimozione.
Oggi la pagina risulta rimossa e il contenuto non è più accessibile, come si può notare accedendo alla URL pubblica precedentemente linkata in numerosi articoli.
L’exploit riuscito sul nostro iPhone XS
Per verificare quanto riportato nell’articolo, il team Forenser ha condotto l’attività di ricerca su un iPhone XS utilizzato ai fini di studio (identificativo hardware iPhone11,2 D321AP) con installato iOS 18.7.9, la versione piu recente disponibile al momento della verifica. La documentazione del progetto usbliter raccomandava esplicitamente l’uso di un Raspberry Pi Pico 2 – la seconda generazione del microcontrollore – motivando la scelta con maggiore stabilità dell’exploit e possibilità di supportare timing più aggressivi.
Nell’articolo sul sito web – ora rimosso – erano segnalati come compatibili anche altri microcontrollori di fascia analoga (RP2040 su schede alternative, alcune varianti STM32).
Nel nostro caso, nell’attesa della consegna di un microcontrollore tra i segnalati, avevamo a disposizione soltanto un Pi Pico di prima generazione (Pico 1 W, basato su RP2040). I primi tentativi di exploitation non davano esito: il dispositivo non transitava in stato PWND DFU e il descrittore USB restituito da libirecovery non mostrava la stringa PWND:[usbliter8] che avrebbe confermato la riuscita dell’exploit. Dopo alcuni cicli di verifica sul timing dei segnali e sui parametri del firmware caricato sul Pico, l’exploit ha iniziato a funzionare in modo affidabile anche sull’hardware di prima generazione.
Il risultato è stato positivo su prima generazione, ma segnaliamo che il Pico 2 resta la scelta preferibile per chi voglia partire da zero: la maggiore affidabilità dei timing riduce il numero di tentativi necessari.
Cosa significa “PWND DFU”: lo stage uno di un exploit BootROM
Un exploit BootROM completo si compone di più stage eseguiti sequenzialmente: ciascuno prepara le condizioni per il successivo, e ciascuno rappresenta un livello di accesso incrementalmente più profondo. Lo stage inizialmente ottenuto – quello che abbiamo raggiunto sul nostro iPhone XS con usbliter – è lo stage uno, ed è il più importante dell’intera catena.
In termini astratti, uno stage uno di exploit BootROM è il punto in cui l’attaccante – o il ricercatore, o l’operatore che utilizza uno strumento di acquisizione forense – ha già iniettato il proprio codice di controllo nella BootROM del dispositivo, prima ancora che qualsiasi componente del sistema operativo venga caricato. Da questa posizione:
- La catena di firma Apple è aggirabile dallo stage successivo: si può caricare un iBoot personalizzato, un kernel modificato, un ramdisk arbitrario, purché si conoscano i passaggi tecnici corretti
- Le protezioni introdotte da iOS sono ininfluenti, perché nessun componente di iOS è ancora stato eseguito: né AMFI, né Secure Enclave in modalità produzione, né i controlli TXM (Trusted Execution Monitor) introdotti nelle versioni più recenti
- Il device è in uno stato “tethered”: ogni operazione richiede il PC e la catena di boot personalizzata, senza modifiche persistenti alla memoria flash del dispositivo se non esplicitamente volute – condizione fondamentale per la preservazione della prova digitale in ambito forense
- Non è un caso che questo genere di accesso sia impiegato dalle piattaforme di acquisizione full file system utilizzano internamente per estrarre i dati dagli iPhone di generazione compatibile. La differenza tra un vendor commerciale (che vende la soluzione a decine di migliaia di euro per licenza annua) e un ricercatore che documenta lo stesso stage è solo l’ingegneria – non l’informazione tecnica di base, che è ampiamente disponibile nella letteratura di sicurezza pubblica sin dal 2019 (CVE-2019-8900 – Apple Security Advisories).
Il valore dello stage uno non risiede tanto in quello che permette di fare da solo – il device connesso in PWND DFU non fornisce ancora accesso ai dati utente – quanto nel fatto che rende possibile ogni stage successivo. Da questa posizione, con il tempo e la competenza necessari, si può in linea di principio arrivare a:
- Il caricamento di un iBEC (iBoot Extended Console) personalizzato, in grado di accettare firmware non firmato da Apple
- Il boot di un kernel iOS modificato per disattivare i controlli di integrità
- Il montaggio di un ramdisk contenente strumenti di estrazione dati (SSH, tar, sqlite, keychain dumper)
- L’accesso completo al file system del dispositivo, sia partizione di sistema che dati utente, incluse le sezioni normalmente cifrate dopo il primo unlock
- L’estrazione delle chiavi crittografiche del keychain
È lo stesso schema che, con implementazioni diverse, viene utilizzato da anni per gli iPhone con SoC A7-A11. Portarlo alla generazione A12 è la sfida attualmente aperta.
Il panorama internazionale
La ricerca in questo ambito è in fermento. Nella medesima giornata in cui Paradigm Shift rimuoveva il proprio progetto, è comparso su GitHub un nuovo repository — usbliter8-fun a cura dell’utente 34306 — che documenta una catena analoga per iPhone 11 Pro (SoC A13 T8030) su iOS 27 beta. Il progetto include patch per iBSS, iBEC, kernel e TXM, oltre a un TSS proxy per la personalizzazione dei firmware tramite blob salvato.
Il progetto 34306 non è direttamente riutilizzabile sul nostro iPhone XS: l’A13 e l’A12 hanno offset diversi, e iOS 27 introduce nuove strutture crittografiche assenti in iOS 18, ma conferma che l’approccio è valido e che la comunità di ricerca sta attivamente lavorando su queste piattaforme.
Il repository resta pubblicamente accessibile al momento della pubblicazione di questo articolo. Il codice è distribuito con avvertimenti espliciti sui rischi di corruzione del Secure Enclave, del passcode, delle credenziali WiFi e del baseband: motivo per cui – come per ogni operazione di questo tipo – la ricerca deve essere condotta esclusivamente su dispositivi dedicati e mai su device operativi.
Prospettive per l’acquisizione forense
Se e quando la catena sarà completa sul nostro laboratorio, le possibilità applicative in ambito forense sono considerevoli. Un iPhone XS con ultima versione di iOS installata, rappresenta ancora una porzione significativa dei dispositivi che entrano regolarmente nei nostri casi come oggetto di analisi. Le capacità che uno stage completo abiliterebbe includono:
- Acquisizione full file system senza dipendere da tool commerciali di terze parti, con la possibilità di documentare integralmente ogni passaggio della procedura
- Estrazione del keychain e delle credenziali applicative, oggi non ottenibili con backup logico via libimobiledevice
- Recupero di chat cancellate e altri artefatti disponibili solo dai database SQLite completi, non nella loro versione backup
- Analisi live del dispositivo in modalità tethered per ricerca di malware persistente, con visibilità sul filesystem, sui processi e sui log a livelli non altrimenti raggiungibili
- Preservazione della prova con controllo totale sui passaggi eseguiti e ripetibilità dell’operazione documentabile
Non è un obiettivo alla portata di ogni operatore, e non lo è ancora nemmeno per noi in questo momento: siamo alla prima porta della catena, con davanti diversi stage da consolidare. Ma la strada è tracciata, e la letteratura disponibile – sia quella pubblica sia quella oggi rimossa ma già distribuita – è sufficiente per proseguire.
Considerazioni finali
Il team Forenser sta proseguendo – ovviamente per fini accademici e scientifici – l’attività di ricerca sui stage successivi per verificare quali sono le vulnerabilità dei sistemi e le potenzialità in ambito informatico forense.
Ogni progresso viene documentato internamente con criteri di riproducibilità che riteniamo essenziali quando si opera in ambito forense: nessun passaggio deve essere frutto di tentativi non tracciabili, nessuna patch deve essere applicata senza comprenderne il razionale, nessun test deve avvenire su dispositivi che non siano stati preventivamente designati come sacrificabili per la ricerca.
Il valore di questa attività non risiede in un jailbreak per finalità di modifica del dispositivo – ambito su cui non operiamo – ma nella comprensione tecnica di uno strato del sistema iOS che è pubblicamente documentato ma poco praticato al di fuori dei vendor commerciali.
Comprendere direttamente come funziona lo stage BootROM di un iPhone A12 significa poter valutare, in casi reali, la qualità delle acquisizioni prodotte da terzi, individuare eventuali artefatti introdotti dagli strumenti utilizzati e – nei casi in cui sia strettamente necessario – condurre l’acquisizione in modo indipendente, con piena documentazione tecnica della catena di custodia digitale.
Aggiorneremo il nostro sito con i risultati man mano che i vari stage saranno consolidati.