Thread: DeanK speaks about SPRX theory

For devs only? Maybe not. That´s why I decided to post here.

+rep if heplful.

Originally Posted by xPreatorianx
There isn't anything to the SPRX theory. It doesn't take TB to tell you. Hell open up the PS3devwiki. Anyone who knows ANYTHING about how the PS3 works, knows SPRX don't have anything to do with running games on the system. Everything pertaining to games is controlled through Appldr and keys. Not SPRX. Otherwise games would ship with SPRX that contain the keys, in which case we would already have them.

Seriously, have we ever patched SPRX to run games? No? That's your answer. SPRX don't have a damn thing to do with it. .

Actually that's not entirely true. Anyone who knows anything about programming (pc/mac *nix ps2/ps3) would spot discrepancies. I'll try to put a very noob-friendly explanation below.

We can drop the big-*** words like SPRX/SELF/EBOOT.BIN and just use "executables" (selfs/elfs/eboot.bins) and "libraries/modules" (sprx/prx). To make it even easier to understand one can think of the executables as "EXE" and the libraries/modules as "DLL" in the windows environment.

Anyway, when talking about the SPRX you may have to differentiate GAME sprx files and FIRMWARE sprx files, because they are a bit different, because of the way they're used.

Originally Posted by xPreatorianx
Seriously, have we ever patched SPRX to run games? No? That's your answer. SPRX don't have a damn thing to do with it.

Yes, we did - even the ebootFIX / ebootMOD applications process all game sprx+self+eboot.bin files - otherwise nothing would work. Since you can think of a game sprx file as a DLL, it is just a number of functions exported in a separate file, so you don't have to load all of them along with your executable (EBOOT.BIN or blabla.exe). Whenever you need a function from the (sprx/dll) library - you load the library, call the function and unload the library. That's all about the game sprx files.

The firmware sprx files... The explanation above can be used for these too, but the main difference is that all applications use these system-wide libraries. It could be games, the video player, the PS Store application or the photo-album slideshow. So each of these applications would at one point load a firmware sprx/library because they need its functions (to access files and folders, to access the network, to process jpg/png images, to read/mount/use psarc archives).

Let's for a moment forget about keys and encryption, and focus on firmwares and the differences between the libraries/sprx.

We have a console (we name it THE_BOX), running firmware version 3 and we create an application for it, which prints a fancy text on screen. Such imaginary application will look like this:

Load system module: lib_screen.sprx (so we can use its functions)
Load system module: lib_text.sprx
Initialize screen: using init_screen(1920, 1080, 3D) function from system library lib_screen.sprx)
Draw fancy text: using draw_text(x, y, "Hello World", red_color, vertically, with_water_effect) from system library lib_text.sprx
Wait for 30 seconds and exit

So we test our cool app on firmware version 3 and everything works as expected: a nice text is drawn in fullHD in 3D mode and has a nice water shader applied to it, so it really looks like made of water.

By accident we have a second console (THE_BOX_2), running firmware version 1 (rather old, but we need to test nonetheless). We load our cool app and launch it then we get:

* Black screen or
* Not so cool looking "Hello World" text in 2D, horizontally and not vertically, with the dull gray color and no effects applied).

What happened?!

We know that THE_BOX_2 is running an older version of the firmware and PROBABLY (most definitely) some internal/system modules are quite different. After a later investigation we find that the firmware version 1 has these two sprx libraries, but they provide much limited functionality:

* init_screen(1920, 1080) (it is missing the 2d/3d parameter)
* draw_text(x, y, "Hello World") (no extended parameters)

It is pure miracle that our sample app even started on that OLD firmware version 1 and produced any results at all.

That should explain why FIRMWARE LIBRARIES (SPRX in the PS3) may affect games, performance and compatibility.

Now back to the reality. Back in the day (and even at the moment) there are games released for firmwares beyond 3.55, but we were still able to play them on 3.55. In most of these cases the games didn't require nor used any special functions presented in the system libraries/modules of the newer firmware. Luckily even now with the PS3 firmware 4.00 there are games, which use the same functions that are available in the modules/sprx of FW 3.41-3.55.

