E come la fai partire la dash homemade?Citazione:
Originariamente Scritto da diffusore
Visualizzazione Stampabile
E come la fai partire la dash homemade?Citazione:
Originariamente Scritto da diffusore
sapendo le varie key della console non si puo' mettere in chiaro la dash update per poterla modificare...tipo quando si cura un eseguibile.....
la dash originale per aggiornare la console chiede ed ottiene dei privileggi dalla console ,quindi suppongo che questa chieda alla console dei dati di sicurezza per eseguire l'aggiornamento.
avendo le varie key della console non si puo' vedere dove e cosa vuole per autorizzare il software.
grazie milleCitazione:
Originariamente Scritto da rf1911
Non è cosi' semplice , credimi , ma nn escludo si possa arrivare in futuro a flashare il lettore tramite dash , ovvio con lo SPI aperto a 0x00 via hardwareCitazione:
Originariamente Scritto da diffusore
@Diffusore: devi avere chiaro il chain of trust della xbox prima.. avere la cpukey non ti porta da nessuna parte. L'unica cosa interessante (direi vitale) che puòi fare con la cpukey è decryptare i bootloader e le patch del kernel per poi poterli analizzare con IDA. Ma non puoi modificare un eseguibile.
In sostanza:
1BL - Carica, decriptda con 1BL e controlla firma del CB_A
CBA- Carica , decripta con CPUKEY e controlla l'hash del CB_B
CBB - Carica, decrypda con CPUKEY e controlla l'hash del CD
CD - Carica,etc,etc.. CE e ci applica le patch kernel
ora però vo a nanna..
Se avessi fatto un dump della nand, post 14717, ti bastava rimetterla su. Ora, se lo fai con pre14717, hai ldv diverso, fuse07 diverso e cb_a/cb_b diversi. No boot! Attendi sviluppiCitazione:
Originariamente Scritto da matrixmorfeus
Inviato dal mio Desire HD
Per ora no. Per l'originlare devi attendere una nuova versione di xebuild, ma probabilmente addio live. Per FB devi attendere il nuovo FB o TX che ha fatto una patch.
Il glitch è stato bloccato. Qui non si tratta di intervenire a casaccio anzi sono state modifiche molto ben congeniate.Citazione:
Originariamente Scritto da Titty
Inserendo un delay a random nel codice del bootloader, proprio sulle chiamate che eseguono le comparazioni dell'hash code, rendi impossibile glitchare la console perchè non puoi temporizzare l'impulso correttamente. Ma non si sono fermati qui sono intervenuti anche sugli altri strumenti utilizzati per l'hacking della console come i postcode.
Non si tratta di panico, altrimenti questo aggiornamento sarebbe uscito a settembre. Hanno fatto esattamente quello che dovevano fare e che tutti si aspettavano.
Ora RGH può solo essere ripristinato tramite downgrade del CB sulle trinity ed eventuali porting futuri di quel CB (che non contiene efuse check) sulle altre revisioni, la fattibilità di quest'ultima parte è solo teorica. Di fatto è stato fixato ed in modo definitivo con sole modifiche al software di sistema.
Io nn sono in panico... anzi onestamente non è ke mi cambi molto sapere se il glitch è morto o meno...ci sono gli ODE (ke al momento per come la vedo io sono usciti vincitori quando erano dati per spacciati)... anche le mod Fw (per ki nn ha 1175)... alla fine una soluzione ci sta. Io son sempre stato dell' idea che non si può aver tutto dalla vita. Fortunato ki ha già fatto il glitch... sfigato ki ha esistato e adesso ha una FAT temporaneamente (o permanentemente) kiusa...
Le dual NAND... le ho sempre ritenute superflue (e i miei soci lo possono confermare).... volete il live? Usate una seconda console... oggi come nn mai M$ ha nuovamente dismostrato ke fa ciò ke vuole con la sua console, Xbox1 non ha insegnato abbastanza...
Per le slim trinity basta aspettare... alla fine è tanto rumore per nulla...
Per quello che ho visto disassemblando con IDA, e per le considerazioni fatte con altri membri dell'RGLOADER a casaccio non è il termine giusto.... hanno fatto di tutto e di più, stile "dove cojo cojo"... in sostanza hanno visto le vulnerabilità e le hanno in qualche modo rimosse... offuscati i POST, implementato Fusecheck, inserito delay e nops a più non posso nella memcompare, cambiato il check del ritorno da una comparazione a 0 a una a -1 (già questo da solo sarebbe bastato)...
Allego immagine di IDA..
Allegato 2632
Mi sbilancio? Sì.. secondo me non serve a molto, ci sono ancora diverse porte aperte..
L'unica porta aperta è l'utilizzo di un vecchio CB. Casomai l'errore è nell'assenza del check per impedire il downgrade. Ma questa è storia vecchia.
Poi scusa se tu hai delle vulnerabilità conclamate e discusse ovunque perchè non dovresti fixarle? Probabilmente bastava mettere il delay ed il glitch sarebbe stato impossibile, ma in ogni caso non costava nulla intervenire anche sul resto, in questo modo si rende difficile anche l'ulteriore studio della macchina. E' ciò che io avrei fatto. Individuato qualcosa di potenzialmente pericoloso lo avrei corretto, indipendentemente dal fatto che sia strettamente necessario.
Mi spiace smentirti, non è l'unica porta aperta. Credimi. Per lo studio della macchina mi pare di aver già dimostrato che non lo si è reso assolutamente difficile.. più chiaro di così..
Beh staremo a vedere qual'è sarà la piega che prenderanno gli eventi futuri. Io scommetto che il prossimo RGH si baserà su un vecchio CB portato.Citazione:
Originariamente Scritto da rf1911
Hanno reso difficile lo studio della macchina, non del codice. Già togliere i POSTCODE, lo avessero fatto un paio di anni fa tu non avresti avuto RGH, anche dopo esserti disassemblato il codice e studiato riga per riga.
Se mia nonna aveva le ruote era una cariola... il porting del cb è *un* modo.
Che vuoi dire? Io cercavo di evidenziare la differenza tra studio del codice e studio della macchina. Meno informazioni puoi ricavare dalla macchina reale su cui il codice gira più l'hacking è difficile. E poi ricordati che come ingegnere software è TUO PRECISO DOVERE correggere ogni potenziale vulnerabilità di cui sei a conoscenza. E queste falle potenziali erano conclamate.Citazione:
Originariamente Scritto da rf1911
Il porting del CB per me è IL modo. Anzi credo che ci siano indizi abbastanza forti che qualcosa si stia già muovendo in tale direzione. Se ci fossero altre vulnerabilità sarebbe preferibile sfruttarle invece di proseguire per quella strada, quindi se tu ne sei a conoscenza potresti sempre darti da fare e rilasciare qualcosa.
"Se mia nonna aveva le ruote era una cariola..." era riferito al fatto che non puoi solo riportarlo al fatto della rimozione dei post. Devi tornare al KK hack con i se e con i ma.. tutto è nato da lì... Per il resto chi vivrà vedrà..
Come tutte le cose ,quando il giro diventa troppo grande , gli si dà una stretta , vedasi $ky et simile.....Se vogliono fanno quello che gli pare, tutto sta nella convenienza che hanno nel farlo.Citazione:
Originariamente Scritto da Titty
Il problema per loro è che l'ha fatto tardi.. e in questo caso "meglio tardi che mai" non vale...
Condivido... probabilmente si sono trovati spiazzati dalla velocità con cui la modifica in se ha preso campo e hanno pensato meglio metterci na pezza.Citazione:
Originariamente Scritto da rf1911
Poi le strade del signore sono infinite ..... :)
Per come la penso io, chi voleva una xbox360 "aperta" ha avuto due treni (il primo quello del Jtag vero e il secondo quello del RGH) quindi se li ha persi entrambi è perchè ha voluto perderli e si accontenta di quello che resta, poi la storia insegna di "bug" ci sono sempre basta solo portarli alla luce e usarli
