PSP Flash Chip Facts: The Good, the Bad and the Ugly
- ryoko_no_usagi
- Posts: 65
- Joined: Tue Nov 29, 2005 4:47 pm
Error correction is only needed when reading from the nand. The idea is that if a block goes bad and a bit flips, the block can still be used for reading because the ECC can correct single-bit errors. So until the block is attempted to be rewritten it is not added to the bad block pool. Error correction does not come into play when attempting to write to the nand, although if a write fails and it's just a single bit error, one can ignore it and let the ECC reclaim the block when it's later being read. If it's a multiple-bit error, then one must write to another block as per my earlier post.
Whence comes the source IPL? Does the IPL in the firmware updates contain the spare areas easily accessible? If so, then it's no worries, just use that and forget about ECC correction.
If dumping from another PSP, run sceNandVerifyEcc() on bytes 4-11 on the dumped spare area and also pass the ECC value stored in byte 12 and 13 (sans the most significant high-nibble which is always set) and if it doesn't complain, there are no worries :)
Though I'm sure Black Cat can also give instructions on how to manually correct a bit error ;)
Oh, and one should read the IPL from the nand with sceNandReadBlock or sceNandReadPages cause then the built-in error correction for the user area will take care of that part. Note that in such a case bytes 0-3 are not passed to the spare area buffer, so one should run sceNandVerifyEcc on bytes 0-7 and the ECC is in bytes 8 and 9. The user area ECC should be autogenerated if writing with sceNandWriteBlock or sceNandWritePages so it doesn't need to be included, but the spare area ECC must be.
Oh, and the above is only guesswork by me since I haven't tested to write to the nand with the sceNand API. Don't want to risk a PSP just yet until I know I can restore it ;)
Whence comes the source IPL? Does the IPL in the firmware updates contain the spare areas easily accessible? If so, then it's no worries, just use that and forget about ECC correction.
If dumping from another PSP, run sceNandVerifyEcc() on bytes 4-11 on the dumped spare area and also pass the ECC value stored in byte 12 and 13 (sans the most significant high-nibble which is always set) and if it doesn't complain, there are no worries :)
Though I'm sure Black Cat can also give instructions on how to manually correct a bit error ;)
Oh, and one should read the IPL from the nand with sceNandReadBlock or sceNandReadPages cause then the built-in error correction for the user area will take care of that part. Note that in such a case bytes 0-3 are not passed to the spare area buffer, so one should run sceNandVerifyEcc on bytes 0-7 and the ECC is in bytes 8 and 9. The user area ECC should be autogenerated if writing with sceNandWriteBlock or sceNandWritePages so it doesn't need to be included, but the spare area ECC must be.
Oh, and the above is only guesswork by me since I haven't tested to write to the nand with the sceNand API. Don't want to risk a PSP just yet until I know I can restore it ;)
IIRC the NAND status only tells you whether the write failed or not. There is no way telling how many bits - in case of an error - failed to be reprogrammed. Unless of course you want to read the block again and check for yourself ... Having said that, this only applies when you talk to the device directly, maybe some sceNAND API goes through all the trouble telling you more specifically what went wrong but I doubt it.ryoko_no_usagi wrote:... although if a write fails and it's just a single bit error, one can ignore it and let the ECC reclaim the block when it's later being read ...
You'd think that ECC verification can cope with that, i.e.If dumping from another PSP, run sceNandVerifyEcc() on bytes 4-11 on the dumped spare area and also pass the ECC value stored in byte 12 and 13 (sans the most significant high-nibble which is always set) and if it doesn't complain, there are no worries :)
Though I'm sure Black Cat can also give instructions on how to manually correct a bit error ;)
1. everything is fine, report success
2. there is a single bit error (ECC or data), correct it and say you did
3. multiple bit error, report verification failure
If this functionality isn't included feel free to drop me a line.
As for bytes 4-11, I personally doubt that the block status (offset 5) is included in the spare ECC. I'd guess it's more like 3,4,6-11 (0-2 being the payload ECC). I could be wrong, it certainly would make the correction code look less elegant due to the gap ;)
- Timale-Kun
- Posts: 13
- Joined: Sat Jan 14, 2006 8:38 pm
- Location: Paris
- Contact:
- ryoko_no_usagi
- Posts: 65
- Joined: Tue Nov 29, 2005 4:47 pm
That's the thing, correction does not appear to be included! I thought that sceNandCollectEcc() would be used to correct a bit-error. Both sceNandVerifyEcc and sceNandCollectEcc call the same function to calculate the ECC and that function also takes a flag, which Verify sets to 0 and Collect sets to 1. The only difference this flag makes, at the end (if a single bit error):kuroneko wrote: You'd think that ECC verification can cope with that, i.e.
1. everything is fine, report success
2. there is a single bit error (ECC or data), correct it and say you did
3. multiple bit error, report verification failure
If this functionality isn't included feel free to drop me a line.
Code: Select all
if (flag == 0) return -1;
spare[7] ^= 0x80;
return -1;
I'm sure it's from 4-11 because bytes 0-3 aren't available when reading with sceNandReadBlock/Pages. The Ecc functions simply read 8 bytes linearly from the buffer they are passed.kuroneko wrote: As for bytes 4-11, I personally doubt that the block status (offset 5) is included in the spare ECC. I'd guess it's more like 3,4,6-11 (0-2 being the payload ECC). I could be wrong, it certainly would make the correction code look less elegant due to the gap ;)
Code: Select all
int
sceNandCalcEcc(u8 *spare)
{
int b0 = spare[0],
b1 = spare[1],
b2 = spare[2],
b3 = spare[3],
b4 = spare[4],
b5 = spare[5],
b6 = spare[6],
b7 = spare[7];
/* Ecc magic happens on those bytes */
}
- ryoko_no_usagi
- Posts: 65
- Joined: Tue Nov 29, 2005 4:47 pm
Looks like some unfinished code then ;) I mean they're going through all the trouble and implement h/w ECC (I assume it's used for payload AND spare area) and then don't even correct single bit errors? Is there any distinction between single and multi bit errors (return code wise)?ryoko_no_usagi wrote:That's the thing, correction does not appear to be included! ... That's really what happens. I thought I was reading it wrong at first and that the xor would be with the offending bit, but it really is always the last byte!
OK. I can live with that.I'm sure it's from 4-11 because bytes 0-3 aren't available when reading with sceNandReadBlock/Pages. The Ecc functions simply read 8 bytes linearly from the buffer they are passed.
BTW, is it really sceNANDCollectECC as opposed to sceNANDCorrectECC? ;)
- ryoko_no_usagi
- Posts: 65
- Joined: Tue Nov 29, 2005 4:47 pm
Now that I think about it, it's very probable it's used for both. But then why include the sceNand*Ecc() functions for? :)kuroneko wrote:Looks like some unfinished code then ;) I mean they're going through all the trouble and implement h/w ECC (I assume it's used for payload AND spare area) and then don't even correct single bit errors? Is there any distinction between single and multi bit errors (return code wise)?ryoko_no_usagi wrote:That's the thing, correction does not appear to be included! ... That's really what happens. I thought I was reading it wrong at first and that the xor would be with the offending bit, but it really is always the last byte!
There is a distinction in the return codes from sceNandVerifyEcc and sceNandCollectEcc:
Code: Select all
-1 = single-bit error that can be corrected
-2 = single-bit error in the ECC value itself
-3 = multi-bit error
Yeah, I suspect it's supposed to be sceNandCorrectEcc really :)kuroneko wrote:OK. I can live with that.I'm sure it's from 4-11 because bytes 0-3 aren't available when reading with sceNandReadBlock/Pages. The Ecc functions simply read 8 bytes linearly from the buffer they are passed.
BTW, is it really sceNANDCollectECC as opposed to sceNANDCorrectECC? ;)
-
- Posts: 7
- Joined: Tue Mar 28, 2006 5:04 pm
- Location: atlantic
- Contact:
I am a Sea Monster, as such, I will require your spongebob icecream, Ryoko.
I have a general question, I hope you will all deem it seaworthy. Now I'm an old man with many barnacles on my belly, but I do know that if you can run code that can program the flash, then you are in kernel mode and can do /anything/ anyways.
What is the goal here, why downgrade if you are already capable of runnign kernel mode code?
Not that I don't think exploring just to explore is a great idea, I'm just wondering if there is some greater scheme that I'm missing.
I have a general question, I hope you will all deem it seaworthy. Now I'm an old man with many barnacles on my belly, but I do know that if you can run code that can program the flash, then you are in kernel mode and can do /anything/ anyways.
What is the goal here, why downgrade if you are already capable of runnign kernel mode code?
Not that I don't think exploring just to explore is a great idea, I'm just wondering if there is some greater scheme that I'm missing.
Is it possible that this is actually fixed up in later firmwares? What version of the code are we all looking at, here?kuroneko wrote: Looks like some unfinished code then ;) I mean they're going through all the trouble and implement h/w ECC (I assume it's used for payload AND spare area) and then don't even correct single bit errors? Is there any distinction between single and multi bit errors (return code wise)?
I can well imagine that they only got round to fixing up finer details like this in, say, v2.0...
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
I doubt so because the scenand API is only "officially" used durring an update and the scenand API is called by the iplupdater module (located in the updater's data.psp) and that module doesn't seem to change from 1.50 to 2.60 updater.
Beside I don't know how the updater would be able to update a 1.50 fw using a faulty nand ECC correction. My guess is that the scenand API doesn't change from v1.00 to v2.60 but I might be wrong about that.
Maybe disassembling the iplupdater module would allow to get more knowledge on how sony uses the scenand API to overwrite the IPL tough.
I can't share the file due to copyright issues :/ so I suggest that you to extract (from a decrypted data.psp) the iplupdater module from a 2.60 updater and decrypt it. (just use an hex editor search for the ~PSP text string copy/paste it and save it as iplupdater.prx, then use a prx decryptor on 1.50) then dissasemble it and take a closer look.
Beside I don't know how the updater would be able to update a 1.50 fw using a faulty nand ECC correction. My guess is that the scenand API doesn't change from v1.00 to v2.60 but I might be wrong about that.
Maybe disassembling the iplupdater module would allow to get more knowledge on how sony uses the scenand API to overwrite the IPL tough.
I can't share the file due to copyright issues :/ so I suggest that you to extract (from a decrypted data.psp) the iplupdater module from a 2.60 updater and decrypt it. (just use an hex editor search for the ~PSP text string copy/paste it and save it as iplupdater.prx, then use a prx decryptor on 1.50) then dissasemble it and take a closer look.
Last edited by Mathieulh on Fri Mar 31, 2006 7:01 am, edited 1 time in total.
OK, I was under the impression that the IPL had changed, but this is far from being my area of expertise and I'm just going on vague memories of past threads.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
Well the IPL itself changes in every fw versions, just because it performs a checksum of most of the critical prx in flash0:/kd/
Of course special IPL revisions (kbooti.bin) does not perform those checksums :) And one of them has a flaw allowing to run decrypted prx :)
However the newer retail IPLs requires to run encrypted prx that matches the checksum otherwise the psp wont boot, that's why you can't run an 1.00 fw with the 1.50 IPL (even if it does have the 1.00 prx keys required to load those)
Some IPL such as the one from v2.00 adds some securities such as ELF = USER mode..... or 2.50 IPL that adds Version = 2.50 .....
They also add/change some failsafe features from 1.50 to 2.50
But mostly every IPL revisions do the same job
BTW: The DEM-100 Kbooti.bin and the psp kboot.bin shares the same encryption keys so a kbooti.bin from a debug unit can be flashed into a retail psp :) Interesting isn't it ?
(If the mods wanna know how I got this information I just decrypted the kbooti.bin located in the japanese version of the ridge racers UMD's modules, it's the DEM-100's 1.0.2's IPL revision (the 1.00 fw is the same as the DEM-100 1.0.3 so it's a pre 1.00 IPL))
Of course special IPL revisions (kbooti.bin) does not perform those checksums :) And one of them has a flaw allowing to run decrypted prx :)
However the newer retail IPLs requires to run encrypted prx that matches the checksum otherwise the psp wont boot, that's why you can't run an 1.00 fw with the 1.50 IPL (even if it does have the 1.00 prx keys required to load those)
Some IPL such as the one from v2.00 adds some securities such as ELF = USER mode..... or 2.50 IPL that adds Version = 2.50 .....
They also add/change some failsafe features from 1.50 to 2.50
But mostly every IPL revisions do the same job
BTW: The DEM-100 Kbooti.bin and the psp kboot.bin shares the same encryption keys so a kbooti.bin from a debug unit can be flashed into a retail psp :) Interesting isn't it ?
(If the mods wanna know how I got this information I just decrypted the kbooti.bin located in the japanese version of the ridge racers UMD's modules, it's the DEM-100's 1.0.2's IPL revision (the 1.00 fw is the same as the DEM-100 1.0.3 so it's a pre 1.00 IPL))
Are you suggesting flashing your PSP 1.00/1.50 with this special IPL and a custom firmware would then allow you to boot this custom firmware (i.e. one consisting of unencrypted prxs)? That would open amazing possibilities...Mathieulh wrote:Of course special IPL revisions (kbooti.bin) does not perform those checksums :) And one of them has a flaw allowing to run decrypted prx :)
I did, the problem is that the flasher I used was not secured: By not secured I mean:
- no ECC correction (that's the part I still miss to have a secure flasher)
- I wasn't sure that all the modules were unloaded before performing SceIo (I fixed that issue)
I was lucky to have all the modules unloaded and no bad blocks at the time I downgraded otherwise I would have ended with a brick.
So I did downgrade once to 1.00 but I don't want to retry unless I have a safe flasher (whitch I do not at the moment) I don't want devs or no one to brick their precious 1.50 (nor as I do want to brick mine) so our work here is to code a safe flasher. Then not only me but everyone else will be able to downgrade to 1.00.
Once we have a secure way to flash then we might work on hybrid fw, although I wont risk to brick my psp while testing those hybrid fws.
Taking risks at downgrading the first time was a necessary step tough as now you know that all the psp requires to update is to overwrite the IPL and the flash0:/ files, Before, there were still chances that another binary or anything similar needed to be modifiesd within the nand non-fat area. We now know that it's not the case.
You now also know that the modules need to be unloaded before overwritting flash0:/ using sceio and that it can be performed by running the flashing elf in VSH or UPDATER mode and that the scenand API works in those modes.
I also told you that the only reason you cannot mix up fw files with another IPL revision is that the IPLs perform a checksum on most critical prx files in the flash0:/kd/ folder (and of course that some keys can be missing if you try to run an higher fw with an older IPL)
That's because the iplupdater module is missing from the bogus update that the 1.00 psp got bricked when people tried to update those with it because the bogus IPL wasn't flashed and that the 1.00 IPL did not have the required keys in order to decrypt loadcore.prx (afaik that's the 2nd prx to run just after mesg_led.prx and that's the most critical kernel module)
Beside the bogus update is an half-retail, half-debug fw,so even if the bogus IPL was to be flashed (witch isn't) it would have tried to run loadcorei.prx (instead of loadcore.prx that is also inclueded within the bogus psar) because loadcorei.prx is meant to be run from a DEM-100 unit's IPL while loadcore.prx is meant to run from a retail IPL, however the loadcorei.prx from the bogus update is slightly different from the loadcore.prx file (from the very same update) because it is supposed to load a lot of more modules originally from the DEM-100 1.0.2 fw that were removed in the bogus update (the bogus update is an hybrid fw, some kind of dummy fw meant to perform tests on the psp's updating abilities as well as to help the updater's developpment. Because the bogus updater was meant to run on a DEM-100 Unit (for testing purposes as these units CANNOT brick) and that the kbooti.bin on those units are NOT located within the nand (it's easy to figure out that they are external and can be boot from any media inclueding UMDs, just look at the kbooti.bin files in the modules of a few older UMDs those files were forgotten. What do you think they were for ? They were meant to boot the DEM-100 Unit of course ! the IPL was loaded from the UMD device ! The IPL isn't loaded form the NAND to prevent people from stealing the DEM-100 units so instead they use external means to boot them such as UMD, WLAN etc etc So for instance when Namco needs to test a revision of ridge racers to show it up to some people at a meeting, they just burn the kbooti.bin file allong with the modules on the ridge racers beta UMD and the DEM-100 will boot as long as the files in flash0:/ matches the IPL revision burned on the UMD .In the end sony just forgot to remove the kbooti.bin files from the UMD but they didn't care as they though that the UMD format was secured at this time, still they removed the kbooti.bin from the European ridge racers version and probably from the USA version too but I am not sure about it) , there was no need for Sony to write the IPL into the DEM-100 unit. Beside in order to test updates Sony only needs a single IPL for every tested fw revisions that wont perform checksums and the fw prx will all share the same key, so there is no need to change the IPL all the time in order to test another fw version.
Thanks to the risk I took and the time I spent (especially disassembling Updaters and IPLs....) you now have plenty of informations regarding how to manually flash a fw and to code your own home made updater.
I sincerly hope those informations will help you as well as possible and that you will create something from those.
Cheers.
- no ECC correction (that's the part I still miss to have a secure flasher)
- I wasn't sure that all the modules were unloaded before performing SceIo (I fixed that issue)
I was lucky to have all the modules unloaded and no bad blocks at the time I downgraded otherwise I would have ended with a brick.
So I did downgrade once to 1.00 but I don't want to retry unless I have a safe flasher (whitch I do not at the moment) I don't want devs or no one to brick their precious 1.50 (nor as I do want to brick mine) so our work here is to code a safe flasher. Then not only me but everyone else will be able to downgrade to 1.00.
Once we have a secure way to flash then we might work on hybrid fw, although I wont risk to brick my psp while testing those hybrid fws.
Taking risks at downgrading the first time was a necessary step tough as now you know that all the psp requires to update is to overwrite the IPL and the flash0:/ files, Before, there were still chances that another binary or anything similar needed to be modifiesd within the nand non-fat area. We now know that it's not the case.
You now also know that the modules need to be unloaded before overwritting flash0:/ using sceio and that it can be performed by running the flashing elf in VSH or UPDATER mode and that the scenand API works in those modes.
I also told you that the only reason you cannot mix up fw files with another IPL revision is that the IPLs perform a checksum on most critical prx files in the flash0:/kd/ folder (and of course that some keys can be missing if you try to run an higher fw with an older IPL)
That's because the iplupdater module is missing from the bogus update that the 1.00 psp got bricked when people tried to update those with it because the bogus IPL wasn't flashed and that the 1.00 IPL did not have the required keys in order to decrypt loadcore.prx (afaik that's the 2nd prx to run just after mesg_led.prx and that's the most critical kernel module)
Beside the bogus update is an half-retail, half-debug fw,so even if the bogus IPL was to be flashed (witch isn't) it would have tried to run loadcorei.prx (instead of loadcore.prx that is also inclueded within the bogus psar) because loadcorei.prx is meant to be run from a DEM-100 unit's IPL while loadcore.prx is meant to run from a retail IPL, however the loadcorei.prx from the bogus update is slightly different from the loadcore.prx file (from the very same update) because it is supposed to load a lot of more modules originally from the DEM-100 1.0.2 fw that were removed in the bogus update (the bogus update is an hybrid fw, some kind of dummy fw meant to perform tests on the psp's updating abilities as well as to help the updater's developpment. Because the bogus updater was meant to run on a DEM-100 Unit (for testing purposes as these units CANNOT brick) and that the kbooti.bin on those units are NOT located within the nand (it's easy to figure out that they are external and can be boot from any media inclueding UMDs, just look at the kbooti.bin files in the modules of a few older UMDs those files were forgotten. What do you think they were for ? They were meant to boot the DEM-100 Unit of course ! the IPL was loaded from the UMD device ! The IPL isn't loaded form the NAND to prevent people from stealing the DEM-100 units so instead they use external means to boot them such as UMD, WLAN etc etc So for instance when Namco needs to test a revision of ridge racers to show it up to some people at a meeting, they just burn the kbooti.bin file allong with the modules on the ridge racers beta UMD and the DEM-100 will boot as long as the files in flash0:/ matches the IPL revision burned on the UMD .In the end sony just forgot to remove the kbooti.bin files from the UMD but they didn't care as they though that the UMD format was secured at this time, still they removed the kbooti.bin from the European ridge racers version and probably from the USA version too but I am not sure about it) , there was no need for Sony to write the IPL into the DEM-100 unit. Beside in order to test updates Sony only needs a single IPL for every tested fw revisions that wont perform checksums and the fw prx will all share the same key, so there is no need to change the IPL all the time in order to test another fw version.
Thanks to the risk I took and the time I spent (especially disassembling Updaters and IPLs....) you now have plenty of informations regarding how to manually flash a fw and to code your own home made updater.
I sincerly hope those informations will help you as well as possible and that you will create something from those.
Cheers.
- ryoko_no_usagi
- Posts: 65
- Joined: Tue Nov 29, 2005 4:47 pm
Here is a program to read/write the IPL. I have not tested this for real as I cannot yet reflash the nand if something should go wrong, and I renounce any responsibility for the use of this progam. It is in fact very likely to brick the PSP...
A couple of notes: the spare area of the IPL appears to be "static", that is, the contents seem to be only two different things depending on whether a page is empty or not. I have only checked my own PSP with fw 1.5 so maybe there is more to it. The program tries to verify the format before doing anything dangerous.
I now think ECC correction is done automatically for both user and spare, so the sceNand*Ecc() functions might be relatively useless actually...
Also, this was done rather quickly on my lunch break yesterday, and finished up this morning, so it's quite possible something will not work as intended...
Beware...
A couple of notes: the spare area of the IPL appears to be "static", that is, the contents seem to be only two different things depending on whether a page is empty or not. I have only checked my own PSP with fw 1.5 so maybe there is more to it. The program tries to verify the format before doing anything dangerous.
I now think ECC correction is done automatically for both user and spare, so the sceNand*Ecc() functions might be relatively useless actually...
Also, this was done rather quickly on my lunch break yesterday, and finished up this morning, so it's quite possible something will not work as intended...
Beware...
Code: Select all
/*
* main.c - writeIPL for PSP
*
* Copyright (c) 2005 Marcus R. Brown <mrbrown@ocgnet.org>
* Copyright (c) 2005 James Forshaw <tyranid@gmail.com>
* Copyright (c) 2005 John Kelley <ps2dev@kelley.ca>
* Copyright (c) 2006 Ryoko no Usagi <ryoko.no.usagi@gmail.com>
*
*/
#include <assert.h>
#include <stdlib.h>
#include <string.h>
#include <pspuser.h>
#include <pspdebug.h>
#include <pspctrl.h>
#include <pspnand_driver.h>
/* Define the module info section */
PSP_MODULE_INFO("writeIPL", 0x1000, 1, 1);
PSP_MAIN_THREAD_ATTR(0);
#define FAKING
#define IPLBIN "ms0:/ipl.bin"
#define printf pspDebugScreenPrintf
/* Nand characteristics */
int g_iPageSize, g_iPagesPerBlock, g_iBlockSize, g_iTotalBlocks, g_iExtraSize = 512 - 128;
int g_bFlashLocked = 0;
static void *g_pIpl, *g_pIplSpare, *g_pIplBM;
static int g_iIplLen;
void LockFlash(int write);
void UnlockFlash(void);
typedef struct {
char block_fmt;
char block_stat;
char block_addr[2];
char unknown[4];
unsigned short spare_ecc;
char reserved[2];
} spare_area_t;
/* This appears to be static */
char spare_for_ipl_block_map[32][12] = {
{ 0xff,0xff,0xff,0xff,0x38,0x4a,0xc6,0x6d,0x89,0xfd,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff },
{ 0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0xf0,0xff,0xff }
};
/* Exit callback */
int exit_callback(void)
{
UnlockFlash();
sceKernelExitGame();
return 0;
}
/* Callback thread */
int CallbackThread(SceSize args, void *argp)
{
int cbid;
cbid = sceKernelCreateCallback("Exit Callback", (SceKernelCallbackFunction) exit_callback, NULL);
sceKernelRegisterExitCallback(cbid);
sceKernelSleepThreadCB();
return 0;
}
/* Sets up the callback thread and returns its thread id */
int SetupCallbacks(void)
{
int thid = 0;
thid = sceKernelCreateThread("update_thread", CallbackThread, 0x11, 0xFA0, PSP_THREAD_ATTR_USER, 0);
if(thid >= 0)
{
sceKernelStartThread(thid, 0, 0);
}
return thid;
}
void
LockFlash(int write)
{
write = 0;
if (!g_bFlashLocked)
sceNandLock(write);
g_bFlashLocked = 1;
}
void
UnlockFlash(void)
{
if (g_bFlashLocked)
sceNandUnlock();
g_bFlashLocked = 0;
}
void
die(const char *msg)
{
UnlockFlash();
printf("Fatal error: %s\n", msg);
while (1)
sceKernelSleepThread();
}
#ifdef FAKING
static int myuserfd = -1;
static int mysparefd = -1;
int
pspBandWriteBlockWithVerify(u32 ppn, void *user, void *spare)
{
if (myuserfd == -1) {
myuserfd = sceIoOpen("ms0:/user.bin", PSP_O_WRONLY | PSP_O_CREAT | PSP_O_TRUNC, 0777);
if (myuserfd < 0) {
myuserfd = -1;
return -1;
}
}
if (mysparefd == -1) {
mysparefd = sceIoOpen("ms0:/spare.bin", PSP_O_WRONLY | PSP_O_CREAT | PSP_O_TRUNC, 0777);
if (mysparefd < 0) {
mysparefd = -1;
return -1;
}
}
sceIoLseek32(myuserfd, ppn * g_iPageSize, PSP_SEEK_SET);
sceIoLseek32(mysparefd, (ppn / g_iPagesPerBlock) * g_iExtraSize, PSP_SEEK_SET);
sceIoWrite(myuserfd, user, g_iBlockSize);
sceIoWrite(mysparefd, spare, g_iExtraSize);
return 0;
}
#endif /* !FAKING */
/*
* Checks if the given page is empty
*/
int
is_empty_page(void *user)
{
int i;
for (i = 0; i < g_iPageSize; i++) {
if (((unsigned char *)user)[i] != 0xff) return 0;
}
return 1;
}
/*
* Verifies the format of the given spare page
*/
int
verify_spare_page(char *spare)
{
int rv;
spare_area_t *p = (spare_area_t *)spare;
unsigned short ecc = p->spare_ecc & 0x0fff;
/* Verify spare */
rv = sceNandVerifyEcc(spare, ecc);
switch (rv) {
case 0:
/* No error */
break;
case -1:
printf("Single-bit error in spare area...\n");
printf("Unknown how to recover!\n");
return -1;
break;
case -2:
printf("Single-bit error in ECC...\n");
printf("Proceeding with caution...\n");
break;
case -3:
printf("Multi-bit error in ECC...\n");
printf("Impossible to correct!\n");
return -1;
break;
default:
printf("Unknown error!\n");
return -1;
break;
}
/* Compare the spare against known formats */
if (!memcmp(spare, spare_for_ipl_block_map[0], 8)) return 0;
if (!memcmp(spare, spare_for_ipl_block_map[1], 8)) return 0;
printf("Unknown format! Please report this to the author\n");
printf("Do NOT attempt to flash to another PSP!\n");
return 1;
}
/*
* Reads the IPL block mapping from the nand
*/
int
read_ipl_block_map_from_nand(void *user, void *spare)
{
int i, rv;
/* Look up IPL block mapping */
for (i = 4; i < 11; i++) {
LockFlash(0);
rv = sceNandIsBadBlock(i * g_iPagesPerBlock);
UnlockFlash();
if (rv != 0) continue;
LockFlash(0);
rv = sceNandReadBlockWithRetry(i * g_iPagesPerBlock,
user, spare);
UnlockFlash();
if (rv != 0) continue;
return 0;
}
printf("All IPL block mapping blocks were corrupt?!\n");
return rv;
}
/*
* Reads the contents of the IPL from the nand and writes it to the memorystick.
*/
int
read_ipl_from_nand(void)
{
char *user, *spare;
char *bm_user, *bm_spare;
unsigned short *p;
int i;
int rv;
int fd;
user = malloc(g_iBlockSize); assert(user);
spare = malloc(g_iExtraSize + 128); assert(spare);
bm_user = malloc(g_iBlockSize); assert(bm_user);
bm_spare = malloc(g_iExtraSize + 128); assert(bm_spare);
rv = read_ipl_block_map_from_nand(bm_user, bm_spare);
if (rv != 0) {
free(user);
free(spare);
free(bm_user);
free(bm_spare);
return rv;
}
rv = verify_spare_page(bm_spare);
if (rv < 0) {
printf("Error in IPL block map\n");
free(user);
free(spare);
free(bm_user);
free(bm_spare);
return rv;
}
fd = sceIoOpen(IPLBIN, PSP_O_WRONLY | PSP_O_CREAT | PSP_O_TRUNC, 0777);
if (fd < 0) {
printf("Failed to open file %s: 0x%08x\n", IPLBIN, fd);
free(user);
free(spare);
free(bm_user);
free(bm_spare);
return fd;
}
/* Okay we've got the block map so read out blocks and write to MS */
for (p = (unsigned short *)bm_user; *p != 0; p++) {
LockFlash(0);
rv = sceNandReadBlockWithRetry(*p * g_iPagesPerBlock, user, spare);
UnlockFlash();
if (rv != 0) {
if (rv == 0x80230003) {
printf("Incorrect user ECC on block %d?!!\n",
*p);
} else {
printf("Unknown error: 0x%08x\n", rv);
}
sceIoClose(fd);
free(user);
free(spare);
free(bm_user);
free(bm_spare);
return -1;
}
/* Verify spare area */
for (i = 0; i < g_iPagesPerBlock; i++) {
if (verify_spare_page(&spare[i * 12]) < 0) {
sceIoClose(fd);
free(user);
free(spare);
free(bm_user);
free(bm_spare);
return -1;
}
}
/* Everything seems to be okay! Write to MS */
rv = sceIoWrite(fd, user, g_iBlockSize);
if (rv < 0) {
printf("Failed to write to %s: 0x%08x\n", IPLBIN, rv);
sceIoClose(fd);
free(user);
free(spare);
free(bm_user);
free(bm_spare);
return rv;
}
}
/* All okay */
sceIoClose(fd);
free(user);
free(spare);
free(bm_user);
free(bm_spare);
return 0;
}
/*
* Generates a proper spare area corresponding to the IPL and stores it in
* g_pIplSpare. The memory for g_pIplSpare is dynamically allocated.
*/
int
generate_spare_page(void)
{
int i;
int rv;
char spare[16];
char *d, *s;
/* First check if the actual IPL on this PSP conforms with the known
* format
*/
LockFlash(0);
rv = sceNandReadPages(4 * g_iPagesPerBlock, NULL, spare, 1);
UnlockFlash();
if (rv < 0) {
printf("Failed to read spare page %d: 0x%08x\n",
4 * g_iPagesPerBlock, rv);
return rv;
}
rv = verify_spare_page(spare);
if (rv != 0) return -1;
/* Allocate memory to hold all the spare pages for the IPL */
g_pIplSpare = malloc(g_iIplLen * g_iExtraSize); assert(g_pIplSpare);
/* Now we look at the source IPL and if it's an empty page we use the
* known empty page spare area (just 0xff with appropriate ECC) else
* we use the spare page that seems to be universal for IPL.
*/
for (i = 0, s = g_pIpl, d = g_pIplSpare; i < g_iIplLen * g_iPagesPerBlock; i++) {
if (is_empty_page(s)) {
memcpy(d, spare_for_ipl_block_map[1], sizeof(spare_for_ipl_block_map[1]));
} else {
memcpy(d, spare_for_ipl_block_map[0], sizeof(spare_for_ipl_block_map[1]));
}
s += g_iPageSize;
d += sizeof(spare_for_ipl_block_map[0]);
}
return 0;
}
/*
* Reads the contents of an IPL stored on the memory-stick to a memory buffer
* g_pIpl. The memory for the buffer is dynamically allocated.
* The contents of the correspsonding spare area is generated and stored in
* g_pIplSpare. The memory for the g_pIplSpare is dynamically allocated.
*/
int
read_ipl_from_ms(void)
{
int rv;
int fd;
SceIoStat st;
printf("Reading %s...\n", IPLBIN);
rv = sceIoGetstat(IPLBIN, &st);
if (rv < 0) {
printf("Failed to get status for %s: 0x%08x\n", IPLBIN, rv);
return -1;
}
g_iIplLen = (((st.st_size - 1) / g_iBlockSize) + 1);
g_pIpl = malloc(g_iIplLen * g_iBlockSize); assert(g_pIpl);
memset(g_pIpl, 0xff, g_iIplLen * g_iBlockSize);
fd = sceIoOpen(IPLBIN, PSP_O_RDONLY, 0777);
if (fd < 0) {
printf("Can't open %s for reading: 0x%08x\n", IPLBIN, fd);
free(g_pIpl);
return -1;
}
rv = sceIoRead(fd, g_pIpl, st.st_size);
if (rv < 0) {
printf("Failed to read %s: 0x%08x\n", IPLBIN, rv);
sceIoClose(fd);
free(g_pIpl);
return -1;
}
if (rv != st.st_size) {
printf("Could only read %d bytes from %s\n", rv, IPLBIN);
sceIoClose(fd);
free(g_pIpl);
return -1;
}
sceIoClose(fd);
/* generate spare pages data */
rv = generate_spare_page();
if (rv < 0) {
free(g_pIpl);
return rv;
}
printf("%s read correctly!\n", IPLBIN);
return 0;
}
/*
* Writes the block map information to the nand.
*/
int
write_block_map_to_nand()
{
int i;
int rv;
int success = 0;
printf("Writing IPL block mapping...\n");
/* Blocks 4-11 are written with the block mapping for the IPL */
for (i = 4; i < 12; i++) {
LockFlash(0);
rv = sceNandIsBadBlock(i * g_iPagesPerBlock);
UnlockFlash();
if (rv != 0) continue;
#ifndef FAKING
LockFlash(1);
rv = sceBandWriteBlockWithVerify(i * g_iPagesPerBlock,
g_pIplBM, spare_for_ipl_block_map);
UnlockFlash();
#else
rv = pspBandWriteBlockWithVerify(i * g_iPagesPerBlock,
g_pIplBM, spare_for_ipl_block_map);
#endif /* !FAKING */
if (rv != 0) {
printf("Writing the IPL block map to block %d failed: 0x%08x\n", i, rv);
} else {
success++;
}
}
if (success == 0) {
printf("Couldn't write the IPL block map to any block...\n");
printf("The PSP is dead...\n");
return -1;
}
printf("IPL block mapping correctly written!\n");
return 0;
}
/*
* Reads ipl.bin from memory stick and writes the contents to the nand, using
* block mapping to avoid bad blocks. Then writes the block mapping to the
* block mapping area of the nand.
*/
int
write_ipl_to_nand(void)
{
int i;
int rv;
int len;
char *user, *spare;
unsigned short *bm;
/* Read the source IPL from memory-stick */
rv = read_ipl_from_ms();
if (rv < 0) {
return rv;
}
g_pIplBM = malloc(g_iBlockSize);
memset(g_pIplBM, 0, g_iBlockSize);
len = g_iIplLen;
user = (char *)g_pIpl;
spare = (char *)g_pIplSpare;
bm = (unsigned short *)g_pIplBM;
printf("Writing IPL to nand...\n");
/* Sanity check */
if (len > 31) {
printf("IPL is too big!\n");
return -1;
}
/* IPL area covers block 16 to 47 */
for (i = 16; len > 0 && i < 47; i++) {
LockFlash(0);
rv = sceNandIsBadBlock(i * g_iPagesPerBlock);
UnlockFlash();
if (rv != 0) continue;
/* Point of no return! */
#ifndef FAKING
LockFlash(1);
rv = sceBandWriteBlockWithVerify(i * g_iPagesPerBlock,
user, spare);
UnlockFlash();
#else
rv = pspBandWriteBlockWithVerify(i * g_iPagesPerBlock,
user, spare);
#endif /* !FAKING */
if (rv == 0) {
/* Block correctly written! Add to block map */
*bm++ = (unsigned short)i;
len--;
user += g_iBlockSize;
spare += g_iExtraSize;
}
}
if (len != 0) {
printf("Couldn't write IPL correctly...\n");
printf("The PSP might now be dead :(\n");
return -1;
}
/* All okay */
printf("IPL correctly written\n");
rv = write_block_map_to_nand();
/* Free all the dynamically allocated memory */
free(g_pIpl);
free(g_pIplSpare);
free(g_pIplBM);
return rv;
}
int
user_selection(void)
{
SceCtrlData pad;
pspDebugScreenClear();
printf("Press:\n");
printf("<CROSS> to read the IPL from the nand to ms0:/ipl.bin\n");
printf("<TRIANGLE> to write IPL to the nand from ms0:/ipl.bin (DANGER)\n");
while (1) {
sceCtrlReadBufferPositive(&pad, 1);
if (pad.Buttons) {
if (pad.Buttons & PSP_CTRL_CROSS) {
/* read data from nand to MS */
return read_ipl_from_nand();
}
else if (pad.Buttons & PSP_CTRL_TRIANGLE) {
/* write data from nand to MS */
return write_ipl_to_nand();
}
}
}
return -1;
}
int
accept_liability(void)
{
SceCtrlData pad;
printf("writeIPL v0.1a (that's right, effing alpha!)\n");
printf("Written by Ryoko no Usagi in 2006\n\n");
printf("This software by itself WILL DESTROY your PSP!\n");
printf("Do NOT attempt to run unless you are prepared for that!\n");
printf("The AUTHOR ACCEPTS NO LIABILITY SHOULD YOU PROCEED!\n\n");
printf("If you read the above and agree to take full responsibility\n");
printf("press the <LEFT TRIGGER> to continue, otherwise please\n");
printf("turn off your PSP now!\n");
while (1) {
sceCtrlReadBufferPositive(&pad, 1);
if (pad.Buttons) {
if (pad.Buttons & PSP_CTRL_LTRIGGER) {
return user_selection();
}
else if (pad.Buttons & PSP_CTRL_RTRIGGER) {
printf("That's the RIGHT TRIGGERS...\n");
return 0;
}
else if ((pad.Buttons & PSP_CTRL_CROSS) ||
(pad.Buttons & PSP_CTRL_SQUARE) ||
(pad.Buttons & PSP_CTRL_TRIANGLE) ||
(pad.Buttons & PSP_CTRL_CIRCLE)) {
return 0;
}
}
}
return -1;
}
int
main(int argc, char *argv[])
{
pspDebugScreenInit();
SetupCallbacks();
sceCtrlSetSamplingCycle(0);
sceCtrlSetSamplingMode(PSP_CTRL_MODE_ANALOG);
g_iPageSize = sceNandGetPageSize();
g_iPagesPerBlock = sceNandGetPagesPerBlock();
g_iBlockSize = g_iPageSize * g_iPagesPerBlock;
g_iTotalBlocks = sceNandGetTotalBlocks();
/* Sanity check: all parameters should be standard */
if (g_iPageSize != 512) die("Non-standard page size, aborting!\n");
if (g_iPagesPerBlock != 32) die("Non-standard pages per block, aborting!\n");
if (g_iTotalBlocks != 2048) die("Non-standard NAND size, aborting!\n");
accept_liability();
#ifdef FAKING
if (myuserfd != -1) sceIoClose(myuserfd);
if (mysparefd != -1) sceIoClose(mysparefd);
#endif
printf("\nFinished. Use [HOME] to exit.\n");
sceKernelSleepThread();
return 0;
}
No, net yet :) I am not willing to sacrifice my psp that soon ;)
However working on a secure updater using some of the code ryoko's rabbit provided isn't a bad idea :)
BTW: I wonder if you can use sceKernelCanReleaseLibrary to unload all the modules in kernel mode instead of running the updater in VSH or UPDATER mode, it might not be safe tough and trying to flash using this method would be playing a dangerous game with the psp, I'd rather stick with loading the updater app in UPDATER mode or VSH mode, that would also free more ram than staying in kernel mode.
Anyway I'll keep you posted. If you want to code your own updater from the infos/datas posted on this thread/forum and share code/binaries/informations or whatever you like you are of course welcome to do so :)
It'll help if I am not the only one working on it ;) !
Again thanks for the piece of code Ryoko no usagi that's really helpful !
P.S. If anyone wants to provide infos regarding the use of the IPL:/ device (that can probably be used instead of Scenand to overwrite the IPL)
it would be great as I don't know much about this device (just that it's mounted and that the IPL:/ device path is hardcoded within the updaters' psp.psar files.)
Knowing how to use the IPL:/ device might actually be safer than using scenand to overwrite the IPL.
Still I don't know why sony inputed different ways of flashing the IPL especially as the iplupdater module (in the updaters) use the scenand API to write the IPL.
However working on a secure updater using some of the code ryoko's rabbit provided isn't a bad idea :)
BTW: I wonder if you can use sceKernelCanReleaseLibrary to unload all the modules in kernel mode instead of running the updater in VSH or UPDATER mode, it might not be safe tough and trying to flash using this method would be playing a dangerous game with the psp, I'd rather stick with loading the updater app in UPDATER mode or VSH mode, that would also free more ram than staying in kernel mode.
Anyway I'll keep you posted. If you want to code your own updater from the infos/datas posted on this thread/forum and share code/binaries/informations or whatever you like you are of course welcome to do so :)
It'll help if I am not the only one working on it ;) !
Again thanks for the piece of code Ryoko no usagi that's really helpful !
P.S. If anyone wants to provide infos regarding the use of the IPL:/ device (that can probably be used instead of Scenand to overwrite the IPL)
it would be great as I don't know much about this device (just that it's mounted and that the IPL:/ device path is hardcoded within the updaters' psp.psar files.)
Knowing how to use the IPL:/ device might actually be safer than using scenand to overwrite the IPL.
Still I don't know why sony inputed different ways of flashing the IPL especially as the iplupdater module (in the updaters) use the scenand API to write the IPL.
How? I have used psardump to extract the 2.6 and everything comes out as encrypted, plus it is only able to get part1 and part2 of the IPLMathieulh wrote:I doubt so because the scenand API is only "officially" used durring an update and the scenand API is called by the iplupdater module (located in the updater's data.psp) and that module doesn't seem to change from 1.50 to 2.60 updater.
Beside I don't know how the updater would be able to update a 1.50 fw using a faulty nand ECC correction. My guess is that the scenand API doesn't change from v1.00 to v2.60 but I might be wrong about that.
Maybe disassembling the iplupdater module would allow to get more knowledge on how sony uses the scenand API to overwrite the IPL tough.
I can't share the file due to copyright issues :/ so I suggest that you to extract (from a decrypted data.psp) the iplupdater module from a 2.60 updater and decrypt it. (just use an hex editor search for the ~PSP text string copy/paste it and save it as iplupdater.prx, then use a prx decryptor on 1.50) then dissasemble it and take a closer look.
if you have any knowledge on how to decrypt 2.6 modules please share
the iplupdater module isn't in the data.psar file but in the data.psp file !
You need a psp 1.50 to do the following:
- Extract the data.psp file from the updater's eboot (using an hex editor or pbp unpacker)
- Decrypt the data.psp file using a decryptor (it needs to be able to decrypt files with a file size of several Mbytes, I use my own decryptor to do so but there might be other decryptors (available publically) having the same ability, otherwise just code your own from the psardumper sources)
- Open the decrypted data.psp file using an Hexadecimal editor (such as hexworkshop)
- Locate this line : ~PSP......IplUpdater
- Copy from the line : ~PSP......IplUpdater (line 358028 ) to the next ~PSP header (do not copy the next psp header tough) (the next psp header should be ~PSP......sceSuspendCaneler it should be line 3631EC
So you should copy from line 358028 to line 3631EC
- Open a new document on your favourite hex editor and paste what you previously copied
- Save it as IplUpdater.prx (or any other name *.prx you like)
- Decrypt the IplUpdater.prx on your 1.50 using any prx decrypter app
- Now you can disassemble it play with it as you like ;) You can also follow the same procedure for every other modules
Cheers :)
About getting the data.psar content you have to do some reverse engeneering on the psar lib called scePSAR_Driver and located in the very same data.psp file, then you need to perform modifications to psardumper according to your previous discoveries on reverse engeneering the psar lib, you might also be able to use the psar lib directly but I doubt that's legal.
I wont help you there because of my lack of interests regarding the 2.60 fw files (witch are probably very similar to the 2.50 fw files).
You need a psp 1.50 to do the following:
- Extract the data.psp file from the updater's eboot (using an hex editor or pbp unpacker)
- Decrypt the data.psp file using a decryptor (it needs to be able to decrypt files with a file size of several Mbytes, I use my own decryptor to do so but there might be other decryptors (available publically) having the same ability, otherwise just code your own from the psardumper sources)
- Open the decrypted data.psp file using an Hexadecimal editor (such as hexworkshop)
- Locate this line : ~PSP......IplUpdater
- Copy from the line : ~PSP......IplUpdater (line 358028 ) to the next ~PSP header (do not copy the next psp header tough) (the next psp header should be ~PSP......sceSuspendCaneler it should be line 3631EC
So you should copy from line 358028 to line 3631EC
- Open a new document on your favourite hex editor and paste what you previously copied
- Save it as IplUpdater.prx (or any other name *.prx you like)
- Decrypt the IplUpdater.prx on your 1.50 using any prx decrypter app
- Now you can disassemble it play with it as you like ;) You can also follow the same procedure for every other modules
Cheers :)
About getting the data.psar content you have to do some reverse engeneering on the psar lib called scePSAR_Driver and located in the very same data.psp file, then you need to perform modifications to psardumper according to your previous discoveries on reverse engeneering the psar lib, you might also be able to use the psar lib directly but I doubt that's legal.
I wont help you there because of my lack of interests regarding the 2.60 fw files (witch are probably very similar to the 2.50 fw files).
In fact I don't think that the decryption keys changed either (I might be wrong tough) , at least I can decrypt my prx modules from my 2.60 games using the 2.00 key....
Otherwise if the key indeed changed you can get it form the mesg_led.prx file (that's probably how psppet retrived the other keys) but you need to extract the 2.60 psar first
If you did manage to get the 2.60 psar files from the data.psar file then you only need to retrieve the prx keys from the mesg_led.prx file
Otherwise if the key indeed changed you can get it form the mesg_led.prx file (that's probably how psppet retrived the other keys) but you need to extract the 2.60 psar first
If you did manage to get the 2.60 psar files from the data.psar file then you only need to retrieve the prx keys from the mesg_led.prx file
there are many 2.6 games that can be decrypted
with 2.0 keys ....mainly cuz the prxs are still using
old decryption process :P that might explain your
decryption of some of your 2.6 prxs but this
trend is slowly being removed such as games like
new syphon filter and any other new releases are
indeed now using this new process on all its prxs
but as for decryption keys are concerned i dont
believe the keys changed at all ;) ...just mud in front,
it seems, of the prxs ....new mangling, new distractions etc...
of course i might be completely wrong but thats for
time to tell
cheers
with 2.0 keys ....mainly cuz the prxs are still using
old decryption process :P that might explain your
decryption of some of your 2.6 prxs but this
trend is slowly being removed such as games like
new syphon filter and any other new releases are
indeed now using this new process on all its prxs
but as for decryption keys are concerned i dont
believe the keys changed at all ;) ...just mud in front,
it seems, of the prxs ....new mangling, new distractions etc...
of course i might be completely wrong but thats for
time to tell
cheers
10011011 00101010 11010111 10001001 10111010
I don't run iso loaders anyway as I buy all my games but I am still kinda pissed that I can't run the newer games on 1.50 because of that there are lots of games that I don't buy.
Beside I don't like that people hex edit nem's run umd to run iso on their 1.50 because they don't want to buy the UMD...
I doubt Nem will want to create a newer version of his run umd now...
If he does I suggest him to make the path a little more obscure so that people stop hex editing it....
It's because of piracy that Sony prevent users from using homebrews, it's also because of piracy that sony prevent people from running their games on the firmware revision they like...
What I can't also get is why Yoshihiro was banned from ps2dev because he created the first game loader from memory stick as a proof of concept and for educational purposes (people said that running a game form a memory stick couldn't be done at this time) and that he has been banned for 9 months because of it (and is still banned)
When people like MPH not only steal others people's concept but ask donations for it (by the use of a 10 minutes shareware version) for an app that is 100% Warez ! (The mph game loader v1.0 needed the exclusive use of an iso and couldn't run any games from an UMD, and it requires (the newer version still does) the decrypted 2.00/2.50fw witch is 100% Illegal and promote warez and piracy) and those people (MPH) do not get a single punishement or are not anoyed in any way....
I'd say either they remove yoshihiro's ban either they ban both... That's what I'd call fairness and justice.
Well let's go back to the original topic that is firmware knowledge sharing especially in the matter of creating our own updater shall we ?
Beside I don't like that people hex edit nem's run umd to run iso on their 1.50 because they don't want to buy the UMD...
I doubt Nem will want to create a newer version of his run umd now...
If he does I suggest him to make the path a little more obscure so that people stop hex editing it....
It's because of piracy that Sony prevent users from using homebrews, it's also because of piracy that sony prevent people from running their games on the firmware revision they like...
What I can't also get is why Yoshihiro was banned from ps2dev because he created the first game loader from memory stick as a proof of concept and for educational purposes (people said that running a game form a memory stick couldn't be done at this time) and that he has been banned for 9 months because of it (and is still banned)
When people like MPH not only steal others people's concept but ask donations for it (by the use of a 10 minutes shareware version) for an app that is 100% Warez ! (The mph game loader v1.0 needed the exclusive use of an iso and couldn't run any games from an UMD, and it requires (the newer version still does) the decrypted 2.00/2.50fw witch is 100% Illegal and promote warez and piracy) and those people (MPH) do not get a single punishement or are not anoyed in any way....
I'd say either they remove yoshihiro's ban either they ban both... That's what I'd call fairness and justice.
Well let's go back to the original topic that is firmware knowledge sharing especially in the matter of creating our own updater shall we ?
yes. lets
however, just because i mentioned a runumd mod or whatever doesnt mean i support piracy. i buy my games, back them up and run the runumd mods, im not gunna wait for any updates to play games ive payed money on.
also, if Yoshihiro created the 1st proof of concept games on the ms example, its because of him umd emulator, fastloader, devhook, hookboot etc was created.
cant argue with that.
however, just because i mentioned a runumd mod or whatever doesnt mean i support piracy. i buy my games, back them up and run the runumd mods, im not gunna wait for any updates to play games ive payed money on.
also, if Yoshihiro created the 1st proof of concept games on the ms example, its because of him umd emulator, fastloader, devhook, hookboot etc was created.
cant argue with that.