So let's say we have the keys and the game in question doesn't use any of the firmware 4.0 functions - we process our 4.0 game with some tools and we get decrypted (from 4.0) + changed + encrypted/signed (for 3.55) all the eboot.bin/self/sprx fiels. Profit. Game works on 3.55.

Now we find another game and apply the same steps as above. But it happens that that particular game (like most that will follow) actually uses the NEW functions provided by the NEW modules/sprx files in the new firmware 4.0. We test that game and we find that it either doesn't start at all (black screen) or starts with major glitches, locks after 2mins, etc. etc.

So we decide to make everything right. Since we're really experienced, we're going to find what SYSTEM modules from fw 4.0 that particular game requires. It is obvious that our 'stock' sprx files miss some functions and we have to find a way to add them or just use the newer module (hoping it won't brake any other app installed on your loved ps3). We start looking at the game executables (eboot.bin/self) and game libraries (sprx) to find what modules are used. Of course these are not listed in plain text and most of the time you may not even see anything readable, but you'll have to find the actual assembler functions which call for loading system modules with specific IDs. After couple of days/weeks we find all of the module IDs, so now we know which modules need to be replaced or further edited (because the usually call/use functions from OTHER system modules).

Once we're absolutely sure we've got all that right, we sign (and encrypt if desired) the files for our THE_BOX_2 console (running the older firmware) and we enjoy the result.

Now back to the keys. Since the "S" in SPRX and SELF means "Signed" one must find a way to remove the protection of these system sprx files, of the game sprx/self/eboot.bin files and then work with their contents. Once you finish, you sign them again for your desired firmware with the desired keys (be it for 3.41, 3.55 or 4.0).

That's about it.

I don't own a TB dongle and the reason I posted this wall of text is to present a REALLY SIMPLIFIED explanation of what one may have to do EVEN if he has the keys for 4.0 firmware.

Not to dare or challenge anyone, but all of you have the opportunity to prove yourself by installing firmware 3.15 to your PS3 and then try to process UNCHARTED 3 to work on it. Basically everything is the same. If you can make UC3 to work on FW 3.15 - you're a hero and the scene will love you.

I hope it wasn't boring for you to read all that, but as a programmer and as someone who watched and learned I decided to clarify something that "anyone" should know.

SOURCE: True Blue (aka) JB2 - Answers Recent Rumors - Page 364

+Rep for you.

I understood everything perfectly except for the words........................

I'm off to have an ice cream (summertime here!!)

so does this mean there aren't any new modules/functions past 3.55? this means all the games upto 4.00 can be decrypted(if the keys are acquired) and be used on our 3.55 except for vita compatibilities

That´s what I understood too. I just could not figure out how can Games like Uncharted 3 be decrypted... what does it mean, somebody has the keys?

my guess is uc3 eboot leaked from sony. this is the only eboot that is left without proof how it was out

The thing is, even if TB really had decrypted .sprx files of firmware or the game itself, and modified them or not, I STILL don't see how did they manage to launch games, without debug eboots(or 4.00 keys) of course(which are unencrypted).
What I'm implying? Even if you make a firmware capable of launching TB eboots making use of .sprx files, you are still not capable of fixing games, which renders all the work useless.
I said it once in another thread already, but I prefer playing games, not waiting for someone to figure something out. TB provides games, and all of you provide WALLS of text, no solutions.
If you want to beat TB - you need to make something like a 3.60+ eboot decryption programm, so there's no need for TB eboots to play games. Can't? Well, then don't make the situation worser by pissing off TB, cause they'll release some new games soon.

now i got it !!

I actually understood that, good post. +rep

Hmm maybe he has sold out to TB after all. Trying to throw us all off the scent to protect his investment maybe?

+rep as I was thinking but after reading this more thing clear and new things come in my mind to be honest this article is not boring.

I read such a long article full first time because as a programming I can understand what exactly he wanted to say.