Notiziona: craccata la Xbox 360.
Come hanno fatto: usando un po' di hardware (un CPLD Xylinx) programmato per fingere un brevissimo momentino di reset in più durante i check iniziali dopo l'accensione.
Risultato: mediamente il 25% delle volte che si applica il trucco si riesce ad aggirare i terribili test fatti dalla Xbox all'avvio, e perciò si riesce ad eseguire codice non "certificato" da Microsoft. Nel caso specifico, eseguono il Linux Loader
XeLL che può caricare ed eseguire da network (via protocollo tftp) o da CDROM. Non sarà la soluzione definitiva, però è già un ottimo risultato per gli smanettoni.
Dal punto di vista della "certificazione" del software da eseguire, purtroppo la Xbox 360 è fatta bene.
Come funziona tutto l'ambaradan. Il processore, all'accensione, comincia ad eseguire codice dalla ROM che carica un loader dalla NAND protetto da crittografia RC4 e "firma" RSA. Tale loader inizializza il security engine del processore (quello che in tempo reale fa crittografia e hash checking della RAM, presumibilmente il primo con AES128 e il secondo col rigoroso Toeplitz hashing, crittografie che variano ad ogni boot perché fondate su numeri casuali estratti componendo lo stato dell'hardware, un contatore e un generatore hardware di numeri random (che viene ulteriormente controllato che non abbia un numero "sospetto" di bit posti a "1").
Quindi - seconda fase - viene eseguito un programma che ripulisce la RAM (in questo caso è bytecode interpretato), poiché molti hack di altre piattaforme tentano di sfruttare qualcosa rimasto in RAM (o posto in RAM di proposito): se non venisse ripulita la RAM a quella che al processore
sembra l'accensione/reset, appena qualcuno va a taroccare l'equivalente del bus indirizzi si finirebbe per eseguire codice presente in RAM anziché il protettissimo codice originale della ROM o NAND.
Dopo la "pulizia" della RAM si passa alla terza fase: caricare un bootloader (sempre dalla NAND) ed eseguirlo. Il bootloader a sua volta carica un kernel minimale (ancora dalla NAND), lo "aggiorna" (patching) e poi lo esegue. Tale kernel contiene una minuscola porzione di codice eseguibile al livello di sicurezza più debole (hypervisor), che si preoccupa solo di controllare e bloccare eventuali punti deboli (per esempio, sapendo che i kernel versione 4532/4548 sono hackerabili, impedisce a quelle versioni di proseguire la procedura di boot).
Esatto,
"hypervisor": quello è l'unico punto di tutta la catena del boot della Xbox 360 in cui si può eseguire del codice "non certificato". Dato che dalla ROM in poi è tutto imbottito di crittografia, si pone il problema di come sfruttare quel breve momentino di hypervisor mode. L'hacking della Xbox 360 si basa sul
confondere (glitching) il processore per via elettronica.
Nel caso specifico, se si manda un brevissimo segnalino di "reset" al processore mentre è in hypervisor, si ottiene il curioso risultato che le operazioni di memory compare riporteranno zero (cioè al processore risulterà che due aree di memoria "risultano uguali"). Se si riesce a farlo proprio mentre sta confrontando "chiavi" e "firme", al processore sembrerà che il bootloader che ha appena caricato ha una firma uguale a quella certificabile. E per di più succederà mentre è ancora in modo hypervisor (massimo livello di privilegi, minimo livello di sicurezza).
L'hack sulla Xbox 360 si basa sul fatto che "alzando" il segnale sul pin CPU_PLL_BYPASS il processore si ritrova rallentato a 0.52 MHz (!!!) anziché ai 66.6 MHz della fase iniziale di boot o dei 200 MHz della fase di calcolo delle chiavi/firme. Così facendo, e calcolando accuratamente i tempi, si fa in modo da "aspettare il momento buono" (quello in cui mandare un impulso al pin CPU_RESET lungo nientemeno che un
un decimilionesimo di secondo, quel tanto che basta per centrare la finestra di opportunità della memory compare della chiave del bootloader; se il segnale di reset è troppo lungo si finisce per resettare davvero il processore).
Visto che i tempi sono così stretti, è probabile che si possa sforare di quel tanto che basta e cercare la finestra di opportunità "troppo tardi" o "troppo presto" (è impossibile stabilire con esattezza quanto tempo sarà richiesto ogni volta dal CPU_PLL_BYPASS per abbassare drammaticamente la velocità del processore), ma a furia di misurazioni e aggiustamenti gli hacker hanno ottenuto un livello di successo ragionevole: mediamente il 25% dei tentativi riesce e la Xbox 360 anziché dare l'errore "AD" al Power On Self Test, prosegue ad eseguire codice "non certificato"... che si guarderà bene dal restituire il privilegio
hypervisor. Da notare che il bypass del PLL è qualcosa di praticamente utile solo in fase di studio e progettazione da parte della Microsoft.
Dato che la CPU verrà rallentata a 0.52MHz (addirittura più lento di quella mostruosa ciofeca del
Commodore 64, che andava a 0.98MHz), per giungere al "dunque" occorrerà parecchio tempo (una trentina di secondi), dopo il quale il bypass del PLL verrà azzerato ed il processore tornerà alla velocità normale di esecuzione. Se la procedura fallisce, l'hack ripete automaticamente il reboot (dopo il quinto la Xbox si arrende con il tipico RROD, Red Ring Of Death, che normalmente indicherebbe un malfunzionamento hardware grave), per cui un tentativo di boot può durare anche diversi minuti.
Sulle Xbox 360 "slim", non trovando il CPU_PLL_BYPASS sulla motherboard, hanno scoperto che il chip HANA può riconfigurare i PLL per il processore, ricevendo i comandi da una porta I2C (comodamente dall'header J2C3 a portata di mano). In tal caso però l'impulso su CPU_RESET durerà ancor meno (venti milardesimi di secondo). Se tutto va bene, anziché l'errore F2 del Power On Self Test, il processore andrà avanti eseguendo in hypervisor mode il resto del bootloader. Questa informazione è interessante perché se io fossi un manager Microsoft avrei già comandato di far sparire la traccia PLL-bypass dalla motherboard e avrei fatto inserire ripetuti controlli sull'effettiva velocità di clock in tutti i momenti più critici. Quanto al CPU_RESET non c'è niente da fare (non vorrete mica dire alla Intel di reinventare il reset di un processore e farlo ipersensibile e imprevedibile?). Intanto sui 55 milioni di Xbox già venduti l'hack può funzionare (purché si abbia a disposizione il CPLD programmato e le "sonde" sui pin).
Nota sulla crittografia. La crittografia RC4 in linea di massima è uno XOR tra un blocco dati ed un flusso di byte apparentemente casuale. Per cui, di queste tre cose (blocco dati originale, flusso dati crittografato, chiave di crittografia) avendone due è possibile risalire all'altra. Dato che i blocchi crittografati sono presenti in tutte le Xbox e presumendo che abbiano identici i primi byte del loro codice decrittografato, allora è possibile inventarsi un pezzo di codice da far crittografare al processore e risalire quindi -per confronto- alla chiave che ha utilizzato.
Implementazione: occorre un micro veloce e preciso, per cui hanno usato un CPLD Xilinx CoolRunner II (xc2c64a) perché è anche economico, programmandolo attraverso il solito linguaggetto VHDL. Il CPLD fa i giochetti coi due segnali CPU_PLL_BYPASS e CPU_RESET con la temporizzazione esatta, ottenendo (nel 25% dei tentativi di accensione) in non troppe decine di secondi di tempo di eseguire del codice arbitrario in modalità hypervisor.
Mie considerazioni personali: per costruire questo hack sono richieste competenze avanzate di informatica e crittografia (almeno da laureato in informatica "pura": e comunque è impresa alquanto titanica riconoscere un algoritmo partendo da codice disassemblato), più competenze avanzate sull'hardware (che non si imparano all'università -poiché troppo commerciali e troppo poco durevoli- e nemmeno leggendo qualche buon libro), più competenze avanzate in fatto di elettronica (un laureato in ingegneria elettronica ci può arrivare sul piano teorico ma ritengo raro che sia sufficientemente smaliziato per immaginare soluzioni del genere, se non ha almeno diversi anni di lavoro concreto nel campo della microelettronica; tutti sanno cos'è un oscilloscopio e forse anche cos'è il VHDL e cos'è una CPLD, ma pochi ci hanno smanettato per un numero di ore sufficienti per dimostrarsi come il McGyver della situazione). Se tutte queste competenze non sono concentrate in una sola persona, occorre un colossale lavoro di gruppo in cui l'affiatamento tra i membri è l'ingrediente fondamentale.
Insomma, anche se questo hack porta la firma di tre autori, devo realisticamente sospettare che abbiano ricevuto qualche "dritta" da qualche progettista Microsoft di quelli più coinvolti nel progetto. Il glitching sanno tutti cos'è: ma
dopo quanti nanosecondi si deve fare? Il riconoscere la "catena" di decrittografie, magari con un disassembler hardware, quante notti insonni costerà? Quanti reboot hardware dovranno fallire prima di imbroccare almeno una volta la sequenza giusta avendo la certezza che è stata un'operazione ripetibile? Anche se c'è una mostruosa quantità di anni-uomo di studio e ricerca da parte di tantissimi altri aspiranti hacker (conoscenze che non si diffondono certo grazie a uno o due messaggini in qualche forum stiloso e sciccoso), affermo che è
decisamente improbabile che dei pur bravissimi esperti siano arrivati in meno di sei anni dall'ingresso sul mercato della Xbox 360 ad una soluzione che identifica, circoscrive, sfrutta l'unico punto debole "centrando" la minuscola finestra di opportunità (difficilmente eliminabile da Microsoft). E naturalmente affermo che chi scopiazza questa mia paginetta senza citare la fonte avrà, nel momento in cui meno se lo aspetta ed in cui è maggiormente imbarazzante, una diarrea improvvisa, galoppante, interminabile.
Post
