Register / Log in

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:

Nothing more.

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!


505 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. http_ftp

    Sorry for my poor English.I am come from China.I would like to know that is there any bug,especially suspend bug,still
    exists? I readlly need permanent patch!

    Thu 25th July, 2013 at 09:21 BST
  2. vLad

    how to fix this? i used almost used all versions of your downgrader.. no luck

    Fri 30th August, 2013 at 07:29 BST
  3. XxGodOfWar2xX

    God I remember testing this…It was so long ago. I barely had internet when I was testing this…I was lucky to even stay connected downloading it! But I will say…This man is a genius, and he deserves all of the respect he can get. I’m still using said 6.20 09g till this day!

    Sun 10th November, 2013 at 08:46 BST
  4. good afte

    file corrupted when running.

    Fri 23rd May, 2014 at 06:58 BST
  5. metal spinning tools

    Hello to every one, it’s really a nice for me to go to
    see this web page, it contains valuable Information.

    Thu 18th September, 2014 at 20:19 BST
« Older Comments

Some HTML is OK

or, reply to this post via trackback.