LTU2, C/R parziali e perdita Stealth

[gteknoz]

Ciao a tutti,
leggendo un forum braziliano mi sono imbattuto oggi in una notizia interessante (che oltretutto sembra fare riferimento a uno studio fatto qualche mese fa da un utente di consolenet, il bravissimo Dark-G).

Mi scuso per il post che sara' chilometrico e tecnico, ma spero che questo suscitera' un po' di interesse in chi come me e' appassionato di reverse engineering, crittografia e compagnia bella :-)

Faccio una premessa tecnica per quello che conosco (e se qualcuno ha correzioni da fare sono bene accette)

Dentro la nand di ogni console c'e' una tabella chiamata FCRT.BIN che contiene una serie di domande e risposte (challenge/response) che vengono periodicamente inviate al lettore dvd per controllare che non sia stato modificato.
Questa tabella era stata introdotta con i primi lettori 16D4S ed i firmware iXtreme avevano trovato il modo per aggirarla senza memorizzarla usando la loro funzione stealth.

Con l'avvento dei lettori 16D5S si e' reso necessario estrarre la tabella dalla nand con il RGH per poi usarla dentro i vari dispositivi (LTU/LTU2 PCB, Matrix PCB, XKey e altri emulatori di drive, etc.).

In pratica questo utente brasiliano (Ubernerd) ha analizzato il modo in cui vengono memorizzate le tabelle challenge/response ed ha scoperto che nel caso degli LTU/2 le tabelle non vengono memorizzate completamente, ma solo in maniera parziale (sembrerebbe per problemi di spazio dentro il chip usato dagli LTU2).

Per dimostrare tutto cio' ha anche pubblicato un programma con tanto di sorgente che mostra la conversione dalla tabella FCRT memorizzata nella nand, alla tabella che invece viene memorizzata nel firmware LTU2 e spiega nei dettagli come durante questa conversione, per risparmiare spazio molti dei dati vengono buttati via rendendo quindi il firmware facilmente riconoscibile da MS.

Il sorgente pubblicato e' pieno di commenti (in inglese) che spiegano nei dettagli il tutto (e sono una vera manna per chi come me gode a scoprire i segreti tecnici dei vari hack :-)

Quello che si capisce dai commenti del sorgente :

Nei files FCRT ci sono 502 coppie di domande/risposte. Ogni coppia e' costituita da una domanda di 16 bytes e da una risposta corrispondente, sempre di 16 bytes.
In pratica la console ogni tanto prende una coppia a caso, invia la domanda da 16 bytes al lettore dvd e controlla che questo risponda con i 16 bytes giusti. Se questo avviene, il lettore viene riconosciuto come originale, altrimenti il lettore e' stato modificato.

Il problema degli LTU2 sembra essere che non memorizzano la domanda completa, ma solo i primi due bytes e l'ultimo.
Quando la console invia la domanda da 16 bytes, il lettore controlla che i primi due bytes e l'ultimo corrispondano a quelli che ha memorizzato internamente e se questo avviene allora manda la risposta corrispondente.
In condizioni normali questo e' sufficiente perche' tutte le domande/risposte sono differenti e 3 bytes corrispondono a circa 16 milioni di combinazioni, quindi tre bytes bastano a riconoscere una delle 500 domande differenti.

Tutto sembrerebbe filare liscio, ma qui entra il brasiliano che fa vedere come questo sia pero' un grosso problema :

Se il drive puo' controllare solo 3 bytes su 16 (perche' gli altri 13 non li ha memorizzati), esisteranno milioni di challenge differenti a cui il drive rispondera' sempre nello stesso modo (e chi si intende di crittografia capira' subito che questo e' un grosso problema).

In pratica lui dice :

