PSP Flash Chip Facts: The Good, the Bad and the Ugly

[Mathieulh]

Mods please delete this post, I clicked on the wrong button :/

[harleyg]

nice work on 1.50 > 1.00!
will you be releasing a downgrader/source soon?

[Mathieulh]

nice work on 1.50 > 1.00!
will you be releasing a downgrader/souce soon?

niiceee

They are not secured :/ Yoshihiro is actually working on a secured version and will release the binaries inclueding the srcs in a few days.

[harleyg]

can we really trust him...

[funetik]

I can't see any reason you shouldn't trust him, but that's up to you.

I've been watching this thread for an age. Good work guys :)

[Mathieulh]

A little update, I forgot to tell others about an important detail if you want to code the 1.00 downgrader on your own:

You will need to unload every modules before overwritting the prx using SceIo unless you use Scenand to overwrite those .
However trying to just unload every modules will just freeze your psp, I know how to bypass this limitation and I wish I could tell you more but that would compromise a MUCH more important project that yoshihiro is currently working on at this time. Fear not, yoshihiro will still work on coding a working and secure 1.00 downgrader as soon as he get a psp (all his psp are bricked atm) and finishes his current project (in fact the 1.00 downgrader itself isn't incompatible with this project.....) I Can't tell you more right now but I'll keep you in touch.

[chrismulhearn]

How would telling us more information "Compromise" someone else's project?

I think you've basically missed the entire point of this forum, and perhaps _communication_, in general.

I think what you meant to say is "I'd tell you, but I want to hoard this information for myself, so no one else beats yoshihiro to whatever he is writing".

None of us would have gotten _ANYWHERE_ with our PSPs had it not been for other people. Each of us is responsible for little tidbits of information. We all share our little tidbits of information, so that we can _all_ have _lots_ of information.

By withholding information, you are subverting that process, and slowing down PSP development on the whole.

Congratulations!

[groepaz]

i second that. posting comments about how you know stuff that others dont and how you cant tell it just makes you look stupid at best.

[dot_blank]

i say Ay.
compromising a project is understood
but others would greatly benefit if details were
explained in more technical terms ...

great information has been known just from
this topic, appreciation and much thanks

but holding details that i see no way would
compromise some new app really is not needed
and really does hamper developement for others

ps. so yoshi out for another psp eh ;)


[/i]

[Mathieulh]

