Flash after Auth
Flash after Auth
http://www.psphacks.net/files/psp2.avi
In this video you will see a US 1.5 get flashed with a JPN 1.5.1. You will notice the HASH check at the beginning of the video before the program starts. Once it starts flashing it simply dumps the firmware from the memory card. Wouldn't it be safe to say that if we could inject a previous firmware before the flash but after the check, that it should work? This is not too dissimular from how we run homebrew on the Nintendo DS.
If you don't think this will work, please explain why. Flaming just degrades the forum and the person posting.
In this video you will see a US 1.5 get flashed with a JPN 1.5.1. You will notice the HASH check at the beginning of the video before the program starts. Once it starts flashing it simply dumps the firmware from the memory card. Wouldn't it be safe to say that if we could inject a previous firmware before the flash but after the check, that it should work? This is not too dissimular from how we run homebrew on the Nintendo DS.
If you don't think this will work, please explain why. Flaming just degrades the forum and the person posting.
We could use the firmware dump, but then the files wouldn't be in a compliant PSAR (though we might be able to pack them ourselves), and we may not have all the files (read thread here)Histo > that's why I say that, we have Not the psar of the 1.0 firmware
-
- Posts: 16
- Joined: Fri May 06, 2005 8:17 am
^^I like that idea, and I'm making a EBOOT.PBP with the 1.51 .SFO and .PSP crossed with the 1.50 .PSAR.
The only problem??
I believe that when you try to run the firmware, it checks the .SFO file AND the .PSP file. .SFO's are editable, but I'm not too sure about .PSP files. Assuming we can't change a .PSP file, it would be sending a message to the PSP saying that it's firmware 1.51 (I'm using the 1.51 .PSP file). Of course, on a 1.51 system, it won't run anything newer than 1.52, so we're still screwed there.
We have 2 options - get a working 1.00 PSAR file, use 1.51's .SFO and .PSP files, and it should run. Other choice is to wait for firmware 1.60 and then run a 1.60 SFO/PSP <-> 1.50 PSAR PBP on a 1.51 system.
The only problem??
I believe that when you try to run the firmware, it checks the .SFO file AND the .PSP file. .SFO's are editable, but I'm not too sure about .PSP files. Assuming we can't change a .PSP file, it would be sending a message to the PSP saying that it's firmware 1.51 (I'm using the 1.51 .PSP file). Of course, on a 1.51 system, it won't run anything newer than 1.52, so we're still screwed there.
We have 2 options - get a working 1.00 PSAR file, use 1.51's .SFO and .PSP files, and it should run. Other choice is to wait for firmware 1.60 and then run a 1.60 SFO/PSP <-> 1.50 PSAR PBP on a 1.51 system.
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
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
This would NOT work to downgrad a 1.5.1.
You cant modify the data before the AUTH proccess. At best, you can trick a 1.5 into thinking your flashing to 1.5.1 but re-flash it with 1.5 again. This is not the complete solution at this point, but could be means to install custom firmware in the future.
You need to have at least one update above your current firmware for this to even work. You need it to start the software, otherwhise you will have "Current Version" or "Currupted Data" errors. If you updated to 1.5.1, then you will have to wait until yet another update is available.
You cant modify the data before the AUTH proccess. At best, you can trick a 1.5 into thinking your flashing to 1.5.1 but re-flash it with 1.5 again. This is not the complete solution at this point, but could be means to install custom firmware in the future.
You need to have at least one update above your current firmware for this to even work. You need it to start the software, otherwhise you will have "Current Version" or "Currupted Data" errors. If you updated to 1.5.1, then you will have to wait until yet another update is available.
I dont think most of you understand.
YOU CANT MODIFY THE EBOOT.PBP. You need it so the PSP passes it through authorization. Then you swap your memory card with a modified EBOOT.PBP.
Now, we would still need a way to convince the PSP that the memory card was never removed. While that may be difficult, it sure is easier than cracking the AES encryption.
So you need:
1 Memory card with 1.5.1 unmodified (use this to boot the update program)
2 A memory card with 1.5.1 but the data.psar replaced with the data.psar from 1.5 update
3 A way to swap memory sticks without PSP having a hissy fit.
First boot 1.5.1 update (unmodified). Once the screen is up telling you what updates will be applied, swap your memory card with the one containing your 1.5.1 update with the 1.5 DATA.PSAR inside the EBOOT.PBP. This should trick your 1.5 into thinking its updating to 1.5.1 but instead, it will be re-writing to 1.5.
If this works, then we will be able to downgrade to any official releases in the future.
YOU CANT MODIFY THE EBOOT.PBP. You need it so the PSP passes it through authorization. Then you swap your memory card with a modified EBOOT.PBP.
Now, we would still need a way to convince the PSP that the memory card was never removed. While that may be difficult, it sure is easier than cracking the AES encryption.
So you need:
1 Memory card with 1.5.1 unmodified (use this to boot the update program)
2 A memory card with 1.5.1 but the data.psar replaced with the data.psar from 1.5 update
3 A way to swap memory sticks without PSP having a hissy fit.
First boot 1.5.1 update (unmodified). Once the screen is up telling you what updates will be applied, swap your memory card with the one containing your 1.5.1 update with the 1.5 DATA.PSAR inside the EBOOT.PBP. This should trick your 1.5 into thinking its updating to 1.5.1 but instead, it will be re-writing to 1.5.
If this works, then we will be able to downgrade to any official releases in the future.
Uhh.. DrEggman, that's what I'm trying to do.
Basically I took a 1.51 PBP, replaced the PSAR with the PSAR from the 1.50 update, and repackaged it as EBOOT.PBP.
I then ran it on a 1.50 system, and I got an error message, as you can see in the short film clip.
All update data was Japanese, and it was run on a 1.50 Japanese PSP from the original made-in-Japan batch.
EDIT ^^ Nevermind then.... I dunno how we'd do a MS swap.
Basically I took a 1.51 PBP, replaced the PSAR with the PSAR from the 1.50 update, and repackaged it as EBOOT.PBP.
I then ran it on a 1.50 system, and I got an error message, as you can see in the short film clip.
All update data was Japanese, and it was run on a 1.50 Japanese PSP from the original made-in-Japan batch.
EDIT ^^ Nevermind then.... I dunno how we'd do a MS swap.
The swap method sounds promising. Is there an image format for memory sticks (as ISOs are to CDs)? IF you could make sure the entire contents of a memory stick are exactly the same except for the EBOOT.PSP, then you could use a simple switch (well, maybe not simple. It'd have to be high-speed and with no bounce, but that shouldn't be too much of a problem) to change between them. The PSP wouldn't know the difference (as long as everything else is in the same place) and if you switched at the correct time (maybe have a computer snooping on the data transfer) you could effective 'swap' one file for the other.
DrEggman wrote:I dont think most of you understand.
If this works, then we will be able to downgrade to any official releases in the future.
Any version except 1.0.
Once we know how to encrypt a psp executable file, we can downgrade to 1.0. But once we know how to do it, downgrading to 1.0 will mean nothing.
In the other thread about network updating a bad bios was flashed with some rather simple editing, and I'm pretty sure it was garbage data and not something encrypted. To sum up what I got out of that other thread as it applies to this:
1) The upgrade to version was arbitrary based on the initial editing which means it could be done to a 1.51 currently
2) The data flashed was bad but managed to get past the psp checks. I'm not sure exactly how it managed to get past the checks but this suggests to me that it doesnt have to be some sort of encrypted data since I don't believe we know how to properly encrypt for the PSP yet.
Soon as someone gets an actual flash image that's not encrypted. Yeah... right... Then we can test it needing to be encrypted.
The more I read about the exploit attempts the more I think it's going to have to be a hardware solution. Especially with Sony able to force flash updates via UMDs if you want to play your games.
1) The upgrade to version was arbitrary based on the initial editing which means it could be done to a 1.51 currently
2) The data flashed was bad but managed to get past the psp checks. I'm not sure exactly how it managed to get past the checks but this suggests to me that it doesnt have to be some sort of encrypted data since I don't believe we know how to properly encrypt for the PSP yet.
Soon as someone gets an actual flash image that's not encrypted. Yeah... right... Then we can test it needing to be encrypted.
The more I read about the exploit attempts the more I think it's going to have to be a hardware solution. Especially with Sony able to force flash updates via UMDs if you want to play your games.
-
- Posts: 7
- Joined: Thu Apr 21, 2005 8:17 pm
- Location: Colorado
-
- Posts: 7
- Joined: Thu Apr 21, 2005 8:17 pm
- Location: Colorado