, mirad el spoiler final. Si esto sirve de algo o no, o ya se ha intentado o tratado, pues decidlo y otra cosa que tachar de la lista, joder.Venga un saludo shurras.
Fuente:http://www.ps3hax.net/showthread.php?p=321389#post321389
De acuerdo vamos directo al grano. Esto es solo una teoría, nada más.
Aquí ha habido información disponible desde hace bastante tiempo. Y yo la he cogido, he pensado en ello, he investigado y he experimentado y ahora quiero compartirla para para romper el 4.0 o parte de él. No es una teoría aleatoria, es simplemente lógica. Quiero que otros devs la vean y a ver si podemos encontrar la forma de hacerlo funcionar, no me lo quiero guardar para mí, quiero compartirlo.El lv2ldr es usado para verificar y desencriptar el lv2_kernel.self. En la distribución de parametros del lv2ldr, los argumentos empiezan en 0x3E800, tenemos que saber esto para poder cargar los argumentos que queramos. Los argumentos finalizan alrededor de donde empieza la lista de direcciones revocadas, esto es alrededor de 0x3F000. u8* significa que lee un byte desde la dirección. Uno de los argumentos del lv2 está en lv2_in* eso debe significar que la dirección está en la ram(donde está alojada). La otra es lv2_out* esa es donde se descifra la dirección del lv2 en la ram(donde se descifra el lv2_kernal.self). Podriamos usar también u8 porque queremos leer un byte desde esa dirreción. Bien, con un programa hecho para leer la dirección como lo lo hace el readself podriamos saber donde miente el lv2 en la ram y donde esta desencriptado. Una vez sabemos la dirección el verdadero desencriptado puedo empezar. Entonces sabiendo la dirección desencriptada podemos coger ese offset y crear un programa como el coreos_tool para extraer y conseguir la key lv2 sabiendo donde está alojado lv2_kernal.self. Romper el 4.00 con este metodo deberia funcionar porque dudo que sony cambiase todas las localizaciones donde los loaders hacen estas cosas, seguro que está encapsulado en el bootloader pero siguen pasando por la ram un momento antes de ser mandados al metldr que carga el ldrs.
Algo asi como estas lineas
- Código: Seleccionar todo
void *buf; // <- that will get the address of the argument we chose to load u? buf_size;// <- pretty clear it gets the size. but would you add u64? } lv2_in; struct { u8 result[0x10];//read it by one byte from the address } lv2_out; }
Esto es solo un ejemplo rápido. No está completo.
Ahora para otros devs, he posteado este posible método aquí para que experimenteis y podamos conseguir algo con el 4.00. Podéis seguirme en Twitter https://twitter.com/#!/RealPsDev
Gracias y adiós.
OK so lets get right to it. This is a theory, nothing more.
There has been information available for quite some time. and I took it, thought about it, researched and experimented and I come out with my theory below to exploit 4.00 part of the way. This is not a random theory to, this is logical stuff. I'm providing this info for other devs to look at and lets see if this can work I don't keep stuff to my self I share.The lv2ldr is used to verify and decrypt the lv2_kernal.self. In the lv2ldr Parameters Layout, the arguments start at 0x3E800 we need to know this so we can load with the different arguments we want to. the arguments end around where the program revoke list address starts, so around this 0x3F000. u8* means read one byte from the address. One of the lv2 arguments are lv2_in* that would mean the address in ram (Where it's located). The other is lv2_out* that's where to decrypt lv2 address in ram(Where decrypts lv2_kernal.self). that would also use u8 because you want to read it by one byte from that address. well with a program made to read the address like how readself works we can know the address where the lv2 lies in the ram and where it is decrypted. once we know the address the real decryption can start. So knowing the decrypted address we can take that offset make a progam like coreos_tool pull the and get the lv2 key all from knowing that decrypted lv2_kernal.self location. exploiting 4.00 with this method would work most likely because I doubt sony changed all the locations where the loaders do there thing, sure there encapsulated in the bootloader but they still pass over into the ram at one point before being fed over to the metldr which loads ldrs.
some where along these lines
- Código: Seleccionar todo
void *buf; // <- that will get the address of the argument we chose to load u? buf_size;// <- pretty clear it gets the size. but would you add u64? } lv2_in; struct { u8 result[0x10];//read it by one byte from the address } lv2_out; }
that just a quick sample. not full.
So other devs I post this possible exploit I found here for you to experiment with and get some where with 4.00. You can follow me on twitter @ https://twitter.com/#!/RealPsDev
Thanks bye.