Yoshihiro just got another psp indeed (it's not his, someone is lending him one)

I've red your posts and indeed I changed my mind, the problem isn't that I don't trust you, but indeed one developper here do not have my trust (did I say MPH ??) Anyway I think this is a communauty, thus we indeed need to exchange our informations even if they might compromise greater projects, that's why I'll give more infos on this post:

OK, let's sum up:

You want to manually downgrade/update a psp, in order to do that it's required to overwrite: -The PSP IPL (about 200 to 300 KB) using Scenand or the IPL:/ device)

- The flash0:/ files by erasing (or formatting usinf fat12 but I don't know how to do that) the older files and then copying the new ones (using SceIo).

Then you should theorically end up with the fw of your choice.

But there is more than theory needed here.

You need to unload every modules before flashing the fw files to flash0:/ (otherwise your psp get bricked because some prx can't be overwritten)

There is still one problem, you can't actually overwrite or copy every modules to flash0:/ using kernel mode ! Why ? Because some modules are actually in use and CANNOT be unloaded from kernel mode ! (the psp freezes) Then how the hell would the update from sony do the same job??
That's simple it's because it runs in VSH mode ! Thus that mode is required to manually update/downgrade

Then you would wonder how to get to VSH mode (that's the interesting part).

Well there are actually 2 possibilities :

-As actually a few know, the 2.00 tiff exploit isn't a user mode exploit but a vsh mode exploit, thus any code running from 2.00 (such as the eloader) run in VSH mode ! (you can try unloading all the modules in 2.00 it WILL work and wont freeze your psp (don't try to load flash modules, this wouldn't work....) And as the update runs in VSH mode, it's of course obvious that the Scenand function works in VSH mode as well ! But well we have a "small" problem here, due to the fact that we are currently running code from an exploit we can't use NIDs ! In order to downgrade/update from 2.00 you would need to know the 2.00 scenand syscalls (I can't help you here, I guess the only way to get those would be to log a working update under the 2.00 fw) this would be quite efficient for people using psp-1007 or new psp assembled in China (if they manage to get to 2.00 with those) that don't have the same NAND chip as the ones assembled in japan and don't work with the 1.50 eboot because the NAND manufacturer isn't identified and the updater doesn't perform scenandunlock (and you get a 80000025 error)

-Another way is to use swaploit to run an eboot from the ms0:/PSP/UPDATE/ folder on 1.50 (to get vsh mode rights) (That's what I did)

Finally you can simply use scenand to overwrite the flash0:/ part as well but that's kinda risky, I don't know if updating the ECC part is required by doing so, beside it's not sony's way of updating so I couldn't advise you more to be careful.

By the way I know how to write to the nand using Scenandwriteblocks if that's secured enough to write a small amount of data (such as the IPL) it's not to write a huge ammount of data (and it's still less secured than scenandwritepages) so if someone could comment the scenandwritepages function here I would be greateful.

Thanks in advance.




P.S. I would like to thanks everyone at ps2dev for their participation in this effort, I also would like to thanks especially Yoshihiro thanks to whom I got that far in the knowledge of the psp (I am more into the Dreamcast and the Gamecube Scenes actually....), but also Nem (kudos to him ;) ), Fanjita, Tyranid, Dot_blank, mrbrown, yoyofr, jmparis, Dr_Vegetable, Canti (aka pyrosama), ryoko_no_usagi, psppet, kuroneko, Edison Carter etc etc.....

And everyone I forgot :p

[Fanjita]

If the update runs in VSH mode, then why is there a 3rd mode, called "UPDATER"? ("GAME", "VSH", "UPDATER").

Also, I don't believe that sceNand is loaded in VSH mode, which is why we don't have the syscalls for it. Obviously it might possible to load it and determine the syscalls, but it just doesn't seem right.

Still, thanks for sharing this info, it's all food for thought.

[groepaz]

If the update runs in VSH mode, then why is there a 3rd mode, called "UPDATER"? ("GAME", "VSH", "UPDATER").

mmmh what "mode" are you referring to? not cpu mode i guess? :)

i'd think that "updater" mode is simply a stripped down running environment, with as few modules loaded as possible. and cpu mode would have to be "kernel".

[ryoko_no_usagi]

Prototypes for sceNand functions:

Code: Select all

int sceNandInit();
int sceNandEnd();
int sceNandSuspend();
int sceNandResume();
int sceNandSetWriteProtect(int protectFlag);
int sceNandLock(int writeFlag);
void sceNandUnlock(void);
int sceNandReset(int flag);
int sceNandReadId(void *buf, u32 count);
int sceNandReadAccess(u32 ppn, void *user, void *spare, u32 len, int flags);
int sceNandWriteAccess(u32 ppn, void *user, void *spare, u32 len, int flags); /* writes to nand */
int sceNandReadExtraOnly(u32 ppn, void *spare, u32 countr);
int sceNandReadStatus(void);
int sceNandReadPages(u32 ppn, void *user, void *spare, u32 count);
int sceNandWritePages(u32 ppn, void *user, void *spare, u32 count); /* writes to nand */
int sceNand_e05ae88d(u32 ppn, void *user, void *spare, u32 count);
int sceNand_8932166a(u32 ppn, void *user, void *spare, u32 count); /* writes to nand */
int sceNand_c478c1de(u32 ppn, void *user, void *spare, u32 count);
int sceNand_badd5d46(u32 ppn, void *user, void *spare, u32 count); /* writes to nand */
int sceNandDetectChip();
int sceNandWriteBlockWithVerify(u32 ppn, void *user, void *spare); /* writes to nand */
int sceNandReadBlockWithRetry(u32 ppn, void *user, void *spare);
int sceNandVerifyBlockWithRetry(u32 ppn, void *user, void *spare);
int sceNandIsBadBlock(u32 ppn);
int sceNandDetectChipMakersBBM(u32 ppn);
int sceNandTestBlock(u32 ppn); /* writes to nand */
int sceNandGetPageSize(void);
int sceNandGetPagesPerBlock(void);
int sceNandGetTotalBlocks(void);
int sceNandCalcEcc(const void *spare); /* spare area of a single page starting from byte 4 */
int sceNandVerifyEcc(void *spare, u16 ecc, int flag);
int sceNandCollectEcc(void *spare, u16 ecc);

Since sceNandWriteBlock() just calls sceNandWritePages() I fail to see how it's really that much less secure :)

Code: Select all

int
sceNandWriteBlockWithVerify(u32 ppn, void *user, void *spare)
{
	int i = 0;

	do {
		rv = sceNandEraseBlockWithRetry(ppn);
		if (rv >= 0) {
			rv = sceNandWritePages(ppn, user, spare, g_iPagesPerBlock);
		}
		if &#40;rv < 0&#41; return rv;

		if &#40;sceNandVerifyBlockWithRetry&#40;ppn, user, spare&#41; >= 0&#41; return 0;
	&#125; while &#40;++i < RETRY_MAX&#41;;
	return rv;
&#125;

(sceNandWritePages in turn calls sceNandWriteAccess...)

With sceNandWritePages you have to erase the block manually of course, before the first page write, since writing can only change a set bit to zero and not the other way. Bad blocks must be mapped (use sceNandIsBadBlock() function, not sceNandTestBlock() since the latter erases the block in question!) and it's also important to remember to verify if the write was okay (check return value). If there is an error (invalid block) a different block must be used.

The block mapping for the IPL seems to be:

Physical blocks 4-11 seems to be allocated to hold mapping information. Each block contains the same information, for redundancy presumably. If one of these blocks becomes invalid, the next one is used etc. If all these blocks are done in, I guess the PSP might be dead...

The contents of these blocks specify the blocks used for IPL. For my PSP they are:

Code: Select all

00010000  10 00 11 00 12 00 13 00  14 00 15 00 16 00 17 00  |................|
00010010  18 00 19 00 1a 00 1b 00  1c 00 1d 00 00 00 00 00  |................|

If for instance block 0x0012 goes bad, I guess the above would be remapped to read:

Code: Select all

00010000  10 00 11 00 1e 00 13 00  14 00 15 00 16 00 17 00  |................|
00010010  18 00 19 00 1a 00 1b 00  1c 00 1d 00 00 00 00 00  |................|

and the contents of block 0x0012 would be stored in block 0x001e instead.

If reading a dump from a live PSP, it is important to verify the ECC. Hardware automatically reclaims single-bit errors in the user-area, but for the spare area this must be done manually.

Depsite my earlier enthusiasm for rewriting the whole nand with sceNand functions, I must now caution against this: it seems to me that certain characteristics of the nand might be stored in certain positions, and indiscriminatingly overwriting this with information from another nand could lead to bad results...

[Mathieulh]

wow ! Ryoko that's what I call a useful post !


Well SceIo IS Very dangerous to use (unlike what I tought in the first place) because we if a single module isn't unloaded correctly your psp get bricked because it can't create the new prx files in flash0:/ (I've been lucky with my first try of downgrading to 1.00, I wont try again unless I have a real secure way of flashing, I might not be that lucky next time)

A "safer" way would be to write the flash0:/ area as well as the IPL using scenand (do not write any other area !) with a flasher capable of updating the ECC Area (thanks to yoshihiro for the idea :) ), then whether modules are running or not wouldn't matter and it could be possible from both kernel mode and VSH mode (afaik the update indeed runs in VSH mode and even uses some vsh functions, it's the first time I ever heared of a "UPDATER" mode, if it does exist I don't know what it's for because afaik the updater does not use it (I might be wrong tough)

BTW the scenand syscalls weren't found in 2.00 because no one actually got them from a running program using the Scenand API (that's the whole point of logging an update running under the 2.00 fw I guess....) And of course because no one thought it was possible to use that API in VSH mode :/

If you plan to log an update yourself here is a small reminder :

Also, yoshihiro gave me the information that in order to run an update from an running eboot you need to reload the vsh modules as the updater needs those because unless the eboot runs from ms0://PSP/GAME/UPDATE/ the vsh modules get unloaded.

BTW: You still need to be careful doing that, the logging driver mustn't use too much ressources otherwise it's very likely that the updater hangs durring its process (and brick your psp)

Of course since the homebrews code running from 2.00 run in VSH mode and still have the required vsh modules loaded it might be easier to run the updater on that specific fw version as you wouldn't have to reload the vsh modules (you couldn't anyway as vsh mode doesn't allow to load flash modules but only to unload those....)

[Mathieulh]

anything running in the update folder runs in VSH mode which gives a few more permissions and functions.

BTW: I just found what Tyranid wrote about the update mode (earlier on this very thread)

I also ran a NAND dumper from the ms0:/PSP/GAME/UPDATE folder (using swaploit on 1.50) and it did work I had a nice dump ;)

I also downgraded my 1.50 running the my binary from that folder, but I might have been extreamely lucky and the modules just all unloaded in kernel mode ! (I still doubt it tough)

P.S. I am not sure you can get to VSH mode on 1.50 using Kxploit because the Vshell might believe that you try to run an eboot from the "ms0:/PSP/GAME/UPDATE%" folder instead of "ms0:/PSP/GAME/UPDATE", that's why I am using swaploit instead (although using kxploit might still allow to run in VSH mode as the elf is loaded from the "ms0:/PSP/GAME/UPDATE" folder, but who knows what might occur ?

[groepaz]

there is no point in trying to use obscure methods to run stuff in vsh mode on 1.5 - you can just run the program in kernel mode.

[Mathieulh]

there is no point in trying to use obscure methods to run stuff in vsh mode on 1.5 - you can just run the program in kernel mode.

Did you find a way to unload every modules in kernel mode without freezing the psp ?

I only managed to do it from VSH mode (the psp doesn't freeze in VSH mode and then you can use SceIo to overwrite (erase and create) the flash0 prx files (all of them) )

The problem remain in the fact that when running an application in Kernel mode lot of flash modules are loaded (others are unloaded tough) and I can't manage to unload these modules without freezing the psp


The same problem occured when Yoshihiro worked on the BFM (a firmware loader) he couldn't unload all the modules while running in kernel mode without making the psp freeze (while he could actually unload those in the 2.00 when he tested to run his BFM on that fw revision, however the 2.00 fw hack (VSH mode) didn't allow him to load flash modules from the MS)

[dot_blank]

ryoko_no_usagi: absolutely wonderful post :D

great analysis man, thanx for the usefull tips
on using between write with pages or blocks
the prototypes are excellent and should be in pspsdk
in no time ....although the checking of ECC needs
to be tested completely for any chance of error

Mathieulh: if you can unload all modules in kernel mode
(minus loadexec.prx as this is always needed :P)
please do share ..as its one pesky problem and
much thanx to you too... i believe if unloading of kernel
modules is handled from ME then this problem can
be rectified ...the means to get to that point is the fog
that is in front of us

logging of what EXACTLY psp does during boottime is highly
needed ....if this information is already available ..please
free me from my ignorance ...psp is doing more than just
load some prxs and go to vsh and kernel memspace has
activity that probably is not known technically yet

thanx again fellas
cheers

ps.ryoko: so who is the pretty lady in your ever changing avatar ;)

[TyRaNiD]

Incidently as per previous discussion you _should_ be able to load a new executable in update mode by loadexec'ing it and in the LoadExec parameters structure setting the key value to "updater". Not in the mood to test it mind you ;) You _should_ also be able to load in vsh mode by setting it to "vsh" but you will need to relocate your executable so it doesn't conflict with paf etc.

Based on the module list though the only difference to vsh mode is it doesn't load the user mode vsh libs, it certainly doesn't remove the core kernel modules.

[Timale-Kun]

ps.ryoko: so who is the pretty lady in your ever changing avatar ;)

ryoko is a Japanese girl's name, the pretty lady, might be her^^. great job for all u. I'm following this Thread on background^^. but even if i cannot understand the whole things, I can see that's is growing kindly, Stop disturbing U^^

[Mathieulh]

Incidently as per previous discussion you _should_ be able to load a new executable in update mode by loadexec'ing it and in the LoadExec parameters structure setting the key value to "updater". Not in the mood to test it mind you ;) You _should_ also be able to load in vsh mode by setting it to "vsh" but you will need to relocate your executable so it doesn't conflict with paf etc.

Based on the module list though the only difference to vsh mode is it doesn't load the user mode vsh libs, it certainly doesn't remove the core kernel modules.

That's a great piece of information, I didn't know how to access vsh mode from kernel mode, this will easy the whole process, let's hope we can unload the kernel modules doing so :)


Ryoko: Anata wa nihonjin desuka ? Nihongo ga shaberu ka ?

[Mathieulh]

**Please delete that post**

[ryoko_no_usagi]

....although the checking of ECC needs
to be tested completely for any chance of error

Oops. Yes you are right, there is an error. I wrote that list quickly from my code (I have source for most of these functions, I probably can't share that due to copyright restrictions, but feel free to ask if something's unclear) and I seem to have slipped up...should be:

Code: Select all

int sceNandCalcEcc(void *spare);
int sceNandVerifyEcc(void *spare, u16 ecc);
int sceNandCollectEcc(void *spare, u16 ecc);

sceNandCalcEcc() reads 8 bytes from spare and calculates and return a 12-bit ECC value.

sceNandVerifyEcc() reads 8 bytes from spare and compares it with the given ECC and returns: 0 for no error, -1 for corrigible single-bit error, -2 for single-bit error in the ECC value, and -3 for multiple-bit errors (not corrigible).

sceNandCollectEcc() does the same thing, and in addition somethign I don't quite understand: it XORs the last byte in spare with 0x80 (?!) Possibly I'm overlooking something here (my first guess was that it would correct a single-bit error, but far as I can tell, that's not actually what happens...)

ps.ryoko: so who is the pretty lady in your ever changing avatar ;)

But it's Usagi's lovely mistress of course :)

