My best friend for over 16 years, my loyal companion; deeply loved, and forever missed. You were given a great life yet you gave back so much more in return. I hope you are surrounded by all the toys you could possibly play with, the largest, juiciest bones to chew on, and a neverending stretch of grass to run on.
Rest In Peace, Snowy. I’ll always love you and I’ll never forget you. You will be dearly missed…
So, a lot of people have been complaining about the unstability of the TIFF “eggsploit” (and thus the successful booting of HEN). The exploit relies on hardcoded memory addresses to succeed however a piece of code in the firmware ensures that memory addresses can randomly change.
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”.
After being away from the PSP scene for several months (due to several factors such as illness etc.) I’ve decided to continue and will be starting to add some new content again.
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
The new PSP-3001 model (03g PSP) has been submitted to the FCC for testing:
This means the new PSP-3000 model should hit retail shelves soon. Though there have been plenty of clues for months & months now, from unused nids referencing new hardware devices, a reference to a “03g” model in the IPL, that “3000″ graphic on the official Sony site, and most recently, alleged pics of a prototype.
Now it’s just a matter of waiting for the official announcement and the official list of changes. Hopefully some of the rumours that have been floating around turn out to be true (the hard disk drive comes to mind).
With the new PSP-2000 TA-088v3 model that is out now that is completely Pandora-proof you can bet the PSP-3000 will also be completely Pandora-proof. Im sure there would be plenty of people who would only want to buy a hackable PSP-3000. Though you can be sure that when this new model gets here we will all be looking thoroughly for new hacks for it.
[Waits patiently for the PSP-3000...]
Thanks to Poison for tip.
EDIT: 21st August 2008
Well it seems it has been officially announced now and the current official changelist really is disappointing. Let’s hope there are still more changes yet to be announced. Otherwise, it’s quite a disappointing model (and no doubt Pandora-proof as well). Oh well, won’t stop us from trying to hack it still 
.
EDIT: 15th October 2008
Now that the PSP-3000 has been released it has unfortunately been confirmed that this model is indeed Pandora-proof (as expected). No extra features apart from what had already been announced. So no HDD, GSensor, Bluetooth, or USB Host on this model (even though these features are supported by the firmware). May have to wait for a PSP-4000 then…
[Waits patiently for the PSP-4000...]
There has been news recently about a Pandora-proof PSP with TA-088 motherboard. There has been a lot of speculation and misinformation being spread around.
There is a Pandora-proof model out now and it is of a TA-088 motherboard. However, that is not to imply that all TA-088 boards are Pandora-proof. There are currently (AFAIK) three different TA-088 models:
TA-088v1: These were the first TA-088 models which came with 3.71 firmware. They are similar to TA-085v2 in that it has disabled writing to the battery eeprom so that Pandora batteries cannot be created with these boards. However, like the TA-085v2, Pandora still worked perfectly fine so cfw can still be installed normally like any other PSP.
TA-088v2: These are newer TA-088 boards which came with 3.90 firmware and had a slight hardware change in the TACHYON IC (the cpu chip). At first, Pandora could not run so it was speculated that the exploit that allows Pandora to work was patched. However, after more research it was found that this was not the case but simply there was a hardware change that made it incompatible with the DDC kernel. Custom IPL’s could still be run so cfw still worked on these models, however they will be unable to be installed with the current versions of DDC. A new DDC version will be needed for these models. (EDIT: DC6 has now been released to fix this problem, DC5 and earlier versions still will not work on these boards)
TA-088v3: These are the newest TA-088 boards that seem to be completely Pandora-proof (as far as I can tell). It has a new TACHYON IC part number – CXD2988GG with a copyright year of 2008 (previous TA-088 models had a CXD2975GG part number with a 2007 copyright year). This PSP looks like to be the real Pandora-proof model, one that has patched the ‘preipl’ exploit that allows Pandora to run. If this is the case (and the exploit was properly patched) there would be no workaround or ‘fix’ to get Pandora to run (unless we find a way to ‘properly sign’ our own IPL).
I hope this clears up some of the confusion surrounding the new TA-088 motherboards and the rumours surrounding this new Pandora-proof PSP.
EDIT:
There’s some confusion with regards to the relationship between the firmware version and the motherboard. There isn’t a one-to-one correlation between the motherboard version and the firmware version. That is, if you have a TA-088v2 board then you have (at least) a 3.90 firmware. However the inverse is not true, that is, it doesn’t necessarily mean that if you have a 3.90 firmware then you have a TA-088v2 board (you may have a TA-088v1 board or maybe a TA-085v2 board).
It’s just the TA-088v2 boards first started appearing with 3.90 firmware. But you may also still have TA-088v1 boards or TA-085v2 boards being produced with 3.90 firmware too. Especially depending on the region. The firmware versions listed above are the earliest firmwares seen with these boards. These boards were released in Asia first so the firmware version may be earlier than on US or Europe models.
Basically, you cannot tell what board you have just based on the firmware version (though you can make an educated guess), however if you have a certain board then you will know at least the earliest firmware it will have.
EDIT2:
The new TA-088v3 boards only come in 4.xx and above. The new pre-IPL in these boards can only boot the 4.xx IPL’s, it cannot boot older IPL’s from 3.xx. So as long as the PSP doesnt come with 4.xx fw you know it won’t be a v3 board. Just remember, v3 boards cannot run firmwares under 4.xx.
More proof of the HDD.
Just how the first fat firmware (1.00) was rushed to be released, it seems the first slim firmware (3.60) was also rushed. A certain module that came only on original 3.60 retail slims was (incredibly stupidly) compiled with full debug info intact. Extracted from the debug info was this:
From the debug info, there are ways to stream MagicGate protected video from HDD.
There is a tonne of useful debug info extracted, also noteworthy were references to Skype and the boot mode “app” (other modes “vsh”, “game”, “updater”, “pops”, etc) with which Skype boots into. There seems to be plans to release more of these ‘app’s in the future. Perhaps more towards a full pda…(03g).
Here’s a quick list, but because most sites only post a single version of an update I’ve been unable to find the alternate versions. Though I have both 2.00 updaters as you see in the list.
Im still looking for the others so if you have an eboot that does not match the following hashes let me know, specifically:
1.52 (MD5: B976783070C12C4ED81CC27785222491)
2.60 (MD5: A69A022FCE43B614A8CB305786F59855)
1.50
release:1.00:
build:89,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4231@updater_for_day1,v11488@updater_for_day1,20050304:
1.51
release:1.00:
build:91,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4389@updater_151,v12880@updater_151,20050507:
1.52
release:1.00:
build:114,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4505@updater_152,v13669@NA,20050602:
2.00a
release:1.00:
build:134,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4689@updater_200,v15800@updater_200,20050722:
2.00b
release:1.00:
build:139,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4689@updater_200,v16630@updater_200,20050819:
2.01
release:1.00:
build:150,0,3,1,0:root@vsh-build
system:17756@release_103a,0×01000300:
vsh:p4798@updater_201,v18571@updater_201,20050929:
2.50
release:1.00:
build:157,0,3,1,0:root@vsh-build
system:17756@release_103a,0×01000300:
vsh:p4801@updater_250,v19017@updater_250,20051011:
2.60
release:1.00:
build:170,0,3,1,0:root@vsh-build
system:17756@release_103a,0×01000300:
vsh:p4954@updater_trunk,v20338@updater_trunk,20051122:
2.70
release:1.00:
build:190,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5181@updater_270,v22592@updater_270,20060420:
2.71
release:1.00:
build:203,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5220@updater_271,v22936@updater_271,20060530:
2.80
release:1.00:
build:214,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5271@updater_280,v24380@updater_280,20060721:
2.81
release:1.00:
build:215,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5280@updater_281,v24651@updater_281,20060814:
2.82
release:1.00:
build:218,0,3,1,0:hoshi@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5353@updater_282,v25795@updater_282,20061003:
3.00
release:1.00:
build:230,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5382@updater_300,v27165@updater_300,20061120:
3.01
release:1.00:
build:231,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5404@updater_301,v27257@updater_301,20061121:
3.02
release:1.00:
build:233,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5414@updater_302,v27411@updater_302,20061204:
3.03
release:1.00:
build:238,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5426@updater_303,v27632@updater_303,20061216:
3.10
release:1.00:
build:247,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5471@updater_310,v28276@updater_310,20070119:
3.11
release:1.00:
build:250,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5476@updater_311,v28775@updater_311,20070206:
3.30
release:1.00:
build:259,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5531@updater_330,v30241@updater_330,20070326:
3.40
release:1.00:
build:261,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5576@updater_340,v30701@updater_340,20070406:
3.50
release:1.00:
build:275,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5662@updater_350,v32514@updater_350,20070522:
3.51
release:1.00:
build:278,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5724@updater_351,v33285@updater_351,20070628:
3.52
release:1.00:
build:279,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5742@updater_352,v33536@updater_352,20070710:
3.70
release:1.00:
build:290,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5840@updater_370,v35316@updater_370,20070831:
3.71
release:1.00:
build:291,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5864@updater_371,v35671@updater_371,20070912:
3.72
release:1.00:
build:295,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5876@updater_372,v36347@updater_372,20071015:
3.73
release:1.00:
build:298,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5928@updater_373,v37903@updater_373,20071121:
3.80
release:1.00:
build:303,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5933@updater_380,v38389@updater_380,20071210:
3.90
release:1.00:
build:310,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5940@updater_390,v38984@updater_390,20080125:
3.93
release:1.00:
build:313,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5989@updater_393,v39469@updater_393,20080215:
3.95
release:1.00:
build:318,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p6004@updater_395,v40308@updater_395,20080328:
EDIT: added 3.80, added 3.90, added 3.93, added 3.95
Note: there were two releases of the 3.93 EBOOT however the app itself stayed the same so there’s only one version listed. There were only minor changes to the packaging of the EBOOT, an extra 0×1000 null bytes for the PBP Header, and an extra 0×10 byte hash added to the end of the PSAR. Strangely enough, the extra 0×1000 bytes were taken out again for 3.95.
We are all familiar with the various tricks SCE use to fool devs, though I recently came across one that has annoyed me the most.
When 3.40 was released, a ‘special’ prx was flashed with the rest of the firmware that didnt seem to be used at all. It was special in that not only was it not used nor referred to once in the entire firmware, it also could NOT be decrypted (the keys to decrypt it simply did not exist in the firmware). Because of this and the fact that the prx was promptly removed from all future firmware (it only exists in 3.40) it was assumed to be a remnant of a debug prx used during testing and they had simply forgot to remove it. Or was it?
The prx was “idcheck.prx”. The module name sounded interesting and on first glance it was assumed to be the debug version of the embedded prx SCE hid in 3.30+ updaters to check for corrupt idstorage in their updaters (the one that refuses to update the PSP if either your keys 4, 5, 6, 7 & 8 were corrupt).
Long story short, the prx has been decrypted and the result was far from expected. It seems that the original module has been taken out and replaced with a dummy instead. The only remains left of the original module was the module name “sceIdCheck” and the data segment, which included the strings “Illegal idstoarge” (SCE always misspell ‘idstorage’), “flash is corrupted”, and “cannot restore PSP system”. The rest of the module (including all the code) had been dummied with another module from the firmware.
Now why would SCE do this? If it were a debug prx that was accidently left in, why would they bother going to the trouble of dummying the code?
Some accidental mistake on their part, or more of their ridiculous mind games at play……
Welcome to SilverSpring’s bunch of random PSP stuff. There wont be much happening here, it’ll just be a bunch of…err…random PSP stuff!
Anyway, enjoy your stay here.
Powered by FireStats