Cosa si nasconderà dietro GBoot?

[Electron^-]

È notizia di ieri, che un team russo sia riuscito a creare il primo "rebooter" per il nuovo Glitch Reset Hack (GRH).
Ovviamente tutti hanno accolto con clamore la lieta novella, che portava un briciolo di speranza a tutti coloro che attendevano una dashboard alternativa avviabile con il nuovo Hack.


Le prime parole degli sviluppatori sono state (riassumendo brevemente ciò che si può leggere nella [URL="http://www.consoleopen.com/xbox360/gboot-un-freeboot-per-reset-glitch-hack-in-sviluppo/"]precedente news[/URL]):
"Abbiamo sviluppato un rebooter i grado di avviare un solo eseguibile che è contenuto in una locazione precisa, e tale locazione cambia da gioco a gioco, quindi per cambiare videogame, si deve ricorrere ogni volta al flash della nand.
L'avvio sarà semplice, una volta flashata la nand, vi basterà mettere il file "xenon.elf" su di una penna usb, avviare Xell Reloaded ed automaticamente sarà caricato il backup nella locazione di memoria specificata nella Nand."

Tutto questo sarebbe fantastico, ma muovendoci un pò sulla rete, si apprende da "Logic-Sunrise" che tutto questo sarebbe una bufala e che tutto questo sarebbe confermato da un fantomatico post di Fallen93 su XboxHacker.
Personalmente non sono riuscito a trovare questo post sul forum in questione, e risalendo agli ultimi messaggi di "TheFallen93" (questo il vero nick dell'utente su XBH), sembra che l'ultimo intervento risalga al 3 luglio di quest'anno.

Per pura informazione riporto di seguito, nello spoiler, quanto scritto su L-S:

Ok so you use the glitch hack to bypass CB_A check, patch CB_B (if present), CD, CF and your good, I don't see what your missing here? No ms keys are required if you patch the RSA/SHA1 checks out. The checks are extreamly trivial to patch out too. CD is not the kernel CE is, CD is just what unpacks the kernel, checks for any patch slots and if they are present loads their corresponding CF slot. Also the kernel never touches any of the bootloaders during the boot process, so no patches are required to get it to boot. Once CD makes the jump to the hv reset vector, your bootloaders are never touched again. Keep in mind we are not rebooting we are just booting!

Se fosse confermato, dal discorso di cui sopra, si apprende che il Glitch Hack, per poter avviare una dash alternativa, non ha bisogno di patchare il bootloader, dato che non serve utilizzarne uno exploitabile dato che l'avvio di codice non firmato è permesso dallo stesso Hack.
Infatti in questo caso non si parla di Rebooting, come già sappiamo, bensì di un vero e proprio booting.

Continuando nell'articolo di L-S, si trova qualcosa di più concreto e dimostrabile rispetto al precedente post.
La console, per avviare un gioco, necessita del kernel della console funzionante, dato che molte delle funzioni dei videogiochi sono incorporate nel sistema di gestione della Microsoft.
Ovviamente, se si pensa di far avviare un videogioco da Xell, esso non dovrebbe partire, o comunque mostrare numerosi errori dato che non trova il kernel per eseguire alcune delle sue funzioni base (perchè qualche funzione è contenuta all'interno del gioco stesso n.d.r.).
Se ci pensate bene, infatti, cosa è possibile avviare da Xell se non gli homebrew programmati unicamente con le librerie "libnenon" che sono implementate nello Xell?

Tutto questo potrebbe esser smentito dalle parole del team russo che afferma che creando la nand con il riferimento alla locazione del gioco, venga incluso nella stessa la dash 13599, però ciò sembra alquanto strano dato che se possono inserire la Dashboard e far caricare ad un gioco le librerie contenute all'interno, perchè non avviare direttamente FreeStyle Dash (o un altro homebrew alternativo tipo Xex Menu) per poi gestire tutto più comodamente da li? (Come direbbe Mariello Prapapappo: "Mishtero!" n.d.r.)


Concludo questa mini inchiesta, concordando con l'atteggiamento di GliGli, che ha sviluppato il Glitch Reset Hack (ma non l'aveva scoperto per caso in seguito ad un bug nel suo software?!? o.O n.d.r.), e di tutti gli hacker che dopo le loro importanti scoperte, comunicano al pubblico la loro impresa ma che poi non continuano a svilupparla ( o magari solamente a condividerla) per evitare che, i loro sforzi, contribuiscano all'aumento della pirateria, invece che alla voglia di sperimentare alternative o espandere le potenzialità di un oggetto.

I vari Hack infatti, nascono con la voglia di ampliare le funzionalità di un qualcosa che è limitata. In questo caso ad esempio, su Xbox era impossibile avviare Linux, per cui in molti si sono cimentati nell'impresa ed hanno creato free60, e di conseguenza Xell. Successivamente è stato creato un parco di librerie attraverso le quali è stato possibile iniziare a programmare staccandosi dal SDK ufficiale di mamma Microsoft, ed in questo modo, si è ottenuta una console completamente trasformata in una macchina OpenSource.
Questo poi ha portato all'utilizzo improprio dettato dalla malsana voglia di "rubare" tutto ciò che si può a sbaffo degli acquirenti coscienziosi. Ciò ha portato ad un rifiuto da parte degli Hacker con la "H" maiuscola, nel rilasciare alcune informazioni succulente.
Bèh, ci se la cerca a volte...

[Pa0l0ne]

Ottimo! Non c'e' veramente altro da aggiungere!

[jonblu]

ottimo articolo,anche un ritardato come me ha compreso il concetto

[D@rio]

Concludo questa mini inchiesta, concordando con l'atteggiamento di GliGli, che ha sviluppato il Glitch Reset Hack (ma non l'aveva scoperto per caso in seguito ad un bug nel suo software?!? o.O n.d.r.)

