Nintendo torna a far rivivere i classici Game & Watch, i giochi elettronici che hanno riscosso un enorme successo tra il 1980 e il 1991, oggi disponibile in quantità limitate e contenente il gioco di Super Mario Bros pubblicato su NES nel 1985.

Il nuovo Game & Watch è già stato hackerato, come riportato da stacksmashing nel suo account twitter, questo piccolo dispositivo nasconde al suo interno un emulatore NES tascabile.

SUCCESS!! YESSSSS pic.twitter.com/EuMh8G9mp7

— stacksmashing (@ghidraninja) November 12, 2020

L’hacker ha voluto registrare l’impresa caricando il video sulla piattaforma YouTube dove spiega nei minimi dettagli il funzionamento del dispositivo e di tutti i suoi componenti.

Il processore principale è un stm32h7b0, un microcontrollore con poco più di 1 megabyte di RAM e 128 kilobyte di flash, è un cortex-m7 che è abbastanza diverso dal cortex-a7 utilizzato nei NES e SNES Classic.

Cortex-m7 non può eseguire Linux, il dispositivo funziona attraverso un firmware più o meno bare metal, il secondo chip è un chip flash SPI micronex da 8 megabit o 1 megabyte su chip SPI Flash che viene fornito in un adattatore soic-8 che lo rende più semplice da scaricare. Gli altri chip sono il circuito di ricarica, l’amplificatore dell’altoparlante, ecc…

Ora i microcontrollori generalmente hanno una porta di debug come JTAG o nel caso di cortex-m JTAG e/o SWD – debug del cavo seriale. Tramite questa porta puoi eseguire il flashing del dispositivo, leggere il firmware in un unico passaggio attraverso il programma e così via.

Queste porte sono spesso esposte per gli ingegneri su alcuni pin di facile accesso, e se diamo uno sguardo alla PCB ci accorgiamo dei pin non popolati abbastanza vicini alla CPU.

Per verificare se questa è effettivamente la porta di debug richiamiamo il Data Sheet e controlliamo su quali pin viene esposta la porta di debug.

Su questo pacchetto lqfp100 possiamo trovare il primo segnale di cui abbiamo bisogno chiamato SWDIO sul pin 72 e il secondo segnale SWCLK sul pin 76.

Nella panoramica dei pin possiamo vedere anche che il segnale di reset viene emesso sul pin 14. Prima di misurarlo sul dispositivo scolleghiamo anche rapidamente la batteria, utilizzando un piccolo cacciavite a testa piatta e facendo leva.

Ora portiamo il nostro multimetro impostato in modalità continua e vediamo se questi pin sul processore sono collegati ai contatti dell’intestazione non popolata e infatti sul primo pin troviamo SWCLK, sul secondo otteniamo la tensione di alimentazione del processore, il terzo è a terra, il quarto è SWDIO e l’ultimo viene resettato.

Ora ci sono alte probabilità che questa porta di debug sia stata disabilitata in produzione ma vale sempre la pena effettuare un tentativo e per farlo sto utilizzando una sonda di debug ARM, nel mio caso sto utilizzando un Segger J-link ma puoi trovare un sacco di diverse sonde di debug compatibili online a partire da circa tre dollari.

Ho collegato anche un paio di clip di prova alle sonde di debug in modo da poter ottenere facilmente una buona connessione ai contatti senza saldature – collegherò la sonda di debug all’USB, fornirò anche alimentazione al gioco e guarderò tramite USB-C. Nota che ho scollegato la batteria questo ci permetterà di accendere facilmente il dispositivo.

Ho avviato il dispositivo ed eseguito il gioco Super Mario Bros, ora passiamo al computer e vediamo se la nostra sonda di debug può connettersi al chip ..

Avvia  Jlink, seleziona stm32h7b0 come destinazione, SWD come protocollo e lascerò la velocità di debug predefinita. Perfetto, la sonda di debug può connettersi al chip perfetto. Ma sfortunatamente quando diamo uno sguardo più da vicino all’output del registro, il chip è “protetto”.

STM32 ha una funzionalità chiamata protezione di lettura che può essere impostata su una delle tre modalità: RDP0, che consente l’accesso completo al debug RDP1, che lascia abilitata la porta di debug ma impedisce le letture flash sebbene possiamo ancora accedere alla RAM e RDP2 che disabilita completamente la porta di debug.

Dovrei anche notare che in RDP1 possiamo riprogrammare il chip, ma farlo cancellerebbe il contenuto flash portando a briccare il dispositivo, quindi fai attenzione quando giochi a casa, ho già ricevuto la prima email da qualcuno che ha cancellato accidentalmente il suo dispositivo.

Ora in questo caso il dispositivo è impostato su RDP1, quindi abbiamo accesso solo alla RAM, il che significa che non possiamo scaricare il firmware, tuttavia, andiamo ancora avanti e scarichiamo le tre aree della RAM, le analizzeremo in seguito.

Quindi scarichiamo il chip flash, per fare ciò sto usando un TL866cs leggermente modificato sebbene dovrebbe funzionare con qualsiasi programmatore di flash SPI con supporto da 1,8 volt. Ho collegato una clip SOIC-8 al programmatore, che mi permette di agganciarla semplicemente al flash.

Notare inoltre che il programmatore alimenterà il flash-chip e quindi assicurati di scollegare la batteria e scollegare l’USB se lo provi a casa. Con la clip attaccata al chip flash, posso usare minipro per scaricare il contenuto della flash.

Ora abbiamo due cose, un dump completo del contenuto della RAM del dispositivo e un file dump della memoria flash esterna. Ora anche se non siamo riusciti a scaricare il firmware del dispositivo, questo ci offre molto da guardare, quindi iniziamo con i contenuti flash.

