58w ago - Following up on his initial release, today PlayStation 3 homebrew developer JjKkYu has updated his SCETool Script to PS3 TrueAncestor EBOOT Resigner v1.1 followed by v1.11 and v1.12 with the changes outlined below.
Oh, my God, I hate rush update. Elf fix doesn't relate to sfo, mate. '33' may allow it working on 3.41. Script will be improved when i finish current work.
wrong "24 13 BC C5 F6 00 33 00 00 00 41" to "24 13 BC C5 F6 00 33 00 00 00 34"
right "24 13 BC C5 F6 00 33 00 00 00 40" to "24 13 BC C5 F6 00 33 00 00 00 34"
4.0-4.11 use 40
4.20-4.25 use 41
In related PlayStation 3 homebrew news today has released (via ps3gameita.blogspot.it/2012/11/eboot-list-menager.html) a PS3 EBOOT List Manager for PC with details below, roughly translated:
Hi, not knowing where to write I write this topic. I am a young Italian developer and saw the turnout and the excellent posts of this forum / blog, let me tell you my new program: Eboot List Manager. From this program you can download all the Eboot out until now.
Finally, Attila (via ps3-infos.fr/forum/applications-pc-mac-f49/outils-pour-faire-vos-fix-de-jeux-3-56-a-4-30-pour-cfw-v1-7-par-attila-t3343.html) has updated PS3 Resigning Tools v1.7 using the recent PS3 Keys leaked with details below, to quote roughly translated:
These windows allow for batch scripts from your game or your bluray update (pkg) to patch the files so that you can make your own fix your game and launch 3.40-3.55 3.60.
Warning: These tools can cause bugs in your PS3. If possible, have dumps done with E3 debricker order, or in case of incorrect handling.
extract_pkg.bat: extract it your PKG "NPDRM" containing updates to games, demos or content of PSN / SEN. Drag your file above.
eboot_self_sprx_decrypter_recrypter.bat: Decrypt EBOOT.BIN all your files, *. self, *. SPRX games or bluray from PKG NPDRM extract it, change all occurrences of 3.60 by 3.40 (sys_proc_param, keyset etc.) to re-encrypt the game so that it is compatible 3.40 / 3.55. Beware, some self / SPRX update klicense need a specific (see klicense_cracker). Drag the file to decrypt it.
BruteForce.exe: Tool by Aldostool, klicense can find the (unique key per set) to decrypt the files self / SPRX updates for certain games. Take the EBOOT. BIN file and a self SPRX or supplied with the game and place them in the program folder. If you found the key, use the notepad to edit "eboot_self_sprx_decrypter_recrypter.bat" KLICENSE1 line, replace the key with this one you found.
patch_paramsfo.bat: Slide your PARAM.SFO file to change the version number 3.40.
create_pkg.bat: You will need to add psn_package_npdrm.exe Sony SDK to create your PKG. Drag the folder containing the folder "USRDIR" of the bat file.
(Use instead Bruteforce.exe) klicense_cracker.bat: Allows you to find the klicense (unique key per set) to decrypt the files self / SPRX updates for certain games. You will need to put EBOOT.BIN decrypted (with the previous tool) and a file named EBOOT.BIN.elf or self SPRX patch.self named folder in the bat file.
Note: it may take a long time and several popups error can potentially occur. Ok done, and wait until you find the key. If you found the key, use the notepad to edit "eboot_self_sprx_decrypter_recrypter.bat" KLICENSE1 line, replace the key with this one you found.
Added key appldr until firmware 4.30.
Update to 2.2.0 bruteforce tool which adds support tool crack of klicense by MAGIC333X
Update key PS3.
No longer uses the file extension to determine whether the file is a SPRX or EXEC, use the "type" value in "ELF64 Header" instead.
Display the command line scetool used to encrypt the file.
Fixed parameter np-app-type, depending on the input file.
Update to version 0.2.9 scetool.
Using the "template" of scetool.
Integration of a ungpkg modified by myself to support and Edat sdat files when decryption of files pkg.
Use FixElf to patch instead of sys_proc_param binmay. The tool should be more effective.
Other minor changes.
Update bruteforcer with the addition of plugin testklic which is faster than scetool to check if the klicense is good.
Modification of the patcher PARAM.SFO to use another tool aldostools compatible with all PARAM.SFO (not just 3.60).
Removed unnecessary parameters scetool when the file is not npdrm.
Added a specific message when you try to decrypt a file that was not the key (3.65 +).
Added a bruteforcer of klicense v1.7.3 by aldostools to replace klicense_cracker.bat.
Fixed a bug with file extractor pkg.
Take your game or your bluray pkg.
If it is a pkg, drag the file to pkg extract_pkg.bat.
You have your folder with the game
Drag the file on PARAM.SFO patch_paramsfo.bat
Drag the file EBOOT.BIN on eboot_self_sprx_decrypter_recrypter.bat.
If it tells you:
The file cannot be decrypted. Maybe it is unknown with a key, or you shoulds klicense add a key (for self / SPRX). Key Revision = [3.65] (3.65 or more), it is not worth continuing with these files, they are not decrypting.
If you see:
Continue thereafter. If you see files or self SPRX, slide one on eboot_self_sprx_decrypter_recrypter.bat
If you see:
"The file cannot be decrypted. Maybe it is unknown with a key, or you shoulds klicense add a key (for self / SPRX). Key Revision = [3.60 - 3.61]"
You know we have the keys 3.60-3.61 and therefore it lacks the klicense file. We must try to crack the key, the next step (Step only if required to do) Take the file EBOOT.BIN file and your self / SRPX you have not managed to decrypt and copy both the folder or is BruteForce.exe. Start bruteForce.exe (if you get an error at launch, install it ) and click start. If you can not find the key, reduce and offset alignment and try again.
If you're lucky, you will find the key, like this: 496e66696e697479576172644b657900 (Example here with the key Modern Warfare 3).
Take the notepad and open the file and change the line eboot_self_sprx_decrypter_recrypter.bat with "set KLICENSE1 19089cbaf948487f9530832bf477b369 =" to put the key klicense found instead of 19089cbaf948487f9530832bf477b369.
For each file self / SPRX drag the game on eboot_self_sprx_decrypter_recrypter.bat. If everything is configured correctly, you should see:
If you have a game patch bluray (not PSN content), you can replace the EBOOT.BIN files, PARAM.SFO, and self / SPRX the game and start the game. Otherwise, if the game files from the PSN (PKG file), you can redo a PKG to simplify installation. Drag the folder that you extracted in step 2 to create_pkg.bat (attention, you will find yourself on the internet psn_package_npdrm.exe file to make it work). Pkg file is created and you can install it with install package file.
I thank her for Asure tool for cracking and klicense opoisso893 to change sys_proc_param aldostools and its tools.
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 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.
* lv2 sys_mount stack overflow
* Original finder: KaKaRoTo (thank you for pointing it out!)
* Note: all offsets/values/addrs in this source are 3.41 specific
printf(" Taking the plunge...\n");
s64 res = sys_mount("FOO", "BAR", "XXX", 0, 0, 0, list, LIST_LENGTH);
printf(" Error: sys_mount returned (res = 0x%016lX).\n", (u64)res);
From Mathieulh (via pastebin.com/naxXkv3M):
Sep 04 13:16:42 I just posted one last thing
Sep 04 13:17:05 I dislike being called "king of liars" especially by someone who doesn't understand sht about ps3 self crypto
Sep 04 13:17:25 and yeah I said the truth
Sep 04 13:17:31 this footer signature
Sep 04 13:17:33 is not checked
Sep 04 13:17:35 even in 4.21
Sep 04 13:17:37 go figure
Sep 04 13:17:44 at least not upon npdrm self execution
Sep 04 13:17:59 I believe it is checked while the packages install
Sep 04 13:18:03 but that's something else
Sep 04 13:18:31 I don't even think it was called on 3.55 at all, (the function that does the stuff)
Sep 04 13:18:33 that's also wrong info
Sep 04 13:18:35 I gave kakaroto
Sep 04 13:18:40 over a week of work
Sep 04 13:18:48 with everything one would want to know
Sep 04 13:18:52 about self format
Sep 04 13:19:16 but he called it "useless" without revealing what I gave him
Sep 04 13:19:31 and he claimed how all of this was already public when most wasn't
Sep 04 13:19:47 he did all this along with his pamphlet in order to hide his incompetence
Sep 04 13:20:04 as he was "begging" me (literally) to get the extra info he needed to get his hack to work
Sep 04 13:20:09 and I told him to figure the rest himself
Sep 04 13:20:12 and he never could
Sep 04 13:20:19 figures
Sep 04 13:20:34 zecoxao, I gave him something he needed
Sep 04 13:20:42 but he wanted me to supply ALL the work
Sep 04 13:20:48 and I wasn't ok with that
Sep 04 13:20:58 the more I gave him
Sep 04 13:21:00 the more he asked
Sep 04 13:21:32 but yeah
Sep 04 13:22:03 if you can actually resign lv0, and put your own keyset in appldr on 4.21
Sep 04 13:22:16 and set your own keyset to something higher than 0x0D
Sep 04 13:22:35 and build a complying npdrm that has all the new values appldr checks, WITHOUT the so called footer
Sep 04 13:22:37 and run it
Sep 04 13:22:41 it runs just fine...
Sep 04 13:22:51 (yes, I did test this)
Sep 04 13:23:18 they do whitelist anything older than keyset 0x0D now for npdrm too
Sep 04 13:23:32 so crafting npdrms for 4.21 would not work on ofw now
Sep 04 13:23:38 but that stupid footer
Sep 04 13:23:47 which he claims is why whatever I told him was BS
Sep 04 13:23:54 is STILL NOT CHECKED
Sep 04 13:24:22 Kraparoto banned me from all the chans he is op as soon as I exposed him
Sep 04 13:24:27 how mature of him eh ?
Sep 04 13:25:22 so not only he is an incompetent whining kid, but he also totally lacks maturity
Sep 04 13:25:28 so I am done with the stupid drama
Sep 04 13:25:32 or talking to him
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!!! ^^
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");
// 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;
// KDSBest Payload
// Prepare for our Syscall