What this is about:
Yoshihiro used Idumper which up till today has been the only public (afaik) idstorage dumper.
However me and codes02 realized a critical error. We questioned 0x0051-0x0099 on how they were identical to 0x050.
Then we questioned what sceIdStorageReadLeaf returns.
Now this is the analysis:
sceIdStorageReadLeaf returns 0 if key exists. If key doesn't exist (doesn't matter what key) it returns a negative integer: -2147483611.
The purpose of that integer is unknown but is returned on every non-existant key.
Now for why 0x0051-0x0099 are identical to 0x0050. This is because when reading a non-existant key the buffer is not altered to 00 or anything. It is left in its current condition.
As the loop in IDDumper didn't clear buffer after every write this is why the key's are identical as no new data was written before sceIoWrite.
Now I have coded a fix for this. This app (mapIDS v3 FINAL) maps every single idstorage key, from 0x0001 to 0x9999.
There are a total of 127 existant IdStorage keys and the highest key number is 0x0140.
mapIDS v3 Final will go through 9999 IdStorageKeys. Although some might think this is a lot of stress reading does not affect the nand flash especially seeing that the keys are in series which lessens strain.
This has been tested over 20 times with no apparent negative effect.
This is why some people claim writing certain keys like 0x6F resulted in changes not staying.
I have attached an eboot and source.
Simple run the eboot and press O. After it has done ~1 minute tops, view the folder mapIDS for the dump of every existant idstorage keys and two text files listing the keys that exist and keys that dont in your PSP.
CREDITS: Stapol, Coder.
Notice: This does not write whatsoever to idstorage.