El desarrollador Kakaroto, ha revelado más información para ayudar a los desarrolladores de PS3 en la construcción de nuevos CFW 4.21 +!
Desde que las claves LV0 han sido filtrados, puedo compartir esta información con ustedes, para ayudar a aquellos que están tratando de construir su propio CFW 4.x: La firma ECDSA NPDRM en el pie de SELF está marcada por lv2. En primer lugar, pide appldr para decir si la firma va a ser verificada o no, y appldr sólo establecerá la bandera si el SELF es un NPDRM con revisión de clave 3.56 + (los que no tienen las claves privadas). Esto significa que los archivos de firmados con las nuevas claves 3,56+ todavía no tienen su chequeo ecdsa (probablemente para acelerar la carga de archivos).
Si el appldr dice que la firma ecdsa Debe comprobarse, entonces lv2 se comprobará a sí mismo, y devolverá un error si no es correcto. Hay muchas formas de parchear esta salida. 1 - Parcheo en la verificación para la revisión en clave appldr 2 - Parcheo la "poniendo el flag a 1" en appldr si la clave de revisión es <0xB 3 - Parcheo en el código de lv2 que almacena el resultado de appldr 4 - Parcheo de la función real de sigcheck lv2. 5 - Ignorar el resultado del ecdsa de lv2.
Aquí está uno de los parches (el cuarto, aplicación de parches a cabo la función de comprobación de lv2): En memoria 0x800000000005A2A8, que corresponde al desplazamiento 0x6a2a8 en lv2_kernel.elf, Sustitúyase: e9 22 99 90 08 02 7c a6 Con: 38 60 00 00 80 00 20 4e
Esto es para el kernel de 4,21 (que fue el último de ellos cuando he investigado esto), yo lo dejo como ejercicio para el lector para encontrar la compensación correcta para los próximos 4,25 y 4,30 ficheros del núcleo.
Y he aquí otro poco de información ... en el lv2 de 4,21, en la dirección de memoria 0x800000000005AA98 (a determinar el desplazamiento de archivo usted mismo), que es donde lv2 carga el 'check_signature_flag' resultan de appldr, así que si prefieres aplicar el método 3 anterior, cambiando el "ld% r0, flag_result_from_appldr" por 'ld% r0, 0' y tienes otro método de aplicación de parches. Cualquiera de las soluciones debe funcionar de la misma manera sin embargo.
Disfruta de nuevo homebrew en CFW 4.x ....
PD: Gracias a Flatz y glu0n que me han a ayudado a invertir este poco de información.
Texto Original en inglés
Spoiler:
Since the LV0 keys have now been leaked, I believe I can now share this info with you, to help out those who are trying to build their own 4.x CFW : The NPDRM ECDSA signature in the SELF footer is checked by lv2. It first asks appldr to tell it whether or not the signature is to be checked, and appldr will only set the flag if the SELF is a NPDRM with key revision from 3.56+ (the ones without private keys). This means that the SELF files signed with the new 3.56+ keys still don't have their ecdsa checked (probably to speed up file loading). If appldr says the ecdsa signature must be checked, then lv2 will verify it itself, and return an error if it's not correct. There are many ways to patch this check out. 1 - Patch out the check for the key revision in appldr 2 - Patch out the "set flag to 1" in appldr if the key revision is < 0xB 3 - Patch out the code in lv2 that stores the result from appldr 4 - Patch out the actual sigcheck function from lv2. 5 - Ignore the result of the ecdsa from lv2.
Here is one of the patches (the 4th one, patching out the check function from lv2) : In memory 0x800000000005A2A8, which corresponds to offset 0x6a2a8 in lv2_kernel.elf, replace : e9 22 99 90 7c 08 02 a6 With : 38 60 00 00 4e 80 00 20
This is for the 4.21 kernel (that was the latest one when I investigated this), I will leave it as an exercise to the reader to find the right offsets for the 4.25 and upcoming 4.30 kernel files. And here's another bit of info... in 4.21 lv2, at memory address 0x800000000005AA98 (you figure out the file offset yourself), that's where lv2 loads the 'check_signature_flag' result from appldr, so if you prefer implementing method 3 above, just replace the 'ld %r0, flag_result_from_appldr' by 'ld %r0, 0' and you got another method of patching it out. Either solutions should work just the same though. Enjoy homebrew back on 4.x CFW....
p.s: Thanks to flatz and glu0n who helped reversed this bit of info.
