SSH ramdisk su iPhone XS con iOS 18.7.9: la chain completa fino al file system
In un precedente articolo pubblicato pochi giorni fa avevamo raccontato il primo stadio della catena: la ricostruzione dell’exploit BootROM usbliter su un iPhone XS di test, con il dispositivo che transitava in modalità PWND DFU, lo stato di accesso più profondo ottenibile prima che qualsiasi componente del sistema operativo Apple venga caricato. Era la prima porta della catena. Oggi documentiamo il completamento dello stadio successivo: il boot di un ramdisk SSH sull’iPhone XS con iOS 18.7.9 installato, l’accesso al filesystem del dispositivo via sessione root, e la conferma che la catena costruita è riproducibile end-to-end.
Il risultato non è un jailbreak – il dispositivo torna alla condizione di partenza al primo reboot, senza modifiche persistenti alla memoria flash – ma è la conferma che la metodologia documentata dalla ricerca pubblica sui SoC A12 è oggi praticabile anche su iOS 18.7.9, la release stabile più recente disponibile al momento della verifica.
Dove eravamo: lo stadio uno
Nell’articolo precedente avevamo descritto la fase iniziale della catena: il caricamento sull’iPhone XS di un handler personalizzato all’interno della BootROM, tramite il payload dell’exploit usbliter distribuito attraverso un Raspberry Pi Pico configurato come ponte USB. Il risultato di quella fase era la modalità PWND DFU: il device visibile al sistema operativo host come dispositivo Apple in DFU, ma con un handler custom installato nella BootROM che esponeva due opcode aggiuntivi (CUSTOM_DEMOTE e CUSTOM_BOOT). Il dispositivo restava però in una condizione di attesa: il payload era iniettato, ma nulla girava ancora in esecuzione vera e propria oltre alla BootROM stessa.
Lo stadio uno è la porta d’ingresso, ma non è utile in sé. Serve un secondo stadio che faccia partire un ambiente controllato dall’operatore – un iBoot patchato che accetti immagini non firmate, un kernel patchato per disattivare i controlli di integrità, un ramdisk custom che contenga gli strumenti di acquisizione e analisi. È questo che abbiamo costruito nei giorni successivi.
L’ecosistema di riferimento: il progetto ICH
La ricerca pubblica su A12/A13 si è consolidata negli ultimi mesi attorno a un ecosistema di repository su GitHub che coprono i diversi livelli della catena: il firmware per il microcontrollore che esegue l’exploit iniziale, il toolkit di post-exploitation con le primitive di lettura/scrittura sulla BootROM, i patchfinder che identificano gli offset corretti nel kernel e nell’iBoot per la versione di iOS in uso, gli script di orchestrazione che assemblano l’insieme in una procedura eseguibile.
Per la costruzione del bootchain patchato – in particolare per la patch dell’iBoot che consente il caricamento delle immagini firmware non firmate da Apple, per la patch del kernel che disabilita AMFI (Apple Mobile File Integrity) e i controlli di debug, e per l’assemblaggio del ramdisk custom che permette l’esecuzione del kernel patchato – ci siamo basati sul progetto open source ICH_A12_plus_Ramdisk, sviluppato dal ricercatore Pa7r0n e disponibile pubblicamente su GitHub all’indirizzo github.com/Pa7r0n/ICH_A12_plus_Ramdisk. Il progetto automatizza l’intera fase di build del bootchain per SoC A12 e A13 e per iOS dalla versione 17 alla 27, integra i patchfinder di riferimento, gestisce l’estrazione parziale dei firmware dall’IPSW ufficiale Apple e produce un bootchain firmato con il certificato IM4M generico per l’A12.
Il progetto richiede un ambiente macOS Apple per la fase di build, perché alcuni strumenti di manipolazione dei formati di firmware Apple (IMG4, IM4M, wrapping dei coprocessori) esistono solo come binari Mach-O nativi. La fase di flash del microcontrollore e la sessione di boot successiva possono avvenire da qualsiasi macchina con libimobiledevice funzionante.
La catena tecnica in sintesi
La sequenza documentata e verificata sul nostro iPhone XS è composta da tre fasi principali. Ogni fase richiede il completamento della precedente e non è persistente al reboot del device: questa è una caratteristica desiderabile per un’attività di ricerca forense, perché garantisce che l’intervento sull’oggetto in analisi sia limitato alla sessione corrente.
Fase 1 – Applicazione dell’exploit BootROM (PWND DFU)
Il dispositivo, portato manualmente in modalità DFU, viene connesso a un Raspberry Pi Pico 2 (microcontrollore RP2350) preventivamente programmato con il firmware usbliter. Il Pi Pico innesca la vulnerabilità nel controller USB della BootROM A12 e inietta lo shellcode custom. In circa 700 millisecondi il dispositivo è in stato PWND DFU: il descrittore USB espone la stringa aggiuntiva PWND:[usbliter8] che conferma il buon esito dell’iniezione. Il dispositivo viene ora scollegato dal Pi Pico e riconnesso direttamente al computer di lavoro tramite un cavo Lightning con connettore USB-A.
Fase 2 – Boot di un iBoot patchato in modalità Recovery
Dal computer di lavoro il tool usbliter8ctl (script Python distribuito con l’ecosistema di riferimento) invia al dispositivo un iBoot personalizzato – costruito nella fase di build dal progetto ICH – tramite l’opcode CUSTOM_BOOT esposto dall’handler installato nella BootROM. L’iBoot personalizzato contiene una patch chirurgica al validatore image4 (due istruzioni ARM64 sostituite in un punto identificato dinamicamente dal patchfinder) che permette il caricamento di immagini firmware successive non firmate da Apple. Il device passa dalla modalità DFU alla modalità Recovery, riconoscibile perché libimobiledevice ora vede il dispositivo con la stringa MODE: Recovery invece di MODE: DFU.
Fase 3 – Caricamento della catena di boot completa e avvio del kernel
All’iBoot in modalità Recovery vengono ora inviati, nell’ordine documentato dal progetto ICH: il DeviceTree, il trustcache, il ramdisk contenente dropbear e gli strumenti di analisi, il kernel patchato (con le due patch AMFI e debugger applicate dal patchfinder Leeksov), e i firmware dei coprocessori (AOP, ANE, AVE, ISP, GFX, SIO) necessari alla corretta inizializzazione del bus USB nel kernel. Al termine il comando bootx innesca l’esecuzione del kernel patchato, che monta il ramdisk come rootfs, lancia il minimo indispensabile di userspace e avvia dropbear in ascolto sulla porta 22.
Il momento della verità: la sessione SSH
Terminata la fase di boot, il dispositivo continua a essere visibile al computer di lavoro come dispositivo USB, ma questa volta il suo endpoint di rete è servito dal kernel appena caricato – non più dalla BootROM o dall’iBoot. Un port forwarding USB tramite iproxy (strumento standard di libimobiledevice) espone la porta 22 del dispositivo su una porta locale del computer, e da lì una comune sessione ssh apre la shell root sul telefono. La password è quella standard del ramdisk di ricerca – alpine – che rispetta la convenzione storica dei jailbreak Apple da oltre quindici anni.
Il primo comando eseguito sulla shell è mount_ich, uno strumento distribuito con il ramdisk che monta in un colpo solo tutti i filesystem del dispositivo: il volume di sistema (sealed system snapshot, sola lettura per design a partire da iOS 15), il volume Dati utente (contrassegnato APFS con flag protect, ovvero con Data Protection attiva at rest), il volume Preboot, il volume xART. A questo punto abbiamo una vista completa della struttura del filesystem del dispositivo, e – a livello di sistema operativo – l’accesso più profondo ottenibile senza modificare permanentemente il dispositivo.
Cosa vediamo e cosa non vediamo
Il fatto che i filesystem siano montati non implica che tutti i loro contenuti siano leggibili in chiaro. iOS applica la sua protezione dati a livello di singolo file, distinguendo quattro classi di protezione: dalla classe A (“Complete”, decifrabile solo quando il dispositivo è sbloccato dall’utente) alla classe D (“NoProtection”, decifrabile senza input utente perché la chiave è derivata solo dall’UID hardware). Nella condizione di ramdisk boot post-DFU il Secure Enclave non è stato coinvolto nel processo di autenticazione utente e non ha derivato le chiavi di classe A, B e C: i file appartenenti a queste classi restano cifrati a livello di storage, e la loro apertura dal ramdisk restituisce Operation not permitted.
Ciò che possiamo ottenere adesso: acquisizione BFU
Nello stato attuale della catena la nostra postazione è in grado di eseguire un’acquisizione di tipo BFU (Before First Unlock) del dispositivo: i file di classe D – che comprendono la struttura del sistema operativo, i log di sistema, i database diagnostici, un numero non trascurabile di database applicativi non protetti da Data Protection e le cache condivise – sono immediatamente leggibili e possono essere copiati bit-a-bit dal dispositivo attraverso la sessione SSH. È lo stesso livello di accesso che gli strumenti commerciali di acquisizione full file system offrono in modalità BFU e rappresenta il risultato utile per una parte rilevante dei casi di analisi che entrano nel nostro laboratorio – in particolare quando la richiesta operativa riguarda dati di sistema, log applicativi, artefatti di rete o ricostruzione di sequenze temporali.
Ciò che non escludiamo: dialogo con il Secure Enclave (AFU-equivalent)
L’accesso ai file di classe A, B e C – che comprendono la maggior parte dei database delle app di terze parti, gli attachment delle chat, il keychain e altri artefatti tipicamente rilevanti in ambito investigativo – richiede la comunicazione con il Secure Enclave dal kernel patchato attraverso l’interfaccia IOKit AppleSEPKeyStore. Quando la password del dispositivo è nota all’operatore (perché comunicata dal titolare, come avviene di frequente nelle attività di consulenza tecnica di parte, o autorizzata dal collegio giudicante), il processo consiste nel fornirla al Secure Enclave via chiamata IOKit, ricevere in risposta le chiavi di classe derivate e passare queste ultime al driver APFS del kernel per la decifratura on-the-fly dei file. Non è una capacità che possediamo oggi sul nostro laboratorio, ma non è nemmeno un obiettivo di ricerca esplorativa: è un lavoro di ingegneria mirata sopra una base già consolidata, con un margine di tuning ragionevole per portarlo a compimento.
A conferma della praticabilità dell’approccio, il progetto pubblico usbliter8-fun (github.com/34306/usbliter8-fun) documenta una catena end-to-end funzionante su iPhone 11 Pro con iOS 27 beta che va ben oltre il ramdisk SSH: include patch al kernel per bypassare le protezioni AMFI e i controlli di trust, il dialogo con il Secure Enclave per il boot del sistema operativo completo, e il ripristino di una condizione di device operativo con SpringBoard funzionante e SSH persistente. Il progetto non è direttamente riutilizzabile sul nostro iPhone XS – l’A13 e l’A12 hanno offset kernel diversi, iOS 27 introduce strutture di sicurezza (SPTM, TXM) assenti in iOS 18, e alcune scelte progettuali di quel progetto sono incompatibili con l’uso forense che ci interessa – ma dimostra che la metodologia è consolidata e che l’estensione al nostro contesto è una questione di porting mirato e non di ricerca da zero.
Prossimi passi
Il traguardo del ramdisk SSH funzionante rappresenta un punto di consolidamento significativo della catena, ma non è il traguardo finale della ricerca. Restano da affrontare almeno tre aspetti di rilievo per l’applicabilità operativa in ambito forense:
- L’implementazione del dialogo con il Secure Enclave per lo sblocco delle chiavi di classe A, B e C, condizione necessaria per accedere ai file protetti da Data Protection quando la password del dispositivo è nota all’operatore o comunicata al collegio giudicante.
- L’automazione della procedura di acquisizione bit-a-bit dei volumi APFS del dispositivo, con generazione degli hash di integrità della catena di custodia e produzione di un’immagine in formato standard per l’analisi successiva con strumenti di parsing forense.
- L’estensione della metodologia al SoC A13 (iPhone 11, 11 Pro, iPhone SE 2020) e alle versioni più recenti di iOS su A12/A13, sulla base della ricerca pubblica in corso da parte della comunità internazionale.
Continueremo a documentare l’attività man mano che i risultati saranno consolidati. Le condizioni per una loro applicabilità in un contesto operativo – con tutte le garanzie di documentazione, riproducibilità e attendibilità che la prova digitale richiede – sono ora considerevolmente più vicine di quanto lo fossero pochi mesi fa.