R-JTAG-COME FUNZIONA? Discutiamone :)

**zeruel85** · 18-05-13

Originariamente Scritto da cirowner

Si, probabilmente è così, però vorrei avere la certezza

Di doman non v'è certezza, scriveva un tale fiorentino, non Renzi...

**MARCHISIO80** · 18-05-13

Puoi provare a creare xell Zereul?
I vecchi tool x "sicurezza" nn ti facevano creare xell-jtag se avevi un CB nn jatggabile..almeno un warning usciva

Freeboot si,lo so...se io ho una xbox-jtaggabile posso dargli in pasto anche una nand "ricostruita" di qualsiasi dash
Se e' jtag il cb e' utilizzato quello di sicuro

Io volevo una conferma che con r-jtag si glitcha x far avviare un Cb nn piu' autorizzato,agendo in qualche modo sulla sequenza di boot

**zeruel85** · 18-05-13

Per te questo ed altro, mio ritrovato amico. Dammi mezzo minuto.

**zeruel85** · 18-05-13

In realtà premendo Create Xell-Reloaded da J-Runner non te lo fa creare, ma va a pescare un BIN precostruito chiamato nel mio caso jasper.bin (o anche volendo jasper_hack_aud_clamp.bin, nel caso uno voglia l'Aud_Clamp). Aprendolo da HxD, le prime stringhe dicono: "zeropair image, version=00, CB=6723".

A questo punto mi domando, come diceva il buon cirowner, deve uscire un J-Runner nuovo o vanno bene i file che si son sempre usati finora? A buon intenditor...

EDIT: errore mio, il file viene creato a partire dal file presente in common/xell, ma poi viene scritto in output, suppongo con le caratteristiche iniettate da console a console...

Precisamente dall'offset 0x4200 i file sono differenti, fino al 0x83FF.

**MARCHISIO80** · 18-05-13

Ottimo

Perfetto

Erano solo "controlli" di sicurezza,visto che prima nn era possibile utilizzare CB revocati x il jtag

Tipo CB 6750 o maggiore == xbox nn jtaggabile

Il nuovo j-runner e i nuovi tool nn avranno piu' sto controllo

Il resto e' uguale,come hai verificato creando il freeboot
X la cpukey(se nn si ha)basta semplicemente flashare un xell-generico vecchio stampo..nn serve neanche il dump

**karcos79** · 18-05-13

Ma scusate non potete chiedere a the pusher l'immagine che ha messo nella console per fare il video?
Sent from my Nokia Lumia 820 using Board Express

**MARCHISIO80** · 18-05-13

Originariamente Scritto da karcos79

Ma scusate non potete chiedere a the pusher l'immagine che ha messo nella console per fare il video?
Sent from my Nokia Lumia 820 using Board Express

ThePusher e' sempre presente,se puo' inviera' sicuramente il dump
Ma sicuramente nn dipende da lui,sia chiaro...

**MARCHISIO80** · 18-05-13

Visto che sta parte e' praticamente fatta..idee su cosa si glitcha?

Un'istruzione di controllo/verifica?
Rf ne aveva parlato tempo fa,circa il fuseset02

Fuseset - Piccola spiegazione Tecnica

Cambiare il valore binario da qualche parte,tramite glitch?Qui ci capisco meno del solito..e gia' ci capisco quasi niente di solito

Originariamente Scritto da free60.org

Their Real Binary Values

If you were actually reading the fuses, they would look like this (0 being an un-burned fuse, and 1 being a burned fuse) There should be 768 ones and zeros here, hence the "768 Bits" of eFUSE. This doesn't mean anything, but is just to show how the eFUSE's are actually set up.

fuseset 02: 0F00000000000000 visualizzato da xell == Fuseset 02: 0100000000000000

Chi puo' inviarmi un CB 6723 decryptato e uno di quelli nuovi(sempre jasper),che bisogna utilizzare come base x l'R-JTAG?

**MARCHISIO80** · 18-05-13

Originariamente Scritto da zeruel85

EDIT: errore mio, il file viene creato a partire dal file presente in common/xell, ma poi viene scritto in output, suppongo con le caratteristiche iniettate da console a console...

Precisamente dall'offset 0x4200 i file sono differenti, fino al 0x83FF.

4200 Keyvault

E a 8400 inizia il CB

**Tommino81** · 18-05-13

Originariamente Scritto da MARCHISIO80

Uhm...penso che ci siamo proprio

Per conferma bAsta creare xell o freeboot jtag col nuovo jrunner partendo da una nand aggiornata...aprire xell o freeboot e vedere che CB ha...se ha il pre 6750.....il resto e' tutto esatto(io nn ho ne nand ne jrunner,ahahahh..vediamo se qualche utente ha voglia di fare sta mini-verifica)EDIT..nn so neanche se c'e' gia' in download il jrunner "modificato" x l'r-jtag pero'

Cmq dovrebbe essere cosi' la storia

- glitch di qualche istruzione che ha a che fare con la sequenza di boot
- CB jtaggabile che prosegue a "girare"
- classico smc-hack
- avvio di codice non firmato

se mi dici cosa ti serve te lo uppo in privato !

**MARCHISIO80** · 18-05-13

Questo potrebbe essere molto interessante

CB looks at fuseline 02: and compares it to bytes at 0x3B0 in decrypted CB, you cant really equate the CB LDV to the fuse row directly. The byte directly after the 3 pairing bytes, unlike CF which stows LDV which directly corresponds to the number of 0xF in CF fuse rows, seems to not be used in CB - I believe this is the value that flash tool is showing you.

@3B0 (example bytes from 5771/falcon, which runs fine on my non-updated/jtag falcon btw)
1 byte: 0x01 console type (compared to line 01: of fuses, 1 is used on retail which usually ends with 0ff0)
1 byte: 0x07 sequence
2 byte: 0x0058 sequence allow

using line 02 of fuses, it will set count to 0x10 and keep right shifting line 02 right 4 bits, and subtracting one from the count until it gets to a 0xF. My line 02 fuses, jtag machine:
02: 0000f00000000000
would result in 0x10-0xB (it has to shift right 11 times until &0xF = 0xF), which is 5. It compares this to the sequence byte, if they are equal it goes on to process the cpu key. In this examples case, they are not equal and it takes a different path.

It will then compare (as 32bit) the 5 it got to 0, if it is less than or equal to zero, it continues to process CPU key. In this examples case, it does not continue but does one more check.

Next it will take the value calculated above, subtract one, then shift 1 left by that many bits then and it with sequence allow - if the result is not zero it will proceed to process the CPU key, otherwise it will POST 0xA0 and error out. More simply, (1<<(5-1))&0x0058 = 0x10 which is not 0 so is allowed;

**pocoyo2** · 18-05-13

Italians do it better!

Originariamente Scritto da rf1911

Giusto per creare un po' di conoscenza...

Aprendo il CB_A della slim noterete una cosa: alla locazione 0x3B0 ci sono 00 00 00 00. Questo è l'epic fail della MS.
Questi 4 bytes indicano: 1° byte=tipo di console (sulle retail è 1), 2° byte: sequenza, 3°e 4°: sequenza autorizzata. Ecco come si calcola:

Esempio di fuseset:
FS02: 0000f00000000000
Bytes a 3B0= 01 07 50 (sulla mia xbox)

1) 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.
2) Lo compara anche a 0 o minore, in questo caso era 5 quindi secondo controllo fallito.
3) Prende 5 ci sottrae 1 e shifta il 5 di 4, ottenendo 80 che è uguale a 50 esadecimale! Quindi passa questo check e infatti va correttamente avanti!

