Glitchare una Xenon

[MARCHISIO80]

Si che puoi

[DrSchottky]

Così, per cambiare un po' aria, ho deciso di provare a passare ad un rjtag piuttosto che a rgh2.
L'incognita principale resta però una: essendo l'istruzione da glitchare parecchio "distante" dall'ultimo post code mi risulta un po' fumosa la metodologia corretta per individuare il giusto istante di tempo per lanciare il reset.
Come suggeritomi da marchisio80 si era ipotizzato di patchare il CB ed inserire un "post code sentinella" esattamente prima della cmp vittima, e far eseguire il CB come CB_B/CD ad una console RGH. In questo modo tenendo sotto controllo il post potevo farmi un'idea del timing da utilizzare.

Chiedo solamente: sono fuori strada o posso proseguire? Tanto per sapere se devo aprire il portafoglio e comprare una piastra RGH-abile...

[rf1911]

Mi pare un suggerimento scriteriato.. pensaci bene..

[DrSchottky]

Recepito.
A questo punto mi chiedo: l'impulso di reset come influenza il condition register? Viene mutato il suo valore o semplicemente non si aggiorna?

[rf1911]

Spiegami perché è scriteriato..

[DrSchottky]

Sarò sincero: non lo so. Sono i miei primi passi in questo campo e per ora mi sto basando solo su congetture basate su "se", "ma" e "forse" e senza dati empirici basati sull'esperienza.
Dando per valido il preconcetto che un CB possa essere avviato da un altro CB/CB_A (così dicono dalla regia) le uniche motivazioni che ho trovato per le quali il metodo da me proposto possa essere scriteriato sono:
-Il CB 1921 è per Xenon, su altre piastre non è compatibile. La mia speranza era che almeno al fusecheck ci arrivasse senza schiantare prima, ma appunto è una speranza.
-Se e solo se il primo punto fosse fattibile potrei, a causa della differenza di hardware, avere risultati alterati (non coerenti con quelli reali su Xenon)

Altre idee, per il momento, proprio non mi giungono.

[rf1911]

Ma il procedimento per crearlo ti è chiaro?

[thunderbirddd]

Ma il procedimento per crearlo ti è chiaro?

E' da tempo che leggo questa discussione (premetto che non ho capito una sola parola di quello che dite) pero' non ho capito ancora perche' le risposte di rf1911 sono cosi' telegrafiche
Se tu sai(e so che sai) ma perche' non lo aiuti per bene?
Perche' invece di dare solo dei piccoli indizi, non collaborate insieme trasferendo nozioni reali e importanti l'uno all'altro?
Cosi' tanto per dire
Ero solo curioso di capire il perche' di codesto atteggiamento
Tutto qui e' solo per capire senza alcuna polemica od altro

[Pa0l0ne]

E' da tempo che leggo questa discussione (premetto che non ho capito una sola parola di quello che dite) pero' non ho capito ancora perche' le risposte di rf1911 sono cosi' telegrafiche
Se tu sai(e so che sai) ma perche' non lo aiuti per bene?
Perche' invece di dare solo dei piccoli indizi, non collaborate insieme trasferendo nozioni reali e importanti l'uno all'altro?
Cosi' tanto per dire
Ero solo curioso di capire il perche' di codesto atteggiamento
Tutto qui e' solo per capire senza alcuna polemica od altro

Quasi mi dispiace dirlo, ma stavolta ritengo che gli interventi di rf1911 siano invece tutt'altro che telegrafici e/o criptici. Devi partire dal presupposto che nessuno ha la scienza infusa, la verita' assoluta, nelle proprie mani. Chiaramente in questo contesto, a domanda, Rf1911 risponde. Ti pare poco? A me sembra una piu' che ottima ed inaspettata linea guida GRATUITA su cui contare e fare affidamento. L'intelligenza e creativita' nel comporre il puzzle deve pur mettercela qualcun'altro e mi sembra che non si stia risparmiando di certo.
Personalmente del risultato me ne infischio, anche solo leggere simili contenuti mi gratifica pienamente.
Grazie RF1911, grazie DrShottky.

[TheLinuxMafia]

Credo che indicare la strada corretta per raggiungere uno scopo sia più costruttivo che dare la pappa pronta.

[DrSchottky]

Ragazzi apprezzo il vostro supporto ma, per favore, cerchiamo di lasciare pulito il topic (anche solo per il fatto che, IMHO, è uno tra i più tecnici e stuzzicanti del forum)
Dico la mia e poi torno in topic:nulla da obiettare a rf1911 (figuriamoci!) anzi, penso che questo approccio 'a contagocce' sia un giusto bilanciamento che consenta di avere una linea guida ma senza fornire nulla di precotto, in modo da far lavorare un po' il cervello. Io non lo faccio né per soldi né per gloria, puro passatempo ed esercizio: volete mettere la soddisfazione di riuscire, seppur accompagnato, a realizzare qualcosa piuttosto che a seguire un tutorial?

