Exploit FW 3.60 rilasciato da Mathieulh

« Older   Newer »
 
  Share  
.
  1. Unversed
        +1   -1
     
    .

    User deleted


    image



    Pochi minuti fa, Mathieulh ha pienamente spiegato il funzionamento del exploit 3.60 con il quale sarà possibile reperire sia le key che criptano il fw 3.60. E' probabile che l'hacker francese abbia deciso di rilasciare l'exploit 3.60 dopo che geohot è rimasto in un certo senso "illeso" dalla battaglia legale con Sony.

    Traduzione non-google:

    CITAZIONE
    Nah, non si tratta di una sola riga di codice, almeno non per l'attuazione.
    Nonostante questo, trovare l'exploit è incredibilmente FACILE, nessuno ne è andato alla ricerca.
    Ho trovato tantissime richieste e piagnucolii [nei forum], di contenuti veramente utili ho trovato pochissimo. xD
    se qualcuno in grado di reversare la SPU cominciasse a esplorarla, sarà lui stesso a trovare [il bug]. Nel peggiore dei casi la cosa richiede qualche ora.
    il bug è *******mente stupido da sfruttare...
    LV0, EID0, secondo me dovremmo essere in grado di mettere mano a qualsiasi grazie al coreOS senza dover usare un flasher hardware.
    Almeno dovremmo essere in grado di mettere fine alla confusione che si è creata [dal rilascio del 3.56].
    ...
    basta solo sapere dove cercare
    basta guardare come i loader processano i file self e te ne renderai conto.
    Accidenti, Vi aiuterò ancora: riguarda l'overflow di un certo buffer
    si, questo è quello a cui io e defyboy abbiamo cercato di documentare nel ps3devwiki: bootprocess and loader locations etc.
    bene, una volta scoperto come i self vengono processati, è facile.
    Ancora un suggerimento:
    è presente prima del controllo dell'ecdsa
    A prima impressione sembrava solo un header overflow, che consentiva l'accesso ai dispositivi locali di memoria.
    E' un *****to exploit
    Se volete sapere di cosa si tratta, ve lo dirò
    La funzione che copia l'header SCE dalla memoria locale condivisa a quella isolata, non controlla la dimensione dell'header!
    \o/
    E' tutto qui, un ****to exploit!!
    L'implementazione non è semplicissima, il loader potrebbe bloccarsi qualche volta, ma quando funziona, ****o
    la dimensione dell'header diventa eccessiva

    ?
    Ora che lo conoscete, potete verificarlo da soli
    dovete procurarvi un self con un header ENORME.
    questo sovrascriverà il codice del loader, che verrà copiato all'interno della memoria locale condivisa.
    Una volta spostato il loader..
    ol dovete solo provare
    X1 è una *****ta implementazione
    ma sentitevi liberi di farlo xD
    ...

    Comunicato in lingua originale (inglese):

    SPOILER (click to view)
    CITAZIONE
    X nah, not a single line of code, at least not for the implementation
    but finding the exploit itself
    is EASY
    except no one has gone looking
    I’ve seen lots of askings and whining, very little looking xD
    if someone who remotely knows spu reversing starts looking
    he’ll find it
    at the very worse in a matter of hours
    the bug is ******ly stupid to begin with
    LV0, EID0, anything with coreOS imo should not be done without a hardwareflasher. Atleast with that you can undo the mess.
    yeah
    I am a bit of a red head here xD
    you keep saying that, but I suck at SPU assembly
    you’d find it even if you fail at it
    you just need to know where to look
    just look at how selfs are processed by ldrs
    and you’ll find it
    hell, I’ll help you, it’s about overflowing a certain buffer
    yes, that is what defyboy and I tried to document in the ps3devwiki : bootprocess and loader locations etc.
    well if you know how selfs are processed by loaders, it’s easy
    another hint
    it happens before the ecdsa check
    my earlier guess btw was that it was a header overflow, which gave access to the local storage
    It’s a ******ed exploit
    if you want to know what it is, I’ll tell you
    the function that copies the SCE header from the shared LS to the isolated Local Store
    doesn’t check the header’s size
    \o/
    it’s just THAT ******ed
    implementing it isn’t easy though
    cause loaders have failsafes and ****
    header size fail

    ?
    but now that you know, you can try it on your own
    X1 yes
    you craft a self with a HUGE header
    so it overwrites ldr code as it gets copied to the isolated LS
    and you wait the loader to jump to it
    ol must try heh
    X1 it’s a total ***** to implement
    but feel free xD
    if someone pwns the bl with this and gets the keys, he’ll have my kudos
    cause finding the exploit is the easy part
    Sony’ll fix it now, but it’s not like I care much
    their “unhackable” ps3s are probably already on the way


    L'impatto che ha l'exploit appena rilasciato su Sony :

    SPOILER (click to view)
    CITAZIONE
    why would they care about bootldr keys?
    ps3devnews etc. host metldr keys, appldr keys etc.
    X1 cause you can get lv0 decrypted
    once you get lv0 decrypted
    you get appldr
    once you get appldr
    you get 3.60 application keys
    once you get that
    you warez
    also, with those keys you can sign your own lv0, no ps3 fw update can beat you then
    yah
    you can have your 3.60+ custom firmware then
    and warez even more
    and mess with the psn again
    and so on


    Per chi se lo stesse chiedendo, "Con questo exploit sarà possibile fare un cf 3.60 e installarlo su una console montante firmware 3.60?", si, si potrà installare un firmware 3.60 su una console con firmware 3.60, di qualsiasi modello (fat, slim...), "Si potrà tornare online sul PSN?", si riavremo l'online con la console Hackata, ma secondo me sony deciderà presto di bannare gli utenti con console Hacked.

     
    Top
    .
0 replies since 22/4/2011, 14:56   108 views
  Share  
.