forums.ps2dev.org

AlexGreen · Joined: 27 Mar 2005 Posts: 35 Location: Seattle

Flash memory has a finate number of times you can write to it untill it breaks down, so we want to avoid frequent writes as much as possible.
_________________
What does this button do?

spiral · Joined: 14 May 2005 Posts: 7

In one Sandisk example where a 4 kB file is written every 5 seconds with 4 kB clusters on a 1 gig card, the card last about 79 years. Flash limits should not be a major concern.

AlexGreen · Joined: 27 Mar 2005 Posts: 35 Location: Seattle

I would think that when this particual flash chip was developed, the specs didn't call for numerous writes so the gates are probably not quite as resilient as the ones in general purpose flash memory found in mp3 players and digital cameras.
_________________
What does this button do?

numchuckskills · Joined: 04 May 2005 Posts: 35

burned...
_________________
Not with a bang, but a whisper.
This is the way the world ends.

Pikoro · Joined: 13 Jan 2005 Posts: 56

It really doesn't seem to me like most people are quite understanding what dreggy was proposing.

This is for example purposes only:

You're on a 2.0 PSP.
You have modified your psp so that when you remove the memory stick, the psp doesn't know about it. (shorted a switch)
You take a memory stick with the 2.1 firmware update on it.
You take a second memory stick with the 1.50 firmware update on it.

You pop in the stick with the 2.1 firmware on it and go to games, memory stick, and launch the update.
The current firmware verifies that it is a "legit" update.
At that point, you take the 2.1 firmware stick out and pop in the 1.5 firmware stick.
The psp does not know that you have made a swap since you shorted the switch out.
You click on "flash now" or whatever, and it reads the firmware image from the 1.5 update file, thinking that it's 2.1.
The firmware gets flashed, and bam! you're back to a 1.5 firmware.

In theory, sounds good. Sounds solid in fact.

However, I can think of a couple of reasons off the top of my head why it wouldn't work.

First, the flash program might be programmed to look at a specific "first block" on the memory stick to pull the flash from.
Reasonable, but not very likley if you ask me. Why put a check like that into a program when the odds are extremely slim that you'll need it. Not everyone has the broadband connection to pull a 14+ meg bios update in less than a minute.

Second, and more important I think, is that the flash program should know exactly how many blocks it needs to read/write inorder for the flash update to procede without error. If the update is a different size than the one that the flash program says, then you might have problems flashing and corrupt your firmware.

Third, every bios flashing program I've used, checks the checksums of the files either during, or after the bios is witten. I would have to assume that alist of md5 sums or whatnot would be stored in the flashing program , or a file referenced by that program. Hence, the checksums would not match and the flash would fail.

Just some ideas, but I'mnot going to check it on MY psp :D

Cheers

DrEggman · Joined: 22 Mar 2005 Posts: 28

*ahem*, In light of the new exploit, here is a big "I told you so" to those who thought a memory card swap was stupid.

ooPo · Posted: Thu Jun 16, 2005 3:31 am Post subject:

Ahem, it still is kinda stupid... but it is useful more as a way to open a 1.5 unit than it is for day-to-day homebrew coding.

What is also stupid is bumping a thread just to rub your naughty bits in front of the rest of us because of some stroke of dumb luck you hit upon what eventually became the first method of running code on a 1.5 unit.

I mean, its not like you contributed anything to its development...

Marco_N · Joined: 29 May 2005 Posts: 46

Warren · Joined: 24 Jan 2004 Posts: 173 Location: San Diego, CA

Ratix wrote:

steddy · Joined: 04 Apr 2005 Posts: 139

Probably just as importantly, did you change the Update version number in the SFO for all languages to the PSP still thought it was a 1.52 firmware? If your firmware is currently 1.51, then change the version in the SFO to 1.52 so it will attempt to run it.

Maybe you could use the swap trick to get the PSP to execute a modified DATA.PSP to update the firmware without the check for it being a lower version number.

Also, since the PSP seems to execute a renamed binary (.PSP) even though its called a .PBP maybe it is using a Load function that checks the file type and works out how to run it. Anyone tried the swap trick by renaming a .PSAR file as a .PBP? Maybe dumb but worth a try.

Steddy

mrbrown · Joined: 17 Jan 2004 Posts: 1536

.psar files are not executable.

steddy · Joined: 04 Apr 2005 Posts: 139

I know they aren't executable, but neither are PBP files. They may seem like they are, but hey are just a container file too.

Since it works for PBP files maybe it examines the file to determine the file type then loads it appropriately. Why else would a renamed .PSP file work as a .PBP? Maybe the PSP natively knows how to handle a .PSAR too.

Steddy

mrbrown · Joined: 17 Jan 2004 Posts: 1536

Yes, it determines the type of file before reading the .psp out of it, I have seen this code myself.

I also know that .psar files are not handled natively, and that they are just an archive used by the updater. There is no code in the kernel (or flash) to handle .psar files directly.

Kamilion · Joined: 01 Mar 2005 Posts: 24

Okay, I've got an idea.
Anyone remember that hack to use Memory Stick Pros on a PSP using the gadget for the mobile phone?

We know the pinouts for the memory stick.
We know there's a chip select system the PSP uses to detect if a card is removed.

Take two identical cards (Such as 2 of the 32MB pack in cards).

Get two memory stick duo to memory stick pro adapters.

Wire the power for BOTH directly, so they BOTH are receiving power constantly. Build a logic switch between the DATA lines of the two cards.

Wipe the cards using linux ( dd if=/dev/zero of=/dev/memorystick )
Format the cards with the exact same settings, volume IDs, and everything.

On the first card, place the original unmodified pbp.
On the second card, place the modified pbp.

Start up with the first card connected. start the updater. hit the logic switch to the second card (Which the PSP should not notice) and initiate the flash.

(Has anyone checked if you can pad null data on the end of a updater PBP ? Will it still run? If so, pad the 'unmodified' padded PBP out to the same length.

Hope someone's got the tools and the drive to test this out, cause I'm broke, unfortunatly.

If this works, someone REPUTABLE in the scene could start a flashing service.

jamima69 · Joined: 01 Apr 2005 Posts: 17

Agoln · Joined: 08 Jun 2005 Posts: 326 Location: Fort Wayne, IN

jamima69 · Joined: 01 Apr 2005 Posts: 17

if you enjoy spending time lost in the woods,more power to ya-but myself,i think i'd rather be having a nice cup of tea with grammy ;)

Marco_N · Joined: 29 May 2005 Posts: 46