per caso fino ad un certo punto... la botta di culo è stata mandare un impulso di reset di durata mooooolto bassa (come se fosse un glitch sul segnale), ma comunque aveva imboccato la strada giusta per l'hacking a livello hardware alla ricerca di bug

[url=http://it.wikipedia.org/wiki/Glitch]Glitch - Wikipedia[/url]

[Electron^-]

per caso fino ad un certo punto... la botta di culo è stata mandare un impulso di reset di durata mooooolto bassa (come se fosse un glitch sul segnale), ma comunque aveva imboccato la strada giusta per l'hacking a livello hardware alla ricerca di bug

[url=http://it.wikipedia.org/wiki/Glitch]Glitch - Wikipedia[/url]

Era più una battuta che una reale constatazione xD resta il fatto che ha trovato forse l'unico modo per bypassare la protezione della console

Sent from my Nexus S using Tapatalk while I'm looking what you are doing... o.O

[Pa0l0ne]

Una piccola constatazione dei fatti: abbiamo da una parte Xell con il suo lavoro di programmazione partito da zero e la sua libxenon TOTALMENTE INCURANTE della Gestione degli Xex e del kernel Microsoft in generale, pienamente in accordo con la filosofia del progetto "free60"; dall'altra i vari "rebooter" (su jtag) ed ipotetici "loading booter" (su RGH) che presuppongono invece un lavoro "illegale" (ma ad ogni modo sopraffino...) di reversing su kernel Microsoft, probabilmente "fomentato" dai vari RGH chip maker. Ragionando in termini economici, capaci di smuovere le menti piu' brillanti (vero Commodore4eva?!) a chi interesserebbe una xbox360 glitchata solo per startare degli elf? Il movimento di denaro provocato dalla vendita di modchip sarebbe "ben poco" e non giustificherebbe un simile sforzo di hacking del lavoro altrui (kernel Microsoft).
Probabilmente, a meta' di questo discorso, potrebbero posizionarsi gli autori di freestyledash (o della nuova RXE) che alla fin fine hanno solo usufruito di uno "stato dei fatti" ovvero un freeboot ormai rilasciato (perche' allora non sfruttarlo) nonostante abbiano cmq evitato accuratamente di includere porzioni di codice "scomode" (aka di proprietà Microsoft) nel codice sorgente rilasciato questa Estate....

Insomma e' come in Star Wars: Da quale "lato della Forza" siete affascinati?
Personalmente, benche i Jedi abbiano il fascino della purezza, rimanere "impassibili" dalle alterne vicende di un Anakin Skywalker ormai invecchiato e' cmq da ipocriti...

[riff82]

Quindi ora se questo gboot e una bufala ,dobbiamo aspettare solo il team del RxE per capire se questa nuova dash supporterà anche RGH.(o si hanno gia info al riguardo?)Speriamo bene...Anche perchè una xbox con dash alternativa diventa un mediacenter ad esempio a me piace molto gustarmi i miei .mvk sulla tv(e ogni volta devo collegare pc alla tv e l'audio sul theater) sarebbe grandioso riprodurre tutto da xbox senza fili volanti xD

[Pa0l0ne]

Nulla di certo per il momento, ufficialmente il TeamRXE (Od exTeamFSD se preferite) non assicura nè smentisce ma bisogna fare chiarezza: Bootare la loro Dashboard è dipendente dalla creazione di un JTAG Rebooter (già esistente) e di un ResetGlitchHack Loader Booter (alla data attuale NON ESISTENTE). Lecito pensare che una simile fatica nel programmare la "Real Xbox Experience", e soprattutto i numerosi investimenti da parte dei vari RGH-CHipMaker vadano di pari passo con il poter (auto)finanziarsi la "ricerca/sviluppo" di questo nuovo e necessario "piece of code" che probabilmente sarà già in mano di qualcuno....

Discorso diverso invece per la questione MediaCenter...Lo Xex FFplay codato da Cancerous e JQE con il porting delle librerie FFmpeg eseguito da Ced2911 e di quelle SDL da Lantus (veri pezzi da 90!) è l'unico programma attualmente abile a riprodurre gli MKV e non senza numerosi bug. D'altronde lo XDK Microsoft (con il quale ricordo è stato illegalmente compilato) non prevede normalmente l'utilizzo di tali codec "a default", presupponendo un lavoro "immane" per integrarli e non sò fino a che punto possa essere lecito aspettarsi una loro integrazione all'interno di un nuovo ipotetico "XBoxMediaCenter" data la "delicatezza" delle questioni legali che ci si porta inevitabilmente dietro e che obbliga a "lavorare" in underground (eliminando alla radice anche buona parte dei programmatori opensource che potrebbero dare "una mano"). Se tutto ciò avvenisse in ambiente libxenon sarebbe invece "un altro paio di maniche", ma è un progetto ancora troppo giovane e soprattutto non sarà mai (almeno ipotizzo) dotato di una sua dashboard in quanto il suo unico e principale scope rimane quello di bootare una distro Linux....al limite con le dovute ottimizzazioni (ma ad oggi ancora non presenti visto che persino la gestione della Gpu è ancora problematica) sarebbe più facile prevedere che l'eventuale XboxMediaCenter verrà lanciato proprio in questo ambiente Linux (i sorgenti già ci sono ed il lavoro sarebbe perfettamente "legale").....ma IMHO, gestire un MediaCenter in questo scenario è ben più macchinoso che farlo attraverso una DashBoard Embedded!

E' ben più facile che il (lo?) FFplay venga integrato e soprattutto sviluppato (così com'è è inusabile a meno di avere passione per le imprecazioni) direttamente nella RXE...non credete?

Chi vivrà...vedrà!

[angelo]

Peccato ci sia sempre qualcuno che rovina tutto.

[riff82]

Nulla di certo per il momento, ufficialmente il TeamRXE (Od exTeamFSD se preferite) non assicura nè smentisce ma bisogna fare chiarezza: Bootare la loro Dashboard è dipendente dalla creazione di un JTAG Rebooter (già esistente) e di un ResetGlitchHack Loader Booter (alla data attuale NON ESISTENTE). Lecito pensare che una simile fatica nel programmare la "Real Xbox Experience", e soprattutto i numerosi investimenti da parte dei vari RGH-CHipMaker vadano di pari passo con il poter (auto)finanziarsi la "ricerca/sviluppo" di questo nuovo e necessario "piece of code" che probabilmente sarà già in mano di qualcuno....

Discorso diverso invece per la questione MediaCenter...Lo Xex FFplay codato da Cancerous e JQE con il porting delle librerie FFmpeg eseguito da Ced2911 e di quelle SDL da Lantus (veri pezzi da 90!) è l'unico programma attualmente abile a riprodurre gli MKV e non senza numerosi bug. D'altronde lo XDK Microsoft (con il quale ricordo è stato illegalmente compilato) non prevede normalmente l'utilizzo di tali codec "a default", presupponendo un lavoro "immane" per integrarli e non sò fino a che punto possa essere lecito aspettarsi una loro integrazione all'interno di un nuovo ipotetico "XBoxMediaCenter" data la "delicatezza" delle questioni legali che ci si porta inevitabilmente dietro e che obbliga a "lavorare" in underground (eliminando alla radice anche buona parte dei programmatori opensource che potrebbero dare "una mano"). Se tutto ciò avvenisse in ambiente libxenon sarebbe invece "un altro paio di maniche", ma è un progetto ancora troppo giovane e soprattutto non sarà mai (almeno ipotizzo) dotato di una sua dashboard in quanto il suo unico e principale scope rimane quello di bootare una distro Linux....al limite con le dovute ottimizzazioni (ma ad oggi ancora non presenti visto che persino la gestione della Gpu è ancora problematica) sarebbe più facile prevedere che l'eventuale XboxMediaCenter verrà lanciato proprio in questo ambiente Linux (i sorgenti già ci sono ed il lavoro sarebbe perfettamente "legale").....ma IMHO, gestire un MediaCenter in questo scenario è ben più macchinoso che farlo attraverso una DashBoard Embedded!

E' ben più facile che il (lo?) FFplay venga integrato e soprattutto sviluppato (così com'è è inusabile a meno di avere passione per le imprecazioni) direttamente nella RXE...non credete?

