|
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
| |
6:14 م
Moneef Alnahdi
"
0 التعليقات:
إرسال تعليق