LE PROTEZIONI NELLE CONSOLES - XBOX CLASSIC

​

Siamo nel 2001, il 15 Novembre per la precisione, quando la XBOX viene lanciata nel nuovo mondo; questo è il periodo storico in cui 2 grandi compagnie detengono il mercato dei videogiochi dopo il fallimento di Sega con il Dreamcast; Nintendo, che mantiene il suo primato sulle consoles portatili con la sua linea DS e Sony che domina con le sue Playstation. In questo panorama generale fa il suo ingresso nel mercato dell'intrattenimento videoludico Microsoft con questo nuovo prodotto !

Il nome sembra venga dall'idea di voler utilizzare il sistema API di Microsoft (DirectX) all'interno di una "scatola" per il gaming contenente un PC che fosse semplice da programmare per gli sviluppatori se confrontata con le sue competitors da qui dunque "DirectX Box" a cui seguì l'appellativo definitivo di XBOX.

Le specifiche erano degne di un buon PC dell'epoca:

- CPU Pentium III Celeron mobile 733 MHz
- RAM 64 MB
- GPU GeForce 3 MX con TV out
- HDD IDE 8-10 GB
- Lettore DVD IDE
- Porta Ethernet 10/100
- USB per i gamepads (porta proprietaria)

e come sistema operativo veniva utilizzata una versione semplificata del kernel di Windows 2000 con DirectX 8 in grado di leggere musica e film rappresentando anche un comodo lettore multimediale. Vennero distribuiti circa 2250 DevKit ad un considerevole numero di imprese videoludiche (pare 165) ed i primi risultati furono molto buoni con circa 1.5 milioni di unità vendute entro fine anno in Nord America e circa 1 milione di copie del titolo 1st party Halo acquistate dagli utenti entro Aprile 2002 (piccola curiosità per far capire i diversi momenti storici: Halo vendette circa 5 milioni di copie fino al 2005 mentre Call of Duty: Modern Warfare 3 circa 6.5 milioni di copie... nelle prime 24 ore dal rilascio !) !

Nel 2002 Microsoft acquistò RARE, casa di produzione che aveva sfornato titoloni per Nintendo, promettendo in generale grandi giochi all'orizzonte per la piattaforma, compreso Halo 2 !

A metà del 2002 venne inoltre lanciato XBOX Live

l'esclusivo servizio online dedicato al gaming, cosa che fino ad ora era stato un fallimento nei suoi precedenti tentativi (vedi Dreamcast) ma stavolta anzichè una connessione modem c'era la veloce porta ethernet a farla da padrona ! Nel tempo l'idea si rivelò un buon successo ed in Italia venne addirittura abbinata ad una postepay "marchiata" per registrarsi ed accedere al servizio:


I suoi principali accessori ufficiali, oltre alle innumerevoli tipologie di joypads e le varie memory cards anche non originali

erano il telecomando infrarossi ed il modulo wireless


Non mancarono nemmeno i modelli "particolari":

• Alpha Tower I
• Alpha Tower II
• DevKit/DebugKit
• Development Discs
• SEGA Chihiro
• Primo Prototipo
• Crystal

• 
  
  Il primo modello di debug kit, aveva solamente un lettore DVD nelle sue prime revisioni mentre successivamente fu introdotta una porta USB.
  
• 
  
  
  Utilizzati tra il 2000 ed il 2001 erano dotati di HDD e caricavano il software nel PC attraverso i development discs.
  
• 
  
  
  Il development kit finale, molto più simile alla versione per uso domestico.
  
• 
  
  Dischi di sviluppo utilizzati in tutte le versioni di console development/debug.
  
• 
  Esisteva anche una versione Arcade prodotta da Sega, il Sega Chihiro:
  
  
  
  
  che utilizzava una versione hardware pre-release/debug della console e leggeva i dati da un supporto GD-ROM anzichè DVD.
  
• 
  
  
  Questa vistosa X di alluminio fu il modello presentato al Game Developers Conference del 2000 da Bill Gates e Seamus Blackley e la sua produzione costava circa 18.000$… al pezzo !!
  
• 
  
  Versione con HDD da 20 giga con case trasparente venduta durante l'ultimo periodo di vita della console.
  

Alla fine dei conti però, vendendo l'hardware in perdita (Microsoft stessa aveva dichiarato che per ogni console venduta avrebbe perso circa 75$), le unità vendute furono solo 24 milioni (contro i circa 100 della PS2 e soprattutto contro i circa 50 stimati dalla casa di Bill !) e le perdite stimate attorno ai 4 miliardi di dollari. Smise di essere supportata nel 2008 mentre il supporto al servizio Xbox Live resistette fino al 2010.

LE PROTEZIONI

Conscia del rischio di costruire e dispiegare milioni di unità hardware con potenziali centinaia di milioni di dollari di perdite iniziali qualora il mercato dell'esigente utente finale, che vuole macchine all'avanguardia con un grande parco software a prezzi da "una cena e via", non fosse stato attratto dalle sue capacità e dai suoi titoli, era fondamentale per il successo del modello di business "black box" (console a sistema chiuso) implementare un valido sistema di sicurezza atto ad ostacolare l'esecuzione delle copie dei giochi per far si che il consumatore fosse obbligato ad acquistare solo prodotti software approvati e soggetti a royalties perchè pirateria e titoli non approvati potevano completamente distruggere i proventi ottenibili.

Purtroppo peró la console è stata vittima del suo stesso design: la scelta di utilizzare un hardware da PC standard dell'epoca aumentava infatti notevolmente il valore di una Xbox "aperta" dal punto di vista dell' "appetibilitá hacker". Inoltre esisteva una ampia base di conoscenza sull'hardware del PC, quindi la curva di apprendimento per l'hacking della XBOX è stata più rapida rispetto ad altre consoles come la PS2 od il GameCube.