- la console sceglie una domanda a caso tra le 502 e la manda al lettore.
- Il lettore rispondera' con i 16 bytes corretti.
- a questo punto la console puo' cambiare uno qualsiasi dei 13 bytes non memorizzati (o cambiarli tutti) e rimanda la domanda cosi' modificata al drive.
- un drive originale rispondera' con una risposta diversa dalla precedente, perche' la domanda inviata e' divesa. Un lettore con LTU2 pensera' invece che la domanda ricevuta sia uguale alla precedente (perche' confronta solo 3 bytes su 13) e rispondera' sempre allo stesso modo.

A questo punto l'xbox sa che sta parlando con un drive moddato.

Il modo per riconoscere il drive e' tanto semplice quanto geniale :-)

Mi farebbe veramente piacere un commento di Dark-G sull'argomento visto che sembrerebbe che dal suo lavoro fatto, sia partito il tutto!

P.S. Il topic in questione (dal quale scaricare programma e sorgenti) e' questo : forum outerspace e chi non parla portoghese puo' usare google translate

[xboxbs]

interessante, vediamo cosa risponderà mister xecuter, grazie per la tua traduzione

[Razorbacktrack]

Dark-Giiiiiiiiii

[The Pusher]

Punto Giiiii

[gteknoz]

Quindi i drive originali invece contengono la tabella completa, giusto?

I drives originali (ed anche il firmware LT3.0) generano le risposte dinamicamente quindi e' come se contenessero tutte le domande e tutte le risposte possibili.
La console invece ha un sottoinsieme di 502 domande/risposte e le usa per controllare che il drive sia originale.
Gli LTU2 contengono tutte le risposte ma solo pochi bytes delle domande e questo crea il problema.

Paradossalmente e' molto piu' sicuro andare su live con un LT3.0 che con un LTU/LTU2 visto che il primo e' realmente stealth ed il secondo e' riconoscibile.

[Di4b0liK]

Anche i 16D5S generano dinamicamente le response?
Io non me ne intendo di LT e storie varie, ma il firmware mod non nasce dal cracking dell'originale, ossia bypassando solamente le istruzioni do controllo autenticità disco e lasciando inalterato tutto il resto?

Infatti è così, tuttavia non bisogna fare confusione tra le due cose, dark-g si occupò semplicemente di rendere disponibile a tutti la funzione di creazione del C-R.bin, ossia fare in modo che partendo da un fcrt e una dvdkey qualsiasi tool potesse generare il file... tutto ciò imho è molto utile (specialmente in ottica open visto che senza quel codice tutti gli altri maggiori programmi tipo autogg, il tool di swizzy ecc... sarebbero stati tagliati "fuori mercato") ma è ben diverso dalla creazione vera e propria del custom firmware

[gteknoz]

Infatti è così, tuttavia non bisogna fare confusione tra le due cose, dark-g si occupò semplicemente di rendere disponibile a tutti la funzione di creazione del C-R.bin, ossia fare in modo che partendo da un fcrt e una dvdkey qualsiasi tool potesse generare il file...

L'apertura dell'algoritmo di conversione ha pero' permesso di scoprire questo grande buco che impedisce di fatto agli LTU/LTU2 di essere stealth (oltre a confermare di fatto quello che e' stato detto dal brasiliano Ubernerd).
Nello specifico, questo e' il documento dove dark-g spiega l'algoritmo di conversione da FCRT a C-R :

https://www.dropbox.com/s/2zjwpfgtg6...sed_Dark-G.txt

nella funzione responses, si vede il loop dove tutte le challenges/responses vengono copiate nel file C-R.bin e salta subito all'occhio la parte :

Oper.removeByteArray(ref array, 2, 13);

che rimuove questi famosi 13 bytes dalla challenge.

[gteknoz]

Ok, ma il mio dubbio era un altro:
I drive 16D4S/5S originali contengono nella MTK una copia 1:1 delle C/R in modo da rispondere adeguatamente o le response vengono calcolate basandosi sulla challenge dal drive?

I drive originali generano automaticamente le risposte utilizzando dei procedimenti crittografici (in pratica prendono la domanda che gli arriva, la mescolano con tutta una serie di dati, chiave dvd, parti del firmware stesso, etc) e calcolano cosi' la risposta. L'idea e' che se uno modifica il firmware per far andare i dvd+r, quando viene calcolata la risposta questa sara' diversa e la console puo' accorgersi che il drive e' stato modificato.
Nei 16D4S per quello che ho visto, i firmware ixtreme usavano una specie di rootkit per nascondere le modifiche apportate al firmware, cosa che invece non e' stato possibile fare per i 16D5S (ed e' stato quindi necessario usare la tabella completa estratta dalla nand della console).

