These are probably used for PSP GO models. The PSP now supports NAND's from Samsung, Toshiba, ST Micro, and Hynix.

After searching for any new supported resolutions for the LCD controller I found a strange one (added in 6.xx):

Don't know why it is missing one single row from the usual 720x480 resolution.

Here's the full list of supported resolutions:

If you are wondering how the PSP can support resolutions higher than it's native screen resolution of 480x272, it's because the LCD controller needs to support PSP devkits as well which have VGA output to connect to an external LCD monitor.

However, the sceKernelGetModel function can do a lot more than just determining whether you're running fat or slim PSP, it can return values for:

That's three more models after the PSP GO! As well as a 4000 model after 3000.

The fw for 04g models is already out, it's included with normal fw updaters (6.xx) and can be decrypted using the 3K keys. There's also code already in the fw supporting 06g and 08g models (which seem to be GO-like models).

So for people thinking the PSP GO was a waste of a update or there wouldn't be any more updates, prepare for three more models...

New registry categories/keys stored in flash1 registry (6.xx fw):

These new registry keys can still be accessed via the sceReg API, sceRegOpenCategory/sceRegGetKeyValue etc.

What other things will they be tracking in future updates? Maybe logging ISO games? Secretly 'phoning-home' with this info? Was any of this mentioned in the EULA?

Rest In Peace, Snowy. I'll always love you and I'll never forget you. You will be dearly missed...

As the vshbridge.prx is loaded and starts, two fixed memory pools are created and used for nothing else but random padding. The size of these mem pools are randomly assigned based on the system time. This can therefore affect the memory addresses of where modules are loaded into ram and therefore affect the hardcoded addresses the TIFF exploit relies on.

The code for the random memory padding (executed on vshbridge module_start):

This bit of random padding code was added in 2.50 firmware and still exists in the latest firmwares.

Because HEN uses the TIFF exploit to run there is nothing the HEN could do to improve it's chances of booting successfully. It may be that it's simply random luck.

Note: there is no doubt there are also many other factors which could affect the stability of the TIFF "eggsploit".

This feature was never documented by Sony but it has existed ever since the very first firmware v1.00. Sony typically used this feature to send personalised PSP's as gifts to VIP's. Now you can make your own personalised PSP too.

I've realised that there has been many bits & pieces of info that I have posted around in several different places over the years (in forums etc.) that are useful however not conveniently accessible so I'll be adding them here also. It may seem redundant since it may not necessarily be new info, however gathering all the public info together into one place will make the info more accessible to the people.

So, greets to all those who still continue to follow and be involved with the PSP community even though the PSP has passed its peak and now entering a declining stage.

SilverSpring

• 0x84a04017 sceUtilsGetLoadModuleCLength
• 0xa86d5005 sceUtilsGetLoadModuleCLengthByPolling
• 0xa4547df1 sceUtilsGetLoadModuleDLength
• 0x94eb1072 sceUtilsGetLoadModuleDLengthByPolling
• 0x198fd3be sceUtilsGetLoadModuleILength
• 0xfbc694c7 sceUtilsGetLoadModuleILengthByPolling
• 0x07e152be sceUtilsGetLoadModuleJLength
• 0x9906f33a sceUtilsGetLoadModuleJLengthByPolling
• 0x46ac0e78 sceUtilsGetLoadModuleKLength
• 0x55c8785e sceUtilsGetLoadModuleKLengthByPolling
• 0x67a5ecdf sceUtilsGetLoadModuleLLength
• 0x85b9d9f3 sceUtilsGetLoadModuleLLengthByPolling
• 0x951f4a5b sceUtilsGetLoadModuleMLength
• 0x58999d8e sceUtilsGetLoadModuleMLengthByPolling
• 0x9fc926a0 sceUtilsGetLoadModuleNLength
• 0x7a922276 sceUtilsGetLoadModuleNLengthByPolling