Vediamo dunque quali erano le mura difensive di questa massiccia fortezza scura e quali sono state le armi utilizzate per fare breccia in esse

DVD-9

I supporti sui quali venivano distribuiti i giochi sono DVD-9 singola faccia double layer per i quali all'epoca non esistevano ancora masterizzatori quanto meno a prezzi abbordabili. Inoltre tali dischi, che prendono il nome di XGD (Xbox Game Disc) possono essere letti correttamente solamente da un lettore XBOX originale a causa di sistemi di sicurezza fisici implementati nel disco stesso con comandi proprietari scritti nel firmware del controller dell'unità ottica.

In particolare i lettori DVD generici sono in grado di leggere tutti i primi 6992 settori (circa 14MB di video DVD che indica di inserire il disco in una XBOX) mentre quelli ufficiali possono leggere anche tutti i restanti settori che vengono definiti "locked":

I dati "bloccati" possono infatti essere sbloccati solamente a seguito di una sequenza di comandi SCSI chiamati, da chi ha tentato di reversare il protocollo, "Sphinx Protocol"; la serie di comandi è criptata con RC-4 e la key utilizzata è derivata da 44 bytes chiamati dal dev "key basis"; questi 44 bytes sono passati sotto l'algoritmo SHA-1 ed i primi 7 bytes risultanti sono utilizzati come chiave per la decodifica RC-4. Gli eseguibili dei dischi sono infine firmati con una chiave RSA-2048.

Una volta ottenuto un dump 1:1 (quindi SENZA alcuna patch/modifica) di un disco originale pare che questo, se masterizzato su un DVD-9 double layer, possa essere avviato su console non modificate poichè i dati e le firme contenute possono essere comunque verificate dal lettore DVD originale; questa informazione è da prendere con le pinze perchè è riportata come funzionante solamente su alcuni forum; probabilmente non è stato un terreno molto battuto perchè la softmod permetteva di caricare i titoli direttamente da HDD rendendo antieconomico (i DVD9 double layer costavano!) e dunque sostanzialmente obsoleto l'utilizzo di copie fisiche dei dischi. In ogni caso esistono hacks dei firmwares DVD che permettono sicuramente l'avvio di backups raw 1:1.

I modelli di lettori conosciuti contenuti nelle XBOX sono i seguenti:

ai quali corrisponde indicativamente un modello di revisione hardware della periferica di gioco secondo il seguente schema:

HDD LOCKED

L'hard disk IDE integrato nella console ha impostata una password per la sicurezza di livello "Maximum" e viene sbloccato dal kernel durante la fase di boot. La password di unlock viene generata a partire dal modello e del seriale del disco mixati con una key specifica (HDKey) attraverso l'utilizzo dell'algoritmo RC-4 come segue:

Si possono così riassumere i diversi passaggi necessari alla generazione della pwd di 32 bytes:

- generazione RC-4_key da eeprom_key e data_hash (i primi 20 bytes di eeprom_data).
- utilizzo della RC-4_key per decifrare il valore del "confounder" contenuto in eeprom crittografato ed i dati crittografati.
- generare un hash HMAC_SHA1 dalla eeprom_key e dal confounder e dai dati decrittografati.
- verificare che questo hash corrisponda al data_hash memorizzato nella eeprom; se non corrispondono i dati della eeprom non sono corretti; se gli hash corrispondono, i primi 16 byte del campo dati decrittografati corrispondono alla HDKey.
- una volta ottenuta la HDKey, viene richiesto tramite specifici comandi il modello ed il seriale del HDD.
- si genera dunque un hash HMAC_SHA1 basandosi su HDKey, modello e numero di serie del disco: I 20 bytes risultanti sono la password dell'HD, i restanti 12 bytes necessari per la password sono tutti zeri.

Il disco utilizza inoltre una partizione proprietaria denominata FATX (variante del FAT16/FAT32) con le seguenti partizioni:

assieme ad una "config area" dove sono salvati molti parametri per l'utilizzo online della console alla quale possono aggiungersi i seguenti "drives":
D - il lettore DVD
F - se formattato è per lo spazio compreso tra 8 e 10GB negli HDD da 10GB che vengono visti come 8GB
G - lo spazio di un HDD eccedente i 127GB viene contrassegnato con questa lettera
H < - > O - memory cards dei controllers

XBOX SECURITY 1.0

FLASH ROM (o BIOS)

Racchiusa all'interno di un package di tipo TSOP, la 29F080 è una FLASH ROM di 1MB (256kB nelle versioni di macchina rilasciate a partire dal 2003) connessa al chip MCXP (lo vedremo a breve) attraverso il protocollo LPC. Questa può essere letta in vari modi (sniffando la comunicazione, estraendo il chip, ecc) e la sua analisi mostra, dopo le prime fasi relative all'inizializzazione dell'hardware ed al caricamento di una "jam table" (detta anche x-code - è una tabella di valori che contiene codici operativi per letture, scritture, e semplici operazioni decisionali utilizzate nel contesto dell'inizializzazione hardware che nel caso della XBOX è memorizzata verso la fine della FLASH ROM), la lettura e decodifica di 16kB all'offset 0xFFFFA000 secondo un algoritmo simile al RC-4 ma leggermente modificato; una volta decodificati tali dati però i bytes risultanti sono "immondizia"… come mai ? Per scoprirlo i devs hanno modificato importanti sezioni della flash rom scoprendo con sorpresa che la console era ancora in grado di avviarsi ! Cosa in teoria impossibile se il boot fosse avvenuto attraverso il codice scritto in tale memoria... e se il codice di boot trovato fosse uno specchietto per le allodole ed il vero boot code risiedesse altrove ? In un processore crittografico esterno ? Impossibile visto che sulla scheda madre non ce ne sono. All'interno della CPU Pentium III ? Molto poco probabile visti gli elevati costi necessari a modificare in tal senso un processore già prodotto; inoltre voci di corridoio dicevano che Microsoft avesse inizialmente scelto AMD e fosse passata ad Intel all'ultimo momento cosa che non avrebbe reso possibile in così breve tempo la rielaborazione di fabbrica di una CPU.

