Lv0ldr / bootldr Exploit ingeniería inversa por Naehrwert

¿Que significa esto?
¿Exploit, CFW........? ejemm

Ni idea compi, me a parecido algo relevante, a ver si alguien nos ilumina y nos explica si sirve de algo.
Salu2.

Esto es solo para devs. No hay ninguna aplicación practica directamente

Pero se podría avanzar algo para los que estemos en OFW con este exploit?

kalon escribió:PS3 dev naehrwert has reversed some parts of lv0 to understand how the lv0ldr/bootldr/howeveryouliketocallit exploit is working. Read the quote below for more information.

The Exploit
November 20, 2012
As the exploit that was used to dump lv0ldr/bootldr/howeveryouliketocallit is public now, let’s have a closer look at it to understand what’s going on. Here is what I have reversed from lv0 (it shares the syscon portion of the code with its SPU counterpart):

view sourceprint?
01
//In .data section.
02
static u8 tmp_pkt[0x800];
03

04
//Get size from sc packet.
05
#define GET_SIZE(pkt) ((pkt[4] << 8) | pkt[5])
06

07
int read_cmpl_msg(/*...*/, u8 *payload_buf /*r5*/, int min_size /*r6*/, /*...*/)
08
{
09
    u16 pkt_size;
10

11
    //Get packet header.
12
    memcpy_aligned_64(tmp_pkt, MMIO_SC_PKT, 0x10);
13

14
    //Check packet size.
15
    pkt_size = GET_SIZE(tmp_pkt);
16
    if(pkt_size - 4 < min_size || pkt_size + 8 > 0x800)
17
        return ERR;
18

19
    //Run first sc_checksum.
20
    if(!sc_checksum(...))
21
        return ERR;
22

23
    //Read packet again (plus header!).
24
    pkt_size = GET_SIZE(tmp_pkt);
25
    memcpy_aligned_64(tmp_pkt, MMIO_SC_PKT, size + 0x1B);
26

27
    //Get size again (not checked now).
28
    //I suspect that this is actually a compiler 'quirk' and not a
29
    //programmer mistake. The original source probably accesses the
30
    //packet size through a structure and the compiler noticed the
31
    //non const access of the packet and generated this read of the
32
    //size member because it could have changed.
33
    pkt_size = GET_SIZE(tmp_pkt);
34

35
    //Let's have some fun (payload_buf on caller stack).
36
    memcpy(payload_buf, tmp_pkt + 8, size - 4);
37

38
    //Run second sc_checksum.
39
    if(!sc_checksum(...))
40
        return ERR;
41

42
    //...
43
}
The syscon library implements some high level functions, e.g. to shutdown the console on panic or to read certain configuration values. Every of this functions internally uses another function to exchange packets with syscon and the exchange function uses the read_cmpl_msg one to get the answer packet. The top-level function will pass a fixed size buffer to the exchange function. So if we are able to control syscon packets, e.g. by emulating MMIO (and thanks to IBM we are), we can change the packet size between the two packet readings and overwrite the caller stack. And if we first copy a little stub to shared LS and let the return address point to it, we can easily dump the whole 256 kB.

Nothing more left to say now, let’s wait and see if this is going to be fixed in future firmware versions (we just have to check lv0 fortunately).

Fuente: http://www.ps3hax.net/2012/11/a-closer- ... naehrwert/

Que gran avance esto es lo que estaba esperando para entretenerme el fin de año...

Saludos...

Muy pero que muy interesante

tonymalpar escribió:Pero se podría avanzar algo para los que estemos en OFW con este exploit?

lulox escribió:I am going to make the most hated question on all the scene but here it goes.... does this lead to a base cfw4.xx?

Answer by twistay:
No there is nothing new here. It just explains what we already have

Saludos

kalon escribió:Ni idea compi, me a parecido algo relevante, a ver si alguien nos ilumina y nos explica si sirve de algo.
Salu2.

Enas, no sirve para nada.
Viene a decir que, ahora que es público (ejem) el xploit utilizado para volcar el botloader,lv0 o como queiras llamarlo (eso me ha molao) , él por su cuenta lo ha analizado y reversado para entenderlo y explica un poco sus hallazgos.

NO, no sirve para las consolas nuevas (Lv0.2) por que para usarlo es necesario tener acceso a ejecutar código y probablemente se necesite un linux además. Y aun así, sólo serviria si puedieramos firmar con la llave privada.

TAMPOCO sirve para las viejas, el Xploit sólo vulnera la seguridad en parte de la cadena de arranque de ps3, concretamente: botldr->lv0, permitiendo la obtencion de las "metadata keys" de lv0 o de la llave del bootloader (no confundir con la Cell-BE pck)

Salu2.

Venia a decir lo que Calantra acaba de decir, se me ha adelantado

Entonces Calantra una preguntas, pero esto que dice si ha dicho como funciona el supuesto xploit puede taparlo sony? y la segunda con esto solo sirve para obtener las keys publicas de todos los firms y crear cfws no?

Miguel20 escribió:Entonces Calantra una preguntas, pero esto que dice si ha dicho como funciona el supuesto xploit puede taparlo sony? y la segunda con esto solo sirve para obtener las keys publicas de todos los firms y crear cfws no?

Aunque $ony pudiera taparlo, no serviría de nada, como el propio naehrwert explica y yo mismo he dicho, sirve para volcar la llaves "como quiera que prefieras llamarlas" (bootloader/lv0) que ya se tienen y se pueden obtener de nuevo descifrando lv0 en cualquier momento.

Nothing more left to say now, let’s wait and see if this is going to be fixed in future firmware versions (we just have to check lv0 fortunately).

Esto sirvió (pasado) para conseguir la llave para descifrar lv0 y obtener las llaves publicas de "cifrado", no confundir con las públicas de la firma, generalmente conocidas como las lleves de los cargadores del firmware (lv1,lv2,app,iso, etc etc) que estaban contenidas en lv0.

Salu2.