J'ai trouvé la traduc du fichier flash rom qui est en jap je vous file la traduc' pour nos amis qui parlent anglais pour les gens francais a 100% il va falloir attendre que je fasse la traduc disponible environ dans deux heures ^^
traduction Japonais->Anglais :
These are a set of Booster's considerations regarding the danger of accessing the PSP's internal FlashROM.
---------------------------------------
Structure of the PSP's Internal FlashROM
---------------------------------------
The PSP has 32 MB of internal NAND FlashROM.
This is split into three areas: IPL, IDStorage, and MASSstorage.
The IPL area is what holds the program information that is necessary to make the PSP start. If this is damages, the PSP will not start (i.e., "bricked" in the vernacular.)
It appears that the IDStorage area is where the OpenPSID, MAC address, serial number, and other such information is recorded. Not much detail is known about this area.
The MASSstorage area is where the files that are accessed as "flash0" and "flash1" are stored. There is functionality for ECC and bad block physical/logical changes, but the format differes from something like the popular SmartMedia.
Logically, it's compatible with a DOS/V HDD image, and it's split into the following four partitions under 1.50:
24560KB:'flash0:' area
4080KB:'flash1:' area
1008KB: empty, use is unknown
944KB: empty, use is unknown
---------------------------------------
The Fragile Nature of the PSP's Internal FlashROM
---------------------------------------
Accessing the internal FlashROM is prohibited from usermode programs.
On the other hand, other than file access, it's possible to read and write to the entire area from kernel mode programs using the physical driver as a medium. Furthermore, it's possible to bypass the driver and obtain direct hardware access, but it's simple to end up rendering the PSP unusable.
The maker (i.e., Sony) should have the ability to restore an unusuable (bricked) PSP, however, this method is currently unknown to ordinary users, thus not much can be done other than returning the unit to the manufacturer or having it modded.
Then, it ended up that homemade software (homebrew) kernel mode software could be run normally from a memory stick due to a weakness in FW 1.00/1.50.
Do we know what kind of danger we're exposed to by running software from unknown sources without thinking about it?
Isn't it probably better to have an environment where software that can be run normally is limited to usermode access and that programs requiring kernel mode access should be explicitly run?
By searching for the following functionality in programs that are to be executed, we can determine the possibility of virus that could destroy the FlashROM.
1. The module attributes are set to kernel mode.
2. The program is linked to the "sceMScm_driver" library.
3. The program is linked to the "LflashFatfmt" library.
4. There are keywords for "flash", "lflash", or "flashfat" present
5. The program is linked to the API for sceIoAssign/sceIoUnassign
6. The NANDFlash hardware register addresses are loaded.
---------------------------------------
The Danger Involved in Rewriting Flash0
---------------------------------------
Flash0 contains files that are required to run the PSP and XMB. No rewriting occurs during normal use.
The PSP's startup is run by the IPL program which is written to the IPL area, but it's necessary that the version is compatible with the flash0 file.
Once flash0's pspcnf_tbl.txt, pspbtcnf.txt, and the files mentioned in pspbtcnf.txt are completed, flash1's registry is checked for consistency or created from scratch, other files necessary for starting the XMB are gathered and the system can startup. If any one of these steps cannot be completed properly, the PSP won't start up.
For programs to run from memory stick, it's also necessary to have the files that are mentioned in pspbtcnf_game.txt. Without getting to this point, homebrew wouldn't run.
I'm yet to verify this, but it's thought that if you use Dark_Alex's custom firmware proof of concept "return" programs can be run even if the registry or certain files required by the XMB are not present. At this time, running devhook from flash also misappropriates this technique.
Dark Alex
My gratitude to Dark_Alex!
Ordinarily, flash0 is mounted read-only so writing is protected against, however, it is possible to re-mount from kernel mode and obtain write access.
Since flash0 is normally read-only, it's thought that as long the files necessary for running are protected, it's ok if the empty area gets used up; although this is totally a guess.
There's 9290 KB of free space in flash0 in FW 1.50.
When devhook 0.46.0000 uses the fonts and tables for 2.71, the empty space goes down to 4,624 KB.
---------------------------------------
The Danger Involved in Rewriting Flash1
---------------------------------------
Flash1 holds the registry and other settings files and is frequently written to in common usage.
Since flash1 is put in a different partition from flash0, flash0 won't be harmed even if the power is cut while accessing flash1.
However, it's possible that the registry files in flash1 can be damaged and if the situation is such that they cannot be re-created, it can become such that the FW1.50 re-initialization and restart can loop and it won't start up. If you fall into this situation:
1. Your file system ended up being broken by interrupting power during file writing.
2. Some other file filled up the space where the now destroyed registry was.
The file system was purposefully destroyed.
one of these three things probably happened.
Regarding the initialization of the registry in FW1.50, two methods have been confirmed that destroy other files on flash1 and appear not to format and so on.
When dealing with flash1, if you protect the existence of the registry files and empty space sufficiently, this won't happen.
Since the registry in flash1 is accessed quite frequently, it is dangerous to remove the ac adapter or batteries without using the power switch when the PSP is in use.
Moreover, if the FlashRom device is put into a writer-protected condition, the PSP won't run.
The empty space in flash1 at startup time in FW1.50 is 3808KB.