Tornando alle Xenon e rispondendo ad rf:
Ni.
Mi spiego: non l'ho mai fatto ma mi sono studiato il funzionamento, quindi sarebbe un approccio trial&error.
Se non ho capito male la sequenza per un panic code è questa:
-Scrivo il postcode in r4
-Copio r21(che contiene un indirizzo di memoria, ma per essere precisi non ho guardato dove venga assegnato) in r3
-Faccio shift a sinistra di 56 bit su r4 per avere una formattazione corretta del postcode
-Scrivo il contenuto di r4 nell'indirizzo di memoria puntato da r3
-Entro in un loop bloccante, in modo da riavviare l'esecuzione da 0.

[rf1911]

Aspetta.. facciamo un passo indietro. Hai sistemato il builder di python per creare uno xell loader con cb_a 9188 e come cb_b 1921?

[MARCHISIO80]

Penso che la prima cosa che dobbiamo verificare(nella nostra ignoranza,che non e' poca)e' dove si puo' agire nel codice



Nn conosco i linguaggi di programmazione,ma guardandoci un po' non mi sembra possibile superare i 2 BNE(primo e ultimo controllo)con il glitch,cosa in sto caso credo fattibile con un BLE(loc_728C nello screen sopra)

loc_728C:
cmpwi cr6, r11, 0
ble cr6, loc_7264

E se ho ben capito e' questo controllo

2) Lo compara anche a 0 o minore, in questo caso era 5 quindi secondo controllo fallito.

Ma e' giusto?Bastera'?Come possiamo verificarlo senza conoscere troppo bene il codice?

Da qui l'idea di utilizzare un CB jtaggabile(o superiore,dipende se il codice che verifica la revoca del CB e' identico,e' tanto che non ci guardo,ma dovrebbe essere identico) come CBB su una xbox RGH e modificare ad esempio il BLE in BNE(loc_7230 nel seguente screen)per vedere se scendiamo correttamente giu'(loc_7264 nel seguente screen)evitando il ramo in cui e' presente il fatidico POST CODE di errore 0xA0






Se fattibile(e funzionante,visto che mi sono limitato in un copia/incolla di valori esadecimali)penso che potrebbe darci qualche indicazione e spunto in piu' aggiungere alcuni POST CODE al nostro FAKE CBB,facilmente riconoscibili da noi,a mo' di debug/segnaposto per avere piu' indicazioni

Tipo cosi',altro test...mettendo ad esempio un post code chiamato AF(che se la teoria sopra e' esatta dovrebbe cosi' trovarsi poco dopo dove dobbiamo glitchare)
(non importa se poi l'xbox si ferma)



Si prende a riferimento l'ultimo POST CODE prima dei controlli(0x21)e sto nuovo POST CODE(0xAF)e penso ci si possa fare un'idea del tempo che impiega il codice a passare dal POST CODE 0x21 al punto da glitchare(in modo molto rozzo,ma meglio che niente credo per i nostri mezzi e conoscenze)




C'e' da sistemare il build.py per farci preparare l'immagine da flashare e questa e' la parte piu' semplice per noi

Essendo solo dei pre-test,si puo' usare direttamente la cpukey per ricryptare il CBB(visto che non abbiamo ne keystream ne cryptato di sto FAKE CBB)

Ora si presenta forse un problema...servono le patch per sto fake CBB?Boh,probabilmente si,ma se nn ricordo male esistono per un CB zephyr(adattato a CBB credo all'inizi di RGH2,comunque era presente nel pacchetto rilasciato dal T-X),quindi ci basta utilizzare una zephyr,per non dover fare il lavoro di studiare le patch da applicare


Dpo sti pre-test,se ne veniamo a capo(soprattutto il punto da glitchare)resta da fare un sacco di lavoro con il codice cpld su una xenon aggiornata e il CB originale jtaggabile




Scusate l'ignoranza e il mio modo di esprimermi XD
Idee/correzioni/consigli sono ben graditi,come sempre

[Titty]

Lo sto leggendo con interesse. E' una bella discussione. Era da un pezzo che non succedva. Mi fa veramente piacere

[sparco1990]

Mi sto appassionando non ci capisco molto di linguaggio, cmq seguo con attenzione. Continuate così

[DrSchottky]

Dunque, andiamo con ordine:
@rf1911: Intendi il build.py per creare una image sulla quale provare il CB 1921 con le post-patches? No, non ancora, ma con python me la cavo abbastanza quindi dovrei riuscire a farlo senza grossi problemi.
@marchisio80: sul dove si possa glitchare non ci metterei la mano sul fuoco appunto perché, come chiesto prima, non conosco conosco con esattezza l'effetto del glitch sui flag del registro condizionale. Quindi prima di trovare la compare bersaglio che c'è da focalizzarsi su questo. Nel caso cr6 rimanga invariato potresti glitchare anche l'ultimo controllo..

C'è ancora la questione CB in ballo: un 1921 "liscio" su non-Xenon al fusecheck ci arriva?
Ci sono ancora troppe incognite in ballo, dobbiamo fare una scaletta e definire delle milestone.

P.S.:L'esempio che hai messo con 0xAF è incompleto, non basta scrivere il valore su r4.

[MARCHISIO80]

1) xD Si,e' solo un esempio,ho lasciato volutamente cosa c'e' dopo il mio 0xAF per far vedere nel codice dove l'ho collocato

2) loc_728C:
cmpwi cr6, r11, 0
ble cr6, loc_7264

