Buenas, parece que llevo un tiempo algo ausente. En realidad he estado investigando por mi cuenta aprendiendo lo que se puede.
El caso es que mi investigacion con la colaboracion de importante devs de la scene internacional ( Tydye (RgLoader) , Blackaddr (Xboxhacker), Marchisio (ConsoleOpen)...) me llevo por el camino de las Dual Cb Fats.
Lo primero fue conseguir la Cpukey en consolas aun sin desencriptar para estudiarlas y porta los parches .
Para ello hice una pequeña porcion de codigo PPC que pudiera insertarlo por Keystream en los bootloader y mostrarmela por POSTOUT sniffer.
Una vez conseguido ya se podian deencriptar y parchear pero hacia falta glitchearlas para admitir los parches.
Para esto me puse a estudiar los codes de los cpld a fondo. En resumen como recordatorio os cuento que el glitch se basa en sniffear el PostOut que genera la consola en el proceso de booteo, en el momento en que comprueba la validez del bootloader elegido se hace un reset al cpu previamente frenado para si hay suerte de por bueno nuestro bootloader parcheado.
Proceso:
Fat Single CB.
Primero decir que para nuestro chip usamos el punto Hana que nos da un CLK=48MHZ
* Esperamos el Post38 y activamos el frenado del Cpu con un 'logic 0' en el punto Cpu_Pll. De esta forma frenamos al CPU x128 veces. Al mismo tiempo activamos un contador de frenado.
* Una vez frenado esperamos el Post 39 (SHA Verify de nuestro CD parcheado), esto quiere decir que en este momento la consola empieza el proceso de verificacion de nuestro CD. Pues bien esta funcion la CPU frenada x128 tarda un tiempo(ns) ,(nuestro chip sigue a 48mhz) si en el momento adecuado (aprox 62% de la duracion completa) hacemos un micro reset del cpu se produce algo en los regitros internos del Cpu que hace que admita el CD. Tiene que ser en el momento exacto y de la duracion correcta, si es diferente el Cpu o no se entera o se bloquea o afecta a registros vitales para que todo siga correctamente.
* Una vez el contador de frenado llega a un valor especifico o cuando tenemos el siguiente Post desactivamos el frenado. Y esperamos si suena la flauta. Si no hay exito en el proceso al estar parcheado el SMC la consola reinicia el proceso infinitamente hasta conseguirlo.
En SLim:
Aqui el punto Hana nos da un CLK=96MHZ
* Aqui en lugar de glitchear la verificiacion del CD lo hacemos en la verificacion del CB_B. Y activamos el Down counter.
Esperamos el Post D8 para frenar el CPU, pero como no tenemos Pll_Down en las slim se utiliza otro metodo de envio de comandos al SPi pero en este caso solo conseguimos frenarla x3 con lo cual el proceso va mucho mas rapido con respecto a la velocidad de nuestro Chip (96Mhz). De este modo todo debe ser mucho mas preciso y sera mucho mas inestable. Es la diferencia de acertar de un disparo a un conejo o a una tortuga.
* Esperamos el Post DA de verificacion del CB y hacemos el reset en el momento exacto de la duracion exacta.
* Cuando el down counter llega a un valor o cambia el Postout desactivamos freno y esperamos exito o reinicia el proceso.
¿A que viene este rollo?
Para entender mejor proceso con las Fat dual cb. En estas pense que no seria dificil. Pense en sniffear el post out esperar el Post D8 frenar el Cpu con en CPU_PLL_DOWN para rebajar la velocidad x128 y esperar el POST DA para aplicar el reset. La diferencia con las slim es que en las dualfat iria mucho mas lento el proceso y lo tendria mas facil de encontrar el Timing perfecto. Me puse a ello y aqui llego la decepcion. Cuando aplicaba el Pll_down en el Post D8 la consola se bloqueaba. Despues de darle mil vueltas probe a aplicar Pll_down en diferentes momentos del booteo y me di cuenta que la consola no le afecta de igual forma el Plldown segun el momento de aplicarlo y que se bloqueaba.
Mi siguiente intento fue activar el Pll_down una vez empezaba el PLL_DA y observer que no se bloqueaba.
Cojonud0. Pero no obtuve resultados estables porque en el proceso de frenado los timings eran variables hasta que el CPU estaba establemente frenado. Al inicio de Post Da el Cpu ya debe estar frenado y estable.
Mala suerte.
Lo comente con sceners y ellos mismos me confirmaron que sufrian estos cuelgues con Pll_down.
Hablamos de aplicar el metodo de SPI para frenar x3 aun sabiendo que seria muy inestable.
Lo descarte esperando el ansiado RGH2 y aqui me quede porque esperaba que este atacaria de otra forma. De hecho comentamos en que probablemente se trataba de glitchear el 1BL para poder cargar cualquier CB_A.
Me he quedado de piedra al ver que la Release de RGH2 hace exactamente lo mismo.
Cierto es que ellos fueron un paso mas alla y concretaron los Timings.
Cierto es que parece definitivo al impedir su FIX.
Dicho esto FELICIDADES a los devs que corresponda.
Lo ideal seria el combinar primero el SPI slow down en el Post D8 y luego activar el PLL_DOWN en el POST DA . Esto seria el glitch mas estable posible ya que frenariamos el CPU x384 (3x128).
Una vez glitcheados y desencriptados nuestros CB_Bs solo es cuestion de decompilarlos (PPC) y portar los parches de siempre.
El problema en los bootloaders posteriores al 14717 es que eliminaron el POsTOUT (nuestra referencia para glitchear).
En este sentido lo que hace el RGH2 es usar las dual CB de fat anteriores al 14717 (que aun usaban el POSTOUT) como CB donantes.
En cuanto a AutoGG esta actualizado para aplicar el RGH2 en fase test . Lo he preparado para que detecte CB posteriores al 14717 y aplique el obligado RGH2.Solo tiene sentido hacerlo en consolas Fat con Dual CBs como unica solucion hasta ahora.
EL resto abstenerse porque solo irian a PEOR.P.D:Otro tema es las Coronas, esto si seria un avance. Aqui el problema esta siendo el proceso de glitcheo y no en el famoso Hana ni en el CLK. Eso de incorporar un CLK al propio chip tiene poco sentido pudiendo usar como referencia la consola. Pero bueno si lo ponen no lo vamos a quitar.
Por ultimo comentar que por temas personales no voy a tener mucho tiempo a partir de ahora para estos vicios. Tratare de dejar actualizado el autogg para este RGH2 y despedirme por un largo tiempo.
Saludos
![[mamaaaaa]](/images/smilies/nuevos/triste_ani4.gif "llorica")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
saludos ![[ok]](/images/smilies/nuevos2/okis.gif "ok")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
. 
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
pues que bueno que te ha funcionado, eres el primero que confirma que Xebuild arranca con el RGH2.