SECRET bootROM !

Restava quindi solo l'ipotesi di una bootROM all'interno del chipset nVidia, molto più facile da modificare per questi scopi e soprattutto già noto per essere una versione "custom" del chip nForce prodotto appositamente per Microsoft !

Spoiler: Northbridge and Southbridge

I termini Northbridge e Southbridge sono specifici dell'architettura PC. Si riferiscono ai due chip di supporto di base che si trovano praticamente in ogni computer.
Un chip Northbridge collega la CPU alla memoria principale ed a qualsiasi bus di espansione ad alte prestazioni, come AGP e PCI.
Un chip Southbridge dipende dal chip Northbridge e gestisce tutte le periferiche extra che si trovano in un PC classico (parallela, seriale, USB, mouse, tastiera, controller IDE, codec audio, ecc), rendendo dunque l'architettura di un PC divisibile in tre moduli principali: CPU, Northbridge e Southbridge.

Nella Xbox il Southbridge è rappresentato da un chip progettato da nVidia chiamato MCPX:

questo è un derivato del nVidia nForce MCP Multimedia and Communications Processor.

Anche il chip Northbridge è stato progettato da nVidia e si chiama GPU NV2A (XGPU):

Sia il Northbridge che il Southbridge sono stati prodotti da TSMC (Taiwan Semiconductor corporazione manifatturiera). L'NV2A combina sia una GPU che una memoria tradizionale ed un controller del bus di espansione presenti nella maggior parte dei chip Northbridge. La combinazione della GPU e del Northbridge consente ai progettisti di unire la memoria grafica alla memoria principale con lo scotto da pagare di avere una certa penalità sulle prestazioni.

Come capire dunque se il "segreto" fosse celato all'interno del Southbridge o del Northbridge ? In un modo piuttosto brutale !

Una console venne infatti "cannibalizzata", le sue piste vennero analizzate ed i suoi chips sottoposti ad una procedura di decapping di tipo casalingo; nel processo si scoprì che probabilmente all'ultimo momento prima del design produttivo finale i pads per l'interfaccia JTAG furono resi inaccessibili e dunque non funzionanti.

Anche il decapping casalingo però non portò a buoni risultati data la mancanza di strumenti professionali atti a far emergere gli strati più profondi del chip (il dev che effettuò il reversing fu il famoso Andrew "bunnie" Huang):

Si decise dunque di "origliare" (eavesdropping) le comunicazioni tra i vari chip. I 3 candidati erano il Front Side Bus (FSB), il bus della memoria principale e la connessione tra Northbridge e Southbridge. Venne scelta l'ultima per motivi di costi, tipologia di trasmissione (protocollo HyperTransport) e di minor numero di piste da poter analizzare che nel PCB hanno addirittura già un label che le identifica:

Per effettuare un eavesdropping è necessario un chip dalle buone performance come un FPGA e nel caso specifico venne scelto uno Xilinx Virtex-E FPGA. Ecco l'immagine del "prodotto finale" installato e pronto all'uso (immagine tratta dal libro "Hacking The Xbox" scritto proprio da bunnie):

Gli stessi ingegneri Microsoft hanno dichiarato che non si aspettavano che qualcuno riuscisse a "sniffare" i dati da questo tipo di veloce protocollo ma così non è andata

Durante l'analisi infatti bunnie ha raccolto diversi dati ed è riuscito ad effettuare un bruteforce della chiave utilizzata nell'algoritmo RC-4/128 attraverso una analisi dell'istogramma di decodifica: in pochissime parole ha avviato un bruteforce attack facendo analizzare ad un software (da lui chiamato "keytest") i bytes decriptati - il programma dava una percentuale di possibilità che i bytes fossero decriptati con la corretta key grazie ad una statistica eseguita sui bytes stessi - chi mastica un po'di decodifica di dati criptati sa che quando una serie di bytes viene correttamente decodificata la maggior parte dei bytes sono "valori noti" (es. molti 00 oppure istruzioni di codice macchina specifiche); sapendo questo nel Febbraio 2002 trovò la key di 16 bytes ed identificò la sua posizione all'offset 0x8745 della "secret bootROM" la quale risiedeva dunque all'interno del SouthBridge MCPX ! Con questa key [2745A910397E6AA686FB4B1A4BA90FD2], segreto di un algoritmo di cifratura simmetrico, era possibile riscrivere la FLASH ROM come se fosse stata compilata da Microsoft bypassando di fatto ogni sicurezza sulla console !

Era infatti possibile riabilitare la programmazione FLASH ROM !

Microsoft aveva infatti rimosso la possibilità di riscrivere il chip dopo la programmazione in fabbrica ma ripristinare la scrittura si rivelò piuttosto semplice. Il segnale di scrittura della FLASH ROM è disconnesso omettendo una singola resistenza (posizionata in punti diversi a seconda della revisione hardware 1.0 o superiore ma comunque inferiore a 1.6/1.6b, vedremo poi perchè). Si può dunque saldare un pezzo di filo tra i due pads del resistore oppure anche semplicemente riempire lo spazio tra i pads con una certa quantità di stagno:


Ora, anche se la programmazione FLASH ROM è abilitata in hardware con questa piccola hardmod, all'inizio non esisteva ancora un programma che effettivamente eseguisse la riprogrammazione. Nel tempo furono dunque sviluppati anche vari tools atti allo scopo come il seguente:


La prima versione di XBOX era stata quindi totalmente "aperta" !

EEPROM

La console è dotata di una EEPROM da 256bytes prodotta dalla Catalyst [Modello CAT24WC02J] che contiene alcuni dati importanti criptati con algoritmo RC-4 tra i quali la key utilizzata per generare la password di unlock dell'HDD e la regione del prodotto assieme ad altri dati non codificati come il MAC Address, la key per andare online, il seriale della macchina, lo standard video, ecc:

La cifratura è effettuata con una key di 16 bytes contenuta nel 2BL e da lui passata al kernel; esistono solo 4 di queste keys a seconda della revisione hardware della console:
EEPROMKey Debug/Chihiro: 7B35A8B727ED437AA0BAFB8FA4386180
EEPROMKey 1.0: 2A3BAD2CB1944F93AACDCD7E0AC2EE5A
EEPROMKey 1.1: 1DF35C838EC9B6FCBDF661AB4F0633E4
EEPROMKey 1.6: 2B8457BE9B1E65C6CD9D2BCEC1A20961

Esistono diversi tool per esplorare ed eventualmente anche modificare un dump della EEPROM sia esso effettuato via software che via hardware:

GLI EXPLOITS UTILIZZATI NEL TEMPO

Esattamente come con altri dispositivi, anche con questo primo prodotto Microsoft si sono avvicendate modifiche ufficiali atte a tentare di chiudere le falle scoperte seguite a ruota da ulteriori exploits nella consueta rincorsa del gatto col topo... chi avrà avuto la meglio alla fine ? Scopriamolo !

Visor Backdoor

Il dev "Visor" scoprì che i dati nella flash ROM (in particolare la jam table) non sono nè criptati nè vengono verificati quindi è possibile eseguire quanto segue:

1 - avviare la console così da far decodificare il kernel in RAM;
2 - mentre si mantiene l'alimentazione si switcha il contenuto della jam table con una tabella alternativa (Visor backdoor) in grado di copiare il contenuto della RAM;
3 - si effettua un soft reset che reinizializza l'hardware senza cancellare la memoria principale cosicchè la nuova jam table venga eseguita salvando il contenuto della RAM.

Perchè andare a modificare la jam table ?

Il secret boot code decripta il 2BL dalla FLASH ROM e controlla un "magic number" scritto verso la fine del 2BL stesso; se lo trova errato la console esegue una serie di istruzioni che termina con l'esecuzione di una istruzione contenuta in 0x00000000 che, nel codice nativo AMD (azienda che sarebbe dovuta essere la produttrice della CPU XBOX), è un indirizzo invalidato quindi la console andrebbe in crash mentre i processori Intel eseguono l'istruzione a 0x00000000 anzichè crashare (nativamente il sistema si bloccherebbe comunque perchè non trova in tale posizione un comando valido); ma attraverso la modifica della jam table in quella posizione si può piazzare una istruzione arbitraria che non provochi il blocco bypassando di nuovo tutto il sistema di cifratura. Questo a quanto pare sembra essere un bug dovuto ad uno "strascico" di codice non revisionato e corretto quando Microsoft decise di passare ad Intel anzichè scegliere AMD per la CPU.

MIST Attack

Al fine di proteggere il codice di avvio segreto in caso di attacco hacker tale codice contenuto all'interno del chip Southbridge procede ad un auto-unmap poco prima di uscire nascondendosi in modo permanente dal sistema al termine dell'esecuzione. Quindi, un programma utente che tenti di accedere ad uno dei primi 512 byte in memoria vedrà il codice-esca contenuto nella memoria FLASH invece del codice di avvio segreto vero e proprio.

Michael Steil, a capo del progetto Xbox-Linux, ha scoperto un modo per sfruttare questa caratteristica. Il processo di annullamento della mappatura viene eseguito scrivendo su 0x80008008, un registro hardware nello spazio di configurazione PCI. La strategia di base è quella di includere un codice operativo nella jam tabelle che scriva su 0x80008008 ed annulli l'unmapping prima che la sequenza di inizializzazione sia terminata. Dal momento che le cache sono in questo momento disattivate, il processore inizierà a recuperare ed eseguire istruzioni dal blocco esca, istruzioni che possono essere liberamente modificate in quanto parte della FLASH ROM il vui contenuto non viene verificato come abbiamo già visto. Il problema, tuttavia, è che l'interprete della tabella jam blocca le scritture nella posizione 0x80008008, quindi questo trucchetto non dovrebbe funzionare. Tuttavia, un bug nella decodifica della configurazione PCI all'interno del chipset Southbridge fa rispondere l'istruzione unmap a più di un indirizzo; in particolare, il campo di bit "funzione" è ignorato, quindi anche una scrittura su 0x80008X08 dove X non è uguale a 0 ha successo, e queste scritture non sono bloccate dall'interprete della tabella jam. Pertanto, per ottenere il controllo dell'IP (Instruction Pointer) della CPU utilizzando l'hack MIST, è necessaria la modifica del blocco esca in FLASH per fargli contenere il proprio codice, quindi aggiungere alla tabella jam l'opcode appropriato per annullare la mappatura della ROM di avvio segreta durante l'inizializzazione dell'hardware.

XBOX SECURITY 1.1

Dopo aver violato la sicurezza 1.0 della console, a metà del 2002 Microsoft corse ai ripari implementando una nuova revisione del chip nVidia correggendo l'exploit scoperto da bunnie. Ad Ottobre 2002 l'hacker Andy Green effettuò in 1 giorno il dump della ROM MCPX (512 bytes) utilizzando un sistema non divulgato e scoprendo una nuova bootchain:

In pratica, non potendo contenere in soli 512bytes l'algoritmo per la cifratura RSA e non volendo spendere troppi denari per incrementare le dimensioni di tale hardware e dover quindi revisionare tutte le future consoles, all'interno della secret bootROM fu cambiata la key RC-4 [5D4E62E73EBA20C322125E91A1C79FE0FA0540FB] ed aggiunto un hash del contenuto di parte della FLASH ROM chiamata Flash Boot Loader (FBL) il quale contiene tale codice (RSA cipher, SHA-1 hash, Microsoft's public key e driver program); l'FBL viene eseguito solo se il suo hash è verificato nei confronti del valore salvato in bootROM.

Una analisi approfondita di questo hash contenuto nella secret bootROM ha evidenziato come questo sia generato dall'algoritmo TEA il quale aveva mostrato delle vulnerabilità già nel 1996; in particolare esiste un sistema attraverso il quale è possibile modificare 1 bit di 2 double words adiacenti senza che l'hash calcolato cambi ! Questo permise ad Andy di modificare una singola istruzione di jump facendola puntare ad una locazione della memoria principale la quale poteva essere "pre-caricata" di un ulteriore jump verso qualsiasi altro codice attraverso il già noto sistema della jam table. Morale della favola: il nuovo sistema di sicurezza 1.1 venne superato in 3 giorni !

A20 Hack

Connettendo il PIN 20 della CPU al GND si sposta il boot dall'offset 0xFFFFFF00 all'offset 0xFFEFFF00, bypassando totalmente la secret bootROM mantenendola però attiva e quindi dumpabile attraverso un piccolo programma caricato in memoria ! La spiegazione di questo hack è da ricercare nella storia dei processori 8086/8088 che i più curiosi possono leggere in originale nello spoiler sottostante (tratto da "17 Mistakes Microsoft Made in the Xbox Security System").

Spoiler: cenni di architettura x86

The memory model therefore was similar to the 8080, which could access only 64 KB, by dividing memory into 64 KB blocks. Intel decided that the 8086/8088 could have a maximum of 1 MB of RAM, which would have meant 16 “segments” of 64 KB each. But instead of doing it this way, they decided to let the 64 KB segments overlap, and have 65536 of these segments, starting every 16 bytes.

An address was therefore specified by a segment and an offset. The segment would be multiplied by 16, and the offset would be added, to result in the effective address. As an example, 0x0040:0x006C would be 0x40*0x10+0x6C=0x46C. An interesting side effect of this method is that it is possible to have addresses above 1 MB: The segment 0xFFFF starts at the effective address 0xFFFF0, so it should only contain 16 bytes instead of 64 KB. So the address 0xFFFF:0x0010 would be at 1 MB, and 0xFFFF:0xFFFF would be at 1 MB plus roughly 64 KB.

The 8086/8088 could not address more than 1 MB,because it only had 20 address lines, so addresses above 0xFFFF:0x000F were wrapped around to the lower 64 KB. But this behavior was different on the 286, which had 24 address lines: It was actually possible to access roughly 64 KB more using this trick, which was later abused by MS-DOS as “high memory”.

Unfortunately there were some 8086/8088 application that broke, because they required the wraparound for some reason. It wasn't Intel who found that out, but IBM, when they designed the IBM AT, and it was too late to modify the behavior of the 286, so they fixed it themselves, by ntroducing the A20 Gate (”A20#”). An unused I/O pin in the keyboard controller was attached to the 20th address line, so that software could pull down address line 20 to 0, thus emulating the 8086/8088 behaviour.

This feature was later moved into the CPUs, and all Pentiums and Athlons have it - and so does the Xbox. If A20# is triggered, bit 20 of all addresses will be 0. So, for example, an address of 1 MB will be 0 MB, and if the CPU wants to access the top of RAM, it will actually access memory that is 1 MB lower than the top.

Keeping this in mind, the attack on the Xbox is pretty straightforward: If we connect the CPU's A20# pin to GND, the Xbox will not start from FFFFFFF0, but from FFEFFFF0 - this is not covered by the secret ROM, but is ordinary flash memory, because flash is mirrored over the upper 16 MB. So by only connecting a single pin, the secret ROM is completely bypassed.

MODCHIPS

Una volta ottenuta le key di cifratura iniziarono ad uscire i primi modchips i quali, mettendosi in parallelo con il flash chip originale, erano in grado applicare patches al 2BL atte a bypassare la verifica della firma digitale RSA e la verifica del tipo di supporto da cui venivano avviati gli eseguibili permettendo l'avvio dei titoli backuppati anche da HDD che poteva ora essere anche sostituito con uno di più grandi dimensioni.

I modchip erano adatti a specifiche revisioni della XBOX rendendo dunque necessaria la possibilità di comprendere facilmente dall'esterno senza dover dunque aprire la console quale versione si avesse per le mani. I sistemi per identificarla, oltre quello del modello del lettore DVD visto più in alto, sono i seguenti:

SERIAL NUMBER

Il seriale applicato alla console è cosi strutturato: LNNNNNN YWWFF dove:

L - numero della linea produttiva all'interno della fabbrica
NNNNNN - numero della console prodotta durante la settimana di lavoro
Y - l'ultimo valore dell'anno di produzione
WW - numero della settimana dell'anno di produzione
FF - codice della fabbrica dove la console è stata prodotta (02 = Messico, 03 = Ungheria, 05 = Cina, 06 = Taiwan)

Di seguito una tabella abbastanza precisa (anche se non perfetta) per ricavare la revisione della console in base a tale valore:


Anche la schermata di informazioni sul BIOS può fornire informazioni utili secondo questa tabella:


Un ulteriore sistema che prevede però l'apertura della console è verificare il nome del chip decoder video:

XBOX SECURITY 1.6

Nel 2004 Microsoft corse di nuovo ai ripari sostituendo la FLASH ROM con una ROM (quindi non più riscrivibile) integrandola all'interno del chip dell'encoder video:

Questo non fermò gli sviluppatori di homebrews da sempre alla ricerca di sistemi per avviare ad esempio Linux (era comunque ancora possibile installare dei modchips). Gli hacker infatti sfoderarono diversi assi nella manica contro la nuova sicurezza !

SOFTWARE EXPLOITS

Di seguito analizziamo gli exploits software sfruttati dagli hackers.

GAME SAVE HACKS

Sono noti solamente 4 giochi utili a poter sfruttare un exploit nei loro savegames per effettuare una softmod sfruttando un classico buffer overflow:

- 007: Agent Under Fire
- MechAssault
- Tom Clancy's Splinter Cell
- Tony Hawk's Pro Skater 4

Per farla breve si deve copiare, tramite PC ed un software dedicato (es. Xplorer 360), un salvataggio modificato in una chiavetta USB formattata dalla XBOX, si inserisce tale chiavetta nella console (ebbene si, le porte della XBOX sono delle USB con forma e pinout proprietari ed attraverso un cavo adattatore acquistato oppure attraverso una femmina saldata su un controller si possono trasformare in comuni porte USB):

si trasferisce il salvataggio nella memoria interna della console da apposito sottomenu della dashboard, si avvia il gioco e si eseguono i passi per avviare l'exploit.

Nello spoiler sottostante potete leggere i passaggi su come utilizzare gli specifici salvataggi modificati per eseguire l'exploit.

Spoiler: SAVEGAME HACKS

Codice:

///////////////////////////////
// Mechassualt
///////////////////////////////
1) Insert the "MechAssault" game
2) Turn the Xbox off and back on
3) Select "CAMPAIGN"
4) Select "Install Linux"