Quello che non capisco è perchè se il drive originale risponde correttamente uno con su LTU(fw originale crackato) non lo debba fare automaticamente.

Per il motivo di cui sopra... perche' alcuni bytes del firmware stesso vengono utilizzati per calcolare le risposta e se uno modifica il firmware, la risposta calcolata e' diversa.
E' una specie di checksum in pratica, tipo il CRC che si usa nei .zip (solo che gli hash crittografici sono solitamente molto piu' complicati di una banale checksum, quindi basta cambiare un solo bit per cambiare radicalmente tutto il risultato).

[Dark-G]

Non per cattiveria ma mi piacerebbe sapere come i brasiliani sono entrati in possesso di quel documento, alla fine avevo scelto di non renderlo pubblico più che altro per una questione di rispetto nei confronti di chi ha buttato energie e risorse nella sua creazione (TX in questo caso), un conto è opporsi ad una scelta commerciale più che criticabile (non ho trovato affatto corretto il fatto di inventarsi la storia del C-R solo per dare una pompata ai download di J-Runner) ma è ben diverso il fatto di reversare l'intero firmware, specialmente in una scena come questa dove appena ti dimentichi una porta socchiusa c'è subito qualcuno pronto a fotterti e clonarti il materiale... per questo mi stupisco, avevo rilasciato il codice solo a pochi e fidati coders per fare in modo di aggiungere quella funzione nei loro tools con la promessa che avrebbero tenuto privata l'intera documentazione ma vedo con rammarico che come al solito gli interessi economici vengono prima del resto... mah... poi si lamentano che le poche persone veramente competenti che popolano la scena si sono tutte accasate con qualche team... gentilmente posta il link alla discussione di cui parlavi all'inizio.

[Razorbacktrack]

[TÓPICO OFICIAL] Discussão Técnica sobre Reset Glitch Hack (RGH possivel em QUALQUER PHAT/SLIM) | Página 1070 | Fórum Outer Space - O único com Emotikongs

C'è scritto nel primo post

[gteknoz]

posta il link alla discussione di cui parlavi all'inizio.

Ciao,
il link e' alla fine del primo messaggio e il codice e' stato postato da un altro utente (NiceShot1985) qualche pagina dopo.
Sara' che bazzico sulla scenda da tanto tempo, ma non mi sorprende che in molti non badino alla riservatezza dei documenti rilasciati (dopotutto basta una sola persona meno fidata e qualsiasi cosa viene distribuita velocemente). E' una cosa che ho imparato ad accettare e tutto sommato forse fa parte del gioco (io appartengo ancora alla scuola di "Information wants to be free" ;-) ).

Detto cio', capisco perfettamente la tua scelta di non voler rilasciare pubblicamente il documento, ma per quello che puo' valere, a me ha fatto piacere leggerlo e da appassionato e studioso, l'ho trovato molto interessante oltre ad offrire degli stimolanti punti di discussione.

Grazie ancora quindi per il contributo dato (seppure contro la tua decisione iniziale)

[xboxbs]

quindi il nostro dark-g lavora per Oreans Technologies? notevole!

[Dark-G]

Ok, concetto chiarito. Sapresti anche dirmi come mai non si riesce ad applicare il "metodo rootkit" ai d5s?

@Dark-G: Spiacente che ti abbiano leakato il code
Comunque ottimo lavoro con Themida, complimenti

Grazie ma ti assicuro che quando si parla di .net Themida diventa un packer a dir poco banale, sono passati anni ma ancora non si sono messi in testa di sviluppare una protezione adeguata.

Comunque nessun problema per il leak, ormai è andata così. A questo punto mi fa anche piacere che possa essere studiato da qualcuno volenteroso e con un po di tempo a disposizione... sperò senza fini di lucro però

[gteknoz]

Ok, concetto chiarito. Sapresti anche dirmi come mai non si riesce ad applicare il "metodo rootkit" ai d5s?