Chi vivrà...vedrà!

sarebbe un sogno l'integrazione nella RxE!!bisogna vedere appunto se un produttore di chip vada a creare un freeboot per le dash alternative anche perche parlandoci onestamente credo che il 99,999% di utenti che effettua RGH vuole dash alternative in cui poter metterci emulatori e homebrew di vario genere anche perchè gente che sperimenta(e che in grado) con xell c'è ne veramente poca(anche se devono essere apprezzati per la volontà)
Un mio amico fortunato possessore di xbox jtag(purtroppo io a differenza sua feci l'errore di aggiornare la versione dash quando era possibile l'hack del jtag) mi ha mostrato il sudetto player sebbene scarno e privo di qualsiasi interfaccia grafica ha per piu di 5-6 minuti riprodotto un filmato correttamente....altri del forum pero hanno detto che se si tenta di andare indietro o avanti con il filmato il programma si blocca....Comunque dico che e sempre meglio di niente anche perche credo che ci saranno sviluppi successivi per quest outilissimo homebrew

[G1zm0]

l'sdk della microsoft è alla base anche di freestyledash come detto più volte, per far si che un gioco parta in ambiente non microsoft (xell) è necessario soddisfare tutte le chiamate esterne che il goco in questione effettua, altrimenti non partirà mai e darà errore.