///////////////////////////////
// 007 Agent Under Fire
///////////////////////////////
1) Insert the "007 AUF" game
2) Turn the Xbox off and back on
3) Select "Select mission"
4) Start the "trouble in paradise" mission
5) When you hear or see the helicopter, press (Start) and quit the mission
6) Press (B) to go back to the main menu
7) Select "load mission" followed by "Xbox Hard Disk"


///////////////////////////////
// Splinter Cell
///////////////////////////////
1) Insert the "Splinter Cell" game
2) Turn the Xbox off and back on
3) Select "Start Game"
4) Select "Linux"
5) Select "Check Points"


///////////////////////////////
// Tony Hawk Pro Skater 4
///////////////////////////////
Now here there are 3 versions of the save, NTSC, PAL & Region Free.
I have found that the PAL Classics edition of TH4 is Region Free, so requires the region free save.
Original PAL games maybe PAL or Region Free.
( French version of TH4 requires the PAL save )
1) Insert the "Tony Hawk Pro Skater 4" game
2) Turn the Xbox off and back on
3) Select "Free Skate"
4) Select "Any Character"
5) Select "Play Level"
6) Select "Created Park"
7) Select "Load Park"
8) Pick "Yes"
9) Select "Hack Xbox Park"
10) Select "Play Park"

Ma come è possibile far eseguire alla console un salvataggio modificato visto che questo è firmato digitalmente con una key generata a partire da un valore contenuto nel file default.xbe de gioco e da una key interna della console ?

La key all'interno del file default.xbe è ottenibile leggendo dal suo header i valori m_base e m_certificate_Addr secondo il seguente codice:

Codice:

var
MS : TMemoryStream;
xbeHeader : pTxbeHeader;
xbeCert : pTxbeCertificate;
begin

MS := TmemoryStream.Create;
MS.LoadFromFile(FileName);
new(xbeHeader);
new(xbeCert);
//Read in header and certificate
MS.Read(xbeHeader^, sizeof(xbeHeader^));
MS.Position := xbeHeader^.m_certificate_addr - xbeHeader^.m_base;
MS.Read(xbeCert^, sizeof(xbeCert^));

Questa key è poi elaborata attraverso l'algoritmo SHA1-HMAC con la key della console chiamata "Cert_Key" [5C0733AE0401F7E8BA7993FDCD2F1FE0] per ottenere un valore di 160 bit dei quali ne verranno utilizzati soltanto 16 come key per la firma digitale.

I dati di gioco saranno poi passati sotto lo stesso algoritmo SHA1-HMAC (escludendo la precedente firma digitale) utilizzando la signing key precedentemente scovata generando una firma che verrà applicata in un punto del salvataggio scelto arbitrariamente dai programmatori dello specifico gioco.

Oltre alla firma alcuni programmatori spesso includono anche un ulteriore controllo di solito basato su algoritmo CRC32 o similare anche esso da considerare se si vuole editare il salvataggio.

Conoscendo queste informazioni ottenute reversando il sistema della console è dunque possibile creare salvataggi dal contenuto arbitrario !

Nella maggior parte dei dispositivi elettronici dotati di sicurezza adeguata un exploit di questo tipo porterebbe a poter utilizzare liberamente lo "user mode" del sistema ma nella XBOX i giochi girano direttamente sotto kernel mode quindi un exploit di un gioco permette di avere il controllo completo della macchina senza dover andare a cercare anche un kernel exploit . Una volta eseguito l'exploit si può riscrivere il flash chip per rendere la modifica permanente !

Il primo di questi hacks (MechInstaller) fu rilasciato ad inizio 2003 dal team del Xbox Linux Project utilizzando il titolo MechAssault con codice del savegame modificato pesantemente offuscato e blindato da una chiave di cifratura custom segreta per rendere difficile la scoperta dello stesso.

DASHBOARD EXPLOITS

La dashboard è memorizzata nel HDD ed è il primo programma avviato dalla console se non è inserito alcun disco. Occupa circa 100MB motivo per il quale probabilmente è stato necessario utilizzare un disco fisso per memorizzarla anzichè un chip di memoria.