Sinceramente non lo so con certezza, posso solo fare delle supposizioni.
Nel caso delle prime board LTU che da quello che si dice in giro montavano praticamente lo stesso chipset, forse il problema era puramente di spazio libero, nel senso che per nascondere la presenza delle modifiche bisogna salvarsi da qualche parte tutta la parte del firmware che e' stata sostituita/modificata. Nei lettore 16D4S, questo sembrava essere piu' facile perche' c'erano molte zone "vuote", forse queste non erano piu' presenti nei nuovi lettori. Un altra ipotesi e' che l'algoritmo di checksum sia stato implementato direttamente in hardware e che non fosse quindi aggirabile facilmente via software.

Nel caso delle board LTU2 che montano invece un vecchio chipset, tutto il firmware e' completamente diverso e quindi decade proprio il concetto del metodo rootkit perche' bisognerebbe salvarsi una copia completa del firmware originale.

Comunque da quello che ho letto, il sistema FCRT e' perfettamente sicuro in quanto la console conosce la risposta solo a quelle famose 502 domande che sono in esso contenute (a patto ovviamente di salvare completamente tutti i dati, altrimenti si apre il possibile buco di riconoscimento che descriveva il brasiliano).

P.S. Per chi vuole dare un occhiata al rootkit degli LT3.0, questo e' presente in chiaro direttamente nei firmware dall'offset 0x3f000 in poi (basta estrarlo e disassemblarlo con un disassembler per 8051).

[gteknoz]

Thanks!
Al rootkit ci darei volentieri un'occhiata, ma purtroppo non mastico così bene l'ASM da poterlo capire a fondo

Quello su LT3.0 e' abbastanza sempliciotto a dire il vero, controlla solo se il firmware sta leggendo delle zone di memoria che sono state modificate e nel caso risponde con i bytes originali salvati in una tabella a parte. Certo bisogna avere un po' di familiarita' con l'assembler 8051...

[gteknoz]

This?

Esattamente. Tralascia i primi 0x10 bytes che sono uguali al firmware originale, dall'indirizzo 0xF010 inizia la parte che nasconde il codice.
Come input in ram 0x56 e ox57 c'e' l'indirizzo a 16 bit che la routine di hash (quella che crea i response) sta controllando.

Questa parte :

mov     A, RAM_57
subb    A, #0x10
mov     A, RAM_56
subb    A, #0xF0
jc      bank3_F01D

in pratica controlla che l'indirizzo letto sia minore di 0xF010.
In caso di lettura di un indirizzo >= 0xF010, la routine ritorna 0xFF che e' il valore presente dall'indirizzo 0xF010 in poi nel firmware non modificato, di fatto nascondendo tutto il nuovo codice presente. In caso contrario l'esecuzione continua all'indirizzo 0xF01D, dove vengono confrontate altre zone di memoria e nel caso vengono restituiti i valori corretti.

Due precisazioni :

La flash e' da 256KB (0x40000 bytes) , ma in realta' si tratta di 4 banchi da 64KB, quindi per disassemblare correttamente con IDA dovresti fare un casino con i segmenti o piu' semplicemente ti salvi la parte del firmware da 0x30000 a 0x3FFFF e ti disassembli solo quella, cosi' IDA da solo dovrebbe continuare il disassembly all'indirizzo corretto 0xF01D (che nel tuo caso invece appare come 0x3F01D).
Il resto del firmware e' cryptato o scramblato in qualche modo... non sono riuscito a trovare l'algoritmo anche se secondo quello che scriveva Geremia dovrebbe essere un vecchio algoritmo usato da mediatek. Io sinceramente non ci ho perso troppo tempo, perche' gia' cosi' e con qualche deduzione uno puo' capire meglio come funziona il firmware hackato.

Se sono stato poco chiaro in qualche punto, chiedi pure

[gteknoz]

Ok, tutto chiaro, praticamente falsifica gli output per le richieste di zone di memoria>=0xF010.
L'insieme di queste falsificazioni servono per generare una response corretta per la challenge inviata quindi?

