Talk:ReDRM / Piracy dongles: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
Line 5: Line 5:
Q: Are they (TB team) just stealing the dev eboots? <br />
Q: Are they (TB team) just stealing the dev eboots? <br />
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). <br />
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). <br />
Q: Is it possible that they (TB team) have an FPGA setup to read the PS3's RAM, upgraded the PS3 to the latest FW and dumped the RAM after the PS3 loads a game. Then extracting decrypted EBOOT.BIN from the RAM dump?


=== Content ===
=== Content ===

Revision as of 11:22, 26 April 2012

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).

Q: Is it possible that they (TB team) have an FPGA setup to read the PS3's RAM, upgraded the PS3 to the latest FW and dumped the RAM after the PS3 loads a game. Then extracting decrypted EBOOT.BIN from the RAM dump?

Content

Title PARADOX
PARADiSO
Disc Dongleless
resigned
'Kind Of' Notes
Air Conflicts: Secret Wars Yes Yes
Alice Madness Returns Yes Yes Yes
Assassins Creed Revelations Yes Yes Yes
Atelie Totori The Adventurer of Arland Yes Yes Yes
Atelier Meruru The Apprentice of Arland Yes Yes Yes
Batman Arkham City Yes Yes Yes
Bleach Soul Resurreccion Yes Yes Yes
Bodycount Yes Yes Yes
Cabelas Big Game Hunter 2012 Yes Yes Yes
Call of Duty Modern Warfare 3 Yes Yes Yes
Call of Juarez: The Cartel Yes Yes Yes
Captain America Super Soldier Yes Yes Yes
Cars 2 Yes Yes
Catherine Yes Yes Yes
Child of Eden Yes Yes Yes
Dance! It’s your Stage Yes Yes
Dark Souls Yes Yes Yes
Dead Island Yes Yes Yes
Deus Ex Human Revolution Yes Yes Yes
Dirt 3 Yes Yes Yes
Disgaea 4 A Promise Unforgotten Yes Yes Yes
Dragon Ball Z Ultimate Tenkaichi Yes Yes Yes
Driver San Francisco Yes Yes Yes
Dungeon Siege 3 Yes Yes Yes
Dynasty Warriors Gundam 3 Yes Yes Yes
F1 2011 Yes Yes Yes
F.E.A.R. 3 Yes Yes Yes
FIFA 12 Yes Yes Yes
God of War Origins Collection Yes Yes Yes
Goldeneye 007 Reloaded Yes Yes Yes
Green Lantern: Rise of the Manhunters Yes Yes Yes
Harry Potter And The Deathly Hallows Part 2 Yes Yes Yes
Kidou Senshi Gundam Extreme Yes Yes Yes
Kung Fu Panda 2 Yes Yes Yes
Lego Pirates of the Caribbean Yes Yes Yes
Lord of the Rings War in the North Yes Yes Yes
Madden NFL 12 Yes Yes Yes
Monkey Island Collection Special Edition Yes Yes
NBA 2K12 Yes Yes Yes
NCAA Football 12 Yes Yes
Need for Speed The_Run Yes Yes Yes
No More Heroes: Heroes Paradise Yes Yes Yes
Portal 2 Yes Yes Yes
Pro Evolution Soccer 12 Yes Yes Yes
Rage Yes Yes Yes
Ratchet & Clank All 4 One Yes Yes Yes
Rayman Origins Yes Yes Yes
Record of Agarest War Zero Yes Yes Yes
Red Faction Armageddon Yes Yes Yes
Resistance 3 Yes Yes Yes
Rune Factory Tides of Destiny Yes Yes Yes
Saint Seiya Senki Yes Yes Yes
Saints Row the Third Yes Yes Yes
Sengoku Musou 3 Empires Yes Yes Yes
Shadow Of The Damned Yes Yes Yes
Sniper Ghost Warrior Yes Yes Yes
Sonic Generations Yes Yes Yes
Spider-Man Edge of Time Yes Yes Yes
Super Street Fighter IV Arcade Edition Yes Yes Yes
Supremacy MMA Yes Yes Yes
Tales of Xillia Yes Yes Yes
The Cursed Crusade Yes Yes Yes
The Elder Scrolls V Skyrim (+update) Yes Yes Yes
The Idolmaster 2 Yes Yes Yes
The King Of Fighters 13 Yes Yes Yes
Thor God of Thunder Yes Yes
Ultimate Marvel vs Capcom 3 Yes Yes Yes
Warhammer 40000 Space Marine Yes Yes Yes
White Knight Chronicles II Yes Yes Yes
X-Man Destiny Yes Yes Yes
WWE '12 Yes Yes Yes

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

stupid newssites

For some reason newssites ([1]/[2] like to be trolled or troll themselves (maybe because they profit from selling these IP-stealing reDRM dongles):

How to use it:
If you attend to downgrade 3.56+ console and use TB dongle after that then 
use this steps (if you already at Rogero CFW V2.0 do the same steps also):
- Dump your NOR flash using Progskeet first if you didn't have a good dump from your console.
- Download patch file attached to this thread.
- Extract this file and you will get 4 folders use patch in folder "Coba_2" to patch your dump using WinSkeet.
- Apply this patch to your dump then flash it to your console.
- Enter a Factory Service Mode using any method you like.
- Use TB CFW with Lv2diag.self to flash your TB CFW in FSM.
- Start your console normally, if it brick just dump this NOR flash again then patch again using "Coba_2" patch.
- If it still bricked use "Coba_3" patch to patch your dump again then flash it back to your console.
- Start console normally, now your console can run TB CFW on downgraded console.
- Power off your console, plug your TB Dongle then power it on again and enjoy . 

Credit goes to Kado for this patch
Also a very big thanks goes to:
Abkarino (Me kado gives me this not me),nice69, uf6667, rogero,muggi, eusnl, ago, and all ppl.

Hot Tip:
For every one interested just look at patch2 file it is and empty coreos file with only part of lv0 modified to do this trick 

There are many wrongs in above statements:

  • It is not related to TrueBlue/Cobra, but to installing unmodified (no downgrader patched lv1.self) firmwares on downgraded consoles (which thus have syscon hashes at 3.56+)
  • There is no lv0 modified in the patch files, the data still there is just author lazyness
  • It can be done so much simpler by just using 3 files and even less stages (mentioned on Downgrader talkpage)
<eussNL> kado ?? <eussNL> ROS empty until 366770 <Abkarino> yea, this is what kado said to me : this is an offset for a modified lv0
<kado> eussNL: yes thats not lv0, thats lv2kernel took from rogero 
<eussNL> ok, so leftover from FSM
<kado> yup
<eussNL> in that case I was correct in my assumption "<eussNL> btw the unreferenced ros area is not lv0, but leftover from lv2_kernel.self"

So much for the trial to make the world believe the lie that they pwned lv0 ;)

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?