FONT EXPLOIT

L'eseguibile della dashboard è firmato digitalmente ed è controllato assieme alle hashes dei sui files di dati, tutti ad eccezione dei fonts ! Modificando questi fonts si può far crashare la console e farle eseguire codice arbitrario quindi, assieme al savegame exploit, ora esisteva un modo per rendere permanente la modifica senza la necessità di riscrivere il flash chip !

AUDIO EXPLOIT

Il player audio della console ha diverse vulnerabilità sfruttabili creando files con specifici nomi quando si rippano le tracce audio di un disco. In sostanza il problema risiede nel file E:\TDATA\fffe0000\music\ST.DB che non viene gestito correttamente dalla dashboard mancando di appropriati boundaries checks.

Questo exploit assomiglia molto al metodo di triggering dell'easter egg chiamato "<<Eggsβox>>"; rippando una traccia audio e chiamandola appunto <<Eggsβox>>, non appena si preme il tasto "done" appare un credit roll con i nomi degli sviluppatori:

RIMEDI DI MICROSOFT ?

Microsoft cercò di porre rimedio al exploit MechInstaller fixando la dashboard con una nuova versione ma era sempre possibile effettuare un downgrade della stessa !

Venne corretta anche questa possibilità blacklistando nel kernel l'eseguibile delle vecchie versioni di dashboard. Ancora nessun problema per gli hackers visto che potevano sempre utilizzare il secondo eseguibile della dashboard chiamato xonlinedash utilizzato per la configurazione del Xbox Live: bastava infatti copiare il vecchio xonlinedash e rinominarlo xboxdash per farlo crashare con il bug dei fonts

Microsoft allora blacklistò nel kernel anche questo eseguibile. Ma di nuovo nessun problema per i profanatori di codice perchè tutti i giochi XBOX hanno un eseguibile chiamato dashupdate che aggiunge le funzione Xbox Live alle prime versioni di dashboard che non lo avevano: anche in questo caso bastava copiare l'eseguibile dal DVD e rinominarlo in xboxdash Non era possibile blacklistare anche questo eseguibile perchè è eseguito da tutti i titoli che funzionano online ad ogni loro avvio: se fosse stato bloccato questi giochi non sarebbero più partiti.

Gli hackers avevano vinto !

CHAIN OF TRUST

A questo punto possiamo fare un riassunto delle catene dell'affidabilità che si sono avvicendate nel tempo.

MCPX versione X2 (utilizzata nelle consoles debug e sistemi arcade Sega Chihiro)
Secret bootROM X-Code Flash Read in a limited virtual-machine (come la versione 1.0 che si analizzerà di seguito ma senza disponibilità di una bootROM quindi in sostanza in queste versioni non esiste una vera chain of trust)

MCPX versione X3 1.0 (la stessa studiata da bunnie)
Secret bootROM X-Code Flash Read in a limited virtual-machine decritta il 2BL (2nd bootloader) utilizzando l'algoritmo RC-4 se ha successo esegue il 2BL altrimenti va in triple fault una volta caricato il 2BL la ROM e le keys per la sua decrittazione non sono più disponibili, il 2BL decritta il kernel utilizzando l'algoritmo RC-4 e lo estrae utilizzando l'algoritmo di compressione LZX una volta avviato il kernel le keys per la sua decrittazione non sono più disponibili ed esso avvia solamente eseguibili .XBE firmati digitalmente con firma RSA-2048 da supporti verificati il kernel avvia un DVD originale se presente oppure avvia la dashboard contenuta all'interno della quarta partizione del HDD.

MCPX versione X3 1.1

Secret bootROM X-Code Flash Read in a limited virtual-machine esegue hashes del FBL (Flash Boot Loader - vedere in seguito) decrittato utilizzando l'algoritmo TEA se ha successo esegue FBL), se fallisce occulta la ROM e va in triple fault FBL verifica l'immagine del 2BL, deriva la key salvata nel MCPX + Flash, decritta ed in caso di successo esegue il 2BL i passi successivi sono gli stessi della versione 1.0

MCPX versione X3 1.6
Il flash chip viene sostituito con una ROM che viene integrata all'interno dell'encoder video nel chip chiamato Xyclops, la catena rimane la stessa.

INIZIALIZZAZIONE DEL SOFTWARE

Quando una Xbox completamente assemblata ha raggiunto la fine della linea di produzione è in questo stato:

- immagine BIOS valida
- EEPROM vuota
- HDD vuoto ed unlocked

Per inizializzare la EEPROM e l'hard disk nella fase finale della produzione un tecnico inseriva un DVD contenente il programma di installazione denominato default.xbe (come qualsiasi altro eseguibile) creato dall'XDK con il flag "allow eject" impostato ed il codice regionale impostato su 0x80000000 ("DEBUG").

Quando viene inizializzato il kernel, questo esegue il checksum della EEPROM. Se fallisce la XBOX viene impostata in modalità DEBUG (ovvero il codice regionale viene impostato su 0x80000000). Con il codice regionale impostato su questo valore il kernel ignora se il disco rigido non è bloccato. Poiché il codice regionale corrisponde, il kernel eseguirà il software dal DVD e tale programma farà quanto segue:

- Formatta le tre partizioni di swap
- Copia XMTAXBOX.XBE dal DVD alla prima partizione di cache e lo esegue

A questo punto il DVD può essere espulso ed inserito nella prossima XBOX.

DVD FIRMWARE HACK

Agli inizi del 2006 iniziarono ad uscire versione di firmware modificate per eseguire copie di backup anche su consoles non modificate. Il dev TheSpecialist le rilasciò per i lettori Hitachi-LG mentre il dev Commodore4Eva le rilasciò per i lettori Samsung. I firmwares andavano caricati collegando il lettore IDE al PC ed utilizzando un specifici programmi proprietari per il flashing (MTK Win flash per i Samsung ed SF8163 per gli LG-Hitachi):


