98w ago - As a follow-up on our previous article with the spirit of Operation: Mongoose in mind, we are continuing to examine both the Cobra and True Blue PS3 DRM-infected dongles and TB EBOOT files, and welcome any help with this project from other PlayStation 3 developers in the scene!
First let me tell you the following explanation is not a theory or any rumors, it's actually how the USB dongles work to allow different things.
We heard many rumors / theories about the process of the Cobra / True Blue but I didn't see anyone give any big answer about that (I'm not saying I would give you the big answer but the explanation how it works and how to make this possible)
Cobra / True Blue Part 1
Both dongle use syscall / payload (after a big investigation, both dongle also follow the work of graf_chokolo and the functionality of the dongle can be ported into a CFW (not a good idea from some devs I guess)
Cobra / True Blue use a lv1_wrapper (syscall implementation) that can allow to use subroutine function into kernel mode call. Following the dump of the Cobra / True Blue, every subroutine are indicated inside the dump (probably the reason of some clone like JB-King)
What all this mean ?
About the TB Eboot, i come back on what i said recently, the TB Eboot come from original Eboot (don't make any sense that they access to the dev server when have not Eboot on it) the PSN dev don't exist this way... but for related beta development games and testing beta multiplayer mode, interface beta test PSN for games etc... but nothing related to a Eboot.
TB use original Eboot and make their own sign (you can easily generate a new NPDRM sign with a Self/elf)
How can boot the games, the NPDRM Sign made in TB can't be run into a user mode, you would have a error of boot and every program that you resign etc... will not boot into a usermode... that's why we need to use a syscall that can let use into a kernel mode to execute a program that not recognized and authorized by the system. The dongle validates the actual eboot by syscall / subroutine.
For example, I want to have a execute something into the CoreOS but I'm not allowed because I can only execute this on a kernel mode, fine, I use my actual user mode to turn into a kernel mode by using a syscall.
A Syscall can allow you to execute, create, read, load, etc... The limitation of a dongle = the PS3 system, a dongle it's only here to prevent a error that by using redirection and syscall, the dongle give a correct answer that PS3 system execute.
If you check correctly the dump you can see 0x80 -> correspond to the C library, also when you call into kernel mode, the kernel fix the table permission that allow to give big access. You can recognized r1 stack register -> 0xA0 (debugger mode) -> R2 stack status...
Ok you probably gonna ask, what is that ? lol
It's actually a schema / plan from the dongle, the dongle is here to give a strong access to the system that you can execute what you want.
For example the PS2 Emu of Cobra = PS2 self (is not executed into a user mode but kernel mode / debugger mode that) reason why it can be execute under a PS3 Slim retail without following an error system.
How this can help ?
This mean many things, that you don't need any keys to execute under a kernel / debugger mode because anyway the syscall will give you a whole access to the cell execution.
I want to give a simply explanation that everybody can understand, the TB EBoot = Original Eboot from Original game, we not interested by the sce header, etc... we only want the elf header program represent and related to the game execution (like a exe, you patch the exe to be run without cd) here almost the same, we patch the elf with a fake sign can be run into a specific mode without asking anything.
What is weird, graf gave many oriented possibility and no one try to exploit them but only in a business way. Anyway like I said, the dongle is in relation with the PS3 system/Dev_Flash/Core_OS
I'm also working on it and try to do my best to release something strong and free... but my knowledge is limited and I can't do that alone.
Why I explain all that, it's because I want to see also some good dev can work on it with me, actually I want to thanks graf for all this awesome stuff, cfwprophet and all the PS3 scene that support us, I say also thanks to the people who insult me and said I'm a fake... more you said that and more I don't care and offer good stuff
Somebody said he want to be fame, no at all... I don't really care, my family and my gf give me already that by supporting me, it's enough
Anyway I would like this project to encourage PS3 homebrew developers to help out if they can, and also for the work that cfwprophet, me and others are doing on it will be updated here periodically.
PS: Probably go have more explanation and more stuff about it in the next week. Oh yes about the Debug PKG that is available on PSN Dev (it's not related to the TB Eboot)
You can make a Debug PKG yourself by only extracting the ELF, make a Self without NPDRM, leave him Eboot.self and make a PKG without NPDRM, this represent exactly what is a debug PKG (it's a standard Self inside a PKG without NPDRM)
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!
i have a true blue will do my best to get a dump for you to proceed where we were stuck for a long time but no it seems like we are going uphill again thanks shadoxi for starting this elf dumper , amazing work cheers triple thumbs up
Then we know the section headers start at 0x17EC228
Last section STRTAB:
ELF64 Section Headers:
Idx Name Type Flags Address Offset Size ES Align LK
029 0001 STRTAB --- 00000000 017EC0F7 0000012C 0000 00000001 000
So elf ends at 0x17EC0F7 + 0x12C. We add padding to 0x17EC228, and insert clean elf64 section headerd dump from original eboot.bin, right? Or does this dump ELF+section headers+some extra stuff we can cut off?
Anybody care to post a dumped elf (raw, with this tool) so i can look at it?
Following up on the previous update, today I am releasing my True Blue USB dongle PS3 ELF dumper which works with any PlayStation 3 Firmware greater than 3.56 to dump the encrypted TB EBOOT / ELF files once they are loaded.
Original 355 -> ok
True Blue CFW v2 -> ok
There are some bugs (size of dump ...) but it works. It's ELF dumper from memory and it work with True Blue cfw v2 and any 3.55 firmware because it doesn't use lv2 peek/poke.
Warning: It will not brick your ps3. But I am not responsible for any damage.
Enable dev_blind with multiman
copy libsysutil_np_trophy.sprx from /dev_blind/sys/external/external to dev_hdd0/ and rename it "orignal_libsysutil_np_trophy.sprx"
copy my modified "libsysutil_np_trophy.sprx" to /dev_blind/sys/external/
load a True blue game from multiman
run your game
wait few minutes (if you get black screen after 3 minutes reboot ps3)
go to ftp
in dev_hdd0/ there are your decrypted DUMPEDBOOT.bin
copy and rename it with another name.
Howto uninstall patch - Two ways:
You could uninstall this patch by replacing modified libsysutil_np_trophy.sprx by orginal libsysutil_np_trophy.sprx
Or update in recovery mode
Thanks to: Ps3dev
1 - Install TB ELF Dumper first as stated in its readme file.
2 - Start Multiman, it will make a dump of multiman eboots, so you must delete it first by browsing to dev_hdd0 then delete all DUMPEDEBOOT.BIN files you found there.
3 - Back to multiman game selection then select any TB game then launch it.
4 - Start the game from XMB then wait for some times until game start.
5 - Exit game now then start multiman again then browse to dev_hdd0 and now you must found a decrypted game dump.
From PlayStation 3 developer deank (via pastebin.com/avcM5iuU) comes a revision as follows:
write_message("Dumping ELF from RAM...\n");
uint64_t ptr= 0x00010000ULL; //ELF offset in RAM;
uint64_t sizeelf = 35*1024*1024; //Need a way to get size of ELF
for(uint8_t i=0; i