Anata wa nihonjin desuka ? Nihongo ga shaberu ka ?

僕は日本人じゃないが良子は日本人だ。でも日本語が少し話せる。
boku wa nihonjin ja nai ga ryoko wa nihonjin da. demo nihongo ga sukoshi hanseru.
[I'm not Japanese but Ryoko is. But I can speak a little.] Edited cause it was confusing before...

[Mathieulh]

I wonder if sceNandTestBlock wouldn't be to recover a bad block ?
Also what are sceNand_e05ae88d , sceNand_8932166a , sceNand_c478c1de and sceNand_badd5d46 for ?

what are the differences between sceNandDetectChipMakersBBM and sceNandDetectChip ?


Usagi San: That's ok but I really prefer to type in English (mondai wa Furansujin keyboard ga tada tsukaimasu, soshite kana to kanji ga dekimasen, tada no romanji dake da :/) Anyway Ryoko seems to be a very beautiful woman ;) No wonder you like to be her rabbit :)

[moonlight]

can we really trust him...

Yes you can, if what you want is a bricked psp, you can really trust yoshihiro, he is an expert in doing that lol

[dot_blank]

ryoko: thanx for clearing that up ...did seem funny
to me before ...makes perfect sense now

as for sceNandCollectEcc() that is indeed a strange
happening with comparing last byte of spare with 0x80
my guessing is that it must change with different
firmware versions ...more testing should be done
although i have only 1.5 to test with and it is the same
maybe there is a difference with 1.0 etc...

moonlight: that comment is irrevelant now, he might be
a master of bricking psps, but some of us might know what
they are doing ...but one does learn from their mistakes
...and alot is learned when making alot of mistakes :P
most info from this thread would not be possible if there wasnt
someone who risked their psps to gain knowledge for others
in this community ...so i guess we should thank yoshi for his never
ending bricks :)

