As an ongoing project, me and some1 have been enhancing this downgrader from birth on the 6.31/6.35 firmwares. This multi-firmware downgrader allows you to install a lower (or higher) firmware without any fuss. No complex flash0 sharing, just running the firmware update.
However, there comes restriction with PSP models and compatible firmware. For example, a PSPgo cannot run 1.50 as there are no drivers for the system and the IPL format is incompatible. Much like this, the PSP 3000 09g is unable to install firmwares < 6.30 which removes it’s ability to appreciate the flexibility of permanent custom firmware.
This is no longer the case.
It started off with rumours of 09g systems being “converted” to 04g systems with some sort of Sony equipment. I explored the firmware comparing 04g and 09g and there is little difference between the modules, so I looked into what makes a 04g and 09g different. I got various testers (named below) to give me information on their IDStorage and internal system data (baryon/tachyon). From this I can conclude that the only (effective) difference between a 04g and 09g is:
Now, it was time to see what it did with these values. I looked up the Idstorage certificates, it’s used in Chkreg and used internally to generate a model number. I found out that 6.20 and 6.39 sets the model of 09g to 04g, lovely.
The big game was the value that is returned from sceKernelGetModel(). Where is this taken from? Well, rooting back from the IPL, there is some code used to determine the model. This code used some strange code which turned out to be syscon code to obtain the Baryon version! The model number is determined from the Baryon.
Here is a little explanation of the Baryon version. When shifted 16 bits to the left, the least significant byte is the data used to determine a model number. the most significant nybble contains the SKU (PHAT, SLIM/3000, GO) and the lower specifies the model of that SKU. However, it got me thinking… Sony don’t know how many revision they will produce in the future. Checking 6.39 firmware, Sony does this: [0x2C -> 0x2E] = 04g, [0x2E -> 0x30] = 09g. Rightfully so, the Baryon version from the 04g’s I had was 0x2C and the 09g had 0x2E. Then i though, if they didn’t know the future, then what does 6.20 IPL do? After analysing I found this: [0x2C -> 0x30] = 04g.
So, if for some reason you find your 09g on 6.20, the IPL is gonna think it is a 04g. Ok, we can work with that, Chkreg sets the certificate based model to 04g and the IPL sets Baryon based model to 04g. Now, lets get some 04g firmware in there!
After a bit of thought, I was sitting at the Downgrader source thinking “how can I install 6.20 on a 09g”. Obviously, run the update and spoof the model. However, changing sceKernelGetModel() did nothing. The model must be determined by some other way. So, 123 and I find Baryon code, yay. Once again, the 6.20 updater has the 09g Baryon as a 04g so if it could run on it’s own, it will flash 04g modules. But why did it error?
IDXFFFFFFFF. That’s the error, it’s to do with error opening INDEX.dat. Wait, a second, why is this happening? Oh wait, it thinks it’s a 04g, so it’s looking for index_04g.dat, doh!
Now, we got a new error. This is weird, it originates from a module called “sceChkuppkg”. Heh, cool. After a brief look at the internals a wild idstorage certificate check appeared. It checked a PSAR block against a list of data composing a PSCode. Easy fix, now the 6.20 could run. Once it had run, it rebooted.
Then it bricked.
Yes i fucked up. By only hooking the usermode version of “sceChkuppkg” caused the updater to validate the blocks until it started to do something important… like read the rest of the firmware after wiping flash clean. Everybody, thank “Gamefreeak100″ for the first brave and bold steps into a 09g permanent patch world, he sacrificed his PSP for it.
A lot of reading later, I identified the problem, fixed it and handed it to another brave tester. This time, it worked! 09g was running firmware 6.20 and for the last 12-ish hours it has been running fine. It retains the ability to update to >= 6.30 and seems very stable!
A word of advice though, this is still experimental. The idstorage certificates do NOT belong to a 04g PSP and upgrading and downgrading from
This would not be possible without the combined efforts of:
Give them all thanks! Leave a comment if you think you should be here!
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.