Talk:ReDRM / Piracy dongles: Difference between revisions
m (→Content: Dongleless resigned/ Final Fantasy XIII-2) |
mNo edit summary |
||
| Line 1: | Line 1: | ||
== another clone == | |||
http://www.jb-infinity.com/infinity_usb/ | |||
== naehrwert : Reversing TB – Part 1: The VM == | == naehrwert : Reversing TB – Part 1: The VM == | ||
source: [http://nwert.wordpress.com/2012/06/02/reversing-tb-part-1-the-vm/ naehrwert : Reversing TB – Part 1: The VM] | source: [http://nwert.wordpress.com/2012/06/02/reversing-tb-part-1-the-vm/ naehrwert : Reversing TB – Part 1: The VM] | ||
Revision as of 13:43, 7 July 2012
another clone
http://www.jb-infinity.com/infinity_usb/
naehrwert : Reversing TB – Part 1: The VM
source: naehrwert : Reversing TB – Part 1: The VM
Thanks to oct0xor we could get our hands on the decrypted TB payload (stage 2). Of course the first thing to do is to fire it up in IDA, our favourite tool of the trade. The entry code of the payload looks like this:
1337C0DE00000000 _start: 1337C0DE00000000 1337C0DE00000000 .set var_58, -0x58 1337C0DE00000000 .set arg_10, 0x10 1337C0DE00000000 1337C0DE00000000 mflr r0 1337C0DE00000004 bl loc_1337C0DE00000008 1337C0DE00000008 1337C0DE00000008 loc_1337C0DE00000008: 1337C0DE00000008 mflr r3 1337C0DE0000000C lis r4, 0 # 8 1337C0DE00000010 addi r4, r4, 8 # 8 1337C0DE00000014 subf. r3, r4, r3 1337C0DE00000018 beq skip_reloc 1337C0DE0000001C li r6, 0 1337C0DE00000020 oris r6, r6, 0x1337 1337C0DE00000024 ori r6, r6, 0xC0DE 1337C0DE00000028 lis r4, 1 # 0xA848 1337C0DE0000002C addi r4, r4, -0x57B8 # 0xA848 1337C0DE00000030 lis r5, 1 # 0x10D18 1337C0DE00000034 addi r5, r5, 0xD18 # 0x10D18 1337C0DE00000038 subf. r5, r4, r5 1337C0DE0000003C beq skip_reloc 1337C0DE00000040 srdi. r5, r5, 3 1337C0DE00000044 mtctr r5 1337C0DE00000048 add r4, r4, r3 1337C0DE0000004C 1337C0DE0000004C reloc_loop: 1337C0DE0000004C ld r5, 0(r4) 1337C0DE00000050 srdi r7, r5, 32 1337C0DE00000054 cmpw r7, r6 1337C0DE00000058 bne skip_rewrite 1337C0DE0000005C clrldi r5, r5, 32 1337C0DE00000060 add r5, r5, r3 1337C0DE00000064 std r5, 0(r4) 1337C0DE00000068 1337C0DE00000068 skip_rewrite: 1337C0DE00000068 addi r4, r4, 8 1337C0DE0000006C bdnz reloc_loop 1337C0DE00000070 1337C0DE00000070 skip_reloc: 1337C0DE00000070 std r0, arg_10(r1) 1337C0DE00000074 stdu r1, -0x80(r1) 1337C0DE00000078 std r2, 0x80+var_58(r1) 1337C0DE0000007C lis r4, 1 # 0x17E40 1337C0DE00000080 addi r4, r4, 0x7E40 # 0x17E40 1337C0DE00000084 add r2, r4, r3 1337C0DE00000088 bl payload_main
In the first loop it will relocate itself using 0x1337C0DE as an identifier for the upper 32 bits and rewrite that to the actual base. The disassembly above was already loaded using 0x1337C0DE00000000 as base. While scrolling through the data section at the end of the payload one quickly figures out that the RTOC is 0x1337C0DE00017E40.
As I was analyzing the code I found a sub that was basically just a really big switch with random looking case values. Once I reversed the sub at 0x1337C0DE00002578 and some of the following ones and analyzed their usage in the switch sub, I knew that I was looking at a fricking virtual machine.
1337C0DE00002578 vm_push_word_0: 1337C0DE00002578 ld r11, off_1337C0DE00010128 # stack_ptr 1337C0DE0000257C ld r9, 0(r11) 1337C0DE00002580 addi r0, r9, 4 1337C0DE00002584 std r0, 0(r11) 1337C0DE00002588 stw r3, 4(r9) 1337C0DE0000258C blr
Paranoid TB developers even used XOR-tables to obfuscate the VM instructions and data. The virtual machine is mostly stack based but the instructions let you work using registers too. The next thing to do is to reverse all the instructions and write a disassembler and emulator. Here is some code to unscramble the embeded vm binary for further investigation. I’m going to write more about this topic in the future.
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 | ||
| Final Fantasy XIII-2 | 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:
- 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
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?