ps. such a lovely mistress indeed mr.rabbit :)

[moonlight]

Anyway logging an update durring its updating process might be very helpful and gives us more intels than spending hours on a disassembled updater's elf.

BTW: You still need to be careful doing that, the logging driver mustn't use too much ressources otherwise it's very likely that the updater hangs durring its process (and brick your psp)

Well, one could use the sceNandSetWriteProtect or sceNandLock in the logger before logging the update (and obviously hooking all sceNandSetWriteProtect
and sceNandLock calls inside the update). In this way, *maybe* it would be a secure process since it wouldn't write to the flash.

dot_blank, that comment was just a stupìd joke (it was night and i was tired), don't get it too serious.

[ryoko_no_usagi]

I wonder if sceNandTestBlock wouldn't be to recover a bad block ?

A bad block is a physical deficiency in the flash so no, it can't be recovered. sceNandTestBlock erases the block and tries to verify that all the bits are set. However, this should not be done for initial bad block that Samsung through special tests have determined can't be guaranteed to maintain integrity, these are marked by byte 5 in the spare area being set to something different than 0xff. However, it might be possible to erase this information and Samsung specifies that there is no way to recover it unless it has been saved somewhere else, and it may be impossible to set the bad block marker again.

Also what are sceNand_e05ae88d , sceNand_8932166a , sceNand_c478c1de and sceNand_badd5d46 for ?

