Nuovo Dae.bin sulla nuova dash Microsoft 2.0.14686.0

[HyperOblio]

Vabbè che probabilmente negli ultimi giorni ti sarai crogiolato nell'HyperOblio....ma dove sei stato nell'ultimo "mese"?.... (Scherzo ovviamente!)

ehehehehheeh Fantastico Volevo avere la certezza.... Ora torno nel mio HyperOblio ahuahuahuahauaha

[Dexther]

Tutti sti casini per fare una partita in multiplayer...bah...

Ormai sono nella mentalità rgh...anzi..qualcuno vuole una cinquantina di dvd dual layer a poco?? ^__^

Ti brofisto fratello !

[ZioPippoSSJ]

Brofisto è una nuova terminologia giovine?! una contrazione di brother e fisting? Lol

Inviato dal mio Nexus S usando Tapatalk

[Pa0l0ne]

Brofisto è una nuova terminologia giovine?! una contrazione di brother e fisting? Lol

Inviato dal mio Nexus S usando Tapatalk

Credo si riferisca a tale pratica:
Allegato 1496

I vecchi come me, sono invece rimasti alla "pacca sulla spalla"....ma come si dice...largo ai GIOOVANI (letto con la "O" apertissima)

[traffiker]

ragazzi tale dash e ancora sicura per rgh??? nel senso anke partendo da questa dash si può fare ????

Come detto prima, questa dash apporta modifiche solo alle ap2.5 oppure blocca l'RGH?

[Pa0l0ne]

Come detto prima, questa dash apporta modifiche solo alle ap2.5 oppure blocca l'RGH?

L'RGH non è bloccabile tecnicamente da un aggiornamento software, tale blocco richiederebbe eventualmente una nuova revision Hardware da parte di MS. Risulta eventualmente bloccabile il processo di caricamento del kernel hackerato così come concepito oggi in accoppiata ai vari CB e CB_a + CB_b attualmente presenti su tutte le Xbox PRE 14686...ma è pur sempre un "blocco" virtualmente aggirabile....

Anche se detto non sò quante volte, ribadisco per chi non avesse ben chiara la situazione che come per le Xbox JTAG, anche per le Xbox RGH, se hai ovviamente a bordo una dashboard "freeboottata" non puoi usufruire direttamente dell'update ufficiale MS, che in presenza di Chip RGH o collegamenti JTAG manderebbe inevitabilmente in errore la Xbox, ma devi attendere il rilascio della nuova dash opportunamente "trattata" per essere applicata su RGH e/o JTAG.

A grandi linee deve essere chiaro che:

Nel caso in cui sbadatamente si effettuasse l'upgrade ufficiale MS con RGH a bordo, sarebbe sempre possibile "recuperare" la situazione (a parità di CB a bordo), mentre con JTAG a bordo, se non si è rimossa la resistenza R6T3 PRIMA dell'eventuale e sbadato update NON SAREBBE PIU' POSSIBILE RIAPPLICARE il JTAG, ma (tranne che per le motherboard Xenon) si potrebbe cmq applicare un RGH.

Ad onor del vero, sembrerebbe però che l'update 14686 riscriva anche il CB, andando quindi "temporaneamente" a bloccare il RGH; si tratta pur sempre di un "blocco" temporaneo aggirabile dallo studio di questo nuovo CB e dal rilascio dei nuovi tool. Nel frattempo vige sempre la regola di evitare l'update come la peste. Se poi di "rumor" vogliamo parlare, sembra che venga applicato un CB splittato anche sulle FAT, proprio come sempre avvenuto sulle SLIM, però con una nuova revision.

Come dite? Il Live?...beh, in questo caso, anche se avete una Dual Nand sconsiglio cmq l'update visto che il CB viene riscritto...e nel caso remoto in cui non venisse rilasciato nuovo kernel reversato avrete segnato un bel autogol!

Per vs conoscenza allego processo di Boot della Xbox:

1BL (Inside CPU)

Loads and decrypts CB(_A) into ram, it computes a RotSumSha1 of CB(_A) and uses it to verify its RSA signature. If the signature is valid, 1BL jumps to CB(_A).

CB

SLIMS ONLY: CB_A loads and decrypts CB_B into ram, it computes a RotSumSha1 of CB_B and checks it against the known hash. If it matches CB_A jumps to CB_B.

CB(_B) starts up a virtual machine, which does:

- initializes the PCI Bridge
- disables the GPU PCIE JTAG test port
- initializes the serial port
- talks to the SMC to clear the "handshake" bit
- initializes memory
- generates RROD if memory init fails

CB(_B) loads and decrypts CD into ram, it computes a RotSumSha1 of CD and checks it against the known hash. If it matches CB(_B) jumps to CD.

CD

Loads and decrypts CE into ram, computes a RotSumSha1 of CE. If it matches the known hash, it decompresses the LZX compressed base kernel.
It then checks for patch slots. If it finds one, it will load and decrypt the corresponding CF bootloader for that patch. It then computes a RotSumSha1 of CF and uses it to verify the CF loaders signature. If the signature is valid, CD stays in memory but jumps to CF.

There can be up to 2 CF/CG pairs for patching the kernel.

CF

Loads CG into memory by reading the CG data in the NAND header and then reads the rest of the CG data from the CG blocks specified in CF header. It then decrypts the CG in memory using the key generated from decrypting CF. To verify it, it computes a RotSumSha1 and checks it against the known hash. If it matches, it uses LZX delta decompress to apply the patch to the base kernel in memory. Once its done, it jumps back to CD and once CD has finished up, it jumps to the reset vector in the hypervisor.

Tutto chiaro?

[pocoyo2]

Cristallino

Inviato dal mio HTC Desire HD

[Baccello]

Credo si riferisca a tale pratica:
Allegato 1496

I vecchi come me, sono invece rimasti alla "pacca sulla spalla"....ma come si dice...largo ai GIOOVANI (letto con la "O" apertissima)

Comincio a sentirmi vecchio allora