69w 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)
860 Comments - Go to Forum Thread »
ff_8000000000539F78o
Here you go mate !
FUSE_3.41_3.55_FiX http://ul.to/nge3t5bh...
I don't know about retail though, I only have one and it's already on 3.41 so I rather not touch it, but I didn't see anything that looks like hashes. Flags are there though. (like the product mode flag, QA flag, debug support flag etc etc...) There are also factory informations stored in there (such as the first firmware flashed at factory) but no hash that I could see, though maybe I overlooked something.
Of course the bootloader wouldn't be in any eeprom, lv0 probably starts and talks to syscon through a vuart in order to read the eeprom content (if the hashes are there) and look at the hashes (to compare them to the digests from the other coreos selfs)