Non è impossibile però.

[Pa0l0ne]

Praticamente per esulare dal kernel Microsoft mantenendo pero' la compatibilità con il software retail esistente, bisognerebbe esistesse un vero e proprio Middleware che si occupasse di "tradurre" all'hardware le funzioni e chiamate "pensate" per operare in ambiente Microsoft. Ammesso che un qualche "pazzo" decidesse di avventurarsi in una simile "opera", avete idea dei "tempi biblici" richiesti da un necessario studio di Reversing sia del kernel che di tutto il parco videogiochi esistente per verificarne la corretta interpretazione? Senza contare le performance in decadimento a cui si andrebbe incontro (ci sarebbe pur di mezzo questo Middleware a sprecare preziosi cicli di clock).
Credo che la strada debba essere ben altra....la via del loaderboot e' infine (pur con le sue grosse difficoltà di patching) mooolto più agevole....il che e' tutto dire!
Pensare poi che qualcuno faccia gratis questo "lavoro" mi fa' ricredere sulla bontà del genere umano...e sull'esistenza di "Babbo Natale"....


Sent from my Jailbreaked iPhone using Tapatalk

[G1zm0]

un emulatore come dici tu non è proponibile anche io ci avevo pensato ma è troppo dispendioso. alla fine è necessario un qualcosa di intermedio. comunque il mio ragionamento è alla base di quello che ho incontrato scrivendo un sistema operativo (non ancora completato per mancanza di tempo). in ambiente non microsoft è necessario ricreare tutte le condizioni necessarie al funzionamento di tale architetture. un pò come ho fatto io per far riconoscere ad eso (il mio sistema operativo) i file .exe.
comunque bene paolone, non ti conosco però sicuramente discutere con te non è mai tempo perso (non ti offendere è un complimento alla mia maniera).