As you can see the naming is very cryptic, but the names do make a little bit of sense (more than some other crypto functions & libs). Each of these functions decrypts a particular ~PSP encrypted executable. The executable type is at offset 0x7C of a ~PSP file, and the executable type number corresponds to the letter listed in the above functions. For example, Type3 exe's (vshmain modules) use the 'C' function to decrypt, Type4 exe's (user modules) use the 'D' function, etc. There are no types 5,6,7,8 exe's so those letters are missing. Other exe types that use the above functions include:

• Type09 UMD games (use 'I' to decrypt)
• Type10 Gamesharing games (use 'J' to decrypt)
• Type11 Debug Gamesharing games (use 'K' to decrypt)
• Type12 MS Updater (use 'L' to decrypt)
• Type13 MS Demo games (use 'M' to decrypt)
• Type14 Flash application eboots (use 'N' to decrypt)

Later fw added extra exe types also (such as POPS executables - Type20). So as you can see the numbering of the executable type corresponds to the letter of the alphabet used in the decryption functions naming.

Type1 exe's are internal debug modules while Type2 exe's are kernel modules, they are both decrypted the same way hence the 'A' and 'B' in the function sceUtilsGetLoadModuleABLength of memlmd.prx.

Here are also 2 more NID's from memlmd (these ONLY exist in 2.00 which was when these functions were added into the fw, they were later 'randomised' the following update in 2.50):

• 0xc3a6f784 sceUtilsPrepareGetLoadModuleABLength
• 0xdf76975e sceUtilsPrepareGetLoadModuleABLengthByPolling

This function is similar to the 'sigcheck' functions in that they take an encrypted ~PSP file and 'scrambles' the 'sig' area (0xD0 Bytes from offset 0x80-0x150 of ~PSP binaries). The only difference is that this scrambling is not unique per PSP, whereas the normal sigchecking IS unique per PSP (using each PSP's FuseID to flash the unique prxs, which is why files from different PSP's are not compatible and therefore cannot be shared).

• 0x739c2d79 sceHttpInitExternalCache
• 0xa461a167 sceHttpEndExternalCache
• 0x8046e250 sceHttpEnableExternalCache
• 0xb0257723 sceHttpFlushExternalCache
• 0x457d221d sceHttpFlushCookie
• 0x4e4a284a sceHttpCloneTemplate

From sceSsl:

• 0xf57765d3 sceSslGetKeyUsage

From sceLibUpdateDL (this completes the lib !!):

• 0xf7e66cb4 sceUpdateDownloadSetUrl
• 0x88ff3935 sceUpdateDownloadSetDestCode

From sceNetWispr (this completes the lib !!):

• 0xc856aaac sceNetWisprLogoffStart

From sceNetIfhandle_driver:

• 0xd5ad6dea sceNetGetIfhandleOpt
• 0xc6d14282 sceNetSetIfhandleOpt
• 0x955f2924 sceNetMCopypacket

From sceNetAdhocctl (new in 5.00):

• 0xb0b80e80 sceNetAdhocctlCreateEnterGameModeMin

From sceDNASCore_lib (this completes the lib !!):

• 0xba0d27f8 sceDNASCoreMakeProxyRequest

From sceVshNetconfAoss:

• 0x50df536d sceNetAOSSInit
• 0xd253b522 sceNetAOSSTerm
• 0x653d453f sceNetAOSSStart
• 0xac307152 sceNetAOSSStop
• 0x2aee9d4d sceNetAOSSGetState

From sceLibFont_HV:

• 0x33ffd07c sceFontIsElement

From sceUsbGps (new in 5.00):

• 0x5881c826 sceUsbGpsGetStaticNavMode
• 0xa8ed0bc2 sceUsbGpsSetStaticNavMode

From scePafHeaparea:

• 0xf50aae41 sce_paf_private_getheaparea1
• 0xacce25b2 sce_paf_private_getheaparea2