VDF_Demon escribió:Ammm Viral, me puedes decir con exactitud que has probado con la consola dañada? la verdad he buscado algo y me parece que los cb tambien son genericos, hasta cierto punto.. en slim
Claro, en el 1er post he estado actualizando lo que he hecho, pero te resumo:
Para no probar a ciegas en la placa que no tiene nand, en caso de que no solo fuera el "daño" de la nand vacia hehe, me puse a hacer pruebas directamente en mi SLIM completamente funcional:
Extraje el CB (CB_A y CB_B) de mi nand y los meti en una donada, la posiciones hex del CB para Kernel 9188 son:
CB_A8400
9F8F
CB_B
9F90
11B4F
Al usar solo mi CB_B y usar el CB_A de la nand donada, no lanzo XeLL.
Al usar solo mi CB_A y usar el CB_B de la nand donada, no lanzo XeLL
Al usar el CB completo, XeLL cargo sin problema, claro esta, el KV no era el de la placa, por lo tanto no mostró DVDKey, pero si CPUKey que es lo importante.
Incluso probe la nand donada con kernels diferentes (obviamente anteriores a 14717/14719, que en ese caso el CB cambia) y da lo mismo al generar el ECC ya que el ECC usa solo: KV, SMC, CB_A, CB_B y CD, pero colo el CB me fue necesario.
Al usar únicamente mi KV, no lazo XeLL
Al usar únicamente mi SMC, no lanzo XeLL
Al usar mi KV y SMC, no lazon XeLL... era de esperarse, ya que en este hack a diferencia del JTAG (SMC), lo que se parcha es el CB
El CD tampoco fue necesario.
Espero esto responda tu pregunta.
Apropósito, he preguntado en los foros de TX... y varios decían (traduciendoles): "No estoy seguro, pero creo que si usas un ECC donado, puedes lanzar XeLL y ver la CPUKey", y al darles mi respuesta, y sobre la explicación que hace Gligli del CB_B... NINGUNO me dio respuesta... hahahah, dejo mi post y un post similiar que se abrio el mismo dia:
http://www.team-xecuter.com/forums/show ... hp?t=87329http://www.team-xecuter.com/forums/show ... hp?t=87302EDITO:VDF_Demon, tienes razon sobre el bootloader:
Details for the slim hack
=========================
The bootloader we glitch is CB_A, so we can run the CB_B we want.
On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS.
Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.
We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs.
Apparently those registers are written by the SMC through an I2C bus.
I2C bus can be freely accessed, it's even available on a header (J2C3).
So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus
So it goes like that:
- We send an i2c command to the HANA to slow down the CPU at POST code D8 .
- We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
- When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
- We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.
When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
- Always activate zero-paired mode, so that we can use a modified SMC image.
- Don't decrypt CD, instead expect a plaintext CD in NAND.
- Don't stop the boot process if CD hash isn't good.
CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
RC4 is basically:
crypted = plaintext xor pseudo-random-keystream
So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
guessed-pseudo-random-keystream = crypted xor plaintext
new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
You could think there's a chicken and egg problem, how did we get plaintext in the first place?
Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!
The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image.
The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.
Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !
En español, ya descifrado el CB_B, no importa cual tenga solo se necesita el CB_A el cual es el que parchan, tal como me dijiste. Lo raro es que al ver el build.py que genera el XeLL, el que se parcha es el CB_B. Ademas al usar mi CB_A y un CB_B donado, mi consola no laza XeLL, lo voy a probar de nuevo en este preciso momento usando mi CB_A y el CB_B de la donada
EDITO 2:Lo he probado y como paso antes, sin resultado, puede ser que a lo que se refiere Gligli es que no importa la VERSIÓN del CB_B hehe, asumo
teyijape escribió:Viral Doom
podrias repararla tu mismo te nviaria las placas mas las nan corruptas es que en bogoto me las dio por muerta un pelao que supuestamente savia tratando de hacer rg y si puedes me respondes al correo es que no manejo mucho los foros
Aguanta, eres de Bogota? claro, me las puedes mandar, soy de Cali
. Pero... apenas me fijo en los títulos que has puesto a los post.. veo 0022. Explícame un poco en que momento te salio ese error, ya que crei que era una nand corrupta que habías extraído y no tenias mayor respaldo de la nand. Hay casos de 0022 irrecuperables, claro que no perdemos nada por intentar
, lo que pasa es mala manipulación.