They just call sceNandReadAccess (e05ae88d + c478c1de) and sceNandWriteAccess(8932166a + badd5d46) with different flags set. I will have to get back with more information and those flags cause I'm not quite sure about them, but 0x01 = read whole spare area including user ECC and don't perform hardware ECC on user part (it seems).

what are the differences between sceNandDetectChipMakersBBM and sceNandDetectChip ?

sceNandDetectChipMakersBBM(u32 ppn) is a little "weird." The name suggests that it will detemine what kind of bad block management the manufacturer has recommended (Samsung's policy I think is to maintain a list of bad blocks). All this function does however, is to read the specified page and examine byte 5 in the spare area (initial bad block indicator) and if it's different from 0xff it returns 1 else 0 (or error if reading went wrong.) There is also a sceNandDumpWearBBMSize() function but I haven't examined it yet.

sceNandDetectChip() is more interesting though: this one reads the manufacturer id and the device code and looks up the characteristics of the flash in an internal list:

Code: Select all

typedef struct {
        u8      Id[2];
        u16     PageSize;
        u16     PagesPerBlock;
        u32     TotalBlocks;
} nand_properties_t;

nand_properties_t manufacturers[] = {
        { { 0x98, 0xe6 }, 512, 16, 1024 },
        { { 0x98, 0x73 }, 512, 32, 1024 },
        { { 0x98, 0x75 }, 512, 32, 2048 },
        { { 0x98, 0x76 }, 512, 32, 4096 },
        { { 0x98, 0x79 }, 512, 32, 8192 },
        { { 0xec, 0xe6 }, 512, 16, 1024 },
        { { 0xec, 0x73 }, 512, 32, 1024 },
        { { 0xec, 0x75 }, 512, 32, 2048 },
        { { 0xec, 0x76 }, 512, 32, 4096 },
        { { 0xec, 0x79 }, 512, 32, 8192 },
        { { 0xec, 0x71 }, 512, 32, 16384 },
        { { 0xec, 0xdc }, 512, 32, 32768 },
        { { 0xec, 0x36 }, 512, 16, 1024 },
        { { 0xec, 0x33 }, 512, 32, 1024 },
        { { 0xec, 0x35 }, 512, 32, 2048 },
        { { 0xec, 0x36 }, 512, 32, 4096 },
        { { 0xec, 0xec }, 512, 32, 8192 }
};

This one is called from sceNandInit() to initialize global variables like g_iPagesPerBlock, g_iTotalBlocks etc.

Does this suggest that the flash-controller is capable of handling these larger flashes? Intriguing possibilities :)