Per verificare se il flash è in chiaro o crittografato, ho eseguito un’analisi entropica sul dump flash utilizzando binwalk. Un’entropia molto alta come quella vista qui generalmente indica che i contenuti sono crittografati o compressi.

Poiché non riuscivo a trovare alcuna intestazione di compressione o giù di lì, ero abbastanza fiducioso che fosse crittografato …

Ho notato anche che non c’erano schemi ripetuti o giù di lì, rendendo meno probabile che si trattasse di una pseudo-crittografia XOR molto semplice o forse AES in modalità ECB, peccato se il flash non fosse criptato sarebbe semplicissimo, ma è ancora troppo presto per rinunciare.

Quindi diamo un’occhiata al dump della RAM dopo. La prima cosa che mi incuriosiva era se la ROM NES del gioco fosse caricata in memoria, e così ho aperto una ROM originale di Super Mario Bros nell’editor esadecimale a destra e il dump della RAM a sinistra.

Quindi ho semplicemente selezionato una parte della ROM originale e l’ho cercata nel dump della RAM, e sì, la ROM NES viene caricata nella RAM.

In seguito ho scoperto anche che la seconda ROM, Super Mario Bros 2 si trova sempre nella RAM, e che entrambe le ROM sono sempre caricate allo stesso indirizzo, per esempio Super Mario Bros 1 viene sempre caricato all’indirizzo 0x2400_0000.

Ho notato anche alcuni strani schemi nella RAM che a me somigliavano molto alla grafica, ho scritto un piccolo script Python che tratta i byte come bitmap RGBA e possiamo vedere il contenuto dello schermo.

Perfetto abbiamo trovato le due rom e il frame buffer, ma… questo non ci avvicina molto a far girare le nostre ROM su di esso. Dobbiamo capire la crittografia flash. Ora, dato che avevamo un bel backup del contenuto flash, mi sentivo sicuro di provare a giocherellare con esso.

Ho iniziato sostituendo un paio di byte nell’immagine flash con zeri in un editor esadecimale e usando il programmatore flash per riscriverlo sul dispositivo.

Dopo che il flash è stato completato, ho provato ad avviarlo e dopo averlo provato un paio di volte con zeri in luoghi diversi nella flash ho scoperto che funzionava ancora nella maggior parte dei casi.

Questo significa che il dispositivo non verifica veramente il contenuto della flash che è una cosa abbastanza importante da sapere quando cercavo di capire l’implementazione della sicurezza di un dispositivo.

La mia ipotesi era che la ROM fosse in qualche modo caricata dalla flash crittografata, e quindi continuavo a mettere zeri in posti casuali nella flash programmata del dispositivo e poi ho scaricato la RAM per vedere se alla fine i dati della ROM che normalmente sono sempre statici cambierebbero e dopo solo un paio di tentativi, sono stato fortunato.

I dati della ROM NES nella RAM sono cambiati. Ho cambiato 4 byte nella flash in 0, e ora improvvisamente, anche 4 byte nella rom sono cambiati.

Questo è fantastico, poiché ci dice molto, significa che la ROM è stata caricata e decrittografata dalla flash, non è convalidato e che è una crittografia bite-wise non ad esempio una crittografia basata su blocchi.

Ora era giunto il momento di pensare e analizzare, e alla fine l’ho capito che se XOR o i 4 byte originali dalla RAM con i 4 byte originali dalla flash, ottenevo esattamente gli stessi 4 byte che erano stati caricati in memoria quando ho scritto gli zeri nella flash …

Quindi stiamo esaminando una crittografia basata su XOR come forse AES-CTR. Ora che conosciamo il testo in chiaro, che è la ROM NES, e il testo cifrato, che abbiamo ottenuto dal flash dump, possiamo ottenere il flusso di dati XOR che è stato utilizzato per la crittografia, che ci consente a nostra volta di crittografare le nostre ROM NES.

Ho scritto un paio di script per provare questo, e puoi trovarli collegati nella descrizione. Il primo script prende un flash dump del dispositivo e un’immagine RAM del dispositivo e genera il flusso XOR richiesto per crittografare la nostra rom.Il secondo script prende un flash dump, il flusso XOR e la nostra ROM modificata e crea una nuova immagine flash crittografata.

Ho apportato alcune lievi modifiche alla ROM  originale del NES e l’ho installata sul dispositivo. Quindi accendiamo il dispositivo premendo il pulsante GAME per scegliere il primo gioco e sì, stiamo giocando ad una versione Hacked di Super Mario Bros, invece che a Super Mario Bros. Quindi siamo in grado di caricare le nostre ROM sul dispositivo, fantastico!

Ora ho anche notato che l’emulatore esegue alcune patch a caldo della ROM, ad esempio per mostrare la stringa del copyright dal 1985 al 2020, quindi c’è ancora molto lavoro da fare per poter caricare liberamente i nostri giochi sul dispositivo, ma i primi passi sono stati fatti e siamo in grado di eseguire il nostro codice NES sul dispositivo.

Il mio prossimo obiettivo è trovare un modo per scaricare il firmware da STM32 e se sei interessato a questo genere di cose sentiti libero di farlo iscriviti a questo canale spero ti sia piaciuto questo video e di rivederti presto su questo canale.

Risorse

Twitter: https://twitter.com/ghidraninja
Discussione Twitter: https://twitter.com/ghidraninja/status/1326855097083686917
Script Game & Watch: https://github.com/ghidraninja/game-and-watch-hacking
Manuale di riferimento STM32H7B0: https://www.st.com/resource/en/reference_manual/dm00463927-stm32h7a3b3-and-stm32h7b0-value-line-advanced-armbased-32bit-mcus-stmicroelectronics.pdf