The supposed SPRX theory and why it's wrong.

[xPreatorianx]

First of all, I might of put this in the wrong section and for that I apologize. Second, I'm putting this here in an effort to destroy all the misinformation going around from the rest of the forums and some members here. Hopefully Gary will come in and reaffirm this topic so people do know I'm telling the truth.

now yes there was a "news post" or "theory post" up from it. But of course it got locked. Why? Because it was completely wrong and purposed by a known individual that spreads misinformation in an effort to raise his popularity. That is your very first clue that this theory is completely false. Wish it was still up so Gary could have simply put up a message officially stating how bogus it was so people would know. But hopefully he'll do it here.

Anywho, so why is the SPRX theory wrong? Well as all of you should know the PS3 uses keys to encrypt, decrypt, and basically authenticate everything on the system. Games are no exception. The keys required for games are stored in Appldr (IIRC. Or it's isoldr. But I'm 95% sure it's appldr.) Not some "drivers" or otherwise called SPRX. That is the reason why people haven't just taken SPRX from a higher firmware, cracked them, and put them on a 3.55 CFW. It's because they have nothing to do with getting games running. Nothing. Plus it's impossible to do so. That's also the reason why we have never messed with SPRX to date. We have always messed with eboot.bin's which are signed with the keys from Appldr.

Now if you still don't 100% believe that the SPRX theory is total BS, ask yourself two simple questions. Why hasn't someone cracked the SPRX already? Why have we all used eboot.bin's and requested new keys from higher firmwares? It's because SPRX don't have anything to do with getting games to function.

So then why has team ac1d come out with this theory? Well I won't get on this bashing wagon, but just look at how the scene has been up to this point. That should give you a good indication of why. But they are spreading misinformation, that much I will say.

Still don't believe me? Read the PS3devwiki.

EDIT: Please keep this topic clean guys. I'm not wanting to start a flame fest or anything in between. I'm simply trying to correct the misinformation. If this devolves into a flamefest I will request for it to be locked.

[pete_uk]

I know this isn't quite on topic but I noticed something strange with the TB dongle yesterday.
I was having problems getting FBA-Next to run properly on my PS3. With the TB dongle plugged in I was able to launch FBA, but it was crashing as soon as I loaded a ROM. I restarted without the dongle plugged in and I was not able to even launch FBA. All I was getting was a 8001003c error. After googling for a while the only reference to that error was with game updates that require a newer firmware. After speaking to Twinaphex, I remembered that I had installed the 3.60 SDK and used it to compile but I used the fail0verflow 3.55 signing tools.
I didn't think about it until twinaphex said the following:

Yes, I think it's pretty self-explanatory that you can't run apps compiled with the 3.60 SDK on a CFW PS3. That True Blue even ran it at all up to the point where a ROM had to be loaded is surprising.

It turned out that the crashing on loading ROMs was due to a hard coded path in the source and not the fact that it had been compiled with the 360 SDK. Normally on a 3.55 CFW PS3 you would receive the 8001003c error. So trueblue must be doing quite alot of patching and not just of the keys.

I unfortunately deleted this compile of FBA and have swapped back to the 340 SDK. I will reinstall and see if I can replicate this again.

Edit: Just got an anonymous tip: All emulators can be compiled with sdk 3.60 if you modify the sys_proc_param to 3.4

[LiteSoul]

Interesting to say the least, pete_uk

[deank]

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

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.

D

[GaryOPA]

I copied Dean's post from the True Blue thread, and move this to the 'technical section'.

Now the biggest problem with the 'Team Ac1d' crap, is one they have to have the KEYS to do anything.

And second, they talking about ripping out the SPRX from the TB dongle, as if it is big USB drive. -- Problem is it does not have any SPRX's it in.

Dean is right about the library calls and such, and currently what Paradox has been doing is including the needed SPRX's with the game, and any firmware specfic calls in the eboot, patching them to point to the old firmware call.

Lucky for now, the SDK being used by developers is still 3.60 and it does not really have much firmware specific calls compare to 3.55 -- Unless you writing a TV app, when games are running not much in the firmware is loaded, most of the extra stuff is on the disc, which can be patched, IF and going back to IF you have the 'keys'.

[pete_uk]

Thanks for your replies Dean and Gary. Hopefully everyone will now understand why it is not just a case of resigning the Eboots.

[Lethal_NFS]

Wow, this is a very informative thread. Very good read.

[PatrickBatman]

Yeah Dean is right. I remember before ebootmod was released belmondo and mote fixing eboots and then I learned how and then Dean was asking people that knew how to do it to help him so he could build an automated tool (since most people didnt know how to do it manually or take the time to learn) And even back then we used .sprx like Homefront was one of the first fixes i remember where you needed .sprx (like dean said they're signed) and I guess Prea overlooked but even some Paradox fixes for TB have .sprx included ex: Sonic Generations (genesis.sprx) and Need for Speed the run (Engine.BuildInfo_Ps3_Retail.sprx) are two that I can think of currently.

Anyway regardless cant be true like prea said because not every game has .sprx files actually most dont.

[mdd45]

i have a question. If TruBlue team has the ps3 v4.00 sign keys why they dont build a TRUBLUE_CFW_4.00 so that psn is supported and also get support for their product for all ps3 ever sold?

P.S. Is there a tutorial-info on how exactly uncharted 3 got patched so it could be able to boot on cfw 3.55 ?

[Digital-Spooker]

i have a question. If TruBlue team has the ps3 v4.00 sign keys why they dont build a TRUBLUE_CFW_4.00 so that psn is supported and also get support for their product for all ps3 ever sold?

P.S. Is there a tutorial-info on how exactly uncharted 3 got patched so it could be able to boot on cfw 3.55 ?

problem is, they can't make support for all ps3's as, past 3.55 there's checks for the firmware, which is why if there is a new CFW, it will only work for those with a hardware flasher or a 3.55 console.