Im sure everyone by now knows of TeaM AC1D and their work on the PS3, their claims of knowing how True Blue Works, their discussion about SPRX’s etc, you can find the discussion here.
True Blue respond to those claims with this statement:
Recently we have been made aware of several announcements made on various forums from people who seek to trivialise the capabilities of True Blue and claim that functionality such as playing 3.6+ games can easily be reproduced on regular custom firmware (CFW).
In each and every case, the announcements amount to nothing more than baseless accusations and disinformation – these people are intentionally spreading information they know to be incorrect in an attempt to create confusion. A lot of effort and research has gone into the creation of True Blue, which has allowed us to take our position as the ONLY team producing any real results, providing solid support and benefits for our customers. For all the people who have claimed that what True Blue does is trivial and can be easily duplicated, there has been absolutely nothing that has come from any of these peopole, they have simply been all talk and have delivered nothing of real value.
The proof is in the result and at the end of the day, with all the claims that have been made by other groups, the fact remains that the True Blue team are the only ones who have actually delivered.
Now “The Scene Donkey” tries to rubbish TeaM AC1D’s claims with his usual babble, pretending he knows what he is talking about, so he makes a thread, on his home forum stating this:
The supposed SPRX theory and why it’s wrong.
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.
Now the most ironic thing, is the last sentence, when PS3 Dev Wiki posted that they had dumped True Blue dongle, the “Scene Donkey” said it was all lies and stated that everything that was on PS3 Dev Wiki was false and lies, anyhow enough of my mini rant, on to the main story.
PS3 Developer deank replied to that thread, basically teaching the “Scene Donkey” right from wrong, this is what he states, deank in blue text, the “Scene Donkey” in pink text.
”Originally Posted by “Scene Donkey”
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.
”Originally Posted by “Scene Donkey”
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
The True Blue and the “Scene Donkey”/deank discussion can be found at PS3Crunch
So there you have it from every side, your decision to believe who you want, i hope it has been a good read 
