Visualizzazione Stampabile
-
Glitchare una Corona
Ciao,
ho saputo, grazie a Nice69, che si può dumpare la nand delle Corona v1 (per non lo sapesse esistono due versioni di Corona, alle v1 è possibile dumpare la nand alle v2 no perchè il chip è diverso dalle solite nand e non viene riconosciuto da nessun flasher specializzato in xbox) e che 360 nand flash tool 0.97 la apre...
Per quanto riguarda il Reset Glitch Hack? Si può fare una cosa analoga a quanto ha fatto Rf1911 con la scheda madre Xenon? (patch del SMC e modifica del build.py per creare il file .ecc)
E si son trovati punti alternativi all'hana?
Riguardo alle Corona v2, qualcuno è al lavoro per riuscire a dumpare la nand? (immagino di si...)
-
Ecco il patch per smc: 0x13B4 ma l'smc è più grande e dovrei cambiare di molto il build.py... ora non posso... Ho il dump della V1 da un bel po'...
-
Tranquillo, era solo una domanda! ^^
Per quanto riguarda i punti sulla scheda madre, quelli trovati da Nice69 (immagino avrai visto i suoi video sull'emulazione Corona su Trinity e Jasper) potrebbero funzionare?
Comunque non mi spiego una cosa, tu sei riuscito a creare la patch per il smc della Xenon in poco tempo ed anche a modificare il build.py, tutto da solo...ora, farlo per una console Corona è più lungo da fare e forse anche più difficile, ma immagino che per altri hacker della scena sarebbe una bazzecola, e se i punti trovati da Nice69 funzionano, perchè non è ancora stato rilasciato il modo per glitchare le Corona v1? Forse vogliono rilasciare insieme anche il Glitch per Corona v2?
Per quanto riguarda il CB, è cambiato rispetto alle Trinity? Ha la stessa "vulnerabilità"?
Ps: non so a quanto tu possa dirmi, se ho fatto domande inopportune dillo pure ^^
-
Procediamo per gradi
Cominciamo dalle corona v1
Raggiunto l'obiettivo si passa alla v2,intanto si avranno notizie su come poter dumpare la nand,che a me al momento non interessa.............
Non e' che possiamo concentrarci su mille cose contemporaneamente................
anche perche' a quanto sembra c'e' solo RF1911 in grado di preparare software e patch ad hoc
Questo e' il mio pensiero
-
Citazione:
Originariamente Scritto da
MARCHISIO80
Procediamo per gradi
Cominciamo dalle corona v1
Raggiunto l'obiettivo si passa alla v2,intanto si avranno notizie su come poter dumpare la nand,che a me al momento non interessa.............
Non e' che possiamo concentrarci su mille cose contemporaneamente................
anche perche' a quanto sembra c'e' solo RF1911 in grado di preparare software e patch ad hoc
Questo e' il mio pensiero
Concordo, comunque quanti hanno una Corona v1 sul forum??
Ps: qualcuno può passarmi la nand della Corona v1, così mi rispondo da solo a una delle domande sul CB XD
-
Il CB e' cambiato per forza,altrimenti come funzionerebbe la corona visto che hanno cambiato i componenti?
La vulnerabilita' non e' nel cb per rgh...............
la vulnerabilita' e' hardware(glitch)
Al massimo un nuovo cb ad hoc puo' cercare di riconoscere il tentativo di glitch via software
Il glitch e' basato sull' hardware,non sul software.............
poi che noi abbiamo bisogno del software per sfruttarlo e' un'altra questione
-
In effetti era una domanda cretina, riguardo alla seconda? C'è un controllo sui fusesets del tipo console/versione CB? (non ricordo quali sono ^^)
E soprattutto, il glitch è stato davvero tappato?
-
Luke69, mi pare tu stia cercando informazioni qua e là come una vecchina di paese che allunga l'orecchio per ascoltare cosa dice il vicino, solo per il gusto di sapere e magari andare a ridire a destra e manca... Io ho letto il post di Nice, cose che si sapevano già, c'è già un altro post più vecchio di uno che aveva dumpato la v1... Nice ha usato un cristallo per il clock... Il problema l'ha spiegato Blackaddr qui [url=http://www.xboxhacker.org/index.php?topic=17535.0]Login[/url]
EDIT: il cb_a della corona non fa il check dei fuse.
-
LooooooL
Comunque ho imparato a tener per me, però resto sempre curioso...
A me piace leggere queste cose, certo che però se nessun le scrive non si sa mai un cazzo
-
Ma capisci che sapere cose che non sei in grado di comprendere o quantomeno di rielaborare è solo una perdita di tempo per te e per gli altri? Questo non significa che non devi chiedere. Anzi, ma l'importante è che tu lo chieda perché ti SERVE, non solo per il gusto di saperlo...
-
Beh allora io non avendo una Corona e non essendo capace di rielaborare niente (ho 15 anni, di elettronica non capisco una sega, ho iniziato ad imparare leggendo il forum) non avrei neanche dovuto chiedere...va beh, spero che questo topic vada avanti comunque, con cose costruttive ^^
-
come si riconosce una corona v1 e una corona v2??
-
Citazione:
Originariamente Scritto da
kingxmod
come si riconosce una corona v1 e una corona v2??
Le v2 hanno la nand nella parte di sotto della scheda madre
-
Luke69, sei molto giovane e se ti interessa questo mondo devi studiare... ma non certo facendo quelle domande.. vai su free60.org o sulla nostra wiki [url=http://xedevwiki.com/wiki/Main_Page]XeDevWiki[/url] e cerca di capire per esempio come funziona il boot della xbox.
EDIT: a quanto pare le versione con 4gb hanno la nand V2, le 250gb la nand v1, un po' come capitava con le jasper 256/512 e quelle con l'hard disk.
-
Citazione:
Originariamente Scritto da
rf1911
Luke69, sei molto giovane e se ti interessa questo mondo devi studiare... ma non certo facendo quelle domande.. vai su free60.org o sulla nostra wiki [url=http://xedevwiki.com/wiki/Main_Page]XeDevWiki[/url] e cerca di capire per esempio come funziona il boot della xbox.
EDIT: a quanto pare le versione con 4gb hanno la nand V2, le 250gb la nand v1, un po' come capitava con le jasper 256/512 e quelle con l'hard disk.
Ho letto e ho provato a capire ma non ho capito alcune cose...tipo il RotSumSha1 che viene calcolato di ogni bootloader dal bootloader precedente...non ho capito cos'è e googlando esce sempre e solo il boot process del 360...
-
Citazione:
Originariamente Scritto da
rf1911
Ecco il patch per smc: 0x13B4 ma l'smc è più grande e dovrei cambiare di molto il build.py... ora non posso... Ho il dump della V1 da un bel po'...
...scusate se vado fuori topic... ma ci sono possibilità di glitchare una Xenon?... ho capito male?
-
Citazione:
Originariamente Scritto da
kazoom
...scusate se vado fuori topic... ma ci sono possibilità di glitchare una Xenon?... ho capito male?
In fondo alla paginata della sezione c'è il topic giusto...comunque ci stanno lavorando
EDIT:
come non detto era già in seconda pagina
[url]http://www.consoleopen.com/forum/sezione-xbox-360-jtag-e-reset-glitch-hack/2606-glitchare-una-xenon.html[/url]
-
Citazione:
Originariamente Scritto da
Luke69
Ho letto e ho provato a capire ma non ho capito alcune cose...tipo il RotSumSha1 che viene calcolato di ogni bootloader dal bootloader precedente...non ho capito cos'è e googlando esce sempre e solo il boot process del 360...
Ti consiglio di leggere e rileggere i vari wiki e i post nel forum.............................
In parole poverissime,verificano che tu non hai cambiato niente.Ora ti faccio un piccolo riassunto in parole poverissime.................
Partiamo dal 1BL(bootloader situato nella rom della cpu)
L'1BL carica in memoria e decripta il CB
L'1BL ricava una specie di hash(RotSumSha1) del CB e l'utilizza per verificare l'RSA
Se l'RSA corrisponde salta al CB_A
CB_A carica e decripta in ram il CB_B
Ricava RotSumSha1 del CB_B
se corrispone il boot passa al CB_B
Il CB_B ha il compito di inizializzare(come farebbe il bios del pc)
le porte pci
disabilita la porta jtag della gpu(per quello su fat non si puo' piu' eseguire il jtag)
e via dicendo
Ora capirai da solo che il CB delle slim inizializza altri componenti rispetto alle corona,indi il CB nelle corona e' diverso.
-
Citazione:
Originariamente Scritto da
MARCHISIO80
Il CB e' cambiato per forza,altrimenti come funzionerebbe la corona visto che hanno cambiato i componenti?
La vulnerabilita' non e' nel cb per rgh...............
la vulnerabilita' e' hardware(glitch)
Al massimo un nuovo cb ad hoc puo' cercare di riconoscere il tentativo di glitch via software
Il glitch e' basato sull' hardware,non sul software.............
poi che noi abbiamo bisogno del software per sfruttarlo e' un'altra questione
Il problema è nell'hardware, ma trattandosi di un glitch strettamente dipendente dal timing, può essere corretto inserendo nel codice CB che viene prima del glitch qualcosa che richieda un numero di cicli di clock variabile da boot a boot.
Riguardo queste ipotesi sulla corona mi pare che si sia perso di vista l'obiettivo. Il problema della corona non è il clock e da dove venga preso, ma il downclock eseguito usando il bus I2C (cioè i collegamenti SDA ed SCL sulla board) per impostare dei registri dell'HANA. Nella corona il chip HANA è cambiato, accorpato al southbridge, anche il master clock della scheda è cambiato, quei comandi non funzionano più. Non si consocono ancora i punti I2C della corona. Non si conoscono valori ed i registri da impostare e non si conosce neanche se sia possibile downclockarla con successo (probabilmente lo è ed è solo questione di tempo).
Trovare il timing, patchare l'smc, creare l'ecc viene dopo, se non pui dowclockare non puoi glitchare. E' lo stesso problema della xenon, ma in quel caso non ci sono comandi I2C, ma un segnale di PLL Bypass che, al contrario delle altre fat, la manda i crash quando viene asserito. Anche qui però invece di provare a glitchare la console bisognerebbe concentrarsi sul downclock. C'è un test point per misurare il clock della CPU è riportato anche nell'nfo dell'RGH. Bisognerebbe collegare un LA o anche un semplice misuratore di frequenza a quel punto e cercare di trovare un sistema per mandare giù e su la frequenza di clock senza crash. Io non credo sia possibile farlo in modo stabile perchè mi pare che sia proprio ciò che gligli e team abbiano tentato senza risultati. Potreste però riuscire a glitchare la xenon, tanto per dire, una volta dopo 1000 tentativi giusto per recuperare la cpu key.
-
Citazione:
Originariamente Scritto da
freelancer
Il problema è nell'hardware, ma trattandosi di un glitch strettamente dipendente dal timing, può essere corretto inserendo nel codice CB che viene prima del glitch qualcosa che richieda un numero di cicli di clock variabile da boot a boot.
Riguardo queste ipotesi sulla corona mi pare che si sia perso di vista l'obiettivo. Il problema della corona non è il clock e da dove venga preso, ma il downclock eseguito usando il bus I2C (cioè i collegamenti SDA ed SCL sulla board) per impostare dei registri dell'HANA. Nella corona il chip HANA è cambiato, accorpato al southbridge, anche il master clock della scheda è cambiato, quei comandi non funzionano più. Non si consocono ancora i punti I2C della corona. Non si conoscono valori ed i registri da impostare e non si conosce neanche se sia possibile downclockarla con successo (probabilmente lo è ed è solo questione di tempo).
Trovare il timing, patchare l'smc, creare l'ecc viene dopo, se non pui dowclockare non puoi glitchare. E' lo stesso problema della xenon, ma in quel caso non ci sono comandi I2C, ma un segnale di PLL Bypass che, al contrario delle altre fat, la manda i crash quando viene asserito. Anche qui però invece di provare a glitchare la console bisognerebbe concentrarsi sul downclock. C'è un test point per misurare il clock della CPU è riportato anche nell'nfo dell'RGH. Bisognerebbe collegare un LA o anche un semplice misuratore di frequenza a quel punto e cercare di trovare un sistema per mandare giù e su la frequenza di clock senza crash. Io non credo sia possibile farlo in modo stabile perchè mi pare che sia proprio ciò che gligli e team abbiano tentato senza risultati. Potreste però riuscire a glitchare la xenon, tanto per dire, una volta dopo 1000 tentativi giusto per recuperare la cpu key.
I punti per le corona si conoscono:
[url=http://www.xboxhacker.org/index.php?topic=17535.0]Login[/url] (leggi tutto il topic)
EDIT:
Corona Hack Requirements (compared to Trinity)
- I2C connections are same header name, same pins (at J2C3).
- POST_OUT1 is exact same location
- CPU_RST, R4D4 still present and in better position than FT5R2.
- Power connections are same header name, same pins (at J2C3)
- STBY clock (no idea where this is right now, but there must be a test point somewhere near the SB, look for a 48 MHz or 50 MHz clock)
