30w ago - Similar to Shark Week, this appears to be PS3 Key week with the latest additions being the PS3 3.70 Appldr (VSH.elf) Keys surfacing while a list of the PlayStation 3 version 3.65 to 4.30 Appldr Keys in SCETool format is also in development.
Today's update begins with dosjuanes posting the PS3 3.70 Appldr Keys on Spanish site Elotrolado (linked above), followed by Chinese hacker Luckystar (via bbs.duowan.com/thread-29248664-1-1.html) developing a PS3 Appldr Keys 3.65 to 4.30 list in SCETool format as outlined below.
From dosjuanes on the PS3 3.70 Appldr Keys, roughly translated:
title = App revision 22
type = app
version = 3.70
revision = 0016
riv = 62773C70BD749269C0AFD1F12E73909E
erk = A106692224F1E91E1C4EBAD4A25FBFF66B4B13E88D878E8CD072F23CD1C5BF7C
pub = 566635D3E1DCEC47243AAD1628AE6B2CEB33463FC155E4635846CE33899C5E353DDFA47FEF5694AF
ctype = 30
REST ask HIM RATHER THAT IS YOUR NAME DOSPIEDRAS
From razorx: Here's the .ps3 keys i've put together (linked above) for you all just extract the zip into your .ps3 folder and your done the zip contains:
From slarty1408: Hi ppl, Just thought i'd add the 3.70 keys to deank's multiMAN[EBOOT_FIX] tool (linked above) so you can fix your own eboots/games. i will add more keys as i get hold them... I have only only tested it with 1 game by the way so any feed back would be great.
From cory1492: None of the keys are decrypted. The ERK/RIV of all keys (app/npdrm/spp) in the raw decrypted appldr are decrypted before use by appldr at runtime. Look at the working 3.70 posted earlier (or any of the previous keys) pub and search it out.
From Luckystar comes a PS3 3.65-4.30 Appldr Keys WIP, roughly translated: Appldr 4.30
2. make sure that the key revision of your SELF is 0x0016 and that it is not a NPDRM self.
I tested the keys with Saints Row The Third, and it decrypted the ELF... shift+Enter.
[*] Error: Could not find keyset for SELF.[*] Warning: Could not decrypt header.[*] SCE Header:
Magic 0x53434500 [OK]
Key Revision [DEBUG]
Header Type [SELF]
Key Revision [DEBUG] means that your file is a FSELF. You just need to unfself it and sign the ELF with the keys that you want (eg. 0x01)
These 3.70-3.73 keys are just for retail SELF files signed with keys 0x0016. SELF files from PKG use NPDRM keys (unless they are custom made PKG created using make_package_npdrm). Yes... there used to be a tool that resigned your FSELF just pressing Ctrl+Enter on the eboot.
The current "3.70 keys" are only for key revision 0x0016 and self type = APP (retail eboot). If you have an "update/patch" eboot 3.70, it will not be decrypted with these keys, because they are self type = NPDRM and use a different key. Key revision 0x0016 is used by apps signed for 3.70, 3.72, 3.73 and 3.74.
Most of these have been confirmed by users including EussNL and ItsKamel and added to the PS3 wiki here: ps3devwiki.com/wiki/Keys. As always, we will update this article as new PlayStation 3 Keys are discovered and posted publicly.
Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!
Following up on the previous PS3 Lv0ldr / Bootldr clarifications by marcan42 and wololo, today PlayStation 3 hacker naehrwert has shared some details based on reverse-engineering the exploit used to dump it.
To quote from his blog: The Exploit
As the exploit that was used to dump lv0ldr/bootldr/howeveryouliketocallit is public now, let's have a closer look at it to understand what's going on. Here is what I have reversed from lv0 (it shares the syscon portion of the code with its SPU counterpart):
//Get size again (not checked now).
//I suspect that this is actually a compiler 'quirk' and not a
//programmer mistake. The original source probably accesses the
//packet size through a structure and the compiler noticed the
//non const access of the packet and generated this read of the
//size member because it could have changed.
pkt_size = GET_SIZE(tmp_pkt);
//Let's have some fun (payload_buf on caller stack).
memcpy(payload_buf, tmp_pkt + 8, size - 4);
//Run second sc_checksum.
The syscon library implements some high level functions, e.g. to shutdown the console on panic or to read certain configuration values. Every of this functions internally uses another function to exchange packets with syscon and the exchange function uses the read_cmpl_msg one to get the answer packet. The top-level function will pass a fixed size buffer to the exchange function.
So if we are able to control syscon packets, e.g. by emulating MMIO (and thanks to IBM we are), we can change the packet size between the two packet readings and overwrite the caller stack. And if we first copy a little stub to shared LS and let the return address point to it, we can easily dump the whole 256 kB.
Nothing more left to say now, let's wait and see if this is going to be fixed in future firmware versions (we just have to check lv0 fortunately).
I think this means good news for PS3 Slim 3k users if it is not fake. I really do think there are people who are willing to leak out information just to help people. I have a PS3 Slim 120GB serial CECH-3001A. Originally it came with 3.72 and I accidentally upgraded it to 4.31 which is the current one. I already know that my console cannot be downgraded to 3.55 to use CFW using the current methods.
I hope someone will make some progress with this to help people like me