Sulle slim (FS02= f000000000000000):
1) Contatore a 16: la prima "f" è a 16 da destra. 16-16=0 byte di sequenza=0.. Bingo!
E voi direte, beh e se viene bruciato un fuse.. vediamo:

FS02=0f00000000000000
1) Contatore a 16: la prima "f" è a 15 da destra. 16-15=1 byte di sequenza=0 .. argh.. non va..
2) 1 non è uguale a 0... non va
3) 1 ci sottrae 1=0 shifta 0 di 0 ottenendo 0 che è uguale a 00 della sequenza autorizzata... Bingo!!

però se brucia due fs?

FS02=00f0000000000000
1) Contatore a 16: .... etc... 16-14=2 .. niente
2) 2<>0 Niente
3) 2 ci sottrae 1 shifta 1 di 1 che non è 0! Quindi blocco.

Ora io NON so se il CB_A contenga o meno il codice del controllo degli efuse. Se lo contiene e vengono bruciati due efuse fine RGH. Altrimenti EPIC FAIL. *** ORA SONO CERTO CHE IL CB_A NON LO FA PROPRIO***

Il porting del CB_A su fat... se il CB_A non contiene il codice del controllo degli efuse e non controlla il FUSE01 (tipo console!!) allora potrebbe essere... altrimenti nada. *** ORA SO CHE SI FARA' ***

Grazie per aver letto...

Fuseset - Piccola spiegazione Tecnica

from Galaxy Note

**MARCHISIO80** · 18-05-13

L'avevo gia' linkato prima pocoyo

Io ai tempi ho preso spunto proprio da quell'articolo di rf