Esattamente, in pratica nasconde le modifiche che sono state fatte al firmware. Quella parte li e' quella piu' semplice e gestisce le zone di memoria >= 0xF010 che nel firmware originale sono tutte 0xFF (basta quindi un semplice confronto per nascondere quasi 4KB di codice aggiuntivo).
Continuando il disassembly all'indirizzo 0xF01D trovi invece altri confronti :

code:0000F01D                 mov     A, RAM_56
code:0000F01F                 mov     R7, A
code:0000F020                 xrl     A, #0x44
code:0000F022                 jz      code_F037
code:0000F024                 mov     A, R7
code:0000F025                 xrl     A, #0x4B
code:0000F027                 jz      code_F037
code:0000F029                 mov     A, R7
code:0000F02A                 xrl     A, #0x65
code:0000F02C                 jz      code_F037
code:0000F02E                 mov     DPL, RAM_57     ; Data Pointer, Low Byte
code:0000F031                 mov     DPH, R7         ; Data Pointer, High Byte
code:0000F033                 clr     A
code:0000F034                 movc    A, @A+DPTR
code:0000F035                 ret

Visto che come dicevamo inizialmente, in RAM_56 e' presente il byte alto dell'indirizzo a 16bit controllato, questa parte di codice controlla se si sta tentando di accedere agli indirizzi 0x44nn, 0x4Bnn o 0x65nn e in caso positivo il programma continua a code_F037, dove inizia una scansione di una tabella per recuperare i dati originali. In caso contrario si tratta di zone del firmware che non sono state modificate e la parte a code_F034 legge il valore attualmente presente.

Se vuoi vedere esattamente dove sono state fatte le modifiche, basta aprirsi con un editor esadecimale il firmware originale (es. Orig-0225.bin) e quello ixtreme (es. LTPlus-0225-v3.0.bin).
Se vai all'offset 0x344b0 vedrai che due bytes sono stati modificati rispetto al fw originale e questa e' la modifica che il primo confronto per il range 0x44nn cerca di nascondere.
Stessa cosa per l'offset 0x34b46 (3 bytes) e 0x365f6 (6 bytes). Queste modifiche sono in una zona del firmware cryptata quindi non si sa esattamente che modifiche siano (anche se per le prime due, da 2 e 3 bytes, si tratta quasi sicuramente di un jmp o una call inserita o reindirizzata per prendere il controllo in un certo punto del firmware).

P.S.:Penso proprio che IDA permetta al caricamento di specificare start e stop address per isolare una sezione di codice, sapresti dirmi come configurarlo?

Non ci avevo neanche mai fatto caso, ma hai ragione. Dove dice file offset, inserisci 0x30000 e lui ti carica solamente gli ultimi 0x10000 bytes. A quel punto se vai all'indirizzo code_F010 dovresti notare che continua a disassemblare anche il resto (se non lo fa in automatico, spostati sull'indirizzo con il cursore e premi 'c').

[xboxbs]

microsoft può forse dumpare i liteon con pcb originali (anche se ho qualche dubbio, dato che la mt è lockata a livello hardware)...ma per le pcb ltu dovrebbe impiegare tempo a reversare il lavoro xecuter per capire come dumpare...spero di non aver detto ca***te

[Razorbacktrack]

Scusa in quel caso appena non riuscirebbero a leggere ,ma allora capirebbero direttamente che il lettore è modificato xD

[gteknoz]

Ma per MS non sarebbe possibile fare da console un dump completo del fw del drive e calcolarne un checksum, in modo da trovare eventuali manomissioni?

Sui vecchi lettori c'erano dei comandi nascosti per dumpare il firmware, ma gli stessi venivano anche utilizzati dagli hackers per leggere i dati sensibili (dvd key e compagnia bella) direttamente dal drive. Hanno quindi pensato bene di impedire qualsiasi lettura dall'esterno e di basarsi sul meccanismo di challenge/response per controllare l'integrita' del drive.

Tutto sommato a loro va meglio cosi' perche' ora chi modda deve faresi uno sbattimento maggiore con RGH per estrarre tutto il necessario dalla motherboard invece che dal drive.