Flash after Auth
-
numchuckskills
- Posts: 35
- Joined: Wed May 04, 2005 4:48 pm
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
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
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...
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...
Ratix wrote:
Did you try copying one of this bits that look checksums over from 1.50 also?This is what I did.
THIS DID NOT WORK AS EXPECTED!!
Packaged a EBOOT.PBP file with the PBP unpacker util.
Contents:
ICON0.PNG - same for both versions, I *think*
DATA.PSP - 1.51JP
PARAM.SFO - 1.51JP
DATA.PSAR - 1.50JP
Here's a movie of it being run on a 1.50 Japanese System.
Streaming - http://www.putfile.com/media.php?n=Fake-PBP-Movie
Downloadable - http://x200.putfile.com/videos/13412451131.avi
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
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
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
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
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.
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.
words cannot begin to describe how bad i feel for oopo and others like him-probably a very smart guy,who knows more about the psp and programming in general than i or most people here will ever know-and to have stupid,brutally simplisitic ideas like "swap the memory card at just the right time....yeah,thats it" constantly brought up,and even to sometimes work....ooPo wrote: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...
really,it's gotta be driving him mad.
Sometimes, the road to grandma's house is a simple straight line.... it get's you there quick and easy. Although you don't learn the forest and if a roadblock is put in place, you're screwed (1.51/52).jamima69 wrote:
words cannot begin to describe how bad i feel for oopo and others like him-probably a very smart guy,who knows more about the psp and programming in general than i or most people here will ever know-and to have stupid,brutally simplisitic ideas like "swap the memory card at just the right time....yeah,thats it" constantly brought up,and even to sometimes work....
really,it's gotta be driving him mad.
Other times, as such as the way that oopo and others have gone, you have to hack every single tree down that stands in your way to find out how grandma's forest is built, so there will be NO way in stopping you from her famous apple pie... once you know the forest like the back of your hand ;). It takes awhile to know a forest the size of texas...
Those checksums are in the bios file (.bin) itself; I can use an older generic bios flasher for newer mainboard specific bios'es, same goes also for my Pioneer dvd-r flasher. This stands to reason as the same flasher can read the checksums from the currently installed bios.Pikoro wrote:(...)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.
(...)
However, for the PSP it might be totally different. I believe mrbrown said that someone had access to an unencrypted -and presumably disassembled- flasher (probably done with kmemdump).