PS3 SCETool v0.2.9 by Naehrwert Updated, Adds NP Fix and More

Following up on his previous release, today Sony PlayStation 3 hacker Naehrwert has updated SCETool to version 0.2.9 which now includes an NP application types fix and more followed by an unofficial update from Gamma Argon as detailed in the changes below.

Plaintext sections will now take less space in metadata header keys array.

Added option to specifiy a template SELF to take configuration values from.

Added option to override the keyset used for en-/decryption.

Fixed NP application types.

[Firmware Version] will now be written to control info only.

[Application Version] will now be written to application info only.

Finally, from ben.ss7: Here is a scetool v0.2.9 which has zlib1.dll and the data folder embedded within the exe, which means it doesn't require you to have zlib1.dll and the data folder for keys.

The original scetool source code hasn't been touched and it shouldn't have any issues. The keys which have been embedded in to this exe are:

NP_tid

NP_ci

NP_klic_free

NP_klic_key

NP_sig

metldr

bootldr(lv0)

If any user wants me to embed all the keys up to 4.31 PM me. Enjoy

Update: From TheUnkn0w via IRC: Updated my sce_encrypt tool, supports drag and drop decryption, added a checkbox for compression and fixed a few bugs Just paste it into your scetool folder and run, makes decrypting/encrypting files far more easier.

Version 0.3.0

Added option to specify the data path

From toolboy2012: Hi Guys, So, I decided to make one more nice update to the SCETOOL, so we could seriously clean up that "::makeself{}" routine.....so I added one more command, so that we could dump the specific fields we need to save off from the original SELF header, so we can re-create it with the same data (rather than build these enormous lists of authids, vendorids, etc!)

So now the "SCETOOL -w" command will dump the specific header info we need to PS3MFW, (example is below):

So, there are a couple of new routines I had to add in my "ps3mfw_base.tcl", and the updated "scetool.exe"....

so feel free to take what you need... so my new ::makeself routine utilizes these fields, all read into a global array... and the routine is now much simpler/cleaner.

Note: I still want to review the "self-app-version" & the "self-fw-version" fields in the SCETOOL, and see where exactly they actually reside in the SCE headers, as I would like to get them 100% copied over as well, right now I'm setting both to the "version" field (ie 3.55, etc)

PS3 LV2_Kernel Exploit Sample Implementation By Naehrwert

Following up on his PS3 SCETool update and PS3 Dump_Rootkey code, today Sony PlayStation 3 hacker Naehrwert has posted some details on exploiting the PlayStation 3 lv2_kernel and has made available a sample 3.41 implementation below.

To quote from his blog: Exploiting (?) lv2

A long while ago KaKaRoTo pointed me to a stack overflow he found while reversing lv2_kernel. But there are two problems:

1. The vulnerability is in a protected syscall (the SELF calling it got to have the 0x40... control flags set). So you’d first need to find a suitable usermode exploit (don’t ask us), that gives you code execution with the right privileges.

2. The payload data is copied to lv2 heap first and the function will do a free call on it before the payload has any chance to get executed. This might not sound like a problem but it looks like lv2′s heap implementation will overwrite the free’ed space with 0xABADCAFE and thus destroy the payload.

Here (pastie.org/4755699) is my sample implementation for 3.41 lv2_kernel (although the vulnerability should be present in all versions of lv2 up to the latest firmware), maybe someone of you will find a way to overcome problem (2.) and can get something nice out of it because right now it’s only good to crash lv2.

The footer signature is still not checked upon npdrm self files execution as of 4.21.

Because kakaroto says something that doesn't make it true. Basically he found a check in 3.55 that was not even called and assumed they used it in 3.60+.

Of course they do whitelist npdrm now so even if the footer isn't checked you cannot run your own npdrm selfs signed with keyset lower than 0x0D making the whole debate rather pointless. Aditional checks are now performed on the actual file format as well such as the segment counter flag that needs to be set to 0x01 except for the very last segment.

Finally, from KDSBest (via twitlonger.com/show/jcmh80): 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 totally 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!!! ^^