KDSBest releases his lv2_exploit for v4.20

[BNDVS]

First, we had scene developer 'naehrwert' posting information on how to exploit lv2, and now another developer 'KDSBest' has jump onto it, and written one that works on firmware v4.20.

Sadly, it seems to not work on later Sony firmwares:

I didn't managed to make it work on 4.21 so I just did on 4.20

Some information about this method from KDSBest:

Since @naehrwert posted an lv2 exploit I will do so too . The stack pointer points to lv2 and if we do a syscall, the syscall saves register to the stack HAHA. Btw. It just crashes the console for now, since I totaly overwrite dump the lv2 or some memory addresses I don't know. Feel free to try around, adjust the address of the stackpointer and so on. If you managed to get the panic payload executed. Tell me!!! ^^

Here is his sample code, for other developers to try it out:

//compile: ppu-gcc kds2.c -o kds2.elf
//or: ppu-lv2-gcc kds2.c -o kds2.elf

register unsigned long long payloadHolder2 asm ("r21");
register unsigned long long payloadHolder asm ("r20");
register unsigned long long stackpointer asm ("r1");
register unsigned long long counter asm ("r25");
register unsigned long long bufferStackpointer asm ("r26");

int __volatile__ main(int argc, const char* argv[])
{
// backup Stack pointer
bufferStackpointer = stackpointer;

payloadHolder = 0x3960024F3960024FUL;
payloadHolder2 = 0x4400000244000002UL;

// Incrementer
counter = 0x00;

// Play with that address till the panic is executed, I lack of time todo so
// add always 2 or 4 to it, i would try 4 or 8... bla bla you will get the idea
stackpointer = 0x8000000000000100UL;
doItAgain:
// KDSBest Payload
// Prepare for our Syscall

asm("li %r0, 0x0");
asm("li %r3, 0x6");
asm("li %r4, 0x1");
// li r11, 0x24F -> PANIC
asm("mr %r22, %r20");
asm("mr %r23, %r20");
asm("mr %r24, %r20");
asm("mr %r27, %r20");
asm("mr %r28, %r20");
asm("mr %r29, %r20");
asm("mr %r30, %r20");
asm("mr %r31, %r20");

// Stack Pointer = Build Address of LV2
stackpointer += counter;

// Syscall 0xA9
asm("li %r11, 0xA9");
asm("sc");
counter += 0x04;

// We write sc
asm("mr %r22, %r21");
asm("mr %r23, %r21");
asm("mr %r24, %r21");
asm("mr %r27, %r21");
asm("mr %r28, %r21");
asm("mr %r29, %r21");
asm("mr %r30, %r21");
asm("mr %r31, %r21");

// Stack Pointer = Build Address of LV2
stackpointer += counter;

// Syscall 0xA9
asm("li %r11, 0xA9");
asm("sc");
counter += 0x04;


if(counter < 0x1000000)
goto doItAgain;

stackpointer = bufferStackpointer;
return 0;
}

Of course remember this stuff is of no use to the current end-user, but it gives us hope there is progress slowly on getting past v3.55 CFW!

NEWS SOURCE: KDSBest's Twitter Account

[Nikola87]

This can lead to something really useful? CFW 4.20 ? Keys?

[Yuu]

As Bryan Downing from BBUK would say before announcing eviction results...."its Crunchtime" it is soo fitting here .

Time to revive that thank you dev's page eh. Keep it up everyone.

[stock2255]

Thank you for the news. This is basically a port of previous work to 4.20, except proper offsets were changed, and little more was added to make it usable. Great job KDS. The problem lies with the actual implementation of the lv2 exploit. Just because you have a way "in" to it, doesn't mean you can take anything out of it. Currently it's no different than causing the console to crash. While I believe the man (or woman, need more woman involved, their intelligence puts ours to shame sometimes) smart enough to successfully cuz a kernel panic, or lv2 to dump through this process, would already possess this (or a thousand other proof of concepts.) There is some cool things you could do with this. Not necessarily in the ps3, or through this exploit, but a proper lv2 exploit can be worth its weight in gold, in probing around and looking at a possible lv1 exploit, or even beyond. You have to start somewhere. And if the information is built upon, and released, hey, you never know. I would never get my hopes up for a true 4.20 firmware. You'd most likely still need 3.55 to upgrade to the custom firmware, or a hardware flasher to manually flash a 4.20 PUP onto a console that can't be downgraded, because we may get public keys, but I doubt us ever seeing private keys again.