Qui ho messo la versione inglese,perche' nn fa confondere(x chi mi facesse i calcoli con le sequenze di cui stiamo parlando adesso)...RF(nn ha piu' aggiornato il topic con le uove "scoperte") parlava di sequenza di boot 00 00 00 00 sulle slim,ma il CBA 9188 nn fa il controllo,per quello e tutto x00
Ma lo faceva il CBB...,ho ricavato(offset 3B0 del CBB) ai tempi la sequenza di boot autorizzata da cambiare nel CBB 9230,per far avviare xell nelle xbox aggiornare a post 14699
Sequenza di boot autorizzata slim 9188 == 03 01 0001
Sequenza di boot autorizzata slim 9230 == 03 03 0005
E' bastato mettere la sequenza 9230 sul decryptato del CBB 9188 x far avviare il 9188 su xbox 9230..altrimenti serviva una patch,che ovviamente nn conoscendo il codice nn saremmo mai riusciti a creare...semplice ma efficace

Comunque...questi sn i 2 CB fat,con relative sequenze

6754
01 0C 0AD0

6723
01 05 0010

Qualcuno mi puo' dire il fuseset 02 delle xbox 6723 e 6754?
Cosi' vediamo che ne esce fuori?

Grazie

O.t x far capire meglio a tutti,in parole povere..sta cosa della sequenza

Se nel CB 6723 si potesse mettere la sequenza del 6754..il 6723 si avvierebbe sulle xbox aggiornate
Ed e' quello che abbiamo fatto sulle xbox 9230,per avviarci di nuovo il CBB 9188

**MARCHISIO80** · 18-05-13

Si

Bravo,io ci stavo litigando,non mi ricordo piu' i settaggi

**pocoyo2** · 18-05-13

Non ho nessuna jasper jtag quindi non posso controllare i CB che hai chiesto. Ma se vuoi ho falcon e zephyr

from Galaxy Note

**MARCHISIO80** · 18-05-13

Grazie Pocoyo

Vanno benone,in pratica tra tutti cercavo un fuseset 02 di una revisione di scheda madre(jtag)e il fuseset della stessa revisione di una xbox aggiornata con gli ultimi CB

**deco.gio** · 18-05-13

ti posto i fuseset di una jtag jasper 16mb:
Fuses dump
fuseset 00: C0FFFFFFFFFFFFFF
fuseset 01: 0F0F0F0F0F0F0FF0
fuseset 02: 0000F00000000000
fuseset 03: FFFFFFFFFFFFFFFFFF
fuseset 04: FFFFFFFFFFFFFFFFFF
fuseset 05: FFFFFFFFFFFFFFFFFF
fuseset 06: FFFFFFFFFFFFFFFFFF
fuseset 07: FF00000000000000
fuseset 08: 0000000000000000
fuseset 09: 0000000000000000
fuseset 10: 0000000000000000
fuseset 11: 0000000000000000

se serve altro son be lieto di mettermi a disposizione....

**deco.gio** · 18-05-13

a seguire i fuseset di una rgh2 jasper 16mb:

fuseset 00: c0ffffffffffffff
fuseset 01: 0f0f0f0f0f0f0ff0
fuseset 02: 000000f0000f0000
fuseset 03: FFFFFFFFFFFFFFFFF
fuseset 04: FFFFFFFFFFFFFFFFF
fuseset 05: FFFFFFFFFFFFFFFFF
fuseset 06: FFFFFFFFFFFFFFFFF
fuseset 07: ffffffff00000000
fuseset 08: 0000000000000000
fuseset 09: 0000000000000000
fuseset 10: 0000000000000000
fuseset 11: 0000000000000000

spero che possano servire.....

**MARCHISIO80** · 18-05-13

Grazie

Nelle 6754 l'ultima(nn l'unica) F a destra e' quasi certamente in questa posizione

fuseset 02: 00000000000F0000 allow cseq 12 = 0C dalla sequenza di boot nell'offset 3B1

Riprendendo il topic di RF dovrebbe essere cosi'

Esempio di fuseset:
FS02: 00000000000F0000
Bytes a 3B0= 01 0C 0AD0

0C = 12
0AD0 = 173?

1) Contatore a 16. Si cerca la prima "f" partendo da destra. In questo caso si trova da destra alla posizione 5. Si compara quindi 16-5 al byte di sequenza, in questo caso 11. Non è uguale. Quindi fallito il primo controllo.

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

3) Prende 11 ci sottrae 1 e shifta l'11 di 4, ottenendo (173???) che è uguale a (0AD0???)esadecimale! Quindi passa questo check e infatti va correttamente avanti!