E perché? DA != 39...
Visualizzazione Stampabile
E perché? DA != 39...
Sì ok, DA è il compare dell'hash del CB_B e 39 del CD, ma ad una prima occhiata all'ASM pare che facciano la stessa cosa (ovviamente su BL differenti).
Quello che mi chiedo è: il calcolo dell'hash del CD (37) è molto più breve del calcolo dell'hash del CB_B(D9)? Perché altrimenti non trovo spiegazione...
CD è più piccolo di CB_B e se non sbaglio SHA è polinomiale sull'input, ma c'è veramente così tanta differenza?
Te lo lascio capire da solo...
Lo prendo come un sì.
Al momento non posso verificarlo sulla piastra sotto analisi (RROD), se ne trovo una pre 14xxx faccio la prova del 9, altrimenti resterà un'ipotesi.
Quello che mi induce a pensare che sia corretta è il fatto che RGH2 FAT non usa il PLL e che su Xenon (CPU ref clock fixed) ci si sia fermati alle single CB.
Update for me: cacchio se cambia da RGH1 a RGH2!
Tabella molto "spannometrica" ma che rende abbastanza l'idea:
http://i57.tinypic.com/oj4kso.png
Ok, dopo un periodo di sosta dettato da cause di forza maggiore mi rimetto al lavoro e chiedo l'aiuto del pubblico: parlando con Swizzy mi ha fatto notare che il mio ECC era spazzatura (avevo commesso una "leggerezza" non indifferente), quindi devo revisionare la parte software.
Quello che non mi è chiaro è la struttura delle patch di xebuild:
-32bit di indirizzo
-32bit di numero patch
-32bit di patch
-Delimitatore(FFFFFFFF)
Prendendo come esempio RGH2 su falcon:
Da quel che capisco:Codice:00 00 69 44 00 00 00 01 60 00 00 00 00 00 6A A0
00 00 00 03 60 00 00 00 60 00 00 00 60 00 00 00
00 00 71 B0 00 00 00 01 38 60 00 00 FF FF FF FF
-Offset 0x6944, una patch: 60 00 00 00
-Offset 0x6aa0, tre patch: 60 00 00 00
-Offset 0x71b0, una patch:38 60 00 00
Le prime 4 sono NOP, mentre l'ultima non ho ancora guardato a che opcode corrisponda.
Corretto il ragionamento?
Quindi ora immagino che debba prendere uno dei CB_B 19XX ( quale? vanno tutti bene?), trovare l'indirizzo delle funzioni da patchare e appilcare i fix, cifrare e impacchettare. Right?
Scusa che ti frega di xebuild per creare l'ecc? Poi se non ricordo jrunner già lo crea.
Xebuild in se a poco, mi interessa sapere quali patch vengono fatte sul CB_B per poi applicarle manualmente al CB_B dell'ECC.
Devi ricavartele.. non è difficile.. poi modifica il build.py e basta
Fatto. Tenendo davanti un 5772 come esempio ho localizzato i 3 fix
-NOP del Panic branch nel caso sia revocato (Post A0)
-NOP dei cmp/branch che portano al panic con Post 0xA3. Non ho ancora capito esattamente il come/perché ma approfondirò.
-Sostituisce un valore in un registro per far combaciare la compare e bypassare il controllo dell'hash.
Ora devo solamente localizzare gli indirizzi dei fix sul CB_B Xenon ( un 1941 va bene?) e patchare+cryptare manualmente o col build.py
Ah, curiosità: avevo letto che veniva disabilitata la cifratura per il loader successivo in modo da poterlo usare in plaintext. Questo dove viene fatto?
Ma cosa stai patchando??
Il CB_B. Perché?
Allora qual è il problema.. Patcha il 1941 e via
Boh, col 1941 proprio non ce ne salto fuori: mi sembra diversissimo dai cb_b delle altre piastre, soprattutto non riesco a capire come stampi sul POST (sembra che le regioni di codice che contengono l'asm per scrivere sulla linea siano riempite con 32bit di zeri), né mi spiego come mai alcuni branch vadano su aree senza codice ma con zeri.
Questi sono gli offest delle patch che ho dedotto.
-0x3d5c
-0x3e90
-0x45a0
Riusciresti a confermarmene la bontà?
usa il 1921
Ma 1921 non è un CB "monolitico"?
...Quindi?
Quindi se voglio fare un ECC universale mi serve per forza il CB_A 9188 zp. Non capisco: posso usare un CB_A per avviare un CB completo?
bah.. prova no?
Mmm ok, non l'avevo nemmeno presa in considerazione come ipotesi.
Comunque: perché il 1941 non va bene?
Si che puoi
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...
Mi pare un suggerimento scriteriato.. pensaci bene..
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?
Spiegami perché è scriteriato..
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.
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' telegraficheCitazione:
Originariamente Scritto da rf1911
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.Citazione:
Originariamente Scritto da thunderbirddd
Personalmente del risultato me ne infischio, anche solo leggere simili contenuti mi gratifica pienamente.
Grazie RF1911, grazie DrShottky.
Credo che indicare la strada corretta per raggiungere uno scopo sia più costruttivo che dare la pappa pronta.
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.
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?
Penso che la prima cosa che dobbiamo verificare(nella nostra ignoranza,che non e' poca)e' dove si puo' agire nel codice
Allegato 17316
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
Ma e' giusto?Bastera'?Come possiamo verificarlo senza conoscere troppo bene il codice?Citazione:
2) Lo compara anche a 0 o minore, in questo caso era 5 quindi secondo controllo fallito.
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
Allegato 17317
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)
Allegato 17318
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 :)
Lo sto leggendo con interesse. E' una bella discussione. Era da un pezzo che non succedva. Mi fa veramente piacere :)
Mi sto appassionando :) non ci capisco molto di linguaggio, cmq seguo con attenzione. Continuate così :D
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.
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
Allegato 17319
Citazione:
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 :)
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?
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
Quindi si puo' dedurre che i 4 bit siano impostati tutti a 0 se poi superiamo il controlloCitazione:
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
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
No, quello che hai trovato si riferisce si registri usati per operazioni aritmetiche, e probabilmente su architettura x86.Citazione:
Originariamente Scritto da MARCHISIO80
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.