[Mathieulh]

Anyway logging an update durring its updating process might be very helpful and gives us more intels than spending hours on a disassembled updater's elf.

BTW: You still need to be careful doing that, the logging driver mustn't use too much ressources otherwise it's very likely that the updater hangs durring its process (and brick your psp)

Well, one could use the sceNandSetWriteProtect or sceNandLock in the logger before logging the update (and obviously hooking all sceNandSetWriteProtect
and sceNandLock calls inside the update). In this way, *maybe* it would be a secure process since it wouldn't write to the flash.

dot_blank, that comment was just a stupìd joke (it was night and i was tired), don't get it too serious.

I think it's useless as the NAND is allready write protected (from Scenand) thus the update allready uses scenandunlock and scenandsetwriteprotect to enable the nand writting, and even if it did not, there would be no way to know if the updater would figure out that the nand is write protected witch in that case would proceed with the flashing and use SceIo to replace the flash0:/ files, then you would end up with a psp having the wrong IPL version and of course it wouldn't boot.


About logging the update:
I think that as far as the logging process uses less than 1MB of ressources it should be ok, but anything could still occur, it's a risk someone has to take.

Also sceNandDetectChip() is beeing used in the updater as well, and probably compared to a manufacturer list embebed within the updater, if it doesn't recognize your NAND chip it wont update. That's probably why psp-1007 users can't downgrade using the 1.50 updater.

[Mathieulh]

Can anyone post a sample of a scenand writter app using scenand to write the IPL as well as ECC check ? Cause I haven't figure out how to use the ECC correction feature of scenand

Then all we'd have to do is:

- Run an elf in UPDATER mode (or VSH mode)
- Unload the modules
- Ensure all the modules are indeed unloaded
- Perform a checksum on the targeted fw and IPL
- If doesn't match then stop the app
- If matches then proceed
- Use scenand with ECC correction to overwrite the IPL (that's the part I didn't fugure out yet, I don't know a thing about scenand ECC correction features and I want to ensure the flasher is safe in case of bad blocks)
- Use SceIo to overwrite flash0
- Use SceIo to overwrite flash1 (optional)
- Reboot

Then you have a safe updater/downgrader to the version you like