23Likes
LinkBack URL
About LinkBacksCOme già spiegato per tappare la falla serve una revisione della CPU e della MOBo in generale. NOn ha molto senso visto ke la vita della 360 sta volgendo al termine (in senso commerciale)Originariamente Scritto da gigigadda
COme già spiegato per tappare la falla serve una revisione della CPU e della MOBo in generale. NOn ha molto senso visto ke la vita della 360 sta volgendo al termine (in senso commerciale)
Non si da supporto privato, i vostri dubbi vanno risolti sul forum tramite un post... così tutta la Comunity cresce con voi
La butto li a caso.
Bucato il nuovo sistema di criptazione RC4.
Si usa un chip diverso,probabilmente sempre xilinx, così si guadagna sull'hardware....l'ecc andrebbe anche sui glitchip attuali.
E se fosse un 128 macrocelle per tenere più di un timing, gestito dallo switch 8? Alla fine penso che anche il CR3 Pro monti quello Xilinx (se è uno Xilinx), e l'alimentazione è sempre a 5V.
Solo supposizioni, devo ancora riceverlo, non fucilatemi. :P
Inviato dal mio GT-I8150 con Tapatalk 2
Nei brainstorming non si fucila nessuno ^_^
io temo invece che faranno una revisione, poichè le xbox360 venderanno, secondo me, ancora fino alla fine 2014, un po' come la ps2...
e non credo sia un "decrypt" rc4 perchè FORSE con un aggiornameto potrebbero nuovamente cambiare algoritmo
ritengo sia coinvolto 1bl, ma non sarò io a scoprirlo, dato che non ho la skill / conoscenza per studiare/decappare dgx nè tantomeno gli ecc
Grazie, mi ero già barricato in casa.. :P
Inviato dal mio GT-I8150 con Tapatalk 2
La prova che funzionerà anche su dash future è data dal fatto che puoi cambiare/cancellare la flash, flashare l'ecc e ricavarti la cpu key....
L'unica contromisura è mettere in blacklist l'ecc (quindi CBA/CBB/CD) su 1BL ma chiaramente lo possono fare su una nuova revisione di CPU... pertanto TUTTE quelle prodotte alla data X di cambio CPU saranno SEMPRE recuperabili
eh poi un'altra cosa.... il core risente sempre del glitch..... quindi sarà solo questione di tempo
premetto che mi deve ancora arrivare " finalmente ,mi è arrivata la mail sda in consegna per oggi"
- ecc è diverso ! ed è complementare al dgx
- secondo me' a a che fare con il sistema di criptazione RC4 " solo perchè a bisogno di un ecc speciale"
-se cosi' non fosse , sarebbe bastato solo il dgx con i normali ecc "che sappiamo quale essere il loro limite 14719"
qualsiasi cosa abbiano fatto "hanno fatto un gran bel lavoro"
shapò!
il post sniffer..
Usb post sniffer v2
Quindi l'ECC del DGX non è altro che un CBA, un CBB e un CD patchati, che vengono caricati perché il check dell'1BL sul CBA è falsato dal glitch effettuato dal DGX..
Inviato dal mio GT-N7000 con Tapatalk 2
"... quando il domani verrà, il tuo domani sarà!"
il glitch è stato spostato..il reset prima agiva su una parte di autorizzazione, adesso su un'altra..ecco perchè cambia anche la freq del quarzo. non si può usare il dgx per freeboot proprio per quello..una volta ottenuta la cpukey, per far partire freeboot serve resettare la cpu in un momento diverso, il "classico"...almeno io credo sia così
Si, è quello che ho spiegato anche nell'altro thread. Però ora mi avete messo la scimmia di capire come funziona... e non mi accontento di sapere quello che già si sa..
Inviato dal mio GT-N7000 con Tapatalk 2
"... quando il domani verrà, il tuo domani sarà!"
Dico la mia da nuibbo totale in sti discorsi... se il dgx glitcha 1bl vuol dire che comunque la console non controlla più niente (1bl patchato per non controllare niente appunto) ovvio che dopo serve un xeboot patchato apposta per avviarsi con tutto quello che c'era prima... un po come é successo all'inizio tra rgh e jtag.. fate finta che non abbia scritto niente se ho detto cazzate
Inviato dal mio Galaxy Nexus con Tapatalk 2
quindi 1BL ha l'incarico di controllare solo CBA e niente altro?
E' una catena, ogni bootloader verifica, decritta ed avvia quello seguente. Sicuramente hanno trovato il punto in cui glitchare l' 1BL in questo modo avviano un CBA modificato ecc... ma l'hardware è sicurametne molto più preciso del xilinx "classico" per fare una cosa del genere.
ieri sera ho fatto qualche prova (senza successo) con una corona v3 250gb e FT3T10...(reset alternativo)
il fatto che il dgx non funzioni su FT3T10 è dovuto al fatto che è un punto troppo lontano? (quindi filo più lungo quindi più millisecondi quindi glitch fuori tempo) ...o forse qualcuno di voi è riuscito a far funzionare il dgx usando FT3T10 al posto di C5R11?
ho trovato anche un'altra discussione qua sul forum che parla di sniffer
I2c sniffer/analyzer
Ultima modifica di xboxbs; 20-02-13 alle 18: 33
Provato diverse volte con DGX su FT3T10. Mai partito xell.
Sugli altri punti del cpu_rst sempre esito positivo.
Così lascio il magico FT3T10 solo al glitchip-
Ho messo la freccia...
Inviato dal mio GT-N7000 con Tapatalk 2
"... quando il domani verrà, il tuo domani sarà!"
Permessi di Scrittura
Segnalibri