cmpwi(compara r11(valore ricavato dal controllo precedente(Contatore a 16. Si cerca la prima "f". In questo caso si trova da destra alla posizione 11. Si compara quindi 16-11 al byte di sequenza, in questo caso 7. Non è uguale. Quindi fallito il primo controllo.)) al valore predefinito 0(zero) e lo mette nel registro CR6

Se e solo se CR6 <= 0 controllo superato

Si potrebbe intuire che resettando in quel punto CR6 o r11,tutto combacia e si superano i controlli

Se r11 = 0
0 = 0
CR6 == 0

Se CR6 == 0
nn ci importa di r11






Oltretutto puoi farti un'idea su come agisce il glitch guardando ad esempio dove si glitchano le slim e cio' "avvalora" quello che pensavo stanotte,che un BNE non e' adatto ad essere glitchato/superato(qui infatti c'e' un BEQ)nei nostri casi

cmpwi cr6, r3, 0
beq cr6, loc_838

The reset glitch in a few words
=======================

We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences"

Idee/correzioni/insulti/suggerimenti sn sempre ben graditi

[DrSchottky]

Cr6 (come tutti gli altri crx) non è un valore binario 0/1, ma un segmento di 4 bit: ogni bit funge da flag ed ha un particolare significato.
Quindi dire che cr6 "va a zero" penso che sia una affermazione errata.

E' per questo che chiedevo gli effetti del glitch: si ha che sul crx coinvolto si attiva l'equal flag (3^bit) o, come avveniva sui power glitch su alcuni PIC, non viene aggiornato il valore?

[MARCHISIO80]

Beh,sto cercando di descrivere le cose il piu' semplicemente possibile,a noi interessa solo il secondo bit,che e' 0 se r11 == 0


Ho trovato questo cercando su google

il registro dei flag: questo registro non contiene valori numerici convenzionali, ma è piuttosto un insieme di bit, detti appunto flag, che segnalano stati particolari della CPU e alcune informazioni sul risultato dell'ultima operazione eseguita. I flag più importanti sono:
Flag di stato:
Overflow: indica se il risultato dell'operazione precedente era troppo grande per il campo risultato: 0 assenza di overflow, 1 overflow
Zero: vale 1 se l'ultima operazione ha avuto risultato zero, altrimenti vale 0
Carry: vale 1 se l'ultima operazione ha ecceduto la capacità del registro che contiene il risultato, altrimenti vale 0 (esempio: in un registro a 8 bit, che può rappresentare solo numeri da 0 a 255, la somma 178+250 darebbe come risultato 172, cioè 428 - 256, e il carry verrebbe posto a 1 insieme al flag di overflow).
Segno: indica il segno del risultato dell'operazione precedente: 0 risultato positivo, 1 risultato negativo

Quindi si puo' dedurre che i 4 bit siano impostati tutti a 0 se poi superiamo il controllo




Cmq credo sia importante al momento lasciare da parte un po' di cose(se nessuno si prende la briga di scrivere chiaramente come agisce il glitch) e testare direttamente se mettendo un BNE al posto del BLE superiamo il controllo ed evitiamo il fatidico POST CODE 0xA0




QUindi


1) preparare il nostro CB/FAKE CBB con la modifica del branch
2) modificare correttamente il build.py
2) testare su xbox rgh2 con post sniffer collegato

[DrSchottky]

Quindi si puo' dedurre che i 4 bit siano impostati tutti a 0 se poi superiamo il controllo

No, quello che hai trovato si riferisce si registri usati per operazioni aritmetiche, e probabilmente su architettura x86.
Su PowerPC il condition register (o meglio uno dei suoi 8 segmenti) utilizzato sulle cmp ha la seguente struttura:
-1 bit per il minore
-1 bit per il maggiore
-1 bit per l'uguale
-1 bit di overflow

Per superare una BEQ,BLE,BGE hai bisogno che il 3^bit (equality flag sia attivo).

UPDATE:
@marchisio80: Invece secondo me è meglio chiarire prima la questione del glicth, altrimenti non sapremo mai quali istruzione poter glitchare.
Che poi se rf1911 ha detto che è una cattiva idea usare post-sentinella forse è meglio, prima di lanciarsi in prove, capire come e soprattutto perché sia sbagliato.

Ah, altra idea (forse) balorda: Nel caso l'ultimo branch fosse glitchabile FORSE, conoscendo quanti cicli di clock richiedono le istruzioni dalla compare ad A0 e il clock della cpu si potrebbe fare un calcolo del tempo ipotetico da sottrarre a 20-A0 per capire quando inizia la cmp. Ma immagino che anche questa sia una idea balorda.

A questo punto aspetterei di sentire cosa dice rf1911 prima di lanciarsi in esperimenti sconclusionati.