I modelli Philips e Thomson sembrano non aver mai goduto di firmware alternativi.

Detto questo ecco un sintetico riassunto grafico di come sono dunque andate temporalmente le cose:

CURIOSITA'

CODICE "DIMENTICATO"

A giochi fatti si è poi scoperto che i primi 512bytes della FLASH ROM da 1MB contengono una vecchia versione della bootROM stessa con codice che dimostra come all'inizio avessero pensato di utilizzare l'algoritmo di cifratura RC-5 il quale però non era stato ancora perfezionato e forse non doveva nemmeno essere nelle mani di Microsoft quindi alla fine optarono per l'RC-4.

BACKDOOR SOSTITUZIONE HDD

Il kernel Xbox dalla versione 4034 ha un'altra backdoor che funziona anche se il controllo EEPROM ha esito positivo (il kernel ne controlla il checksum, se negativo la console entra in debug mode ed ignora se l'HDD sia "locked" oppure no): se è impostato il bit 30 della flag "media" di un XBE la condizione (locked oppure unlocked) del disco rigido viene ignorata. Questo consente a Microsoft di sostituire dischi danneggiati senza sostituire una EEPROM funzionante in una console inviata per la riparazione. Prima di questa modifica la EEPROM andava riscritta ogni volta che veniva sostituito l'HDD.

ALTRO EASTER EGG

A Maggio del 2021 è stato scoperto un nuovo easter egg:
1 - Andare in “Musica” ed insere un CD audio (meglio se di breve durata così da necessitare meno tempo)
2 - dalla schermata del CD audio, scegliere "Copia", di nuovo "Copia" e quindi "Nuova traccia".
3 - eliminare il nome predefinito della traccia e sostituirlo con (senza virgolette)
"Timmyyyyyyyyyyyyyyyyyyyyyyyy!"
(26 volte "y" + un punto esclamativo finale).
4 - attendere la fine del ripping e tornare al menu principale.
5 - da qui andare su "Impostazioni" e poi su "Informazioni di sistema": ora si dovrebbe vedere una nuova schermata che elenca i membri del "Xbox Dashboard Team":

XBMC E KODI

Kodi, il famoso multimedia player che viene utilizzato su molte distro di linux:

trae le sue origini proprio dalla XBOX quando, nelle sue prime versioni su questa console, era l'homebrew chiamato XBMC (XBox Media Center).

ALTRE KEYS

La key RC-4 debug è: 5742290C301ED301B3E55D285031E1CE

La kernel key è: EE006D2C35372D9AD39227FBFC1FEC20

CONCLUSIONI

Queste vicissitudini dimostrano come utilizzare un algoritmo di cifratura con chiavi simmetriche significa che la key deputata a mantenere sicuro il dispositivo è contenuta nel dispositivo stesso; utilizzando un sistema di chiavi asimmetriche la key privata non si sarebbe trovata nel dispositivo e dunque la sicurezza sarebbe stata maggiore.

La storia dell'hacking XBOX ha avuto anche importanti vicissitudini legali perchè il dev bunnie ebbe non pochi problemi a far riconoscere dal MIT (Massachusset Institute of Technology) il suo lavoro come "ufficiale" mentre altri devs che provarono a contattare Microsoft per spiegargli le vulnerabilità scovate non ottennero risposta.

Era inoltre da poco stato introdotto (1998) il Digital Millennium Copyright Act (DMCA) ha portato la crittografia fuori dal dominio dell'hacker: ora la legge precisa che solo i ricercatori "impegnati in un corso di studi legittimo, impiegati o adeguatamente formati od esperti” sono autorizzati a indagare sui metodi crittografici per proteggere i diritti di accesso alle opere. È diventata una battaglia tra hacker e legislatori al fine di mantenere la crittografia all'interno del diritti legali degli hacker.

L'aspetto più allarmante del DMCA per gli hacker è che incarna il concetto dove le uniche fonti di innovazione di beneficio per la società si trovano all'interno degli enti di ricerca. Improvvisamente, è un crimine da esplorare, nel comfort di casa tua come hobby, i metodi crittografici utilizzati per proteggere i diritti di accesso; l'atto limita di fatto la ricerca di tale tecnologia solo a istituzioni consolidate e non consente la possibilità di sviluppo tecnologico da parte di individui non "affiliati". Senza la libertà di ricercare e sviluppare la tecnologia "nel proprio garage", dove sarebbero oggi "artisti" del calibro di Bill Hewlett e Dave Packard, o Steve Jobs e Steve Wozniak ?

In ogni caso, dopo aver violato la sicurezza sul Xbox, questa non resta che un PC standard ed anche in questo caso si è visto come, per ogni schema di protezione del copyright che viene sconfitto da un hacker, qualcun altro ha la possibilità di imparare una importante lezione su come realizzare un sistema di protezione migliore.

(cit. "17 Mistakes Microsoft Made in the Xbox Security System")​

 

Beh si è vero comunque anche quella è arte e se fatta bene paga anche più di tante altre (per fortuna? purtroppo?)

Uuuuuu quanti errori ! Grazie mille come sempre

 

Concordo pienamente con tutto quello che hai scritto, sono tutte "figure" necessarie affinchè rivoluzioni tecnologiche ed intellettuali come quelle avvenute con questi personaggi possano mettersi in pratica; è, nel suo piccolo, un po'la storia della società, il solo "tecnico" non è sufficiente per far funzionare le cose, serve anche la macchina "propagandistica" per far si che una idea o una innovazione possa far breccia nei cuori delle persone con tutte le conseguenze positive ma anche negative che ne possono derivare.