My 6th downgrader idea

[IndianCheese]

The way I see it, the PSP only senses when the Memory Stick is removed, not if the data is changed. So, this could possibly work with the 4GB hard drive OR the 4-in-1 NEO pad thing that supports Memory Sticks, SD cards, MMC card, etc. and take out the card being used. Maybe the PSP wouldn't recognize that the pass-through Memory Stick Duo dongle that was part of the 4-in-1 was still connected, but there was no data in it because there were no cards inserted into it. That way you could switch the update files without disassembling anything.

Also, this method only works on downgrading any version below the current version (i.e. 2.70 update can be run on 2.60 and below, so it would work, but there is no update above 2.70 to run/edit with 1.50 psar.)

1 more thing: The risk of bricking is VERY high, because in reality, you are updating to 1.50 via the flashing program of a 2.60/2.70 update. So there you have it!

[Kaiser]

The way I see it, the PSP only senses when the Memory Stick is removed, not if the data is changed. So, this could possibly work with the 4GB hard drive OR the 4-in-1 NEO pad thing that supports Memory Sticks, SD cards, MMC card, etc. and take out the card being used. Maybe the PSP wouldn't recognize that the pass-through Memory Stick Duo dongle that was part of the 4-in-1 was still connected, but there was no data in it because there were no cards inserted into it. That way you could switch the update files without disassembling anything.

Also, this method only works on downgrading any version below the current version (i.e. 2.70 update can be run on 2.60 and below, so it would work, but there is no update above 2.70 to run/edit with 1.50 psar.)

1 more thing: The risk of bricking is VERY high, because in reality, you are updating to 1.50 via the flashing program of a 2.60/2.70 update. So there you have it!

Not bad idea. Hard to say if it would work though. Like you said this method has a high likelyhood of bricking your PSP.

[F9zDark]

Requires:

PBP Unpacker
2 Memory Sticks
2.01 or 2.50 PSP
2.60 Update
1.50 Update

Instructions:

Copy 2.60 update PBP. Place into first Memory Stick. Open PBP Unpacker. Extract files from 2.60 update. Extract files from 1.50 update. Create new PBP with 2.60 icon0.png, param.sfo, data.psp, and 1.50 data.psar. Save as update on second Memory Stick. Insert first Memory Stick into PSP. Run 2.60 update. Follow instructions. When screen displays the message that says to press the left arrow on D-pad to begin updating, remove Memory Stick and insert second one. Press left arrow. After update, error should be displayed. When PSP starts, corrupted settings error should be displayed. Restart again for 1.50.

Explanation:

I heard something like this failed before, but there was one difference; only one Memory Stick. The PBP didn't even run let alone update. As can be seen with any homebrew program, when the Memory Stick is removed, the program continues running. So I figure that if the update is already running and the second Memory Stick is inserted that has the same update data on it EXCEPT for the actual update files (data.psar), the program will read from the 1.50 data.psar and copy them to the flash. The only way this wouldn't work is if Sony developed a checksum that, once again, checks the data.psar file to see if it is the right one for the specific update WHILE THE PROGRAM IS RUNNING. We all know it checks when the update is first executed; what about while it is running. No PBP boot problems at all. The valid PBP will have already be booted.

Disclaimer:

I AIN'T PAYIN' FO' YO' BROKEN PSP IF IT DON'T WORK, YO!

Not going to work. I have tried this idea extensively last year when I mistakenly updated to 1.51 and wanted the homebrew abilities of 1.50.

Changing ANY information in the Updates makes there AES signatures void, and thus they will not run.

As well, there is a data check. The Updater protocol doesn't just look at the PARA.SFO for the version. It apparently looks at the data inside the EBOOT and see if it matches the data already in the flash.

If it matches, or is older than the data in the flash, it does not continue.

Sony obviously patched up the Updater protocol very tightly, since the consequences that can occur due to an error are fatal to the PSP.

Trust me, the Updater-swap route is a failure. It will not work.

[Cooe14]

Not going to work. I have tried this idea extensively last year when I mistakenly updated to 1.51 and wanted the homebrew abilities of 1.50.

Changing ANY information in the Updates makes there AES signatures void, and thus they will not run.

As well, there is a data check. The Updater protocol doesn't just look at the PARA.SFO for the version. It apparently looks at the data inside the EBOOT and see if it matches the data already in the flash.

If it matches, or is older than the data in the flash, it does not continue.

Sony obviously patched up the Updater protocol very tightly, since the consequences that can occur due to an error are fatal to the PSP.

Trust me, the Updater-swap route is a failure. It will not work.

He already said swapping memory sticks won't work.

[F9zDark]

Apparently not, since thats the motives behind his Neo4-in-1 idea above...

Again, trying to hack through the updater protocol WILL NOT work. Sony took extra care in ensuring that this is air tight. A simple bug in the Updater protocol could essentially brick 1000s of PSPs and Sony would be dealing with a Class Action Lawsuit.

Just give it up; you're ideas have been tried extensively last year. The PSP checks other sources to ensure the data is legit, not just the SFO.