Glitchare una Xenon

[DooM]

ehi lapht xD ci si becca pure qui fidatevi che rf lo ha letto, e se ci avesse potuto aiutare lo avrebbe gia fatto ma sono sicuro che ne caveremo qualcosa

[lapht]

Gli ho mandato un PM.. magari passa

[Luke69]

Cpu PIN AF18: CPU_EXT_CLK_EN (Point under the motherboard between R6R6-R6R7)
If you leave this point to GND the 1BL clock speed is normal, 66Mhz. If you give 3.3V to this point the clock speed slow down to 6.2Mhz.

[lapht]

Ok, di conseguenza bisognerebbe attaccare il PLL in quel punto?

[Luke69]

Credo di si, è un punto alternativo al pll_bypass per poter downclockare la cpu...comunque è affidabile quello che dico, il CPU_PLL_BYPASS e CPU_EXT_CLK_EN sono stati scoperti da Cjack qualche anno fa, pensa che si parlava di "Glitch attack on CB authentication" già dal 2007...

[lapht]

Si ho letto quel post.. poi ho visto tutti che lo prendevano per il c***... ed ecco che gligli lo ha messo in atto xD

[D@rio]

ieri mi sono messo a cercare un po' di cose ed ho letto quel thread su XBH... se Gligli è il papà del reset glitch hack, di sicuro cjack è la mamma!!! (nota di colore: per chi non lo sapesse, cjack è italiano)

è stato divertente leggere tutti i passi e le teorie di quasi 4 anni fa, che alla fine si sono rivelate vincenti

[rf1911]

Ragazzi.. il problema è complesso. Per prima cosa con il 3.3 sul pll si abbassa la velocità a 520hz. E' vero che l'altro punto porta a 6.2mhz, ma la finestra si abbassa di più di 10 volte!!

1) Fare il porting del glitch su ARM7 (Tipo Olimex)
2) Modificare build.by per accettare CB/CD della xenon
3) Patchare SMC xenon
4) Trovare il timing

Il tutto senza che ovviamente la console si pianti mai. Quindi la vedo dura.... Ora si potrebbe ovviare ai punti 1 4 andando a provare dei valori, magari iniziando da una media dei tempi di glitch delle altre -50. Ma ciò significherebbe che ad ogni cambio di timing è necessario riprogrammare il chip.

Se qualcuno di voi ha tanto, ma tanto, tempo posso vedere di modificare il build.by e trovare la patch per l'smc. Posso cioè fornire un ecc che dovrebbe permettervi di provare il glitch. Poi posso anche spiegarvi come ricompilare i jed. Si potrebbe anche pensare di installare un cristallo da 48mhz sul chip in modo da avere un clock più stabile.

[DooM]

Se tu riesci a fornirmi i files, e mi spieghi più o meno dove mettere le mani, io il tempo posso trovarlo...

[lapht]

rf, io mi metto a tua completa disposizione

[DooM]

rf, io mi metto a tua completa disposizione

siamo gia in due! dai qualcosa caviamo...

[D@rio]

come prima cosa bisogna provare a dare i 3,3V al punto che porta a 6MHz, togliere i 3,3V e vedere se il boot prosegue normalmente. Se si pianta il tutto anche con l'altro punto è inutile proseguire su questa strada

[lapht]

Appunto poi a me interesserebbe TANTO capire come fa rf a patchare l'SMC

[Luke69]

Se ci sono parte niubbe (o che possa fare senza particolari conoscenza comunque) da fare che non richiedano test di prima persona (faccio schifo a saldare T.T) io ci sono ^^

[Luke69]

[18:56] <Juvenal> its not an issue with pll_pypas
[18:56] <Juvenal> the issue is when cpu_rst is asserted the cpu crashes
[18:56] <Juvenal> instead of messing up on memcmps like we want it to
[18:57] <deado> because cpu doesnt downclock like on other boards

Continuano a confermarmi che non è possibile...la CPU crasha quando viene resettata, non dipende dal punto di downclock come pensavo, ma da CPU_RST

[lapht]

tentar non nuoce

[Luke69]

[19:06] <luke69> there is a way to glitch the cpu without crashing?
[19:12] <Juvenal> luke69, who knows
[19:13] <Juvenal> gligli and others tried it and had no luck

Speriamo bene ^^

[rf1911]

Beh.. facciamo così... mandatemi in pm i vostri dump di xenon, così posso iniziare a vedere di cercare le patch per smc/cd e creare un ecc ad hoc. Intanto fermiamoci qui. NON dump di xenon jtaggabili.

[MARCHISIO80]

Ragazzi.. il problema è complesso. Per prima cosa con il 3.3 sul pll si abbassa la velocità a 520hz. E' vero che l'altro punto porta a 6.2mhz, ma la finestra si abbassa di più di 10 volte!!

1) Fare il porting del glitch su ARM7 (Tipo Olimex)
2) Modificare build.by per accettare CB/CD della xenon
3) Patchare SMC xenon
4) Trovare il timing

Il tutto senza che ovviamente la console si pianti mai. Quindi la vedo dura.... Ora si potrebbe ovviare ai punti 1 4 andando a provare dei valori, magari iniziando da una media dei tempi di glitch delle altre -50. Ma ciò significherebbe che ad ogni cambio di timing è necessario riprogrammare il chip.

Se qualcuno di voi ha tanto, ma tanto, tempo posso vedere di modificare il build.by e trovare la patch per l'smc. Posso cioè fornire un ecc che dovrebbe permettervi di provare il glitch. Poi posso anche spiegarvi come ricompilare i jed. Si potrebbe anche pensare di installare un cristallo da 48mhz sul chip in modo da avere un clock più stabile.

Perfetto,una modifica hardware e' proprio quello che ci vuole,anche a solo scopo di studio.......il problema e' di segnali,la cpu della xenon,su zephyr glitcha.indi bisogna replicare i segnali simulando una zephyr,anche con l'utilizzo di ulteriori componenti hardware


Io ho preso 3 xenon apposta un po' di tempo fa,poi ho abbandonato il progetto perche' mi mancano certe basi per prepararmi da solo tutto il necessario


Parlando di altri modelli fat,in teoria il CB diverso(non splittato),tipo falcon Cb 5772 e jasper 6752,non esclude la possibilita' di glitch............
"Basta" creare l'ecc,adattare xell a partire su quel fuseset e trovare il timing giusto(visto che cambia il cb),confermi o smentisci?

Sei un grande..............

Grazie

[Luke69]

Comunque su IRC mi han detto che le cpu Xenon e quelle Zephir non sono le stesse, e non ci han girato intorno, domanda diretta ^^