Pare che Mathieulh abbia bucato il FW3.60

Come da titolo pare che il coder Mathieulh sia riuscito nell'impresa di bucare l'ultimo FW originale sony, il 3.60

Il firmware 3.60 implementava nuove funzioni di protezione dalla pirateria oltre alla funzione di sincronizzazione dei salvataggi online, e secondo la sony (anche secondo alcuni coder) erano stati cambiati i sistemi di protezione e bucarlo non sarebbe stato così facile.

Mathieulh annuncia anche che non rilascerà un bel niente, non aiuterà nessuno e non gliene frega niente se viene ricoperto di insulti dagli altri coder che invece hanno sempre condiviso tutto con tutti!

Mathieulh sarà un coder in gamba, su questo non si discute, ma dovrebbe imparare che certi atteggiamenti è meglio evitarli, sopratutto per rispetto di quelle persone come GEOHOT e GRAF_CHOKOLO che hanno sfondato le porte della PS3 e che purtroppo ora sono in battaglia legale con la sony!

Hai trovato un exploit che non vuoi condividere???perfetto, non ci sono problemi, ma almeno stai zitto, per rispetto verso queste persone, STAI ZITTO!

La notizia è circolata in rete grazie a Drittz, il coder del Gaia Manager e del FuckPSN che sul suo twitter ha riportato alcune parti della discussione con Mathieulh sui canali IRC

Qui la frase di Mathieulh che ha fatto incazzare tutti:

Citazione:

---

[03:15] while you are insulting me like morons, I already have code running on 3.60, and I am laughing, and guess what ? I am happy I stopped sharing, you can hate me for it, I don’t care.

---

Qui il video di prova del CFW 3.60
http://www.youtube.com/watch?v=Qohuq...layer_embedded

Se osservate bene nel punto 00:40 si vede l'icona di sincronizzazione online dei salvataggi, funzione presente solo nei FW 3.60 e SECONDO MOLTI CODER è quindi la prova del fatto che il video non sia un falso.

Che dire, solo il tempo ci dirà se sia tutto vero o se sia tutto un falso organizzato a regola d'arte!

Nuovi dettagli ci arrivano su questo exploit dal coder stesso, ve li riporto anche se io non ci ho capito granchè:

Citazione:

---

@xShadow125 You can't overflow user processes, the NX bit applies here, you can only overflow lv2 or a process with higher privileges.

@xShadow125 You can update from your pwn pup only from 3.55 or lower, unless you have an exploit.

@xShadow125 Of course that should be fixed in upcoming lv0 revisions anyway (By moving the ldrs to the top of lv0)

@xShadow125 You run the 3.60 lv0, then you switch the nor, and pull the cell reset line, and you dump the extra KBs where the loaders are.

@xShadow125 Basically you have a nor with 3.55 (or lower) lv0 and your own small lv1 code that does the dump, and 3.60 lv0 on the other.

@xShadow125 You wont get all of lv0 but the part with the loaders shouldn't be overwritten.

@xShadow125 You can actually get all the 3.60 keys/loaders without knowing lv0 keys by dumping lv0 from ram with dual nor and signed lv1.

@xShadow125 That's from an older lv0, the method to get the data isn't the same, the one I posted was a dump, this one is a decryption

@xShadow125 There is a nice way to dump pre 3.55 lv0 as well by using a small lv1 binary, it's a risky process though.

@xShadow125 Oh! You mean my pm ? congrats, you just figured I have had lv0 dumped/decrypted for quite some time xD

@xShadow125 Reminds me of those stupid lv2 overflows I spotted ages ago in the bdemu code, which are useless now on 3.55+ anyway.

---

e ancora:

Citazione:

---

To those planning on building a 3.56+ pup for whatever reason, the files attributes changed, the group and user ids for the files as well.

The new 3.56+ values for tarballs are the following: owner_id, "0000764" group_id, "0000764" owner, "tetsu" group, "tetsu" ustar, "ustar "

You can use fix_tar to use those new values. Use with caution.

By comparison, those are the pre-3.56 values. owner_id, "0001752" group_id, "0001274" owner, "pup_tool" group, "psnes" ustar, "ustar"

@davidkont 3.60 isn't "hardcore security" anyway, it's just sony thinking they are safe hiding everything inside lv0...

@Ps3WeOwnYoU You can't decrypt lv0 without the bootloader keys. Your best bet is to look at 3.56, decrypt loaders, look for exploits, profit

@Ps3WeOwnYoU You need to either decrypt or dump lv0, then you can get the encrypted loaders and decrypt them with the metldr key. Good luck.

---

FINALMENTE Mathieulh ha spiegato il funzionamento del exploit 3.60 con il quale sarà possibile reperire le key che criptano il fw 3.60.

Qui la sua spiegazione:

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
lol
?
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
lolol 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

---

Più o meno , riassumendo, il coder dice che: avviando un file self con un header enorme, questo header viene spostato dalla memoria locale condivisa alla memoria isolata ed eseguito da li.
quindi basta il self di un loader con un header enorme per scrivere il codice che ci interessa nella memoria isolata della ps3 e patchare così il sistema