For the average current ps3 user, one would probably just hope exploits are released, (than patched by Sony), than released again, with each exploit unlocking a new catalog of games, software downgrade possibility (for those stuck on service mode on 3.56 for example). It's impossible to know for sure, frankly, because I doubt you'll see this "exploit" or the previous "exploit" modified and released in the public with the appropriate changes.

[Duggle]

Thank you for the news. This is basically a port of previous work to 4.20, except proper offsets were changed, and little more was added to make it usable. Great job KDS. The problem lies with the actual implementation of the lv2 exploit. Just because you have a way "in" to it, doesn't mean you can take anything out of it. Currently it's no different than causing the console to crash. While I believe the man (or woman, need more woman involved, their intelligence puts ours to shame sometimes) smart enough to successfully cuz a kernel panic, or lv2 to dump through this process, would already possess this (or a thousand other proof of concepts.) There is some cool things you could do with this. Not necessarily in the ps3, or through this exploit, but a proper lv2 exploit can be worth its weight in gold, in probing around and looking at a possible lv1 exploit, or even beyond. You have to start somewhere. And if the information is built upon, and released, hey, you never know. I would never get my hopes up for a true 4.20 firmware. You'd most likely still need 3.55 to upgrade to the custom firmware, or a hardware flasher to manually flash a 4.20 PUP onto a console that can't be downgraded, because we may get public keys, but I doubt us ever seeing private keys again.

For the average current ps3 user, one would probably just hope exploits are released, (than patched by Sony), than released again, with each exploit unlocking a new catalog of games, software downgrade possibility (for those stuck on service mode on 3.56 for example). It's impossible to know for sure, frankly, because I doubt you'll see this "exploit" or the previous "exploit" modified and released in the public with the appropriate changes.

Or we can compile it to a pkg file and put it in 4.20 dex and we have piracy


ye ye i know isnt this simple

[the-green]

It's awesome to read such news !!! good job KDSBest

[rednekcowboy]

Thank you for the news. This is basically a port of previous work to 4.20, except proper offsets were changed, and little more was added to make it usable. Great job KDS. The problem lies with the actual implementation of the lv2 exploit. Just because you have a way "in" to it, doesn't mean you can take anything out of it. Currently it's no different than causing the console to crash. While I believe the man (or woman, need more woman involved, their intelligence puts ours to shame sometimes) smart enough to successfully cuz a kernel panic, or lv2 to dump through this process, would already possess this (or a thousand other proof of concepts.) There is some cool things you could do with this. Not necessarily in the ps3, or through this exploit, but a proper lv2 exploit can be worth its weight in gold, in probing around and looking at a possible lv1 exploit, or even beyond. You have to start somewhere. And if the information is built upon, and released, hey, you never know. I would never get my hopes up for a true 4.20 firmware. You'd most likely still need 3.55 to upgrade to the custom firmware, or a hardware flasher to manually flash a 4.20 PUP onto a console that can't be downgraded, because we may get public keys, but I doubt us ever seeing private keys again.

For the average current ps3 user, one would probably just hope exploits are released, (than patched by Sony), than released again, with each exploit unlocking a new catalog of games, software downgrade possibility (for those stuck on service mode on 3.56 for example). It's impossible to know for sure, frankly, because I doubt you'll see this "exploit" or the previous "exploit" modified and released in the public with the appropriate changes.

Well, never say never. There were plenty of people around here a year ago that were calling me crazy for wanting the cex->dex conversion released because they said it was useless and would never lead anywhere (actually they were still saying this a couple of months ago) and look where we are now.

As you said, it all starts somewhere.

[rental]

Question, so once the exploit is executed properly, what we will get?

1. Peek/Poke access
2. Keys
3. New CFW
4. None of the above, just a kernel panic

[Fma965]

Question, so once the exploit is executed properly, what we will get?

1. Peek/Poke access
2. Keys
3. New CFW
4. None of the above, just a kernel panic

Of course remember this stuff is of no use to the current end-user, but it gives us hope there is progress slowly on getting past v3.55 CFW!

maybe that answers your question.

[lolong]

without a proof, this l2_exploit 4.20 is useless