Talk:ReDRM / Piracy dongles
Q&A
Q: Is this posible on other dongles from the FW3.41 days like Blackcat and Teensy?
A: Dongles are bad and obsolete, mkay :P (once you have the key/algo, you don't need any dongle at all)
Q: Are they (TB team) just stealing the dev eboots?
A: You can only rumor which source they use to resign the content to lock-in their DRM. But ofcourse those very same DRM-less files can be resigned for 3.55 too (as has been done numerous times in the past). Piracy is bad, but pirates using DRM to make sure they get the money and not genuine developpers is even worse (especially when they lock you into a single firmware that has even less to offer than generic MFW and makes you loose OtherOS++ too).
Files to strip
rootfolder, LICDIR + content, TROPDIR + content, USRDIR (EBOOT.BIN + other signed binaries like .SPRX, .sdat)
example (portal_2_BLUS30732) :
|-- ICON0.PNG |-- LICDIR | `-- LIC.DAT |-- PARAM.SFO |-- PIC0.PNG |-- PIC1.PNG |-- PIC2.PNG |-- PS3LOGO.DAT |-- SND0.AT3 |-- TROPDIR | `-- NPWR01719_00 | `-- TROPHY.TRP `-- USRDIR |-- EBOOT.BIN |-- bin | |-- datacache_ps3.sprx | |-- engine_ps3.sprx | |-- filesystem_stdio_ps3.sprx | |-- inputsystem_ps3.sprx | |-- launcher_ps3.sprx | |-- localize_ps3.sprx | |-- materialsystem_ps3.sprx | |-- scenefilecache_ps3.sprx | |-- soundemittersystem_ps3.sprx | |-- steam_api_ps3.sprx | |-- steam_config.sdat | |-- steam_resources.sdat | |-- steamclient_ps3.sprx | |-- studiorender_ps3.sprx | |-- tier0_ps3.sprx | |-- vgui2_ps3.sprx | |-- vguimatsurface_ps3.sprx | |-- vjobs_ps3.sprx | |-- vphysics_ps3.sprx | |-- vscript_ps3.sprx | `-- vstdlib_ps3.sprx `-- portal2 `-- bin |-- client_ps3.sprx |-- matchmaking_ps3.sprx `-- server_ps3.sprx
About USB descriptors
FAKE troll BS
00:27:50 <openTB> Get TB payload.bin 2.3 from wiki dev 00:27:55 <openTB> Get TB dongle-updater.pkg.out 00:28:02 <openTB> Create folder /dev_hdd0/game/BLES80608/USRDIR/payload 00:28:10 <openTB> Copy payload.bin in /dev_hdd0/game/BLES80608/USRDIR/payload 00:28:17 <openTB> Copy TB EBOOT.BIN.elf , EBOOT.bin /dev_hdd0/game/BLES80608/USRDIR/payload 00:28:23 <openTB> EDIT multiman options_default.ini 00:28:30 <openTB> # Load payload (FW 3.55) 00:28:39 <openTB> load_custom_payload=1 00:28:47 <openTB> LOAD Multiman and enjoy TB Games 00:30:02 <McLamer> working on kmeaw or tbfw needed ? 00:31:06 <openTB> normal,, rebug 3.55.2, 00:32:24 <McLamer> done by you or found in somewhere in web ? 00:32:31 <openTB> non need tbfw 00:33:14 <openTB> made by me 00:33:35 <McLamer> sounds great :-) 00:33:43 <McLamer> for what is the updater ? 00:35:37 <openTB> EBOOT.BIN.elf , EBOOT.bin ,, on dongle-updater.pkg.out
Fake proof:
- Though the 2.3 payload upon execution does relocate itself to 0x80000000007f0000 then continue execution, the USB descriptor is still present, at minimum those 0x20 bytes would need to be removed, or accounted for during the initial execute. multiMan has no facility for this.
- The initial EBOOT.BIN.elf does contain the 2MB flash contents for the dongle, BUT that would need to be carefully extracted (and has been, it too is available on the ps3devwiki), again multiMan has no facility for this.
- The creating of the folder and copying the files into it was just to make this fake seem more real with additional steps. multiMan has no code to ever look inside that directory.
- The fact of the matter is that the source code for multiMan was available, and there is NO provisioning in multiMan for "additional" payloads of any kind, the values possible in the .ini file are hard-coded. It is well documented what payloads work with multiMan, and multiMan will only work with those payloads.
You have as much chance loading Windows 9 on the PS3 by using ntldr as payload renamed...
http://pastie.org/private/2dnlv03jlewuyrw9g4he6w
old talk
(seems obsolete and incorrect in many ways)
It seems the ps3jb2 loads masterdiscs with fself, with the algo provided and the right key (which is not provided) you can decrypt said masterdiscs images right on pc and grab the fself files.
// do crypt unsigned char sector_key[16]; memset(sector_key, 0, 16); sector_key[12] = (sector_num & 0xFF000000)>>24; sector_key[13] = (sector_num & 0x00FF0000)>>16; sector_key[14] = (sector_num & 0x0000FF00)>> 8; sector_key[15] = (sector_num & 0x000000FF)>> 0; // encrypt sector aes_context aes_ctx; aes_setkey_enc(&aes_ctx, G_DEBUG_KEY, 128); aes_crypt_cbc(&aes_ctx, AES_ENCRYPT, aligned_size, sector_key, buff, buff); // decrypt aes_context aes_ctx; aes_setkey_dec(&aes_ctx, G_DEBUG_KEY, 128); aes_crypt_cbc(&aes_ctx, AES_DECRYPT, aligned_size, sector_key, buff, buff);
that's the algo for masterdiscs
ps3gen dll has the static keys for masterdiscs
you can also get it from sv_iso
the crappy sdk tool that generates masterdisc images for dex
more talk:
folks I looked a little more and it seems the psjb2 just runs masterdiscs with fself kinda lame very lame npdrm encrypted but labeled as fself it's a fself but I dunno what it does I never looked at it I don't really care on doing more if you use the masterdisc algo I provided and the proper key which I am not supplying you can decrypt all the psjb2 disc images right on pc grab the fself and use them to run them on a regular 3.55 fw basically security == LAME still interesting to see how they patched the firmware to allow masterdiscs they also do some auth with the dongle which involves crypto to make sure the firmware does not load without it but if you don't need the firmware to load the games... they could have added some extra keys in appldr and encrypted the damn eboots at least I guess they didn't have enough time or enough spu skills
Regarding FSELF from "RikuKH3":
Real FSELFs are never encrypted. You can extract it with official unfself tool from SDK. But, in this FSELF I looked into (driver sf) ELF inside IS encrypted. You can say this because it's masterdisc fself, but I really doubt it. It doesn't look like a proper fself to me at all, in header it says that sections unecrypted, but it's not true. Another thing - Masterdisc Generator tool from Sony gives errors with this EBOOT (if it's a masterdisc eboot as stated, why?).
Seems the above from mathieulh may be incorrect and the eboots ARE encrypted. So much for lame security, maybe this wont be so trivial?