Info below compiled from various sources, including: adrahil, Chilly Willy, FreePlay, harleyg, jas0nuk, l_oliveira, Mathieulh, Saben, SilverSpring, Squirrel, vb_master

The following keys are backed up separately from the IdStorage, non-indexed: 4, 5, 6, F, 30-3F, 40-46, 50, 140

NOTE: Slim v1 = TA-085 baryon 22B200, Slim v1.1 = TA-085 baryon 234000, Slim v2 = TA-088, Fat v4 = TA-086

* = key is the same per model, but not necessarily the same in every PSP
* = key is unique to each PSP
* = key is partially unique (e.g. WLAN region are all similar but with a few bytes changed for different regions)

General info on each key
* 0x4 - Baryon settings/information - extra data added since Slim v1
* 0x5 - Clockgen/I2C setup commands - invalidating the first four bytes enables 1.50 to boot on TA-082+ by preventing an IPL crash due to unsupported hardware
* 0x6 - Battery, CPU frequency and general power settings - extra data added since Slim v1
* 0x7 - Unknown usage (exists since Fat v4/Slim v1) - changed in Slim v2
* 0x8 - Brightness hardware control (exists since Fat v4/Slim v1) - changed in Slim v1.1 and again in Slim v2 - if this is detected, the data in them is used to control the brightness levels. If not, the board acts as a TA-079 which causes brightness level issues with the new hardware.

* 0x10 - MagicGate
* 0x11 - MagicGate
* 0x12 - MagicGate
* 0x13 - MagicGate
* 0x40 - Contains the 0x5 bytes at 0x88 from key 0x10
All of the above are required for MagicGate to work

* 0x41 - USB (Driver type identifier) - slightly different since Slim v1
* 0x43 - USB (Device ID) - slightly different since Slim v1

* 0x44 - WLAN MAC Address (can be rebuilt using Noobz MAC Address Fixer)
* 0x45 - WLAN Region (can be rebuilt using KeyCleaner)

* 0x47 - Default parental lock level (first byte is 0x09, rest is empty)

* 0x50 - Serial number (not used since TA-082)
* 0x51 - Firmware the PSP shipped with, and unknown unique data (exists since Fat v4/Slim v1)
* 0x52 - Unused by PSP - Mostly the same per PSP except for slight variations - could be manufacturing info (exists since Slim v1)
* 0x54 - Default XMB background colour - first 3 bytes: 02 00 02 in PSP-200X IS, 02 00 00 in PSP-200X PB (exists since Slim v1)

* 0x100 - DNAS, VSH & Internet browser region, ad-hoc region (if missing, official updaters cannot run - error CTA80000025)
* 0x101 - OpenPSID (non-indexed duplicate at [location of original + 0x8000])

* 0x102 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x103 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x104 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x105 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x106 - UMD (non-indexed duplicate at [location of original + 0x8000])
102-106 is a continuous key which the UMD drive uses. Any invalid ones (missing, edited, or from another PSP) will prevent the UMD sectors being decrypted, resulting in a Disc Read Error

* 0x120-0x126 - backup of respective 0x0100-106 key

* 0x140 - Unknown unique data

More info on keys 4-8
Keys 4-8 are setup data for various devices. Their structure is as follows:typedef struct {
u32 signature; // "Clkg", "Bryn", etc
int type; // always 00000001 so far
int datalen; // length of data starting at 0x10
u32 hash; // hash of data from 0x10 to 0x10+datalen
u8 databuf[0x1F0]; // data used for hardware init/control
} SceIdStorageLeaf;

Since official updater 3.30, every updater has a hidden module called sceChkDegeneration which checks the signatures of these keys and produces an error if the signature is incorrect:

DRNFFFFFFD8 = key 0x4 missing
DRNFFFFFFD7 = key 0x4 header is not "n y r B" (in hex: 6E 79 72 42)
DRNFFFFFFCE = key 0x5 missing
DRNFFFFFFCD = key 0x5 header is not "g k l C" (in hex: 67 6B 6C 43)
DRNFFFFFFC4 = key 0x6 missing
DRNFFFFFFC3 = key 0x6 header is not "r d D M" (in hex: 72 64 44 4D)

Additional checks in TA-086:
DRNFFFFFFB9 = key 0x7 header is not "D a P A" (in hex: 44 61 50 41)
DRNFFFFFFB0 = key 0x8 missing
DRNFFFFFFAF = key 0x8 header is not "p D C L" (in hex: 70 44 43 4C) - for this error, creating a fake key 8 is not enough as this will result in the brightness not working at all, a real key must be used.

KIRK commands
IdStorage keys are created by one of the KIRK commands, so we need to get as much information as we can about KIRK (aka semaphore hardware decryption)

0x01 - PRX decryption
0x02 - ???
0x03 - ???
0x04 - Scramble, savedata (chnnlsv) [paired with 0x7]
0x05 - Unsigcheck, savedata (chnnlsv) [paired with 0x8]
0x06 - ??? [paired with 0x9]
0x07 - Descramble [paired with 0x4]
0x08 - Sigcheck, savedata (chnnlsv) [paired with 0x5]
0x09 - ??? [paired with 0x6]
0x0A - ???
0x0B - SHA-1
0x0C - ??? (memab)
0x0D - ??? (memab)
0x0E - savedata (chnnlsv), memab, semawm, DbsvrGetData
0x0F - ???
0x10 - ??? (memab)
0x11 - ??? (memab)
0x12 - IdStorage checks

GetPsCode (0x100 region key) return codes
List compiled by harleyg/Slash

Region code is returned from sceChkregGetPsCode, in the format 01 00 XX 00 01
Model Country Region GetPsCode Comments
--------------------------------------------------------------------------
PSP-1000 Japan 2 0x03 Standard Pack
PSP-1000CW Japan 2 0x03 White Giga Pack
PSP-1000K Japan 2 0x03 Value Pack
PSP-1000KCW Japan 2 0x03 White Value Pack
PSP-1000G1 Japan 2 0x03 Giga Pack
PSP-1000G1CW Japan 2 0x03 White Giga Pack
PSP-1001K North America 1 0x04 Value Pack
PSP-1001G1 North America 1 0x04 Giga Pack
PSP-1002K Australia/New Zealand 4 0x09 Value Pack
PSP-1002G1 Australia/New Zealand 4 0x09 Giga Pack
PSP-1003K UK 2 0x05 Value Pack
PSP-1003G1 UK 2 0x05 Giga Pack
PSP-1004K Europe 2 0x05 Value Pack
PSP-1004G1 Europe 2 0x05 Giga Pack
PSP-1005K Korea 5 0x06 Value Pack
PSP-1005G1 Korea 5 0x06 Giga Pack
PSP-1006CW Hong Kong/Singapore 5 0x0A White Giga Pack
PSP-1006K Hong Kong/Singapore 3 0x0A Value Pack
PSP-1006G1 Hong Kong/Singapore 3 0x0A Giga Pack
PSP-1007K Taiwan 3 0x0B Value Pack
PSP-1007G1 Taiwan 3 0x0B Giga Pack
PSP-1008K Russia 5 0x0C Value Pack
PSP-1008G1 Russia 5 0x0C Giga Pack
PSP-1009K China 6 0x0D Value Pack
PSP-1009G1 China 6 0x0D Giga Pack

I've been thinking about this and it got me wondering how they do the initial burn of idstorage. Is it possible that a standard firmware has a function someplace to setup id storage on a new unit, or do you think the factory jig-kick process does this while installing the IPL and firmware?

I've been thinking about this and it got me wondering how they do the initial burn of idstorage. Is it possible that a standard firmware has a function someplace to setup id storage on a new unit, or do you think the factory jig-kick process does this while installing the IPL and firmware?

The latter. The Pandora's an awesome great tool but it's been set up from scratch. Sony's magic stick is different and probably includes the code to regenerate IDStorage. But as long as there's no complete dump of it but just the crippled ones floating around the net, chances are few of reversing it. So the other option is solid research and that's what Jas0nuk is proposing.

There's probably some unique ID stored somewhere on the mb (where?). And the jigkick depends on this to create the IDstore keys.

IdStorage is a special part of the firmware NOT in the normal flash areas. It's composed of "leafs" that contain 512 bytes of data. There can be at most 65520 of these leafs (also called keys by most folks), but Sony only uses about 128 of them currently. They hold various bits of info used by subsytems in the PSP. Things like the WIFI MAC address, levels for the battery, levels for the LCD brightness, etc. There's a thread here that goes into detail on the IdStorage. Read that for more info.

No IdStorage means loss of many functions related to WIFI, USB, and PS3 connectivity. The IdStorage is in every PSP and varies a little by motherboard revision. Each new mobo introduces a few more keys, and some existing keys have new content. So rebuilding the IdStorage will require knowledge about the mobo. Probably at first, the person will have to manually choose the mobo from a list.

Even then, some info cannot be found except by opening the PSP. The WIFI MAC address in key 0x44 is that way.

There's probably some unique ID stored somewhere on the mb (where?). And the jigkick depends on this to create the IDstore keys.
Yeah, and it's called Kirk. My strong believe is that all IDS keys for a certain type of motherboard are identical with exception of things like MAC and serial, but it's encryption or signing that makes them not work on another PSP.

Even then, some info cannot be found except by opening the PSP. The WIFI MAC address in key 0x44 is that way.

Don't agree, you can also use a wifi router to find the MAC without opening the PSP. The serial is written in the battery bay if some a**hole didn't remove the label (I've seen LOADS of PSP's that for some reason had the label removed, probably because the user expected tons of screws underneath it).

But even more, I think everything can be retrieved from the PSP itself by software, including MAC and serial (the serial must be stored in Kirk in order to create unique encryption keys). I bet it's only readable in factory mode, though.

BTW. Jas0nuk, wouldn't it be wise to move all this "what is IDStorage for" discussions to another thread (maybe the general IDStorage thread)? This thread is only one day old and it's already clogged with posts that do not add anything to the initial discussion.

Thread cleaned up. Please post TECHNICAL info here and questions in the general IdStorage thread which is stickied in this section.

IdStorage is a special part of the firmware NOT in the normal flash areas. It's composed of "leafs" that contain 512 bytes of data. There can be at most 65520 of these leafs (also called keys by most folks), but Sony only uses about 128 of them currently. They hold various bits of info used by subsytems in the PSP. Things like the WIFI MAC address, levels for the battery, levels for the LCD brightness, etc. There's a thread here that goes into detail on the IdStorage. Read that for more info.

No IdStorage means loss of many functions related to WIFI, USB, and PS3 connectivity. The IdStorage is in every PSP and varies a little by motherboard revision. Each new mobo introduces a few more keys, and some existing keys have new content. So rebuilding the IdStorage will require knowledge about the mobo. Probably at first, the person will have to manually choose the mobo from a list.

Even then, some info cannot be found except by opening the PSP. The WIFI MAC address in key 0x44 is that way.

Just to clear some things up, max number of leaf's is only 480 (all that can fit on the nand - without doing some voodoo repartitioning stuffs). Idstorage area is only 256KB (ie. 512pages==16Blocks). Each leaf takes up 1 page (512Bytes), so then why cant you fit 512 leaf's in, because each leaf is mapped to a keyID (0x0044 for example) and these ID's are stored in an index. 2 pages are allocated to the index, so really that only leaves 510 pages left for the leaf's. However, due to another restriction, the index pages can only be stored at the start of a block (ie. the first 2 pages of a block). So really you only have 15Blocks left for actual leaf data (32pages per block and you end up having only 480 pages, hence only 480 maxium leafs).

The leaf's keyID however can be represented by any 16bit digit (from 0x0001-0xFFEF), you can choose to have whatever you wish in that range.

This is defenetly something to look at.

currently have a psp TA-082^ with corrupted keys all the way, once Pandora's Unbricked the flash and ipl, it will not boot up.

The simptoms are similar to a brick, except that the LCD screen is always lighted and the psp never power off.

If anyone here would like to contact me so you can have "certain files" from my psp for research, I will be happy to help out.

THX.

I have a US TA-081, a US TA-082 and a JP TA-086 PSPs in full working state.
I'd like to help with the IDstorage research.

I also have the dump from the failed TA-079 board I posted pictures a few weeks ago...

Jas0nuk, which type of board your PSP has ? It has ID storage problems, right ?

I have a white JAP PSP, came with 2.00. I suspect it is a TA-081.

It has a corrupt 0x100/0x120 and no backup of the original :)

edit: How I messed it up: I tested harleyg's EARLY region changer without having made a backup (I expected it to work xD).

Squirrel, I checked my battery bay and there's no MAC address there. If anyone removed a sticker, it was at Sony because I'm the only one to use this PSP, and I removed it from the box when I bought it. Maybe it was something they started recently. Mine is a TA-082 bought from WalMart about a year ago.

Also, wouldn't a WIFI router need the PSP to be actively doing WIFI to get the MAC address? We're talking about rebuilding the keys from a dead PSP, right? If a PSP is working well enough to do WIFI, it's not in the condition the thread is trying to find the cure for.

So we come back to either opening the PSP (if not recorded in the battery bay), or hoping it's recorded in some bit of the hardware in the PSP accessible to something run from Pandora.

@Squirrel, I can confirm what Chilly Willy noticed. I have a US (PSP1001) TA-082 bought at a Sony store and it never had a sticker with the MAC address in the battery bay. There is a serial number in the sticker, but it does not seem to be related to the MAC address.

@Chilly Willy, I understand your concern about the need of a working wi-fi connection to be able to get the MAC address from a router, but I wonder if a PSP trying to set an ad-hoc link would broadcast some packets anyway. Those packets could be captured with a wi-fi sniffer like Kismet (http://www.kismetwireless.net). I guess we need a PSP with a corrupted key 0x0044 to test this.

The MAC address obviously is readable through the data port connection from the PSP to the module. The PSP kernel has to compare what is on it's ID Storage to an answer from the module before it shows a error message. Obviously this "command" would be used by the official restore software to rebuild the mac address key.

If you can dismantle your PSP, the sticker with the MAC is on the top of the WIFI module (TA-079/TA-081/TA-086) or at the memory stick board (TA-082).

An connection test will also show the mac at the PSP screen, again proving it's readable through the I/O port.

I suspect the WiFi module has a basic firmware built in but with feature that would allow firmware update upload and this update is contained in the file wlanfirm_magpie.prx

Can anyone confirm this ?

By the way, if we wish to run our own app under Pandora, do we make a PBP and use it in place of the update.pbp, or do we replace one of the elf files in the kd folder? I know the readme file says that it's not a FULL 1.50 kernel so some apps won't work correctly, so that implies we can run our own apps. I was thinking of making a version of IDSM for Pandora so I could experiment on the IdStorage at that level.

An connection test will also show the mac at the PSP screen, again proving it's readable through the I/O port.


You may be wrong. As harleyg has mentioned in the IdStorage thread (http://lan.sh/showpost.php?p=697&postcount=26), it looks like the vsh only reads the MAC address stored at key 0x44, not the real hardware address. That's why his MAC address changer did not work. This doesn't mean, however, that the real address is not accessible at all.

An connection test will also show the mac at the PSP screen, again proving it's readable through the I/O port.


You may be wrong. As harleyg has mentioned in the IdStorage thread (http://lan.sh/showpost.php?p=697&postcount=26), it looks like the vsh only reads the MAC address stored at key 0x44, not the real hardware address. That's why his MAC address changer did not work. This doesn't mean, however, that the real address is not accessible at all.

Read again what I wrote. I said the kernel can compare the REAL mac address on the wi fi module and the ID storage key without even have to start negotiation of a ADHOC connection with another PSP !

Edit:
The behavior of the AHDOC function with mismatched mad address on ID storage is show a kernel error message as soon the kernel access the wi fi module. It doesn't need to connect the wi fi to anything to just figure the real hardware MAC. So with this behavior analyzed we might be able to figure out a proper way to get the mac from the wi fi module without need the manual labor of inserting it ourselves.

And when you do a infrastructure network test on FW 3.25 it shows the real hard mac at the PSP screen regardless what is on the ID storage key. I fixed a PSP that way and I didn't even had to bother with looking at the wifi router administration page to get logs of the mac address. It just worked when I changed the mac to what I saw on the PSP screen.

@Chilly Willy, MajorGrubert:
Maybe I wasn't clear enough, maybe you didn't read well, but what I meant is that the battery bay usually contains a label with the PSP's serial. The label with the MAC address can only be found on the Wifi/MS board.

To retrieve the MAC address without opening the PSP (thanks for the tip on 3.52 l_oliveira!) through a router:
Establish a connection with a router. You can use WEP or WPA but no MAC filter since you don't know the correct MAC :).
Proceed to the screen after the connection test, but don't finish the setup to keep the connection alive. Now enter your router's setup page throug a PC and check the logfile (every router has it). The last registered MAC on a wifi connection is that of the PSP. You can use MAC address changer v2 to rewrite it to the PSP.
I've corrected MAC addresses countless times using this method but I guess I will be using l_oliveira's method in the future ;)

BTW. The MAC address only affects ad-hoc connections. Even with a fooked MAC address (like those people who think it's cool to have DE:AD:BE:EF as MAC address), it's still possible to establish a connection to a router.

people should know that idstorage keys from 0x100 to 0x106 (and their respective backups 0x120-0x126 ) are signed by kirk engine certgen and checked by kirk engine cert validate. If you really wish to sign/replace those keys you are going to have to toy with kirk commands.

certvalidate is seems to be performed by semaphore_4C537C72 (which triggers kirk command 12)

About the signcheck, it is checked against kirk id and has nothing to do with idstorage. Signcheck is beeing performed by kirk commands cmd2 (encryption) and cmd3 (check/decryption) if I recall properly

P.S. I dunno about certgen, but about signcheck, you can signcheck anything even a txt file.

people should know that idstorage keys from 0x100 to 0x106 (and their respective backups 0x120-0x126 ) are signed by kirk engine certgen and checked by kirk engine cert validate. If you really wish to sign/replace those keys you are going to have to toy with kirk commands.

certvalidate is seems to be performed by semaphore_4C537C72 (which triggers kirk command 12)

About the signcheck, it is checked against kirk id and has nothing to do with idstorage. Signcheck is beeing performed by kirk commands cmd2 (encryption) and cmd3 (check/decryption) if I recall properly

Fully restoring a ID storage would then be regenerate the fixed value keys, the non encrypted unique keys (especially MAC address) and finally performing the 10-13/100-106/120-126 keys restoration, but the challenge is fully automate the process, I guess. Recover the MAC automatically is interesting and I bet the Sony official recovery software does that together with regeneration of the UMD/Region keys.

Thanks for the info Mathieulh, please check your PMs l_o :)

And when you do a infrastructure network test on FW 3.25 it shows the real hard mac at the PSP screen regardless what is on the ID storage key.
That's good news. I was under the wrong assumption that the vsh only showed the address stored at key 0x44, not the actual hardware address.

And when you do a infrastructure network test on FW 3.25 it shows the real hard mac at the PSP screen regardless what is on the ID storage key.
That's good news. I was under the wrong assumption that the vsh only showed the address stored at key 0x44, not the actual hardware address.

It did on older firmwares, but it seems Sony's changed that. I guess the change came when they swapped MAC and firmware version in the System info screen, although that info screen still shows the MAC stored in IDStorage.

This might help you with restoring some IDstorage keys specially on the UMD

I have unbricked my TA-082 board successfully and it was fully functional(umd,WIFI,region code correct,etc.)I have been testing that psp because i was going to sell it to a customer,Then a flaw occured I was playing the UMD game SIMS2 when i decided to turn it off without exiting the game and poof when i started it it wont load any UMD games anymore.I thought i have to replace the umd drive because the lens is not working anymore there is no red light so i swapped my spare UMD drive to see if it was the problem then i checked if there was a red light coming from the lens and to my surprise there was nothing.I was using a Fully working UMD drive not 1 but 2.So i decided to Flash it again using devo to 1.5 version then the UMD drive works again.So i decided to upgrade to 3.40OEA and walla the umd drive does not work again then i upgraded it to 3.51m33-2 and the UMD drive is working again.Its not the UMD drive thats faulty I have 3 fully working UMD Drives but all of them show the the same problem.If the problem is on my IDStorage then It automatically fix itself when i flash my psp.Ive read here that some keys have some back-up.What im suggesting is dumb i think maybe the PSP can fix its own IDstorage its just that we havent found that yet.

Im noob and i dont know what im talking about,Im here to spread some rumors
but rumors can be true(SONY JIGKICK)

I've encountered some "strange" behaviour too on some unbrickings, which led me to think that some official updaters recognize IDStorage keys as bad, but when the "backup" copy is still valid, automatically substitute these backups for the invalid keys.

Of course, when this is true and both the key and it's backup are invalid, there's no current way back.

Been doing some tests with l_oliveira, established quite a lot of information, check the table on first post :)

OK...

After speaking a lot with l_oliveira and Matheiulh, it's time we investigated the commands which are used to verify the key. Here is a complete reversal of memlmd.prx from 1.50 which contains all the semaphore commands and how they interface with KIRK (the decryption engine), plus a reversal of the GetPsCode functions from sceChkreg (used to verify key 0x100)

Semaphore command 0x12 is used to verify IdStorage keys
Commands 0x11 to 0x17 are not documented, commands later than 17 are not implemented.
The likelihood is that 0x11 is the command used to produce IdStorage keys.

Big thanks to adrahil and FreePlay for the attached code which they reversed for me months ago, and I've never considered it's importance until my conversations today.

Faulty motherboards can cause data corruption on the nand and that will eventually lead to a software brick.

Such a board require a treatment with reflow oven for proper operation.... :)

Trust me ... If the NAND receive a page clear command and in the midle of the process it is feed with a wrong address the wrong page will be erased. What you think would happen if one of the pages with the boot loader were to be erased ? or the ID storage ?

Every time you change a setting or the PSP itself decides it's time to write on the NAND there's a chance for that to happen.

I think that possibility brings a satisfactory explanation for random bricks on PSPs which are crashing often.

I can't stress enough how important is to store a safe backup of every PSP you are working with. I repair PSPs professionally and trust me, the backups saved me from having to replace customer's units more than once :)

I know this post is unrelated but I thought it was a good idea help people out on not wasting their time looking for problems at the wrong place at their systems ;)

Big thanks to adrahil and FreePlay for the attached code


Great; the int semaphore_ declarations can be replaced as follows:

0x8EEB7BF2 sceUtilsBufferCopyByPolling
0x4C537C72 sceUtilsBufferCopyWithRange
0x77E97079 sceUtilsBufferCopyByPollingWithRange


Source of course: http://moonlight.lan.st/1.50/kd/memlmd.html ;)

Yes, forgot to do that :)

edit: Updated the original post
edit 2: Uploaded it again, put the new NID names, thanks ByteMaster :P

Added a table of KIRK commands to the first post. We need to determine which one is used to generate IdStorage keys :)

Cool. This thread had enlightened me quite a bit about why my original PSP (have 2 because I bricked my first one early on) shows a different MAC address than it really is. First, I confirmed that doing an infrastructure test DOES show the correct MAC address... oh backing up a bit I fixed it by replacing the motherboard so naturally what is in the NAND wouldn't match my actual wireless card.

This PSP, howerver hasn't had 1 single problem since with multiplayer, internet, running updates, or anything for that matter. In light of this, I don't think there is a need to pay attention to this key as much as it seems some of you are because if it was required as a part of these kirk checks or whatever, my PSP would be screwed simply because I changed the motherboard.

Urherenow, since you replaced the complete motherboard, your PSP has a working motherboard with the complete IDStorage that matches it (since it was factory-installed for that motherboard). IDStorage is stored on the motherboard, not somewhere else in the PSP.

The only thing you did when you replaced the motherboard, is use a different MAC in software than your wifi actually has. As you've experienced, this isn't causing problems for everything that you can use a router or accesspoint for. However, ad-hoc gaming will be impossible. For that reason, it's recommended to everyone who replaces his motherboard or the wificard, to read the wificard's actual MAC and reprogram that to the motherboard.

Since you have two PSP's, you can easily test it by trying to connect them in a game in ad-hoc mode.

But since the MAC key is not part of the "protected" keys, it's already been covered by MAC address changer v2 and no additional investigations are necessary on this key. However, it might be interesting to find out if the real MAC can be read by software, directly from the hardware, for automated IDStorage rebuilding.

Btw. that last remark makes me wonder if it is possible to read the real motherboard type from the hardware. Currently, motherboard detection is done by recognizing the IDStorage keys, but if IDStorage is destroyed, this method is unreliable.

There are several possibilities:
- The motherboard ID is stored somewhere in hardware. Would be the best for regenerating IDStorage, but I wonder if it really is present.
- The serial is stored somewhere in hardware. I think it is, because the serial is included in IDStorage and Sony should want an automated IDStorage generation without manual intervention (typing in the serial number). Although it's still possible that the serials are generated automatically and after flashing, a corresponding label is put on the PSP. However, the serial ranges could possibly be used to determine the motherboard type.
- There's nothing stored in hardware that can be used to determine the motherboard type. Sony factories just changed the motherboard and changed the IDStorage generation files at the same time.

Btw. that last remark makes me wonder if it is possible to read the real motherboard type from the hardware. Currently, motherboard detection is done by recognizing the IDStorage keys, but if IDStorage is destroyed, this method is unreliable.

There are several possibilities:
- The motherboard ID is stored somewhere in hardware. Would be the best for regenerating IDStorage, but I wonder if it really is present.
- The serial is stored somewhere in hardware. I think it is, because the serial is included in IDStorage and Sony should want an automated IDStorage generation without manual intervention (typing in the serial number). Although it's still possible that the serials are generated automatically and after flashing, a corresponding label is put on the PSP. However, the serial ranges could possibly be used to determine the motherboard type.
- There's nothing stored in hardware that can be used to determine the motherboard type. Sony factories just changed the motherboard and changed the IDStorage generation files at the same time.

There are multiple ways to determine the motherboard type, usually by polling the version of some part of the hardware that has changed with motherboard versions eg. wlan, vme, nand etc. etc. (this is the way SCE do it).

Also, there is a way to get the real mac address from the wlan hw without relying on idstorage. And there is a way to regenerate the unique idstorage keys.

Also, there is a way to get the real mac address from the wlan hw without relying on idstorage. And there is a way to regenerate the unique idstorage keys.

Yeah, we all now there is. But we still dont know what the way is :D

But with the whole world and their mothers now concentrating on IDStorage, I bet it won't be long until that secret is unveiled too.

Good work guys. On pages 1 and 2 you talk about getting the MAC address by connecting to WiFi. Kismet (the NetStumbler of Linux) will pick up the MAC address very quickly from a PSP. The LiveCD of blacktrack is the fastest way to get Kismet running on most systems.

Btw. that last remark makes me wonder if it is possible to read the real motherboard type from the hardware. Currently, motherboard detection is done by recognizing the IDStorage keys, but if IDStorage is destroyed, this method is unreliable.

There are several possibilities:
- The motherboard ID is stored somewhere in hardware. Would be the best for regenerating IDStorage, but I wonder if it really is present.
- The serial is stored somewhere in hardware. I think it is, because the serial is included in IDStorage and Sony should want an automated IDStorage generation without manual intervention (typing in the serial number). Although it's still possible that the serials are generated automatically and after flashing, a corresponding label is put on the PSP. However, the serial ranges could possibly be used to determine the motherboard type.
- There's nothing stored in hardware that can be used to determine the motherboard type. Sony factories just changed the motherboard and changed the IDStorage generation files at the same time.
TA-082 comes with firmware 2.50, 2.60, 2.70 or 2.71 installed (box codes H through K)
TA-086 comes with firmware 2.81 or higher (box codes L and above). TA-086 also has the brightness problem in firmware 1.50, but TA-082 does not.
info about box codes (http://forums.qj.net/f-guides-general-psp-42/t-determining-psp-firmware-using-box-codes-jun-28th-2007-28718.html)

I'm not sure about TA-079 and TA-081 (because I only have had a TA-082 and TA-086 before).
If someone could tell us this info for TA-079 and TA-081, then maybe the Pandora menu could ask you which motherboard you have (with these explanations for each).

btw, in the Pandora's battery menu, you misspelled "Pandora's":
Pandory's battery authors:

Also, there is a way to get the real mac address from the wlan hw without relying on idstorage. And there is a way to regenerate the unique idstorage keys.

Yeah, we all now there is. But we still dont know what the way is :D

But with the whole world and their mothers now concentrating on IDStorage, I bet it won't be long until that secret is unveiled too.

Yes I meant out of your own retail psp, as opposed to some form of external hw from the factory or something.

Also, there is a way to get the real mac address from the wlan hw without relying on idstorage. And there is a way to regenerate the unique idstorage keys.

Yeah, we all now there is. But we still dont know what the way is :D

But with the whole world and their mothers now concentrating on IDStorage, I bet it won't be long until that secret is unveiled too.

Yes I meant out of your own retail psp, as opposed to some form of external hw from the factory or something.
I think we have a little misunderstanding. I meant that too, I'm sure that MAC, serial and maybe motherboard type can be retrieved from any PSP, given the right software. But what I also meant is that as far as I know, the software has still to be made (although Sony surely has it, but they're not spreading).

The IDstorage is encrypted by sha1 or aes? I do see that sha kirk command but I have known aes to be used for some other things.
Thats one of the big issues I would guess, other then that is to know the rest of the keys and figure out where they come from, another issue,
but like Squirrel said half the world is looking at the Idstorage.

The IDstorage is encrypted by sha1 or aes?
Just to make things clear: SHA-1 (http://en.wikipedia.org/wiki/SHA-1) is not an encryption algorithm, it is a hashing algorithm. AES (http://en.wikipedia.org/wiki/Advanced_Encryption_Standard) is a block cipher encryption algorithm.

AES is used to encrypt/decrypt a block of data using a key know to both parties. Suppose you have some data (say, a block of 512 bytes). You select a cryptographic key and encode your data using AES. You end up with another 512 bytes of encrypted content that can only be decrypted using the original cryptographic key. If Sony encodes something using AES, the PSP must have a copy of the key somewhere, even if it is buried inside some piece of hardware used only for cryptography and can't be retrieved.

SHA-1 is used to calculate a fixed-length hash code, known as a message digest, of a given data block. The digest is always 20 bytes (160 bits) long. SHA-1 cannot be used for encryption, its main use is to digitally sign data in order to prevent further tampering, together with private/public key algorithms such as RSA.

Hope this help to clarify things.

Whoops, I know sha1 is a hashing formula, I made a mistake in that question, I know about sha1 because WoW(yeah, World of Warcraft) uses a modded version of sha which is as you said a fixed length hash code.

I do love you whole post tho as I didn't know that much about AES, I knew the sizes on how it semi worked but thanks it is very helpful stuff :)

Keys 0x0102 - 0x 0106 are unique to each motherboard type, not unique to each psp.
It might be the same with 0x0100 and 0x0101, but I don't know for sure about them.

ok... please tell me how to extract or otherwise look at these keys and I can definitely find out about all of them. Both of my PSPs I'm pretty sure have the same type of motherboard (the first one... ta079?) I have 33MB nand dumps and I have Hex workshop 4.2 installed. Can I find these keys in the 33MB dumps? What offset do they start at? anyway with the same motherboards it should stand out what (if) keys are different per PSP. Of course I'm smart enough to know already keys such as the MAC address will be different...

urherenow:

Some offsets for you to play with:

0x00042000 Second IPL / NAND IPL (1st IPL is on CPU)
0x000C6000 IDStorage start
0x000DAA00 IDStorage index record
0x00108000 LFlash (partitions) start

Keys 0x0102 - 0x 0106 are unique to each motherboard type, not unique to each psp.
It might be the same with 0x0100 and 0x0101, but I don't know for sure about them.
I have yet to see a 0x100-106 (mirrored to 0x120-126) key be identical between two different PSPs.

Keys 0x0102 - 0x 0106 are unique to each motherboard type, not unique to each psp.
It might be the same with 0x0100 and 0x0101, but I don't know for sure about them.
False.
Every PSP has unique 10-13, 40, 100-106 (and mirrored 120-126) keys.

still don't get it. How do I know which sections equal a 'key' by looking at a nand dump? I can clearly see data starting at 0x000C6000 but it looks like I have nothing at 0x000DA000. a bit below that, at:
da3c4-da3cf,
da5d4-da5df,
da7e4-dafef, and
da9f4-da9ff

I have FFFF FFFF FFFF FFFF 00F0 FFFF

written with a bunch of zeros before and in between, and nothing but fffffff aftwerwards... what's this for?

Ok... I found my serial number down at 0x000CE610 but it's listed here as 'key 0x50' this is what's confusing me.
also the code for my serial:
3446 4D35 3031 3434 3439 3457 3131 3036 serial: 4FM50144494W110648830211150118
3438 3833 3032 3131 3135 3031 3138 0104
0001 0001 0101 0101 0101 0101 0100 0000

Of course the serial will be different, but why do you suppose mine has a 0104 where Harleyg has 0103... even though that's after the text portion of the serial? I'm pretty darn sure I'm using a ta-79

Another confusing thing is the region codes listed here... I did a search for USA (and the others) and none of those codes are on my nand dump! Plz explain :( nevermind again... harleyg added an extra 00 01 too all of his region codes :P

each "key" or leaf like sony calls them is a cellar of 0x200 bytes then there's a spare of 0x0F bytes which is from the NAND itself, the PSP uses the spares for indexing and bad block marking.

the last blocks of the IDStorage contains a sort of "FAT table" which we just refer to as "Index table" then a huge blank area follows until where the LFLASH
(partitions area) starts.

Every time you change a setting or the PSP itself decides it's time to write on the NAND there's a chance for that to happen.

I was under the impression that the PSP settings were stored on a CMOS RAM chip, and the data was kept on it with a small cell battery. Isn't that why if the PSP battery is kept uncharged for long enough that you lose all your settings and need to re-enter them at boot?

I think only RTC is kept via that battery, when that is lost it prompts you to enter the settings. Most psp setting/userdata is kept in flash1 registry dat files though.

Keys 0x0102 - 0x 0106 are unique to each motherboard type, not unique to each psp.
It might be the same with 0x0100 and 0x0101, but I don't know for sure about them.
False.
Every PSP has unique 10-13, 40, 100-106 (and mirrored 120-126) keys.
When I flashed someone else's TA-082 keys to my TA-082, the UMD still worked (102-106). And the only thing not working was game saves for certain games like Socom FTB2.
That's why I thought that.

I still don't get the key/leaf thing and the 512bytes... where does this information come from? The UMD data CLEARLY takes up a whole lot more than 512 bytes. And my uneducated guess is that it takes 3,232 bytes. I think this because the region code information is there 5 TIMES (with a heck of a lot more than 512 bytes in between) and I kept following it until it was just fffff... because everything from 000c6000-000c6ca0 (3,232 bytes) is repeated byte for byte at 000d6800-000d74a0. It's like this on both of my PSPs.

I was foolishly hoping that I could copy that whole block of data from a different region but now know it's not true because most of the code there is very different between my PSPs. I haven't completed a byte for byte comparison yet but so far I've found many short bits of code repeated and many 28byte and 8byte segments that match exactly on both PSPs

can somebody tell me the significance of the code from c64d0 to c676f? It's scary how close that section is between my PSP's except for a few distinct 4 byte segments here and there. This wouldn't be an embedded key?

Keys 0x0102 - 0x 0106 are unique to each motherboard type, not unique to each psp.
It might be the same with 0x0100 and 0x0101, but I don't know for sure about them.
False.
Every PSP has unique 10-13, 40, 100-106 (and mirrored 120-126) keys.
When I flashed someone else's TA-082 keys to my TA-082, the UMD still worked (102-106). And the only thing not working was game saves for certain games like Socom FTB2.
That's why I thought that.
Are you sure ALL the keys were replaced? This is interesting, unless you were using M33 which nulls out the KIRK checking of firmware PRXs and IdStorage keys.

I had a similar experience some time ago: I unbricked (classic method) a motherboard straight to M33-4 and decided to do some tests before restoring the IDStorage from the bricked nand. Since I had to return the board, I couldn't do much testing, but I managed to start a Sony downloadable program (the Go Cam soft) with no errors. Since there's currently no newer update available than 3.52, I couldn't test update capability nor UMD's (the board came without PSP ;) ). Later tests by Covert have proven that most things don't work so installing M33 is not a universal solution for PSP's where IDStorage has been damaged.

False.
Every PSP has unique 10-13, 40, 100-106 (and mirrored 120-126) keys.
When I flashed someone else's TA-082 keys to my TA-082, the UMD still worked (102-106). And the only thing not working was game saves for certain games like Socom FTB2.
That's why I thought that.
Are you sure ALL the keys were replaced? This is interesting, unless you were using M33 which nulls out the KIRK checking of firmware PRXs and IdStorage keys.
I used one of Chilly Willy's apps (forgot which one). I think his app replaces all keys, but you would have to ask him to make sure. I was using an OE firmware at the time (probably 3.40 OE). M33 firmwares didn't exist when I did this.

I still have both sets of TA-082 keys, for if you want more info about them.

When I flashed someone else's TA-082 keys to my TA-082, the UMD still worked (102-106). And the only thing not working was game saves for certain games like Socom FTB2.
That's why I thought that.
Are you sure ALL the keys were replaced? This is interesting, unless you were using M33 which nulls out the KIRK checking of firmware PRXs and IdStorage keys.
I used one of Chilly Willy's apps (forgot which one). I think his app replaces all keys, but you would have to ask him to make sure. I was using an OE firmware at the time (probably 3.40 OE). M33 firmwares didn't exist when I did this.

I still have both sets of TA-082 keys, for if you want more info about them.

IdStorage Manager will overwrite all keys in the folder. KeyCleaner only messes with the few keys associated with the old downgraders.

If you downgrade a TA-082 PSP using the Pandora Battery do you need to use the key cleaner to fix the brightness problem?

Doing some digging on my nand dump, I found some interesting ID-Storage tidbits. I did a SHA1 digest of my keys, and then went searching for duplicates. I expected to find duplicates for 0x100-11f -> 0x120-13f, but what I found was something different. I found triplicates for all but 1 of these keys (0x100->0x120), and duplicates for many more. These extra hits are intermixed with the keyed data, but have no index entries. These may be a source for getting the "as-shipped" values. I need to do some more testing to see if these values change when the keyed value is changed. Details follow:

ID-Storage Dup Data Hits::
SHA1 = #ofHits = keys associated with specified blocks


SHA1 [d44b3c66f08eb17afef53294d8e8cd7eacf752e4] = 3 = 122, ???, 102
Blocks ---> 00C0400, 00C8400, 00D0400
SHA1 [1b6e44f27aa259da0f998c7d457a55f221e0ced6] = 3 = 125, ???, 105
Blocks ---> 00C0A00, 00C8A00, 00D0A00
SHA1 [e7c9a935b63e1c7a806961b004422ff47db3ff3e] = 2 = ???, 050
Blocks ---> 00CC200, 00D4200
SHA1 [ba81cacf8bc2d96f0009a8984761888674053218] = 2 = ???, 005
Blocks ---> 00CCC00, 00D4C00
SHA1 [4a3352cac1d52f740285a76fc9114a8ea74b82ac] = 2 = 120, 100
Blocks ---> 00C0000, 00D0000
SHA1 [78c2b90368c456391b8581e9e4e1356df90fb111] = 3 = 126, ???, 106
Blocks ---> 00C0C00, 00C8C00, 00D0C00
SHA1 [15e5c302e30a4ba88b99f28fa5682495a97ae8a7] = 2 = ???, 004
Blocks ---> 00CCA00, 00D4A00
SHA1 [44c2f0d9731c4e33fb37d51c992295d9ae16eaae] = 2 = ???, 040
Blocks ---> 00CD800, 00D5800
SHA1 [254112d98ceaa50f75a7dcadc1113c72b9ef3976] = 3 = 121, ???, 101
Blocks ---> 00C0200, 00C8200, 00D0200
SHA1 [5c638b20222bc2964f8a002941d611a2968065fa] = 2 = ???, 044
Blocks ---> 00CD600, 00D5600
SHA1 [864a574e75b5c379f219f5d787fb1f7df317ded0] = 2 = ???, 047
Blocks ---> 00CC800, 00D4800
SHA1 [38f9f84b7d1bce676cfc80d97f781cdb8ca86f26] = 2 = ???, 043
Blocks ---> 00CD400, 00D5400
SHA1 [8f36d0af58b1d00069a9a6232c36190c2ad40d8f] = 3 = 123, ???, 103
Blocks ---> 00C0600, 00C8600, 00D0600
SHA1 [9930af3ac2d38786d4c345bc1b835f1414978338] = 2 = ???, 041
Blocks ---> 00CD000, 00D5000
SHA1 [3a6c799555b5f343a19928313a62b9b1d2a5a40b] = 3 = 124, ???, 104
Blocks ---> 00C0800, 00C8800, 00D0800
SHA1 [6400b8878514d41e7b9ca9dc912e406c63d9c4f5] = 2 = ???, 006
Blocks ---> 00CCE00, 00D4E00
SHA1 [4e6f3605928849fe5c82b66efc9cab6106d52b04] = 2 = ???, 045
Blocks ---> 00CC400, 00D4400

Interesting ;)
I'll add some of your info to the first post when I have a moment. What is your PSP's motherboard?

I've never cracked the case, but Chilly Willy reports it as a TA-079/81 Unpatched PSP.

These were dumped from vb_master's AT031503136-PSP2001 Silver using IdStorage Manager 1.2

KEY.. .......MD5 CHECKSUM
0x0004.bin 53a94e603e899b5532e58b3132121b80
0x0005.bin 3e28ab59c7fa7deacf58020f5718f968
0x0006.bin d257d6b3b48257605843a44254f449d7
0x0007.bin 0679c71c1fbf663fc067b4b825ac9128
0x0008.bin bbf75082e43a357015372a7e6220e971

0x0010.bin 9b991d9ec47d0a9a1f6e006b6963c4bf
0x0011.bin 05b198ca62464526fa0a2287da6234d7
0x0012.bin 651b907c7c46668a88069c51c632bec5
0x0013.bin 5ffa20f2af8f315fc2b9c976b5e59623

0x0040.bin c03e93f6ffad62dfab81570b49b248f1
0x0041.bin fe405748cf64d3a22dc22aef56a02c2c

0x0043.bin 050acd6caf4cec9d64f3308a2aefcaa8
0x0044.bin 49a38f8b7982d923d76b7c5b0d92d586
0x0045.bin 8860f116447d82d80b0f201addd7b2c1

0x0047.bin 6e41a2b4e99b8fc5ea2fe19a8137fe95

0x0050.bin c3a72ab7cc803afc4bfbfe59353eb01e
0x0051.bin 18bf50f98a833375206ce4d2d59607cd
0x0052.bin e44e8d3dc005f846a060fc7dcc50b438

0x0054.bin 782604e5650305e8048cd0600fbd7a7f

0x0100.bin 9345abb1ebc262e9d367691957f92b1e
0x0101.bin 7595607d4d6ca88aabcc1ff52d68a733
0x0102.bin 002d2535fbc9b498c76cf246154feca8
0x0103.bin 2dfddd9ecb621ca980a63a8edf839c29
0x0104.bin 29c5be0abc68d81f0d28d4823b754e25
0x0105.bin c1dbfdfd2de5a9a02f34779832f1783b
0x0106.bin 52196690cfa2e1165c1571994cb4d744

0x0120.bin 9345abb1ebc262e9d367691957f92b1e
0x0121.bin 7595607d4d6ca88aabcc1ff52d68a733
0x0122.bin 002d2535fbc9b498c76cf246154feca8
0x0123.bin 2dfddd9ecb621ca980a63a8edf839c29
0x0124.bin 29c5be0abc68d81f0d28d4823b754e25
0x0125.bin c1dbfdfd2de5a9a02f34779832f1783b
0x0126.bin 52196690cfa2e1165c1571994cb4d744

0x0140.bin f7636e9236ac206ce97d26a40fd4ad0b

Many keys have a checksum of bf619eac0cdf3f68d496ea9344137e8b, and contain nothing but zeroes. For the full list, including these keys, check the attachment.

Thanks vb_master for your help, and Chilly Willy for IdStorage Manager which was luckily HEN compatible.

You're welcome.

Added the new unidentified Slim keys to first post. I'll do more digging tomorrow to check differences between old and new keys.

If you downgrade a TA-082 PSP using the Pandora Battery do you need to use the key cleaner to fix the brightness problem?

No, the Pandora downgrader is corruption-free. If you have a brightness problem after downgrading with it, you have a PSP with the newer LCD and the problem is due to the display libs and the LCD module, not the keys.

By the way, I installed 3.60 M33 on my Silver Slim and my latest KeyCleaner and IDStorage Manager apps run on it fine. Dumping the keys works fine, and an examination shows that the keys aren't encrypted at the library level. Using IDSM to look at the keys (or looking at the dumped keys) shows that the keys are mostly like the previous models with a few changes in keys like 4, 5, 6, etc. I rather expected them to make minor changes. I'll be releasing an update to KeyCleaner this coming weekend that properly identifies the keys for the Slim so that idiots don't think their Slim has bad keys because they examined it as a TA-082/86.

These were dumped from kando's PSP-2001 using IdStorage Manager 1.2

KEY.. .......MD5 CHECKSUM
0x0004.bin 27ee75565988aad2d98344f9238561a5
0x0005.bin 3e28ab59c7fa7deacf58020f5718f968
0x0006.bin c162792f2cef016aacbe5b91e1b436ad

0x000F.bin fc24ef97068734866fa9ab63a719be36

0x0010.bin ea8e3adadef7f63b8ce9a075b8dfc392
0x0011.bin 258c39d1371ba786b2c73008ba6ab703
0x0012.bin 651b907c7c46668a88069c51c632bec5
0x0013.bin 2b198c209434947c9f12140b617fb735

0x0040.bin b044feeab63855be6c2e72185d941c74
0x0041.bin 594b44944e193787fd57df83a195f8c3

0x0043.bin 2fd958155c71c165a4bd95a087becc96
0x0044.bin 2d8c2f1ee0d57df4908cca57f4bfde45
0x0045.bin e517301d5dc276caec0dedf7454f6319

0x0050.bin 2774c7c3fad2130d956d549795a053d3

0x0100.bin fb2ac788a8816e41db6a283a1f53d40b
0x0101.bin fe8f0a8e614d133ce269e25ad8370941
0x0102.bin f6270ad8a6d544f1469db1b92c172438
0x0103.bin d38070838adf0e462ed3f65a6f236147
0x0104.bin 311a8e13e7e46995235e48e9d889a9e0
0x0105.bin c9f2511a3765c0aa6723bfe932e81ea2
0x0106.bin efad9a85359e9e38435c7ba7cc576c1d

0x0120.bin fb2ac788a8816e41db6a283a1f53d40b
0x0121.bin fe8f0a8e614d133ce269e25ad8370941
0x0122.bin f6270ad8a6d544f1469db1b92c172438
0x0123.bin d38070838adf0e462ed3f65a6f236147
0x0124.bin 311a8e13e7e46995235e48e9d889a9e0
0x0125.bin c9f2511a3765c0aa6723bfe932e81ea2
0x0126.bin efad9a85359e9e38435c7ba7cc576c1d

0x0140.bin a16d094bba2c6453f4b5d887980978df

Thanks kando.

Check checksums.txt for the others (blank ones)

Just checked kando's keys, his PSP seems to be missing 0x7, 0x8, 0x47, and 51-54... o_O
Also it has a few bytes in 0xF unlike vb_master's which is blank.

I have seen the rare JPN region PSP which is entirely missing 0xF (aka: 1 in about 15)

Here's the MD5 checksums from my Slim keys:



53a94e603e899b5532e58b3132121b80 0x0004.bin
3e28ab59c7fa7deacf58020f5718f968 0x0005.bin
d257d6b3b48257605843a44254f449d7 0x0006.bin
68a31d2458115a63e101081ce5294c53 0x0007.bin
6ab54388ef519ffcac0d4d7dbbbc4a0c 0x0008.bin
bf619eac0cdf3f68d496ea9344137e8b 0x000F.bin
e0b68993a9e35eff78854b9387838fd4 0x0010.bin
ad3f902d046ef8d19b3bbe15b445d029 0x0011.bin
651b907c7c46668a88069c51c632bec5 0x0012.bin
cff5e60f5f2a6640ddf939ec54d139bb 0x0013.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0014.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0015.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0016.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0017.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0018.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0019.bin
bf619eac0cdf3f68d496ea9344137e8b 0x001A.bin
bf619eac0cdf3f68d496ea9344137e8b 0x001B.bin
bf619eac0cdf3f68d496ea9344137e8b 0x001C.bin
bf619eac0cdf3f68d496ea9344137e8b 0x001D.bin
bf619eac0cdf3f68d496ea9344137e8b 0x001E.bin
bf619eac0cdf3f68d496ea9344137e8b 0x001F.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0020.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0021.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0022.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0023.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0024.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0025.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0026.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0027.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0028.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0029.bin
bf619eac0cdf3f68d496ea9344137e8b 0x002A.bin
bf619eac0cdf3f68d496ea9344137e8b 0x002B.bin
bf619eac0cdf3f68d496ea9344137e8b 0x002C.bin
bf619eac0cdf3f68d496ea9344137e8b 0x002D.bin
bf619eac0cdf3f68d496ea9344137e8b 0x002E.bin
bf619eac0cdf3f68d496ea9344137e8b 0x002F.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0030.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0031.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0032.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0033.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0034.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0035.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0036.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0037.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0038.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0039.bin
bf619eac0cdf3f68d496ea9344137e8b 0x003A.bin
bf619eac0cdf3f68d496ea9344137e8b 0x003B.bin
bf619eac0cdf3f68d496ea9344137e8b 0x003C.bin
bf619eac0cdf3f68d496ea9344137e8b 0x003D.bin
bf619eac0cdf3f68d496ea9344137e8b 0x003E.bin
bf619eac0cdf3f68d496ea9344137e8b 0x003F.bin
61a60fe29873b7d7a5e1b8a3528bdd8b 0x0040.bin
fe405748cf64d3a22dc22aef56a02c2c 0x0041.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0042.bin
050acd6caf4cec9d64f3308a2aefcaa8 0x0043.bin
5f54bdaf045c70c4d7b2a084f1154f43 0x0044.bin
8860f116447d82d80b0f201addd7b2c1 0x0045.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0046.bin
6e41a2b4e99b8fc5ea2fe19a8137fe95 0x0047.bin
c3a72ab7cc803afc4bfbfe59353eb01e 0x0050.bin
d2688f277fe80558e67412314bc0efd8 0x0051.bin
56397cd9e166fb38ade1252c9d076d90 0x0052.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0053.bin
782604e5650305e8048cd0600fbd7a7f 0x0054.bin
6fb66a8317c077bfd84b84808c780adb 0x0100.bin
52a8b0e61378173e34994cdb107c94da 0x0101.bin
52eb792880f9494c28ba07557fb81a4c 0x0102.bin
5f8746f8e87411bf8d85246470493b24 0x0103.bin
1d190d2f95e0e45d3acdf766aa58238e 0x0104.bin
ac9868ad9b996a753100cbce43c7b107 0x0105.bin
36b5c2ef42f7992f166de675084af8c1 0x0106.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0107.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0108.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0109.bin
bf619eac0cdf3f68d496ea9344137e8b 0x010A.bin
bf619eac0cdf3f68d496ea9344137e8b 0x010B.bin
bf619eac0cdf3f68d496ea9344137e8b 0x010C.bin
bf619eac0cdf3f68d496ea9344137e8b 0x010D.bin
bf619eac0cdf3f68d496ea9344137e8b 0x010E.bin
bf619eac0cdf3f68d496ea9344137e8b 0x010F.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0110.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0111.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0112.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0113.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0114.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0115.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0116.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0117.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0118.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0119.bin
bf619eac0cdf3f68d496ea9344137e8b 0x011A.bin
bf619eac0cdf3f68d496ea9344137e8b 0x011B.bin
bf619eac0cdf3f68d496ea9344137e8b 0x011C.bin
bf619eac0cdf3f68d496ea9344137e8b 0x011D.bin
bf619eac0cdf3f68d496ea9344137e8b 0x011E.bin
bf619eac0cdf3f68d496ea9344137e8b 0x011F.bin
6fb66a8317c077bfd84b84808c780adb 0x0120.bin
52a8b0e61378173e34994cdb107c94da 0x0121.bin
52eb792880f9494c28ba07557fb81a4c 0x0122.bin
5f8746f8e87411bf8d85246470493b24 0x0123.bin
1d190d2f95e0e45d3acdf766aa58238e 0x0124.bin
ac9868ad9b996a753100cbce43c7b107 0x0125.bin
36b5c2ef42f7992f166de675084af8c1 0x0126.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0127.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0128.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0129.bin
bf619eac0cdf3f68d496ea9344137e8b 0x012A.bin
bf619eac0cdf3f68d496ea9344137e8b 0x012B.bin
bf619eac0cdf3f68d496ea9344137e8b 0x012C.bin
bf619eac0cdf3f68d496ea9344137e8b 0x012D.bin
bf619eac0cdf3f68d496ea9344137e8b 0x012E.bin
bf619eac0cdf3f68d496ea9344137e8b 0x012F.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0130.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0131.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0132.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0133.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0134.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0135.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0136.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0137.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0138.bin
bf619eac0cdf3f68d496ea9344137e8b 0x0139.bin
bf619eac0cdf3f68d496ea9344137e8b 0x013A.bin
bf619eac0cdf3f68d496ea9344137e8b 0x013B.bin
bf619eac0cdf3f68d496ea9344137e8b 0x013C.bin
bf619eac0cdf3f68d496ea9344137e8b 0x013D.bin
bf619eac0cdf3f68d496ea9344137e8b 0x013E.bin
bf619eac0cdf3f68d496ea9344137e8b 0x013F.bin
fc7f44bc26f888155deb3b83e1e19d2f 0x0140.bin

Here's the keys from my Silver Slim (PSP-2004IS). Black will follow.

53a94e603e899b5532e58b3132121b80 *0x0004.bin
3e28ab59c7fa7deacf58020f5718f968 *0x0005.bin
d257d6b3b48257605843a44254f449d7 *0x0006.bin
d6f359e59e1230dcbf71b44a1c48f78e *0x0007.bin
6169c86514897e0fa31b612972eb3128 *0x0008.bin
bf619eac0cdf3f68d496ea9344137e8b *0x000F.bin
1be18185d1d65393b0486969d6db1106 *0x0010.bin
c8c6a7d49119c52808a9bd40a9871ed7 *0x0011.bin
651b907c7c46668a88069c51c632bec5 *0x0012.bin
2c97ffc7530c83d5d9a07c7c7c1beff2 *0x0013.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0014.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0015.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0016.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0017.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0018.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0019.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0020.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0021.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0022.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0023.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0024.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0025.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0026.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0027.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0028.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0029.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0030.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0031.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0032.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0033.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0034.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0035.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0036.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0037.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0038.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0039.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003F.bin
062f66cead1a4283ad78bd0db9d3bc05 *0x0040.bin
fe405748cf64d3a22dc22aef56a02c2c *0x0041.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0042.bin
050acd6caf4cec9d64f3308a2aefcaa8 *0x0043.bin
05354ee59aaa32938ab8d5b7762b606f *0x0044.bin
e8d17760026c327a2d93fe18a4a50b45 *0x0045.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0046.bin
6e41a2b4e99b8fc5ea2fe19a8137fe95 *0x0047.bin
91222d6f3367e738b0a37ca04956fbaa *0x0050.bin
254c89325e41def33a88733723200079 *0x0051.bin
7012ecdfb2d5b356966c390c5dd76555 *0x0052.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0053.bin
782604e5650305e8048cd0600fbd7a7f *0x0054.bin
0b0f42151565d6a524d74926b53ecb0e *0x0100.bin
857be6684f862dd08a78b8e2e2e71d89 *0x0101.bin
57c136d468e36bbb327671ac65af5daf *0x0102.bin
9fc8d5e7c003eb784ca3c65aec040771 *0x0103.bin
72e163152e4dacb649f8785e316c1c02 *0x0104.bin
53fd38be3b846c7e0800220a9a011014 *0x0105.bin
9f72722f0c740e4c8d949cf86dcba1c6 *0x0106.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0107.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0108.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0109.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0110.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0111.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0112.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0113.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0114.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0115.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0116.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0117.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0118.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0119.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011F.bin
0b0f42151565d6a524d74926b53ecb0e *0x0120.bin
857be6684f862dd08a78b8e2e2e71d89 *0x0121.bin
57c136d468e36bbb327671ac65af5daf *0x0122.bin
9fc8d5e7c003eb784ca3c65aec040771 *0x0123.bin
72e163152e4dacb649f8785e316c1c02 *0x0124.bin
53fd38be3b846c7e0800220a9a011014 *0x0125.bin
9f72722f0c740e4c8d949cf86dcba1c6 *0x0126.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0127.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0128.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0129.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0130.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0131.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0132.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0133.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0134.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0135.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0136.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0137.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0138.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0139.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013F.bin
44e711daaf9205a7535587c15ecd2ad6 *0x0140.bin

Here's my black PSP-2004PB:
53a94e603e899b5532e58b3132121b80 *0x0004.bin
3e28ab59c7fa7deacf58020f5718f968 *0x0005.bin
d257d6b3b48257605843a44254f449d7 *0x0006.bin
16da003449dd5ae958cdd419eb5efdbc *0x0007.bin
566dc1d29519b311f85158f7cd5868e6 *0x0008.bin
bf619eac0cdf3f68d496ea9344137e8b *0x000F.bin
2cd3706d992a3bedec30f576db18c571 *0x0010.bin
81e8f1f68b35f2ceeba81098ea778a8e *0x0011.bin
651b907c7c46668a88069c51c632bec5 *0x0012.bin
06cb87f53709bb0e3290b9b2f21c9fb7 *0x0013.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0014.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0015.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0016.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0017.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0018.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0019.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0020.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0021.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0022.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0023.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0024.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0025.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0026.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0027.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0028.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0029.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0030.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0031.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0032.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0033.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0034.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0035.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0036.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0037.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0038.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0039.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003F.bin
fa9002f8bdd1e3e6ccdc0a528fe99777 *0x0040.bin
fe405748cf64d3a22dc22aef56a02c2c *0x0041.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0042.bin
050acd6caf4cec9d64f3308a2aefcaa8 *0x0043.bin
6f86e8450aa0d55ff5543dfd29321de4 *0x0044.bin
e8d17760026c327a2d93fe18a4a50b45 *0x0045.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0046.bin
6e41a2b4e99b8fc5ea2fe19a8137fe95 *0x0047.bin
91222d6f3367e738b0a37ca04956fbaa *0x0050.bin
9c69c4f1988ff06d8eefef0640ee95a1 *0x0051.bin
cfc2578e45f93e283a9d2d55e74062b5 *0x0052.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0053.bin
d340f23a7d18057bb02252a3cb40b877 *0x0054.bin
3c4472c32fecbd0dd48e603d5c274550 *0x0100.bin
085c9c66706ca64d9b842018239a2c7b *0x0101.bin
93bda47a4159d386f95b79a0f549d96e *0x0102.bin
9382844296b9ffbabba8344fface7e1f *0x0103.bin
6b50b48d732ac6028f9cedea096edb08 *0x0104.bin
196383d59116a2e54199661eaeb0d1f4 *0x0105.bin
e7e1dff7621c4be53fd98d78eb873fdb *0x0106.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0107.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0108.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0109.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0110.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0111.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0112.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0113.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0114.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0115.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0116.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0117.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0118.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0119.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011F.bin
3c4472c32fecbd0dd48e603d5c274550 *0x0120.bin
085c9c66706ca64d9b842018239a2c7b *0x0121.bin
93bda47a4159d386f95b79a0f549d96e *0x0122.bin
9382844296b9ffbabba8344fface7e1f *0x0123.bin
6b50b48d732ac6028f9cedea096edb08 *0x0124.bin
196383d59116a2e54199661eaeb0d1f4 *0x0125.bin
e7e1dff7621c4be53fd98d78eb873fdb *0x0126.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0127.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0128.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0129.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0130.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0131.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0132.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0133.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0134.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0135.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0136.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0137.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0138.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0139.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013F.bin
42a596d71cd25bee4a42022677a3cd6b *0x0140.bin

The PSP's are identical except for the color so this should make a good comparison to determine which keys are PSP-dependant.
Chilly Willy, if you're interested in the keys contents, please let me know.

If you look at your checksums, you see that the following are different:
7,8,10,11,13,40,44,__,__,51,52,54,100-106,120-126,140

While between your IS and mine is:
7,8,10,11,13,40,44,45,50,51,52,__,100-106,120-126,140

What we see is (seemingly) 45 related to the region of the PSP (as we knew before), 50 seems to be region related as well, while 54 seems model related (both ISs the same, but the IS and PB different).

Here are the keys from my PSP-2001 (Ice Silver) PSP Slim:

MD5:


53a94e603e899b5532e58b3132121b80 *0x0004.bin
3e28ab59c7fa7deacf58020f5718f968 *0x0005.bin
d257d6b3b48257605843a44254f449d7 *0x0006.bin
a6a6557e79456b21d441b3959213fef3 *0x0007.bin
ed0391f50dbfd958cca3fa3a7695f998 *0x0008.bin
bf619eac0cdf3f68d496ea9344137e8b *0x000F.bin
5e5b78787327faa6f71c99105886b195 *0x0010.bin
37f89bc403450545bdd2b450379c7c23 *0x0011.bin
651b907c7c46668a88069c51c632bec5 *0x0012.bin
7ecfb02dd727e5e40c62260a590e2a49 *0x0013.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0014.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0015.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0016.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0017.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0018.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0019.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x001F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0020.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0021.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0022.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0023.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0024.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0025.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0026.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0027.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0028.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0029.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x002F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0030.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0031.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0032.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0033.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0034.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0035.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0036.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0037.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0038.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0039.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x003F.bin
a83ef204a59d62a30d3661bd790824cd *0x0040.bin
fe405748cf64d3a22dc22aef56a02c2c *0x0041.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0042.bin
050acd6caf4cec9d64f3308a2aefcaa8 *0x0043.bin
8b213114b2a44aaed1fde6c89fcc6327 *0x0044.bin
8860f116447d82d80b0f201addd7b2c1 *0x0045.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0046.bin
6e41a2b4e99b8fc5ea2fe19a8137fe95 *0x0047.bin
c3a72ab7cc803afc4bfbfe59353eb01e *0x0050.bin
053c9c7415691f5c39c22e092045d0d0 *0x0051.bin
4e0d5bfe700066109b614895b75dcf75 *0x0052.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0053.bin
782604e5650305e8048cd0600fbd7a7f *0x0054.bin
cc8652b976f7264becd0b3ad6ccc4a21 *0x0100.bin
f4d429ec4e57853b2becfb3d8c682bfb *0x0101.bin
46c918008ba87a00e04f48284832d524 *0x0102.bin
c25b38e1e2446556f996df9209be019a *0x0103.bin
96058c04d8a74e3d244c222af6c0c9c3 *0x0104.bin
d3560986b1f93c037992309569864e50 *0x0105.bin
6673eecff0ea6e19c4a6b210c403e1d9 *0x0106.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0107.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0108.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0109.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x010F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0110.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0111.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0112.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0113.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0114.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0115.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0116.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0117.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0118.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0119.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x011F.bin
cc8652b976f7264becd0b3ad6ccc4a21 *0x0120.bin
f4d429ec4e57853b2becfb3d8c682bfb *0x0121.bin
46c918008ba87a00e04f48284832d524 *0x0122.bin
c25b38e1e2446556f996df9209be019a *0x0123.bin
96058c04d8a74e3d244c222af6c0c9c3 *0x0124.bin
d3560986b1f93c037992309569864e50 *0x0125.bin
6673eecff0ea6e19c4a6b210c403e1d9 *0x0126.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0127.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0128.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0129.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x012F.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0130.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0131.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0132.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0133.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0134.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0135.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0136.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0137.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0138.bin
bf619eac0cdf3f68d496ea9344137e8b *0x0139.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013A.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013B.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013C.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013D.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013E.bin
bf619eac0cdf3f68d496ea9344137e8b *0x013F.bin
ae79e7d1ef87181299bc7acc00c4a2fc *0x0140.bin

SHA-1:


01766c7b8114daea64fcf44841a12d6b84b7b405 *0x0004.bin
ba81cacf8bc2d96f0009a8984761888674053218 *0x0005.bin
18719b84ee220dc2383a4adb26277deca3736350 *0x0006.bin
cd8e587aae191ad6baf0b2c047546e8ce88807d3 *0x0007.bin
f8c3c3e18d05ac23b2edd1481844311e100d78b6 *0x0008.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x000F.bin
23c88ad8fea46411cf14e890d1869747c8c326a6 *0x0010.bin
932291506022ef0e4820dc36d2df259a8ba7f92a *0x0011.bin
334258e3368fb3fc38431ebcdc48f3a625269965 *0x0012.bin
862fd09e009efc30248a19f40c06fd65a2cef978 *0x0013.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0014.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0015.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0016.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0017.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0018.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0019.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x001A.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x001B.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x001C.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x001D.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x001E.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x001F.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0020.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0021.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0022.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0023.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0024.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0025.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0026.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0027.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0028.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0029.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x002A.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x002B.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x002C.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x002D.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x002E.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x002F.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0030.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0031.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0032.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0033.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0034.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0035.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0036.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0037.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0038.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0039.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x003A.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x003B.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x003C.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x003D.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x003E.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x003F.bin
10b977dd9cde0821f3ca76ff729d076a3a7a11c0 *0x0040.bin
1fb73dc0445aaa8ae7146c4d08a2c1228f0fc860 *0x0041.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0042.bin
0a24361fca20818e74b0b9cb09517d0787515173 *0x0043.bin
f9f475a8c9b127efe770ac558e63845da3c42ac4 *0x0044.bin
b2b1e077509b37ad4f45ed856baa8952e11c8e42 *0x0045.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0046.bin
864a574e75b5c379f219f5d787fb1f7df317ded0 *0x0047.bin
c04f92ce47bcc00247ef64db13009d7b2ad8fd7e *0x0050.bin
cb8f0bd3ee1002b5589278fc8d01c60841b02779 *0x0051.bin
99d19472fbca8a79d0f47b1fb133dcea9b5d4362 *0x0052.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0053.bin
ee072c5e000ff9dc00aa020695f4e987ba9caa2d *0x0054.bin
01e1b151b9cc7cebf2986fac8cf2dffcf961bc5b *0x0100.bin
6fcb7427ea409b367da413b1f772418138216f69 *0x0101.bin
103ce926a6d8581c0e9e386bdd4792b16800e5cd *0x0102.bin
4687c303835e9deb3578ddf2f913dd9341218395 *0x0103.bin
cd37217ae295217bc30e10b30355e1d1daf45d19 *0x0104.bin
5e73c8baff13e97352bc8bfc9cfbfcc79637a41f *0x0105.bin
89365b97edcae724c557b5c4c42f08053071f7f0 *0x0106.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0107.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0108.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0109.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x010A.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x010B.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x010C.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x010D.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x010E.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x010F.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0110.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0111.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0112.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0113.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0114.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0115.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0116.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0117.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0118.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0119.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x011A.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x011B.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x011C.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x011D.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x011E.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x011F.bin
01e1b151b9cc7cebf2986fac8cf2dffcf961bc5b *0x0120.bin
6fcb7427ea409b367da413b1f772418138216f69 *0x0121.bin
103ce926a6d8581c0e9e386bdd4792b16800e5cd *0x0122.bin
4687c303835e9deb3578ddf2f913dd9341218395 *0x0123.bin
cd37217ae295217bc30e10b30355e1d1daf45d19 *0x0124.bin
5e73c8baff13e97352bc8bfc9cfbfcc79637a41f *0x0125.bin
89365b97edcae724c557b5c4c42f08053071f7f0 *0x0126.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0127.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0128.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0129.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x012A.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x012B.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x012C.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x012D.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x012E.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x012F.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0130.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0131.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0132.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0133.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0134.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0135.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0136.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0137.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0138.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x0139.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x013A.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x013B.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x013C.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x013D.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x013E.bin
5c3eb80066420002bc3dcc7ca4ab6efad7ed4ae5 *0x013F.bin
b620060d304fd38f44a67a3558765aa505b8aa4c *0x0140.bin

Thanks Squirrel, Chilly and x3sphere.

Another set of key MD5sums, this time from l337Espeon (thanks!)
0x0004.bin 53a94e603e899b5532e58b3132121b80
0x0005.bin 3e28ab59c7fa7deacf58020f5718f968
0x0006.bin d257d6b3b48257605843a44254f449d7
0x0007.bin a7c3ce5aa5a7bc0423acaed7a779454c
0x0008.bin 6169c86514897e0fa31b612972eb3128
0x000F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0010.bin af4b0cc4ed3e9c6b912cae719b7e56e0
0x0011.bin de5df862f8f8b57376d0d5b0ff5ce622
0x0012.bin 651b907c7c46668a88069c51c632bec5
0x0013.bin 70ae1db0f538b039f0f0ce586c8fdceb
0x0014.bin bf619eac0cdf3f68d496ea9344137e8b
0x0015.bin bf619eac0cdf3f68d496ea9344137e8b
0x0016.bin bf619eac0cdf3f68d496ea9344137e8b
0x0017.bin bf619eac0cdf3f68d496ea9344137e8b
0x0018.bin bf619eac0cdf3f68d496ea9344137e8b
0x0019.bin bf619eac0cdf3f68d496ea9344137e8b
0x001A.bin bf619eac0cdf3f68d496ea9344137e8b
0x001B.bin bf619eac0cdf3f68d496ea9344137e8b
0x001C.bin bf619eac0cdf3f68d496ea9344137e8b
0x001D.bin bf619eac0cdf3f68d496ea9344137e8b
0x001E.bin bf619eac0cdf3f68d496ea9344137e8b
0x001F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0020.bin bf619eac0cdf3f68d496ea9344137e8b
0x0021.bin bf619eac0cdf3f68d496ea9344137e8b
0x0022.bin bf619eac0cdf3f68d496ea9344137e8b
0x0023.bin bf619eac0cdf3f68d496ea9344137e8b
0x0024.bin bf619eac0cdf3f68d496ea9344137e8b
0x0025.bin bf619eac0cdf3f68d496ea9344137e8b
0x0026.bin bf619eac0cdf3f68d496ea9344137e8b
0x0027.bin bf619eac0cdf3f68d496ea9344137e8b
0x0028.bin bf619eac0cdf3f68d496ea9344137e8b
0x0029.bin bf619eac0cdf3f68d496ea9344137e8b
0x002A.bin bf619eac0cdf3f68d496ea9344137e8b
0x002B.bin bf619eac0cdf3f68d496ea9344137e8b
0x002C.bin bf619eac0cdf3f68d496ea9344137e8b
0x002D.bin bf619eac0cdf3f68d496ea9344137e8b
0x002E.bin bf619eac0cdf3f68d496ea9344137e8b
0x002F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0030.bin bf619eac0cdf3f68d496ea9344137e8b
0x0031.bin bf619eac0cdf3f68d496ea9344137e8b
0x0032.bin bf619eac0cdf3f68d496ea9344137e8b
0x0033.bin bf619eac0cdf3f68d496ea9344137e8b
0x0034.bin bf619eac0cdf3f68d496ea9344137e8b
0x0035.bin bf619eac0cdf3f68d496ea9344137e8b
0x0036.bin bf619eac0cdf3f68d496ea9344137e8b
0x0037.bin bf619eac0cdf3f68d496ea9344137e8b
0x0038.bin bf619eac0cdf3f68d496ea9344137e8b
0x0039.bin bf619eac0cdf3f68d496ea9344137e8b
0x003A.bin bf619eac0cdf3f68d496ea9344137e8b
0x003B.bin bf619eac0cdf3f68d496ea9344137e8b
0x003C.bin bf619eac0cdf3f68d496ea9344137e8b
0x003D.bin bf619eac0cdf3f68d496ea9344137e8b
0x003E.bin bf619eac0cdf3f68d496ea9344137e8b
0x003F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0040.bin 9a63a7d0de0251e2fe16595b519bca11
0x0041.bin fe405748cf64d3a22dc22aef56a02c2c
0x0042.bin bf619eac0cdf3f68d496ea9344137e8b
0x0043.bin 050acd6caf4cec9d64f3308a2aefcaa8
0x0044.bin eb750d967af8be1f5d14360ae0782711
0x0045.bin 8860f116447d82d80b0f201addd7b2c1
0x0046.bin bf619eac0cdf3f68d496ea9344137e8b
0x0047.bin 6e41a2b4e99b8fc5ea2fe19a8137fe95
0x0050.bin c3a72ab7cc803afc4bfbfe59353eb01e
0x0051.bin 12d01ed69391d521c0adde7a134d56df
0x0052.bin 0452d50c72d46bcf01597cce82e3757a
0x0053.bin bf619eac0cdf3f68d496ea9344137e8b
0x0054.bin 782604e5650305e8048cd0600fbd7a7f
0x0100.bin d7e715f52879c4f89e3a8b8afa9976a9
0x0101.bin d6a9f14eb7bfa45fe4a8aeaf837516bb
0x0102.bin 9084bacccc5c5ba0434a60b302dee1a5
0x0103.bin 7f043ef916d353a3a4996bf16a9059e0
0x0104.bin decd45d0a50b23605f930ba202f28233
0x0105.bin 2ad58a57b1fb235dddc7610c456d529d
0x0106.bin 8eea9df398a47442c4e3fd79142250a0
0x0107.bin bf619eac0cdf3f68d496ea9344137e8b
0x0108.bin bf619eac0cdf3f68d496ea9344137e8b
0x0109.bin bf619eac0cdf3f68d496ea9344137e8b
0x010A.bin bf619eac0cdf3f68d496ea9344137e8b
0x010B.bin bf619eac0cdf3f68d496ea9344137e8b
0x010C.bin bf619eac0cdf3f68d496ea9344137e8b
0x010D.bin bf619eac0cdf3f68d496ea9344137e8b
0x010E.bin bf619eac0cdf3f68d496ea9344137e8b
0x010F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0110.bin bf619eac0cdf3f68d496ea9344137e8b
0x0111.bin bf619eac0cdf3f68d496ea9344137e8b
0x0112.bin bf619eac0cdf3f68d496ea9344137e8b
0x0113.bin bf619eac0cdf3f68d496ea9344137e8b
0x0114.bin bf619eac0cdf3f68d496ea9344137e8b
0x0115.bin bf619eac0cdf3f68d496ea9344137e8b
0x0116.bin bf619eac0cdf3f68d496ea9344137e8b
0x0117.bin bf619eac0cdf3f68d496ea9344137e8b
0x0118.bin bf619eac0cdf3f68d496ea9344137e8b
0x0119.bin bf619eac0cdf3f68d496ea9344137e8b
0x011A.bin bf619eac0cdf3f68d496ea9344137e8b
0x011B.bin bf619eac0cdf3f68d496ea9344137e8b
0x011C.bin bf619eac0cdf3f68d496ea9344137e8b
0x011D.bin bf619eac0cdf3f68d496ea9344137e8b
0x011E.bin bf619eac0cdf3f68d496ea9344137e8b
0x011F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0120.bin d7e715f52879c4f89e3a8b8afa9976a9
0x0121.bin d6a9f14eb7bfa45fe4a8aeaf837516bb
0x0122.bin 9084bacccc5c5ba0434a60b302dee1a5
0x0123.bin 7f043ef916d353a3a4996bf16a9059e0
0x0124.bin decd45d0a50b23605f930ba202f28233
0x0125.bin 2ad58a57b1fb235dddc7610c456d529d
0x0126.bin 8eea9df398a47442c4e3fd79142250a0
0x0127.bin bf619eac0cdf3f68d496ea9344137e8b
0x0128.bin bf619eac0cdf3f68d496ea9344137e8b
0x0129.bin bf619eac0cdf3f68d496ea9344137e8b
0x012A.bin bf619eac0cdf3f68d496ea9344137e8b
0x012B.bin bf619eac0cdf3f68d496ea9344137e8b
0x012C.bin bf619eac0cdf3f68d496ea9344137e8b
0x012D.bin bf619eac0cdf3f68d496ea9344137e8b
0x012E.bin bf619eac0cdf3f68d496ea9344137e8b
0x012F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0130.bin bf619eac0cdf3f68d496ea9344137e8b
0x0131.bin bf619eac0cdf3f68d496ea9344137e8b
0x0132.bin bf619eac0cdf3f68d496ea9344137e8b
0x0133.bin bf619eac0cdf3f68d496ea9344137e8b
0x0134.bin bf619eac0cdf3f68d496ea9344137e8b
0x0135.bin bf619eac0cdf3f68d496ea9344137e8b
0x0136.bin bf619eac0cdf3f68d496ea9344137e8b
0x0137.bin bf619eac0cdf3f68d496ea9344137e8b
0x0138.bin bf619eac0cdf3f68d496ea9344137e8b
0x0139.bin bf619eac0cdf3f68d496ea9344137e8b
0x013A.bin bf619eac0cdf3f68d496ea9344137e8b
0x013B.bin bf619eac0cdf3f68d496ea9344137e8b
0x013C.bin bf619eac0cdf3f68d496ea9344137e8b
0x013D.bin bf619eac0cdf3f68d496ea9344137e8b
0x013E.bin bf619eac0cdf3f68d496ea9344137e8b
0x013F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0140.bin d50c15882218ac3c5c8270cb0f5c4b88

I think we have enough Slim IdStorage dumps for the current revision. We can conclude that there are no new keys apart from 0x52 and 0x54.
As for the IdStorage keys common to both models, we need to find out what the purposes of 0x7, 0x47 and 0x140 are.

False.
Every PSP has unique 10-13, 40, 100-106 (and mirrored 120-126) keys.
When I flashed someone else's TA-082 keys to my TA-082, the UMD still worked (102-106). And the only thing not working was game saves for certain games like Socom FTB2.
That's why I thought that.
Are you sure ALL the keys were replaced? This is interesting, unless you were using M33 which nulls out the KIRK checking of firmware PRXs and IdStorage keys.

Probably showing my ignorance here, but if M33 nulls out KIRK checking, why doesn't my UMD read when I flash M33? It's a TA-082 bought as a brick that I recovered with Pandora. Does that mean that idstorage isn't my problem?

Probably showing my ignorance here, but if M33 nulls out KIRK checking, why doesn't my UMD read when I flash M33? It's a TA-082 bought as a brick that I recovered with Pandora. Does that mean that idstorage isn't my problem?

You're putting things upside down. If your UMD doesn't read, IDStorage is your problem. I guess you did a full flash including IDStorage because "M33 nulls out KIRK checking" but if you read well, it's been reported repeatedly that it's still impossible to use another PSP's IDStorage, even on M33. Maybe they didn't null the KIRK checking fully or maybe it's the signing that's still present on the IDStorage keys.

If you didn't make (and save) a dump of the bricked nand before flashing it, you're screwed. That is, you can still use the PSP for homebrew only.

http://www.noobz.eu/joomla/news/wifi-mac-address-fixer.html

MAC address recovery shouldn't be a problem now, as long as the PSP is running homebrew :P

I don't know if this is any help, but I've just ran the Noobz MAC address fixer, and now I get the UMD could not be read message as soon as I insert the disc. Prior to that it took maybe 30 seconds for the message to appear. Don't know if this is any help or old news, but I'm happy to provide nand dumps or more info if it's any use to anyone.

I don't know if this is any help, but I've just ran the Noobz MAC address fixer, and now I get the UMD could not be read message as soon as I insert the disc. Prior to that it took maybe 30 seconds for the message to appear. Don't know if this is any help or old news, but I'm happy to provide nand dumps or more info if it's any use to anyone.

Why did you use the MAC fixer? Did you replace your wifi card or your motherboard, or did the MAC just "magically" disappear?

If the MAC disappeared or corrupted without doing anything to the hardware, it well could be your IDStorage has been screwed. Are you using 3.71 M33 firmware and did you use the USB flash0/1/2/3 access to write something to your flash? Is your PSP a fat or a slim?

if it takes a lot of time for you to get a disc read error message, the mechanism is damaged.

If IDstorage is damaged, the error is shown at the first attempt of access, thus real quick.

By the looks of it you had a perfectly working motherboard and a damaged UMD mechanism. Now it seems like you have a messed up IDStorage and damaged UMD mechanism... :(

I Used the MAC address fixer as it was a bricked motherboard that I put in a differnet chassis and therefore would not have been able to ad hoc (I didn't even try it). I have no history of the motherboard, I got it in a bricked PSP I bought for the screen. The UMD drive in the chassis worked fine with another motherboard which has a screwed backlight (not jut the fuse, the voltage doesn't step up)

So, does that mean the MAC address fixer broke my ID storage?

Ok i got a bricked PSP from my cousin and i have unbricked it with N00bz unbricker.And i have put another IDstorage on it now it won't read UMDs.

(The disc could not be read, Official firmware won't load, DNAS error (80530313), Remote Play (RSOD) & It is not ever update to 3.71M33

My firmware is 3.52M33-4
PSP was not a TA-82/86 but since i use the dump of another PSP it is now a TA-86.

PLEASE HELP ME.
THANKS IN ADVANCE

I Used the MAC address fixer as it was a bricked motherboard that I put in a differnet chassis and therefore would not have been able to ad hoc (I didn't even try it). I have no history of the motherboard, I got it in a bricked PSP I bought for the screen. The UMD drive in the chassis worked fine with another motherboard which has a screwed backlight (not jut the fuse, the voltage doesn't step up)

So, does that mean the MAC address fixer broke my ID storage?
MAC address fixer is not known to cause bricks or broken IDStorage, so I'm afraid the guy who bricked it had a good job at it.

Ok i got a bricked PSP from my cousin and i have unbricked it with N00bz unbricker.And i have put another IDstorage on it now it won't read UMDs.

(The disc could not be read, Official firmware won't load, DNAS error (80530313), Remote Play (RSOD) & It is not ever update to 3.71M33

My firmware is 3.52M33-4
PSP was not a TA-82/86 but since i use the dump of another PSP it is now a TA-86.

PLEASE HELP ME.
THANKS IN ADVANCE
Microwave it and put a vid of it on Youtube.

OMG, why don't people ever read....

Next time, try it first on your own PSP instead of screwing your cousins'

Ok i got a bricked PSP from my cousin and i have unbricked it with N00bz unbricker.And i have put another IDstorage on it now it won't read UMDs.

(The disc could not be read, Official firmware won't load, DNAS error (80530313), Remote Play (RSOD) & It is not ever update to 3.71M33

My firmware is 3.52M33-4
PSP was not a TA-82/86 but since i use the dump of another PSP it is now a TA-86.

PLEASE HELP ME.
THANKS IN ADVANCENever, ever, EVER use an idstorage from a different PSP.

Well, you screwed the PSP up and lost the IdStorage forever, end of.

Note: Any more stupid off-topic posts will be instantly deleted by myself, this topic is for technical discussion and info, not general PSP unbricking help.

Hi,

My PSP S&L also has key 0x000F. It is not mentioned on page 1. So I will dump the content in this message. I do not know where it is for, but maybe you all can have an idea about it.

Content:

00000000h: 01 00 00 00 EC 00 00 00 00 00 00 00 00 00 00 00 ; ....ì...........
00000010h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000020h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000030h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000040h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000050h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000060h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000070h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000080h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000090h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000a0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000d0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000000f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000100h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000110h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000120h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000130h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000140h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000150h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000160h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000170h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000180h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000190h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001a0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001d0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

Hi,

I made a small program based on the code of Chilly Willy's IdStorage Manager.
It will dump the hex value's of the ID Storage keys in a csv-file.
This file might come in handy to check ID Storage keys of different PSP's.

And I should have said, after the MAC address change, Ad-hoc works fine. Didn't try it before as I assumed it wouldn't work. So, is my IDStorage partially screwed, or is the immediate disc read error not a symptom of IDStorage issues?

And I should have said, after the MAC address change, Ad-hoc works fine. Didn't try it before as I assumed it wouldn't work. So, is my IDStorage partially screwed, or is the immediate disc read error not a symptom of IDStorage issues?
if it takes a lot of time for you to get a disc read error message, the mechanism is damaged.

If IDstorage is damaged, the error is shown at the first attempt of access, thus real quick.

By the looks of it you had a perfectly working motherboard and a damaged UMD mechanism. Now it seems like you have a messed up IDStorage and damaged UMD mechanism... :(
l_oliveira summed it up quite nicely ;)

I was wondering, was is the role of key 0x140? Ookm posted in his blog that some really old versions of psp were lacking this key along with 0x47. Is there any side effects of deleting it? And what does it do in the first place.

Try to delete it. :)

Try to delete it. :)
What a strange thing to say.


Should you try this way, MAKE SURE you have a FULL IDStorage backup.

I am still thinking about the latest press release from Elcomsoft and breaking passwords with a GPU. From what I read is that the GPU is very powerful and can calculate very fast. Can we use that GPU in combination of bruteforcing an new ID Storage Key?

For some indication about the speed of the GPU:

Slide show @ ExtremeTech (http://www.extremetech.com/slideshow/0,2394,l=&s=201&a=133950,00.asp)

http://common.ziffdavisinternet.com/util_get_image/7/0,1425,sz=1&i=78747,00.jpg

for you to calculate using a gpu you would need a C able gpu thus meaning it is required for it to accept non GPu language coding for this to work.

like on PCs apart from GSLS and D3x code, only the nVidia quadro cards can accept pure C codes and asm assembly.

i'm not saying it would be impossible to do in GPU but without a proper way of telling it to do other things apart from GFX language it's pretty steep. you might even bog down your performance on the bruteforce.

for you to calculate using a gpu you would need a C able gpu thus meaning it is required for it to accept non GPu language coding for this to work.

like on PCs apart from GSLS and D3x code, only the nVidia quadro cards can accept pure C codes and asm assembly.

i'm not saying it would be impossible to do in GPU but without a proper way of telling it to do other things apart from GFX language it's pretty steep. you might even bog down your performance on the bruteforce.

In the past, I used to have an Amiga computer. It might have been the first computer to use a real GPU (although I'm not completely sure about this because I didn't research it). The GPU had to be programmed in a special language and could only be used for graphic effects. Even then, people managed to program it to aid the main processor in heavy calculations. So as long as a GPU is programmable, it can be used for user programs.

But for Jachra's remark, Elcomsoft currently can only use GPU processors which are capable of integer arithmetic. Most GPUs are designed for floating point arithmetic and only a few are capable of integer arithmetic.

Still, it's an interesting development. We all know the PSP's GPU is pretty powerful for such a small unit.

Thanks for the answers. It might be something I or we can look into if it is possible.

In the past, I used to have an Amiga computer. It might have been the first computer to use a real GPU (although I'm not completely sure about this because I didn't research it). The GPU had to be programmed in a special language and could only be used for graphic effects. Even then, people managed to program it to aid the main processor in heavy calculations. So as long as a GPU is programmable, it can be used for user programs.

You're thinking of two separate parts of the custom chips: the COPPER and the BLITTER. The COPPER was the coprocessor and did VERY simple instructions - move data to a custom chip register, skip based on beam position, and wait for beam position. Using those few commands, you could control what happened in the custom chips based on the screen position. This was mostly used for changing colors on the fly, or sprites on the fly, but you could do more with some thought.

The BLITTER was a fairly decent bitblk engine, capable of blitting data with logical operations between the two sources and destination, drawing lines, and filling between drawn lines. Using the logic of the blitter, you could do things like convert chunky pixel data into planar data.

Don't get me wrong, as I may be off in my thinking, but isn't the slowdown in brute forcing keys mainly going to be checking the key's signing is valid wrather than calculating things?

And even with the best tactics, wouldn't a 512byte (4096 bit) password (wrather than some form of crypto key) still take ages to crack?

You're thinking of two separate parts of the custom chips: the COPPER and the BLITTER. The COPPER was the coprocessor and did VERY simple instructions - move data to a custom chip register, skip based on beam position, and wait for beam position. Using those few commands, you could control what happened in the custom chips based on the screen position. This was mostly used for changing colors on the fly, or sprites on the fly, but you could do more with some thought.

The BLITTER was a fairly decent bitblk engine, capable of blitting data with logical operations between the two sources and destination, drawing lines, and filling between drawn lines. Using the logic of the blitter, you could do things like convert chunky pixel data into planar data.

Yeah, I lost the details in time. The Copper couldn't be used for any kind of calculations, but I remember some programmers used the Blitter's functions for maths that the standard 68000 without FPU couldn't do fast enough. However, "programming language" is not exactly the way to describe how the Blitter had to be programmed. If I remember well, on a hardware level it was a matter of moving some data (start, end, destination, required operation) to special registers and with the last write the whole process started. I don't know how modern GPU's are working, but on a hardware level it still could be not too much different ;)

Don't get me wrong, as I may be off in my thinking, but isn't the slowdown in brute forcing keys mainly going to be checking the key's signing is valid wrather than calculating things?

And even with the best tactics, wouldn't a 512byte (4096 bit) password (wrather than some form of crypto key) still take ages to crack?

Under normal conditions you are right, but maybe with the use of the GPU we could speed things. Also since there isn't any program available yet, we could create it and let people just try it. I do not how many outputs of the ID Storage keys have been compared. Maybe we do not have to calculate all the bytes.

A little hope is in my honest opinion better than no hope.

well cory if we are able to nail a perfect GPU code execution via microcode it's fairly fast to achive a 512bit decrypter r code breaker, but the big hassle here is getting to know all of the Gpu microcodes to begin with. the EE on the Ps2 has been known to be very code worthy when it comes to helping the Mips cpu out ( i remember Shadow of colossus using this technique). using squirrels technique of bit flushing or blitting will work too but it's likely we would be limited to the ram available to the GPU since flushing data back and forth will eat bandwidth.

modern GPU's work by taking commands:
screen size
buffer params
3d vertex datas
high order priority bit (which things need to be calculated first)
raster or 3d data bits for physical or virtual calculations
and a whole lot of other stuff.

the bright side of things are GFX cards are in the 256bit + modes not like our cpu's which are just frailing the 64bit range. with this power all we need is the proper codes to activate it. since microcodes are the fasted possible executable code existant to cpu's it's out best bet to bruteforce the passwords. but like i said microcodes are tough to handle since you need to be very familiar with the architecture in order to work with it.

First post updated, thread title changed to reflect nature of topic.

Why are we ASSUMING that once IDstorage keys are lost, they can be REgenerated?
It could just be a rumour.

I think not even SONY can fix them once they're lost.

I think not even SONY can fix them once they're lost.

Yes they can. Why not, if you're the company that invented the whole thing including the encryption used? It is well known that Sony uses a magic memory stick to unbrick PSP's, that's somewhat comparable with the Pandora stick, but which also regenerates IDStorage.

Why are we ASSUMING that once IDstorage keys are lost, they can be REgenerated?No one here is assuming anything like that, else this thread probably wouldn't exist. The problem is, the info required to actually create a certain few of the keys isn't available (hence the discussion on figuring out what options are available) and isn't really in standard firmware to be utilized/reversed.

From what i've read on this thread, our best bet is bruteforcing the idstorage keys. Maybe we should start with key 0x100 since the other important keys for umd will probably be much harder(since they are 4). A good bruteforcing program for key 0x100 would do these steps: 1. Ask the user to input the original region of the psp(to set the region bytes) 2. Calculate the bytes that are unique to each psp and flash the bruteforced key 3. Call getpscode to evaluate if the key is valid. 4. If the key is valid, flash it to 0x100 and 0x120 and reboot the psp, and if its not it will get back to step 2. Well that was just a thought out loud. Start the flame war i guess :D .

Feel free to try bruteforcing the keys, it is a project that your family can continue for generations to come so that perhaps your great great great great great grandkids will have a working PSP (if the thing doesn't fail in the process xD ).

From what i've read on this thread, our best bet is bruteforcing the idstorage keys. Maybe we should start with key 0x100 since the other important keys for umd will probably be much harder(since they are 4). A good bruteforcing program for key 0x100 would do these steps: 1. Ask the user to input the original region of the psp(to set the region bytes) 2. Calculate the bytes that are unique to each psp and flash the bruteforced key 3. Call getpscode to evaluate if the key is valid. 4. If the key is valid, flash it to 0x100 and 0x120 and reboot the psp, and if its not it will get back to step 2. Well that was just a thought out loud. Start the flame war i guess :D .

Remember that you can only flash the NAND-chip about roughly 100.000 times. So you have to redirect it to RAM.

Feel free to try bruteforcing the keys, it is a project that your family can continue for generations to come so that perhaps your great great great great great grandkids will have a working PSP (if the thing doesn't fail in the process xD ).

ROFLMFAO XD damn that made my day i hadn't laughed this hard in... well today

but yeah you are right tho bruteforcing is hella long especially with such long bits

Ok, maybe you guys can help me.

I have a original PSP (TA-82/86) with 3.71 M33-3. I downgraded using Noobz 2.71 downgrader, and I guess that corrupts key 0x41. I ran Keycleaner v1.4, and it showed me that key 0x41 is a copy of 0x6. I know this has something to do with USBHOSTFS, since I could run Remotejoy before using the 2.71 downgrader. I ran the key 43 dumper or whatever, and said my USBHOSTFS was fine.

How can I fix key 41?

Ok, maybe you guys can help me.

I have a original PSP (TA-82/86) with 3.71 M33-3. I downgraded using Noobz 2.71 downgrader, and I guess that corrupts key 0x41. I ran Keycleaner v1.4, and it showed me that key 0x41 is a copy of 0x6. I know this has something to do with USBHOSTFS, since I could run Remotejoy before using the 2.71 downgrader. I ran the key 43 dumper or whatever, and said my USBHOSTFS was fine.

How can I fix key 41?

KeyCleaner doesn't (yet) fix 0x41 when it is bad all by itself. The way to fix it is to run IdStorage Manager and dump the keys. Then replace the 0x0041.bin file with a good copy (key 0x41 is universal on phat psps, so any good 0x41 would work). Then run IDSM again and select verify/fix keys. IDSM will see that 0x0041.bin doesn't match the key in the idstorage and will ask if you wish to overwrite the key with the contents of the file.

Ok, maybe you guys can help me.

I have a original PSP (TA-82/86) with 3.71 M33-3. I downgraded using Noobz 2.71 downgrader, and I guess that corrupts key 0x41. I ran Keycleaner v1.4, and it showed me that key 0x41 is a copy of 0x6. I know this has something to do with USBHOSTFS, since I could run Remotejoy before using the 2.71 downgrader. I ran the key 43 dumper or whatever, and said my USBHOSTFS was fine.

How can I fix key 41?

KeyCleaner doesn't (yet) fix 0x41 when it is bad all by itself. The way to fix it is to run IdStorage Manager and dump the keys. Then replace the 0x0041.bin file with a good copy (key 0x41 is universal on phat psps, so any good 0x41 would work). Then run IDSM again and select verify/fix keys. IDSM will see that 0x0041.bin doesn't match the key in the idstorage and will ask if you wish to overwrite the key with the contents of the file.
Ahh well. I had a nand-dump of MY psp (original) with 3.71 OFW on it. I used NandTOOL and it lets me restore individual things. I choose the IDSTORAGE, and now all keys are perfect, and USBHOSTFS works again..

Thanks on making Keycleaner. Its a great app.

Ok, maybe you guys can help me.

I have a original PSP (TA-82/86) with 3.71 M33-3. I downgraded using Noobz 2.71 downgrader, and I guess that corrupts key 0x41. I ran Keycleaner v1.4, and it showed me that key 0x41 is a copy of 0x6. I know this has something to do with USBHOSTFS, since I could run Remotejoy before using the 2.71 downgrader. I ran the key 43 dumper or whatever, and said my USBHOSTFS was fine.

How can I fix key 41?

KeyCleaner doesn't (yet) fix 0x41 when it is bad all by itself. The way to fix it is to run IdStorage Manager and dump the keys. Then replace the 0x0041.bin file with a good copy (key 0x41 is universal on phat psps, so any good 0x41 would work). Then run IDSM again and select verify/fix keys. IDSM will see that 0x0041.bin doesn't match the key in the idstorage and will ask if you wish to overwrite the key with the contents of the file.
Ahh well. I had a nand-dump of MY psp (original) with 3.71 OFW on it. I used NandTOOL and it lets me restore individual things. I choose the IDSTORAGE, and now all keys are perfect, and USBHOSTFS works again..

That works, too. :D

Thanks on making Keycleaner. Its a great app.

Thanks.

Looking through the first post, key8 existed AFTER the TA-086 motherboard was out.

I have a TA-082 mobo, and I had problems with the brightness bug. (In other words my TA-082 mobo acts like a TA-086)

Using IDSM I popped in key8 into my PSP, and the symptom that appear are simply.... gone.

Through email Chilly Willy said that the LCD modules of later 82 boards are same as 86 motherboards.

So I assume key8 are existed in some 82 boards (not just 86 boards of what the first post says)?

Sincerely,
Stoffbeat/Acerthief.

Correct.
There seem to be two revisions of the TA-082 board. The second one with the new brightness hardware one was first labelled the TA-082, and later labelled the TA-086. This can be proven by the fact that the TA-082 and TA-082 rev2/TA-086 both have the same Tachyon (VME) hardware version but different Baryon (aux.) hardware versions :)

Hi folks,

I've been reading this forum for a while, and thinking about idStorage issues. I took the time to register an account, in case the following will be helpful for you guys to figure out idStorage regeneration.

We know that:

* idStorage stores keys required to properly verify/decrypt UMD and MagicGate content
* those keys are unique per PSP

I suspect that:

* there is a set of "master keys" that SCE has and uses to encrypt/sign UMD / MagicGate stuff.
* because an UMD must be read everywhere, this set of keys is most certainly unique.
* SCE doesn't want to embed these keys directly into the flash of their devices, as it would be far too easy to recover them.

Hence, we might deduce that:

* actual encryption/decryption of UMD/MG content is done in hardware, not by the MIPS. isn't there a specific DRM chip on the PSP mobo?
* the idStorage keys are themselves encrypted with a per-device key. this per-device key is used to decrypt idStorage into the master keys

Well, knowing this, the regeneration of idStorage would require:

* the knowledge of the master keys, and the per-device key. SCE has the master keys, and there could be a specific "magic command" to retrieve or modify the per-device key

This DRM could be cracked, not that easily though. A possible way of attack is to reverse-engineer the DRM chip, from there you could recover the master keys, and also find out the "magic command" to retrieve/reset the per-device key.

This is also another alternative: perhaps, to reduce costs, there is no per-device key. Then, the master key is already embedded in the DRM chip, and the idStorage UMD/MG blob is actually not a set of encrypted keys, but rather a keyed MAC (for example, HMAC-MD5 or whatever) of a specific part of the PSP, like the serial number. The DRM chip knows the MAC key and the serial number, and checks if the calculated MAC matches the idStorage MAC. If not, it turns down itself.

However, this would mean there is not a per-device key, but rather a common "MAC key" to authentify the idStorage. Someone in this thread mentioned the possibility of brute-forcing it -- just not possible if SCE did their homework on message authentication codes.

Anyhow, just my 2c. If there are mistakes above, feel free to correct me :)

Well, knowing this, the regeneration of idStorage would require:

* the knowledge of the master keys, and the per-device key. SCE has the master keys, and there could be a specific "magic command" to retrieve or modify the per-device key


I don't think we need the per-device key. For a simple reason...
The "Syscon" chip obviously has some kind of service mode which is used to create the ID storage. If it does work this way, then it would maybe require a "master key" and then receive a set of static data to be encrypted internally by the device using it's per-device key.

The resulting data would work only for the device that encrypted it, on our case, the PSP that generated it. The result is achieved without the need of the internal device key be ever needed by anyone else than it's own internal encryption engine.

An pretty decent test would be taking two boards of the same kind and swapping the contents of their nands RAW, then using proper BGA soldering equipment swap the "Syscon" chips.

Did anyone ever consider logic probing the bus that goes from the CPU to the "Syscon" ?

l_oliveira:

Only if the mechanism to recreate the idstorage keys still exist in syscon (currently the prime suspect of where this "unique id key" is stored). Though it's still no trivial task to extract the id if that mechanism no longer exists.

And yea, that is (currently) the only way to make a nand dump from a another psp work, though you still need bga equipment to do it. But essentially that is no different to doing a full mobo swap with the psp that the nand dump came from.

toto12345:

Yes decryption of umd's are done via hardware, there is a dedicated crypto device to do that. Essentially what happens is: (NOTE: not totally confirmed yet but all evidence so far suggests it to be the case)

* the UMD has 2048 Byte sectors with a 16 Byte "spare" area per sector.
* the spare area holds a key to decrypt that sector
* that key is encrypted
* the keys to decrypt that key are in idstorage
* those keys are also encrypted
* the key to decrypt those keys is the unique per psp id
* which again leads us right back to syscon...

SCE does use keyed MAC elsewhere though, the 2.60+ IPL encryption uses a standard HMAC-SHA256 algo (with part of the preipl as secret key). So they have done their homework to prevent bruteforce attacks. Though unfortunately for them it was an exploit in the preipl code that lead it to be dumped (rather than an attack on the crypto) making their "secret key" not so secret anymore and hence their crypto completely useless :p.

I'll be writing up tech doc for that too (since it is by far the most paranoid attempt from SCE for any of their security to date).
A quick summary:

- Preipl buffer used as secret key
- Various global buffers are also used for the secret key for each HMAC-SHA256 generated along the way (I've ommited those in the following)

Initialise the seed:
- Seed a MT19937 pseudo random number generator with address of the preipl buffer
- Grab 4KB from the prng
- Merge it with the preipl buffer
- Generate HMAC-SHA256 of the new buffer
- Xor MAC with a global buffer
- That is now your seed to use to decrypt an encrypted buffer

To decrypt:
- Gen HMAC-SHA256 of the seed from above
- Repeatedly fill the MT19937 state with this MAC
- For each 32-bytes of ciphertext:
- Grab 64-bytes from the prng
- Gen HMAC-SHA256 of those 64-bytes
- Xor the ciphertext with that MAC to get the final plaintext

* the UMD has 2048 Byte sectors with a 16 Byte "spare" area per sector.
* the spare area holds a key to decrypt that sector
* that key is encrypted
* the keys to decrypt that key are in idstorage
* those keys are also encrypted
* the key to decrypt those keys is the unique per psp id
I've stumped up some theories now, I'm sorry if they're completly wrong :p
So you need 2 keys to decrypt the UMD data:

Key #1 = Get this key from the IDStorage, then decrypt it with a PSP-unique key
Key #2 = The key from the UMD spare sector, which is still encrypted and needs to be decrypted with key #1

If I understand correct, key 1 is always the same in the end, it gets different values on every PSP at first, but then always ends up with the same key after decrypting it.
Now, what if you would create a memory dump of the decrypted key 1, then save it elsewhere. That'll give you a PSP-independent decryption key, right?
Next thing, would it be possible to hook the sce functions that execute the whole key 1 decryption process, and instead just force it to take the already independent key that we dumped on a working PSP?

If I understand correct, key 1 is always the same in the end, it gets different values on every PSP at first, but then always ends up with the same key after decrypting it.
Indeed, this is what we've always suspected. Just like with sigchecking, the final data is probably the same on all PSPs :)

The UMD decryption does not take place on an accessible area of memory, but inside one of the encryption processors (actually mask rom) called Spock. So we can't get the key. The Spock has probably got access to the PSP unique ID, which it uses to decrypt the IDStorage key. Then, the decrypted key (which after having been decrypted is the same on all PSPs) is used in conjunction with the UMD MKI (in spare areas) to decrypt the data.

The UMD decryption does not take place on an accessible area of memory, but inside one of the encryption processors (actually mask rom) called Spock. So we can't get the key. The Spock has probably got access to the PSP unique ID, which it uses to decrypt the IDStorage key. Then, the decrypted key (which after having been decrypted is the same on all PSPs) is used in conjunction with the UMD MKI (in spare areas) to decrypt the data.

Knowing Sony, the unique ID will be somewhere called 'Picard' or something... :D

So... Spock = Syscon?

Knowing Sony, the unique ID will be somewhere called 'Picard' or something... :D

So... Spock = Syscon?

No, dont know the codename for syscon.

Spock is the other crypto engine (as opposed to Kirk :p). Both have access to the psp's unique id. Both are similar in many ways, they both have roughly the same number of cmds, have similar registers, but Spock is many many times more complex to interface with.

Kirk HW registers are mapped to 0xBDE000xx while Spock HW registers are mapped to 0xBDF000xx.

The Signature & Version registers:

0xBDE00000: 'K' 'I' 'R' 'K'
0xBDE00004: '0' '0' '1' '0'

0xBDF00000: 'S' 'P' 'O' 'K'
0xBDF00004: '0' '0' '5' '0'

These were from my psp (a TA-079) so the versions might be different on your psp.

(Note: this will all be in the tech doc, plus the rest of the registers and how to use)

EDIT:

Before I posted a sample of how to interface with the Kirk registers, it currently decrypts IPL but can be modded to decrypt prx's as well.

http://silverspring.lan.st/IPL Decrypt Sample.rar

The interface with the Spock registers will be similar but a lot more complex.

Silverspring, is the chip already identified on the motherboard?


/all others:

What does Iowio.prx?

Yes the chip is already known.

About lowio.prx, it was just an attempt from sce to save some flash space. They implemented a few things starting from 3.50 to save space:

- changed the prx format by stripping some data from it (saving upto a few KB per prx in some cases)
- started using RLZ compression for a few of the larger prx's (saving over 150KB in the case of libssl.prx)
- packing multiple prxs together into a single prx to save on slack space due to the use of 16KB cluster sizes of the FAT12 filesystem that they use for flash0.

That was the case with lowio.prx, it grouped together the low level io drivers:

- sysreg.prx (7KB)
- gpio.prx (4KB)
- pwm.prx (2KB)
- i2c.prx (5KB)
- dmacplus.prx (9KB)
- lcdc.prx (5KB)
- emc_sm.prx (3KB)
- emc_ddr.prx (9KB)

Note: sizes are of pre-3.50 fw (ie. 3.40).

Since each prx is less than 16KB, each wastes quite a bit on slack and all individually stored on a 16KB cluster FAT12 partition would take up 8*16KB = 128KB.

From 3.50 stored all in one prx, lowio.prx is 30KB so would take up 32KB on a FAT12 partition, saving 96KB of flash space.

In future firmware, more & more prxs will probably be grouped together like this to save even more space, especially with small prx's that are only few KB in size (each of which would take up 16KB on the partition).

Dear All,

I have the following missing keys on my phat TA-086 PSP. Is it possible to get these keys from another phat TA-086 PSP to restore it? I have also having problem identifying my motherboard with keycleaner 1.4. It said that my IDStorage is having probem. Thanks.

0x7
0x40
0x51
0x140

Dear All,

I have the following missing keys on my phat TA-086 PSP. Is it possible to get these keys from another phat TA-086 PSP to restore it? I have also having problem identifying my motherboard with keycleaner 1.4. It said that my IDStorage is having probem. Thanks.

0x7
0x40
0x51
0x140
Yes, you can use these keys from another TA-086. Just get the keys and use KeyCleaner to flash them.

Too bad, i do not have another TA-86 phat PSP. Can anyone send me the keys? Thanks.

Dear All,

I have the following missing keys on my phat TA-086 PSP. Is it possible to get these keys from another phat TA-086 PSP to restore it? I have also having problem identifying my motherboard with keycleaner 1.4. It said that my IDStorage is having probem. Thanks.

0x7
0x40
0x51
0x140
Yes, you can use these keys from another TA-086. Just get the keys and use KeyCleaner to flash them.

Check your PM in about 5 minutes.

Dear All,

I have the following missing keys on my phat TA-086 PSP. Is it possible to get these keys from another phat TA-086 PSP to restore it? I have also having problem identifying my motherboard with keycleaner 1.4. It said that my IDStorage is having probem. Thanks.

0x7
0x40
0x51
0x140
Yes, you can use these keys from another TA-086. Just get the keys and use KeyCleaner to flash them.

KeyCleaner won't do that. If the keys are missing, you need to run IdStorage Manager, create the keys (they will be created as clear keys), make a dump of the keys, replace the specific dumped keys with the good keys, then do verify/fix in IdStorage Manager.

Roger that. Thank you guys for all the information.

Dear All,

I have the following missing keys on my phat TA-086 PSP. Is it possible to get these keys from another phat TA-086 PSP to restore it? I have also having problem identifying my motherboard with keycleaner 1.4. It said that my IDStorage is having probem. Thanks.

0x7
0x40
0x51
0x140
Yes, you can use these keys from another TA-086. Just get the keys and use KeyCleaner to flash them.

KeyCleaner won't do that. If the keys are missing, you need to run IdStorage Manager, create the keys (they will be created as clear keys), make a dump of the keys, replace the specific dumped keys with the good keys, then do verify/fix in IdStorage Manager.

Hi Chilly Willy,

Do you know which is the key that KeyCleaner 1.4 uses to identify the motherboard of a phat PSP TA-086? Cos mine is having problem identifying my board. I think it might be due to the corrupted keys. Thank you.

Regards,
Yong Teck

Dear All,

I have the following missing keys on my phat TA-086 PSP. Is it possible to get these keys from another phat TA-086 PSP to restore it? I have also having problem identifying my motherboard with keycleaner 1.4. It said that my IDStorage is having probem. Thanks.

0x7
0x40
0x51
0x140
Yes, you can use these keys from another TA-086. Just get the keys and use KeyCleaner to flash them.

KeyCleaner won't do that. If the keys are missing, you need to run IdStorage Manager, create the keys (they will be created as clear keys), make a dump of the keys, replace the specific dumped keys with the good keys, then do verify/fix in IdStorage Manager.

Hi Chilly Willy,

Do you know which is the key that KeyCleaner 1.4 uses to identify the motherboard of a phat PSP TA-086? Cos mine is having problem identifying my board. I think it might be due to the corrupted keys. Thank you.

You could look at the code... it comes with the app. There's two functions - one to ID the mobo, and another to ID the region. I forget offhand what keys they use, so check the source.

Ok, Thanks.

Hi Chilly Willy,

Do you know which is the key that KeyCleaner 1.4 uses to identify the motherboard of a phat PSP TA-086? Cos mine is having problem identifying my board. I think it might be due to the corrupted keys. Thank you.

You could look at the code... it comes with the app. There's two functions - one to ID the mobo, and another to ID the region. I forget offhand what keys they use, so check the source.

Sounds like you lost your whole IdStorage. I sent you a set of TA-086 keys you can try but you won't ever regain functionality like DNAS/adhoc since your 0x100 region key is lost.

Cool. Thank you. Will try and see how it goes. Hopfully with the new set of keys, i would be able to update to 3.71.

Sounds like you lost your whole IdStorage. I sent you a set of TA-086 keys you can try but you won't ever regain functionality like DNAS/adhoc since your 0x100 region key is lost.

Sad to said, even with the given set of working keys, i am still unable to update to 3.71 M33. Think i will have to stick with 3.52 M33 V4 till the end lol.

Sad to said, even with the given set of working keys, i am still unable to update to 3.71 M33. Think i will have to stick with 3.52 M33 V4 till the end lol.
Once key 0x100 is changed, you can't run official updaters. You should, as far as I know, be able to use Despertar del Cementario to flash 3.71 M33

Sad to said, even with the given set of working keys, i am still unable to update to 3.71 M33. Think i will have to stick with 3.52 M33 V4 till the end lol.
Once key 0x100 is changed, you can't run official updaters. You should, as far as I know, be able to use Despertar del Cementario to flash 3.71 M33

I did try to use Despertar del Cementario to update to 3.71 M33, but still i faced the same problem after the update. Unable to on the PSP.

By the way, i am using U.P.M.S. Emerald Full for the udpate.

First, merry X-Mas to everyone.

I know that there is a leaked version of the memstick Sony uses to reflash a PSP. Did anyone succeeded in enabling it to boot with the Pandora battery?
Did anyone decrypt those prx's yet?

It's impossible to decrypt without the original memory stick that it was on.

It's impossible to decrypt without the original memory stick that it was on.

You mean Sony used the MagicGate function so it can only run from the memorystick on which the files originally where created?

It's impossible to decrypt without the original memory stick that it was on.

You mean Sony used the MagicGate function so it can only run from the memorystick on which the files originally where created?
Rather, they probably use the MS's serial as a seed. If MS IPL booting relied on magic gate I have my doubts we would have pandora now.

I do not think they used the MS Serial as a seed, because they have to use that memstick on several PSP's. I do think you need the correct MS IPL to launch it. I do not know if anyone is able to recreate it. I guess it is safe to assume that it is not encrypted with the KIRK-engine but with SPOCK-Engine.

I guess it is safe to assume that it is not encrypted with the KIRK-engine but with SPOCK-Engine.

.....What makes you think that?

I do not think they used the MS Serial as a seed, because they have to use that memstick on several PSP's.
You're contradicting yourself :p This is the REASON why they used the MS serial: they used the same memory stick on different PSPs, this allowed them to strongly encrypt it and make it useless for other memory sticks, whilst allowing it to be used on any PSP (no worrying about the KIRK ID messing it up). Remeber the memory stick serial is stored on the memory stick, so whatever PSP they used it on, the serial would be the same.

Also, SPOCK is probably only used for UMD decryption. I find it unlikely that they wouldn't use KIRK, as it's used to decrypt all other files.

I guess it is safe to assume that it is not encrypted with the KIRK-engine but with SPOCK-Engine.

.....What makes you think that?

Since nobody is able to decrypt it.

@jas0nuk

Good point.

Since nobody is able to decrypt it.

As far as I know, there's no reason why, should we get a copy of Sony's Service IPL, we can't decrypt it.

You think a different crypt engine is being used just because we don't have a decrypted version in front of us?

The jigkick topic is a bit off topic :)

Not hugely, since it is a common beleif the official service software that was leaked might be able to repair a broken/MIA idstore and thus hold the "keys" to deal with regenerating idstore.

Makes complete sense, instead of flashing IPL and NAND like we do, they can just flash a fresh IPL, IDStorage and NAND in one go. The Service Software could even lead to us being able to regenerate IDStorage.

I agree with brin_vg that we should look into those files. There are 5 PRX's that are not part of a normal firmware. They could hold some information for us.

brin_vg, that was my thought.

When I look in those PRX's I see something reoccurring. I do not know at this point if it is related to the encryption. The bytes at 0x00000000 to 0x00000004 are empty aka has the byte filled with the value 0x00. The firmware PRX's have in that spot the "string "~PSP". That part seems to be removed for a purpose. Maybe to show that it is a different encryption method.

The first block of bytes always end at 0x000000B4 with the value of 0x80. The value for each byte from 0x00000005 to 0x000000B3 is not the same in every PRX.
From 0x000000B5 to 0x000000CF it is always filled with value 0x00 for each byte. The "string" "SCE-1783 for_CS" always starts at 0x000000D0 and ends always at 0x000000DE.
The next block with the value 0x00 for each byte starts at 0x000000DF to 0x0000014F. Then follows the rest of the data.

What i meant is that there is not much point in continuing discussing jigkick, as it doesn't restore all keys. Just a few that even WE can. (If it did restore all keys, why do you think they'd give refurbished PSPs back instead of restoring, in some really fucked up cases? ;) )

What i meant is that there is not much point in continuing discussing jigkick, as it doesn't restore all keys. Just a few that even WE can. (If it did restore all keys, why do you think they'd give refurbished PSPs back instead of restoring, in some really fucked up cases? ;) )


We can't know for sure if they restore idstorage keys or not using the jigkick unless we get ourselves a decrypted version of the MS files, which we don't and given the likely copyrighted nature of the content we'd better delete the files especially since encrypted those wont bring us anything good and that it would be illegal to have these anyway. In fact speaking of anything copyrighted should be off limits unless you want SCE to shut down these forums.

In my belief, whatever way used to setup idstorage keys at factory is probably gone (destroyed at factory) and probably sony themselves cannot restore the said keys. (I came to that conclusion as sony do not even dare touch to idstorage keys in their updaters (to prevent downgraders or custom firmwares) probably in the fear of damaging those.)

Finally the best would be to concentrate on things such as the lepton (UMD) hardware which probably has a mean to access spock. (since it checks for the idstorage keys by itself) I wouldn't be surprised if there is a microcode inside the UMD drive (a firmware or such) and a way to dump it. We may also interact with the hardware itself and try to access spock by bruteforcing the calls the UMD drive uses.

@Mathieulh

I do not think it is illegal to have them, however I think it is illegal if anyone might use them. Even the DMCA allows for reverse engineering. Even the European Laws allow it. We are allowed to speak over them as we all have our freedom of speech. but we can not hosts those files here. That will surely allow Sony to close this board.

The ID Storage keys maybe discarded at the factory but Sony can restore them. They can make them again by doing the same process again. The updaters never have to do anything with the ID Storage than to query. Sony does that part right. If there is a error within the ID Storage or some keys, then it should display an error message to contact Sony or Vendor.

However their memstick might be able to repair the ID Storage or might not be able to fix it. Until we have looked in those files, we can never be sure of it.

It is illegal to have the files, as they remain full property of Sony, when you buy a PSP, you buy an license for the firmwares too, allowing you to legally own/use (with lots of limitations, of course).
However, Sony never gave anyone permission (through a license, or any different way) to use/own the JigKick files, meaning it remains property of Sony.
If they all talk about the files here on the forums, they have their proofs everyone who is talking about them (illegally) owns them, so you're basically getting yourself in problems. But that's just my theory, can't be really sure, I'm not an lawyer :p

Oh no, not another discussion on legalities trying to subvert the thread entirely :( Put simply, none of us have the files, and even if we did two things have been proven from unknown sources...
1) they are crypted and we don't know or those of us who do know aren't saying exactly what is required to decode them into recognizable formats
2) whatever was leaked is inferior to des.cem and/or pandora (recreating generic keys was never an issue) - chiefly because of the above arguments and #1

One point... it is also a common beleif the Loch Ness monster exists. Even if it does float, no one has proven it - or those who can prove it choose not to. ;)
If it did restore all keys, why do you think they'd give refurbished PSPs back instead of restoring, in some really fucked up cases? ;)
Well, there is the simplest answer... it is cheaper to scrap a hardware issue than pay a tech $50+/hr to rework a board. It's been proven that many PSP have essentially randomly failed due to the dpad/NAND stress issue causing problems with the BGA. Also, where do you beleive they get the refurbs from that they send to people? Generally they are the harder to fix units that were put on the back burner until the specialist (be it special/unique hardware like something that reinstates full idstore where the general service util can't, or someone with rework experience) has a chance to repair them.

Yeah, the standard Jigkick (at least the PSP 100X) one is inferior to Des. Cem, what we need now is IDStorage regen, everything else can be easily handled due to the recent work of cory and others on repartitioning the NAND :)

And leave the amateur lawyer discussion out of this thread, please :p

Oh no, not another discussion on legalities trying to subvert the thread entirely :( Put simply, none of us have the files, and even if we did two things have been proven from unknown sources...
1) they are crypted and we don't know or those of us who do know aren't saying exactly what is required to decode them into recognizable formats
2) whatever was leaked is inferior to des.cem and/or pandora (recreating generic keys was never an issue) - chiefly because of the above arguments and #1

One point... it is also a common beleif the Loch Ness monster exists. Even if it does float, no one has proven it - or those who can prove it choose not to. ;)
If it did restore all keys, why do you think they'd give refurbished PSPs back instead of restoring, in some really fucked up cases? ;)
Well, there is the simplest answer... it is cheaper to scrap a hardware issue than pay a tech $50+/hr to rework a board. It's been proven that many PSP have essentially randomly failed due to the dpad/NAND stress issue causing problems with the BGA. Also, where do you beleive they get the refurbs from that they send to people? Generally they are the harder to fix units that were put on the back burner until the specialist (be it special/unique hardware like something that reinstates full idstore where the general service util can't, or someone with rework experience) has a chance to repair them.
Time and money to make and send out a new one is probably less than that of figuring out what's wrong with it, then fixing it.

And yes, if someone has managed to obtain and decrypt those files, then they are probably the only ones who can (or should) make use of them, be that reversing or whatever.

Perhaps, as adrahil said, the Sony Service PRXs aren't worth investigating, they're difficult to get, and very likely to get us into trouble.

And leave the amateur lawyer discussion out of this thread, please :p
Indeed :D

Perhaps, as adrahil said, the Sony Service PRXs aren't worth investigating, they're difficult to get, and very likely to get us into trouble.

And leave the amateur lawyer discussion out of this thread, please :p
Indeed :D

Well, it remains speculative if they are worth investigating until someone does it. It could lead to nothing or to a solution in regenerating the ID Storage keys. The different encryption would suggest that there is something they are hiding. The files are not that hard to get. You just have to know where to look. ;)

@jas0nuk and brin_vg

I agree on leaving the law stuff out, because laws differs from country to country. ;)

It's not speculation, if you don't want to believe the words of mathieulh and adrahil, you are free to continue investigating but I believe even if you do manage to untangle the mess it would be for nothing.

As suggested previously, the best available courses of action that could generate results are still:
1) attacking the hardware directly to gain inner workings.
2) attacking the firmware to remove it's reliance on certain unique keys.

My own amateur law "degree" extends to this:
"I saw an amazing thing the other day. It was so cold out I saw a lawyer with his hands in his own pockets!"

It's not speculation, if you don't want to believe the words of mathieulh and adrahil, you are free to continue investigating but I believe even if you do manage to untangle the mess it would be for nothing.

As suggested previously, the best available courses of action that could generate results are still:
1) attacking the hardware directly to gain inner workings.
2) attacking the firmware to remove it's reliance on certain unique keys.

My own amateur law "degree" extends to this:
"I saw an amazing thing the other day. It was so cold out I saw a lawyer with his hands in his own pockets!"

Well, it is. We do not know exactly what those 5 different PRX's do. Until we know exactly and I mean exactly what they do, it remains speculation. And it is not for nothing. We or someone or I found a way not to fix the ID Storage keys. The path they suggest could lead to a way to fix the ID Storage, but it might not be the only way is what I am saying.

It is not a must to decrypt those files.That is all.

It's not speculation, if you don't want to believe the words of mathieulh and adrahil, you are free to continue investigating but I believe even if you do manage to untangle the mess it would be for nothing.

As suggested previously, the best available courses of action that could generate results are still:
1) attacking the hardware directly to gain inner workings.
2) attacking the firmware to remove it's reliance on certain unique keys.

My own amateur law "degree" extends to this:
"I saw an amazing thing the other day. It was so cold out I saw a lawyer with his hands in his own pockets!"

I think the latter is much more likely, based on what I've read :D
Utopia...

It's not speculation.
It is.
I'll save some time here, one could just copy/paste the above into hundreds of posts to continue the discussion. I won't waste my time typing any more than this, as it would apparently be a complete utter waste of time as apparently I just go around typing BS every chance I get :rolleyes:

@cory1942

I do not think you are typing BS. ;)

A friend of mine got his PSP back after getting it fixed by SONY and He purposely over wrote the IDStorage and sent it to them.....

He scratched the faceplate across the screen...and hoping he would get a referb without the scratch he overwrote IDStorage with mine plus he deleted flash0 and sent it in...and got it back in working condition... so...maybe then can reproduce IDStorage..

That is good news, indeed. I already suspected that they could "easily" rewrite the ID Storage. The only question remains how they do it.

to my knowledge we've always known sony can regenerate IDStorage
it makes no sense if they couldnt
how is the big question

not a dev...just an avid reader of lan.st/lan.sh
good luck guys

Did he have a dump of the original IDStorage? Were the new unique keys exactly the same as the old ones?

I think it'd be good to do a few little investigations like this...

Good question, brin_vg.

ah i see
good thinkin brin_vg if im understanding you right
you're sayin there may be a few valid keys for every PSP rather than one unique set per PSP
like windows has many valid keys but only one true volume license key
so all youde need is the decryption key and the algorythm that generates the IDStorage keys
well worth investigation
but if the unique keys come back different, that would surely make working out the generation of such keys all that much harder, wouldnt it?

just thought of something, couldn't we kind of brutez force the keys that are one of a kind?
Maybe that would be long but maybe thazt would work, we would try every possible value for each key, and maybe one day we'd get the good one...
possible?

A friend of mine got his PSP back after getting it fixed by SONY and He purposely over wrote the IDStorage and sent it to them.....

He scratched the faceplate across the screen...and hoping he would get a referb without the scratch he overwrote IDStorage with mine plus he deleted flash0 and sent it in...and got it back in working condition... so...maybe then can reproduce IDStorage..

Unfortunately, that is still not proof enough. It is known that Sony do motherboard replacements in some repairs. What he should have done is scratch the motherboard instead.

What he got back may simply have been his original case but with a new refurbished motherboard inside.

That's more likely. What I now believe is that the PSP is only able to generate its IdStorage on it's first ever boot into the firmware at factory, and then this ability is physically destroyed - sort of like the eFuse system in the Xbox 360.

That's more likely. What I now believe is that the PSP is only able to generate its IdStorage on it's first ever boot into the firmware at factory, and then this ability is physically destroyed - sort of like the eFuse system in the Xbox 360.

That should not be too hard to realise. Install a special PRX that loads at the first firmware boot, creates the IDStorage keys and erases itself from flash and btcnf. But if that is the case, it must be possible to find traces of that PRX in the untouched flash0 dump of a brand new PSP.

Depends really, from what I have seen so far deleting a file in lflash results in it's data being destroyed unlike a PC which just marks the block as unused. Also, what jas0nuk suggests could be plausible, where certain commands in the chip are completely disabled by blowing a transistor or efuse by overloading it.

Makes more sense to me though that they'd have special hardware to deal with initialization at factory rather than relying on internal tricks.

Depends really, from what I have seen so far deleting a file in lflash results in it's data being destroyed unlike a PC which just marks the block as unused. Also, what jas0nuk suggests could be plausible, where certain commands in the chip are completely disabled by blowing a transistor or efuse by overloading it.

Makes more sense to me though that they'd have special hardware to deal with initialization at factory rather than relying on internal tricks.

You mean in the KIRK-engine and/or SPOCK-engine? If it is inside a chip, well, that is very hard to detect.

-------------

If that is truly the case, what for options for regeneration are left? Brute Force a key, recovering the method to recreate a key by breaking the encryption aka decryption or being able to use a PSP without a ID Storage?

You mean in the KIRK-engine and/or SPOCK-engine? If it is inside a chip, well, that is very hard to detect.

Er.


What?

If that is truly the case, what for options for regeneration are left? Brute Force a key, recovering the method to recreate a key by breaking the encryption aka decryption or being able to use a PSP without a ID Storage?
As before, the most feasible way I think would be to bypass IDStorage, however the fact that, for example, UMD decryption uses the keys themselves (not 100% sure on that one, mind), makes this very difficult.

@brin_vg

If they destroy a e-fuse or a transistor in the factory then the most likely candidate would be the crypto-chips.

That's more likely. What I now believe is that the PSP is only able to generate its IdStorage on it's first ever boot into the firmware at factory, and then this ability is physically destroyed - sort of like the eFuse system in the Xbox 360.
I think that sounds like a plausible way that sony makes the idstorage keys because some ware i saw that one of the IDStorage keys shows the first firmware that was on the psp so when the psp first boots the prx must read the firmware version and read some other hardware ino then create the IDStorage so there must be a prx that does this then deletes its self off of the flash0.
EDIT: the key is key 0x51 and on the first post it says Firmware the PSP shipped with (exists since TA-086)

I think that sounds like a plausible way that sony makes the idstorage keys because some ware i saw that one of the IDStorage keys shows the first firmware that was on the psp so when the psp first boots the prx must read the firmware version and read some other hardware ino then create the IDStorage so there must be a prx that does this then deletes its self off of the flash0.
EDIT: the key is key 0x51 and on the first post it says Firmware the PSP shipped with (exists since TA-086)

Off topic: You spelt your name wrong :( GameBpx :D

The method of generating IDStorage (or at least, the keys generated, obviously) changed with the hardware, which would suggest a hardware method. But as retrieving lost info on lflash is supposedly impossible, there's no clear way to tell.

EDIT: Random pondering:

Key 52 - Suspected to contain manufacturing info, which would mean either:
- Each factory/production line/etc has a unique chip used in IDStorage generation
- There is some kind of production stage input into IDStorage.

Key 54 - May well be used for unlocking/special features, i.e. The Simpsons game on a Simpsons edition PSP.
Key

[/ponder]

My experiments on key 54 showed that reset to default changed which color wallpaper showed up initially right after reset. Whether the effect is limited to that, dunno, but there appear to be a few keys that are there to set such things.

But as retrieving lost info on lflash is supposedly impossible, there's no clear way to tell.


It's be interesting to know if one of the hardware gurus would be able to obtain a hardware-method flash dump of a PSP that has never been turned on since it left the factory, then compare it to a dump after the same PSP has been booted.

If part of the production line powers on (00000000) the PSP and does the magic there, IDStorage will already be in place.

btw in case anyone is interested, in slim nands (factory flashed ones without any modifications like M33 installed or 3.70+ installed) you can see the reminants of some IPL blocks that have not been erased by 0xFF (there is about 25kBytes of remaining IPL blocks) and that was probably preflashed on the nand and used at factory to setup the psps. The fact that there are still traces of it suggest the IPL itself to have been huge. Unfortunately we have not enough blocks to ever hope for a decryption.

It is likely that this IPL starts a specific kernel on the psp that setups the psp (inclueding idstorage) then destroy the possibility to ever generate idstorage keys again and overwrites itself with 3.60 kernel.

I tried to locate traces of simuilar IPLs on a fresh 1.00 dump but all I could see was 0xFF so either sony did not use the nands to setup original psps from factory, either they did a better job at occulting the factory IPL than they did on slim (I believe in that second option) it also explains the 0x00000000 serial used in the batteries that auto poweron the psps and yet still runs the IPL from the nands.

Very interesting. Sounds about right that they produce all the batteries with 0x00000000, insert it into the PSP with the one-time IdStorage setup IPL, and it generates a unique serial for the battery and immediately writes it.

@MatieulH

So Sony is able to do the same again when a PSP is bricked. They can flash the same "firmware" again. Too bad that the leaked jigkick memory sticks aren't decrypted yet.

My belief is that the factory kernel (I will call it that way) writes the kirk id into the syscon chip, the kirk id would be a One Time Programmable and Write only. Once the kirk id is set, the kernel stores it into ram and starts using kirk commands to generate the idstorage keys using the kirk id previously stored in ram. I expect the kirk id to be a random number. This means that even sony could not regenerate idstorage keys for the kirk id would be lost at power off. (and of course there would be no way of getting it but hardware probing) Also this means that even in the unlikely event that we ever get this factory kernel available to reverse (which means that it somehow would have been leaked) it would be of no use to us.

Well well, I did not know about this IPL (never bothered to look I guess :p).

Well I had a look from a 3.60 dump. The only remains of the factory IPL is the last 6 blocks of it. The blocks themselves decrypt fine but unfortunately, being the last 6 blocks of an IPL they end up landing right at the end of the payload, which of course (being the bastards they are) are encrypted again. Without having the full copy, wont be possible to extract any sort of plaintext out of it.

Interestingly though, it's quite a massive IPL (roughly 240KB decrypted), and entry point is still 0x040F0000 just like the retail IPL's.

Should also point out that service center flashing (ie. via jigkick) may not necessarily be the same as factory flashing. They might be similar in methods, but does not necessarily mean that either of them can full restore idstorage. My guess is that it may be possible, if taken back to factory. Though I doubt they would waste money doing that. Most of the time it would be cheaper just to provide a refurbished model instead.

Also yes, key0x54 is just the setting for default XMB background colour. All default settings are stored in idstorage. This is so they can change them for different region models, eg. your default time/city/language etc. for the different models. You can play around with key0x54 by changing values and "Restoring Default Settings" to have a look. Utterly useless, but fun nonetheless (oh and thanks to cory for actually rebooting so many times to test the different values on his own psp :P).

But if we were to get the kirk id, there's a possibility of using it to reverse the IDStorage keys, right? Of course this would have to be per PSP, which would be annoying...

Interestingly though, it's quite a massive IPL (roughly 240KB decrypted), and entry point is still 0x040F0000 just like the retail IPL's.
Assume... nuff said (good theory and I'm willing to believe it but I don't see any way to test it beside contracting some ninja or something...) Having the last few blocks simply isn't enough to tell how big it was to begin with, perhaps they did it on purpose or made an SCE at the last second and this so called factory IPL starts 0x10 blocks farther in than it usually does. Index dependent and all; nothing says it has to start at the beginning of the available space. Maybe they even left it/did it to taunt, knowing before hand exactly how compromised their units are already :D

It does make a lot of sense though, the chips can come pre-flashed and QA'd with a standard firmware from factory - also somewhat explains the lag between current firmware and installed firmware on a new unit. I guess keep an eye out for an out of the box brick that can still run pandora though, you never know... a "factory stick" may be a part of that initial setup process.

(oh and thanks to cory for actually rebooting so many times to test the different values on his own psp :P)
Quite welcome. If I ever get the time I'd set up my own idstore to my liking, though I think I have reset the PSP I use a total of... 1 time, IIRC.

Interestingly though, it's quite a massive IPL (roughly 240KB decrypted), and entry point is still 0x040F0000 just like the retail IPL's.
Having the last few blocks simply isn't enough to tell how big it was to begin with, perhaps they did it on purpose or made an SCE at the last second and this so called factory IPL starts 0x10 blocks farther in than it usually does. Index dependent and all; nothing says it has to start at the beginning of the available space. Maybe they even left it/did it to taunt, knowing before hand exactly how compromised their units are already :D



Sure it does :D. In fact you really only need the final block of the IPL to determine the decrypted size, since it gives you the entry address and also the address and size of where the final block is to be loaded.

The last 6 decrypted IPL blocks of the Factory IPL.

loadaddr blocksize entry checksum
0x04125980 0xF50 0 0x729D1DC0
0x041268D0 0xF50 0 0x39C3A1D7
0x04127820 0xF50 0 0x572B030C
0x04128770 0xF50 0 0x7B8E52F8
0x041296C0 0xF50 0 0x0462AFB0
0x0412A610 0x210 0x040F0000 0x331B9575

So the whole decrypted Factory IPL is loaded from 0x040F0000 - 0x0412A820, which equals 0x3A820 Bytes (239,648 Bytes)

Entry code... pseudoasm
0x040F0000 mov reg0, #0
0x040F0004 j reg0
0x040F0008 add reg0, PC, 0x125980
Probably won't work, but you should get the idea. Since the data is not known... you just don't know. Though I still agree, mainly as I doubt they'd flash something at factory that contains NULL'd blocks unless it is to specifically test their idea of the biggest IPL block they may ever use on the unit as some form of demented QA.

I didn't ever think I'd have to explain all that too though, especially after some reading...
The mind games SCE play…
We are all familiar with the various tricks SCE use to fool devs :p
Anyhoo, back to keeping an open mind. Seems easier the less you know, though :( (for all I know, the original comment came up because someone got a hold of a factory IPL and is just teasing with useless tidbits)

My belief is that the factory kernel (I will call it that way) writes the kirk id into the syscon chip, the kirk id would be a One Time Programmable and Write only. Once the kirk id is set, the kernel stores it into ram and starts using kirk commands to generate the idstorage keys using the kirk id previously stored in ram. I expect the kirk id to be a random number. This means that even sony could not regenerate idstorage keys for the kirk id would be lost at power off. (and of course there would be no way of getting it but hardware probing) Also this means that even in the unlikely event that we ever get this factory kernel available to reverse (which means that it somehow would have been leaked) it would be of no use to us.

The syscon chip is powered with a internal cell battery, so the kirk id in the syscon chip is not lost. Is it possible to extract aka read that kirk id again? If that is the case than the regeneration of the ID Storage is still possible. I do agree that creating such code is not easy.

The KIRK ID is not lost even when the internal cell runs out; this has happened to my fat PSP, so the time is lost every time the battery is removed. So, it's probably one time programmable.

But that doesn't mean it can't be stored in one of the hardware registers just like the other hardware serial numbers.

jas0nuk, you catch my drift. :)

So again we come back to the necessity of investigating the KIRK commands :(

*wishes he wasn't rubbish at C*

Heh... after talking to l_oliveira again I discovered that key 7 is actually unique!

Here are a few examples:
44 61 50 41 01 00 00 00 08 00 00 00 5D 6A CE 3E 40 2B 40 CF 40 2C 00 CB (TA-086)
44 61 50 41 01 00 00 00 08 00 00 00 5B 74 BE 52 C0 33 C0 D5 40 38 40 B7 (TA-086)
44 61 50 41 01 00 00 00 14 00 00 00 50 ED CE 7F 40 31 80 CD C0 35 C0 D2 (TA-085 Slim) Ice Silver
44 61 50 41 01 00 00 00 14 00 00 00 D6 4D 78 6B C0 3A 40 CC 80 42 80 CA (TA-085 Slim) Ice Silver
44 61 50 41 01 00 00 00 14 00 00 00 62 D1 CD EB 80 2C 00 D1 00 31 00 CF (TA-085 Slim) Ice Silver
44 61 50 41 01 00 00 00 14 00 00 00 98 D5 7B 1F C0 35 00 C1 00 40 40 B7 (TA-085 Slim) Piano Black
44 61 50 41 01 00 00 00 14 00 00 00 C7 08 C4 F2 80 2E 00 CD 40 2E 00 D1 (TA-085 Slim) Piano Black
44 61 50 41 01 00 00 00 14 00 00 00 E2 ED 5B 98 C0 32 40 D1 40 30 00 C9 (TA-085 Slim)


So, byte 0x8 is 0x8 in the FAT and 0x14 in the SLIM, and the rest after 0xC looks pretty random. Looks like theres some pattern in there but can't work out what it represents.

:confused: The unique keys I found a few months back (pre-slim) via md5 checking amounts to these... I think I posted my hashes in a xls a while back too with the hashes from slims that were shared here too.
Per PSP keys (unique)
0x0005 not always unique
0x0006 not always unique
0x0010
0x0011
0x0013
0x0040
0x0044 mac id
0x0045 not always, per region?
0x0050 serial?
0x0100 chkreg
0x0101 psid
0x0102 umdman
0x0103
0x0104
0x0105
0x0106
0x0120 chkreg
0x0121 psid
0x0122
0x0123
0x0124
0x0125
0x0126
0x0140
Newer PSP's only (82/86)
0x0007
0x0008
0x0047
0x0051
Not always present but different in most instances
0x000F

My Piano Black PSP-2002 key 0x0007:
44 61 50 41 01 00 00 00 14 00 00 00 98 D5 7B 1F C0 35 00 C1 00 40 40 B7

@Jas0n: 0x10 in key 7 is C0 on my Slim too. Any idea what colour/make the other Slims on there were?

My 0x11, and all the other 0x11s up there are also very close together, so I don't think some, if not most of the key is random.

I have seen slim's with a empty key 0x7. So something else can use that key, but is not needed by the firmware.

Also GhostMan (http://forums.maxconsole.net/showpost.php?p=827591&postcount=10) posted this on maxconsole:

Hope this helps some of you guys with corrupted key41 on your Phat PSP's and having problems installing CFW 3.80M33. Just fixed my key41 doing this and CFW 3.80M33 installed normaly and running fine.

Use IdStorageManager and insert the following code manually on your key41.
Save and backup your keys.

0x000->4C05 = [idVendor]
0x004->0A = [bLength]
0x005->03
0x006->53006F006E007900 = S.o.n.y. [iManufacturerString]
0x044->05 = [? bNum]
0x048->C801 = [idProduct]
0x04C->16 = [bLength]
0x04D->03 = [? bDescriptorType]
0x04E->5000530050002000 = P.S.P. .
0x056->540079007000650020004100 = T.y.p.e. .A. [iProductString]
0x08C->C901 = [idProduct]
0x090->16 = [bLength]
0x091->03
0x092->5000530050002000 = P.S.P. .
0x09A->540079007000650020004200 = T.y.p.e. .B.
0x0D0->CA01 = [idProduct]
0x0D4->16 = [bLength]
0x0D5->03
0x0D6->5000530050002000 = P.S.P. .
0x0DE->540079007000650020004300 = T.y.p.e. .C.
0x114->CB01 = [idProduct]
0x118->16 = [bLength]
0x119->03
0x11A->5000530050002000 = P.S.P. .
0x122->540079007000650020004400 = T.y.p.e. .D.
0x158->CC01 = [idProduct]
0x15C->16 = [bLength]
0x15D->03
0x15E->5000530050002000 = P.S.P. .
0x166->540079007000650020004500 = T.y.p.e. .E.

This fixes USBHostFS problems and CFW installation problems.

So it could be that key 0x0007 is generated sometime during use.

If someone could look at key 0x0007 of a TA-08X which hasn't been touched (apart from bring Pandora'ized), then do some trialing to see what triggers the key to be generated, if at all, perhaps?

Thanks brin_vg, I've added the case colours that I could get hold of to the list, along with your key and one from another Slim :)

cory1492, that list isn't entirely accurate. I've just checked a few that I didn't think looked right and came to conclusion that key 4 and key 6 are always the same in Fat TA-079~TA-086, slightly different in the Slim and they added more stuff, but still the same in all Slims.
However I didn't realise that key 12 was actually the same in ALL PSPs, so thanks :)

edit: Key 4-8 mystery solved :p The data only starts at 0x10, the stuff earlier is a hash, so whenever the data is changed the hash is updated. In the Slim, they only just started using the data rather than leaving it blank, so the datalength and hashes changed. Added key 4-8 struct to first post, thanks for the explanation SilverSpring.

Does key 07 have to be there? what problems occur if it isn't found, because it's not in any of the pre 86 models.

The TA-086's I have hashes for shows the same key 6 as slim (MD5:d257d6b3b48257605843a44254f449d7), though I don't have a TA-082 hash list to compare to at all the 079/081 seem to all have the same key in 6 (MD5:c162792f2cef016aacbe5b91e1b436ad). Might be only minor differences in the actual data, but...

Also, keep in mind that list was one I had not updated since just before slim went into the wild.

edit:/ updated the list in the previous post to show the qualifiers I had put on the spreadsheet as well ;)

also, whats the deal with the "non-indexed duplicates", I presume I should look at restoring these non-indexed dupes and validating their existence at orig+0x8000 when touching idstore?

Are the duplicates even used? As in, checking main key vs duplicate?

The TA-086's I have hashes for shows the same key 6 as slim (MD5:d257d6b3b48257605843a44254f449d7), though I don't have a TA-082 hash list to compare to at all the 079/081 seem to all have the same key in 6 (MD5:c162792f2cef016aacbe5b91e1b436ad). Might be only minor differences in the actual data, but...

Also, keep in mind that list was one I had not updated since just before slim went into the wild.

edit:/ updated the list in the previous post to show the qualifiers I had put on the spreadsheet as well ;)

also, whats the deal with the "non-indexed duplicates", I presume I should look at restoring these non-indexed dupes and validating their existence at orig+0x8000 when touching idstore?

Are the duplicates even used? As in, checking main key vs duplicate?

That information was given to me by l_oliveira, apparently those keys have duplicates at their original location + 0x8000, separately from 0x120-0x126 which are read at the same time as 0x100-0x106 respectively, in case there's a random error on the 0x100X ones - just shows how valuable those keys are.

But no the keys are never used to compare against their original, it's just a backup thing.

Also, cory, I have a bunch of key dumps where 0x006 was just a copy of 0x005 and all sorts of other messed up combinations, a la original TA-082 downgrader and Noobz TA-082 downgrader. This may have affected your results.

Does key 07 have to be there? what problems occur if it isn't found, because it's not in any of the pre 86 models.

Looks like it isnt being used at the moment, and whatever it's doing doesn't apply to older hardware.

But no the keys are never used to compare against their original, it's just a backup thing.

Seems a bit of a useless backup, since if the main keys go, odds are so have the backups :D I'm assuming Pandora and or NandTool replace those backup keys as well as the main set?

It would've made much more sense (and would be rather useful) to create a backup set in flash3/4/5 in the factory.

^-- Woot, random thought, perhaps they do? Maybe they can't regenerate IDStorage, but can retrieve it from a full backup set of the original generation when refurbing PSPs?

I have been experimenting with idstorage keys and here's what I came up with.

I have a phat psp-1001 and a slim PSP-2001.
My phat was working fine except it had a corrupt key41 wich I fixed manually.

My slim has idstorage all f****d up.

Running IDStorage Manager my slim showed that my motherboard could not be recognized and that psp was an unknown PSP-100?

I dumped my phat keys and using IDStorage Manager wrote the phat keys into the slim

Now my motherboard still can't be recognized but the model now shows as beeing an American PSP-1001.

Conclusion, I think that it may be possible to fix the slim with some other slim keys using IDStorage Manager. I'm going to dump a fully working slim keys from a friend and work on those keys. Maybe I'll find something important.
I'll post back.

It is possible to restore a slim that has had it's keys lost to a state where most functions under custom firmware will work, but the stuff that relies on unique/per-psp keys (ie: UMD reading) is not going to work. Because of the way idstore is crypted on slims, those who have lost their idstore entirely (sometimes by overwriting with another slims's nand dump, sometimes by using idstore manager from pandora - which will try to put the keys in unencrypted) it becomes nearly impossible to run homebrew on the slim even from cfw. I added a method to reinstate idstore even on slim to nandTool when it's loaded from des.cem V3 base which will crypt the keys back in those cases and the above was the results of my pre-release testing.
-------

If anyone is interested in looking at the raw dumped contents of the decrypted NAND area of slim's idstore, see attachment for the dumper. It only dumps the 16 blocks relevant to idstore, it interleaves the spare data after each page, and I have only ever run it from an elf menu under des cem V3 - though it would probably work under custom firmware if the appropriate nids are mapped out. A most notable oddity is that blocks/pages that are normally 0xFF on a fat seem to be something else entirely when decrypted on a slim and are not 0xFF in a raw NAND dump. Also, before anyone asks it's not necessary to decrypt idstore on non-slim models (you can extract keys from a fat using various scripts and tools out there already.)

cory1492, thanks for the src and the working version of the IDS decrypter :P :)

Seems a bit of a useless backup, since if the main keys go, odds are so have the backups :D I'm assuming Pandora and or NandTool replace those backup keys as well as the main set?

It would've made much more sense (and would be rather useful) to create a backup set in flash3/4/5 in the factory.

^-- Woot, random thought, perhaps they do? Maybe they can't regenerate IDStorage, but can retrieve it from a full backup set of the original generation when refurbing PSPs?Yes, flashing a NAND dump would totally destroy that backup even if it was hidden, but they don't expect the user to have NAND access :P
However, I don't believe there is any other place that the IDS is stored, unless syscon has a storage area...?

I have been experimenting with idstorage keys and here's what I came up with.

I have a phat psp-1001 and a slim PSP-2001.
My phat was working fine except it had a corrupt key41 wich I fixed manually.

My slim has idstorage all f****d up.

Running IDStorage Manager my slim showed that my motherboard could not be recognized and that psp was an unknown PSP-100?

I dumped my phat keys and using IDStorage Manager wrote the phat keys into the slim

Now my motherboard still can't be recognized but the model now shows as beeing an American PSP-1001.

Conclusion, I think that it may be possible to fix the slim with some other slim keys using IDStorage Manager. I'm going to dump a fully working slim keys from a friend and work on those keys. Maybe I'll find something important.
I'll post back.
It's shows up as an American PSP-1001 because that's what your Phat is. IDSM/KeyCleaner reads the key, and if one byte is (can't remember, lol) it decide it's a PSP-1001. This has always been the case.

On the subject of backup keys, as we're not meant to have NAND access in the first place, the backups seem odd. Were they planning on modifying the keys at some point?

cory1492, thanks for the src and the working version of the IDS decrypter :P :)

Seems a bit of a useless backup, since if the main keys go, odds are so have the backups :D I'm assuming Pandora and or NandTool replace those backup keys as well as the main set?

It would've made much more sense (and would be rather useful) to create a backup set in flash3/4/5 in the factory.

^-- Woot, random thought, perhaps they do? Maybe they can't regenerate IDStorage, but can retrieve it from a full backup set of the original generation when refurbing PSPs?Yes, flashing a NAND dump would totally destroy that backup even if it was hidden, but they don't expect the user to have NAND access :P
However, I don't believe there is any other place that the IDS is stored, unless syscon has a storage area...?

jas0nuk, maybe at a very secure server within the Sony network?
I have been wondering about that, because libdnas_core.prx has url pspdnas-ld02.rd.scei.sony.co.jp hardcoded. I tried to resolve that in DNS, but I did not find it. It could be a internal address.

Oh, btw, what should be in the directory ms0:/PSP/LICENSE?

Yes, flashing a NAND dump would totally destroy that backup even if it was hidden, but they don't expect the user to have NAND access :P
Just to clarify, I meant flashing someone else's NAND dump. Obviously flashing your own PSPs NAND dump wouldn't matter xD

I dunno what the LICENSE folder is, probably something to do with POPS or PSN downloadables.

Oh and I doubt Sony would store something as important as that on a server, though you never know :p

I have been experimenting with idstorage keys and here's what I came up with.

I have a phat psp-1001 and a slim PSP-2001.
My phat was working fine except it had a corrupt key41 wich I fixed manually.

My slim has idstorage all f****d up.

Running IDStorage Manager my slim showed that my motherboard could not be recognized and that psp was an unknown PSP-100?

I dumped my phat keys and using IDStorage Manager wrote the phat keys into the slim

Now my motherboard still can't be recognized but the model now shows as beeing an American PSP-1001.

Conclusion, I think that it may be possible to fix the slim with some other slim keys using IDStorage Manager. I'm going to dump a fully working slim keys from a friend and work on those keys. Maybe I'll find something important.
I'll post back.
It's shows up as an American PSP-1001 because that's what your Phat is. IDSM/KeyCleaner reads the key, and if one byte is (can't remember, lol) it decide it's a PSP-1001. This has always been the case.

On the subject of backup keys, as we're not meant to have NAND access in the first place, the backups seem odd. Were they planning on modifying the keys at some point?

I did dump my friends slim idstorage keys and wrote them to my f****d slim.

Now running idstoragemanager it show my motherboard as being a TA-085 and my region as an American PSP-2001.

Flashed CFW 3.71 M33-2 with pandora and voilá, almost fully working PSP (UMD didn't work) but played ISO's and homebrew.

Tried to flash 3.80 m33 UPDATE and it formated my flash2 and bricked it again.

Back to square1 so, opened nandtool v0.3beta1 and wrote nand full image, then wrote my friends keys again, flashed 3.71M33-2 and formated flash1
got the BSOD removed battery. Plugged battery back and started PSP and it's working again (except UMD).

So I guess that it's possible to write idstorage keys from one slim to another. The only thing missing is UMD functions.

The non-indexed duplicates are just from a backup nand block.

Im sure Ive posted about this before on the forums somewhere a while ago, but anyway, here's my idstorage index (I think from my original 1.00 JP, dont remember):

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000000 20 01 21 01 22 01 23 01 24 01 25 01 26 01 27 01 .!.".#.$.%.&.'.
00000010 28 01 29 01 2A 01 2B 01 2C 01 2D 01 2E 01 2F 01 (.).*.+.,.-.../.
00000020 30 01 31 01 32 01 33 01 34 01 35 01 36 01 37 01 0.1.2.3.4.5.6.7.
00000030 38 01 39 01 3A 01 3B 01 3C 01 3D 01 3E 01 3F 01 8.9.:.;.<.=.>.?.

00000040 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17 00 ................
00000050 18 00 19 00 1A 00 1B 00 1C 00 1D 00 1E 00 1F 00 ................
00000060 20 00 21 00 22 00 23 00 24 00 25 00 26 00 27 00 .!.".#.$.%.&.'.
00000070 28 00 29 00 2A 00 2B 00 2C 00 2D 00 2E 00 2F 00 (.).*.+.,.-.../.

00000080 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000090 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000000A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000000B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

000000C0 0F 00 50 00 45 00 46 00 04 00 05 00 06 00 41 00 ..P.E.F.......A.
000000D0 42 00 43 00 40 01 44 00 40 00 30 00 31 00 32 00 B.C.@.D.@.0.1.2.
000000E0 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
000000F0 3B 00 3C 00 3D 00 3E 00 3F 00 FF FF FF FF FF FF ;.<.=.>.?.ÿÿÿÿÿÿ

00000100 00 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 ................
00000110 08 01 09 01 0A 01 0B 01 0C 01 0D 01 0E 01 0F 01 ................
00000120 10 01 11 01 12 01 13 01 14 01 15 01 16 01 17 01 ................
00000130 18 01 19 01 1A 01 1B 01 1C 01 1D 01 1E 01 1F 01 ................

00000140 F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF õÿõÿõÿõÿõÿõÿõÿõÿ
00000150 F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF õÿõÿõÿõÿõÿõÿõÿõÿ
00000160 F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF õÿõÿõÿõÿõÿõÿõÿõÿ
00000170 F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF F5 FF õÿõÿõÿõÿõÿõÿõÿõÿ

each one of those 'blocks' maps to exactly one Nand Block. As you see the third block is not indexed at all, but the actual contents of that nandblock is just backup of the fourth block. It's a bit unusual yes, but that's sce.

Yes the LICENSE folder is for psn certificates, they've removed it now but along with the 'Certificate Utility' icon in XMB.

Also I seriously doubt sce would store copies of the idstorage on a server anywhere, a single factory produces over 30,000 psp's per day. Im sure they wouldnt store copies of each ones idstorage.

SilverSpring, maybe so, but I wonder why that url is hard coded. Could also be a test that Sony does on random select new PSP's.

Btw, how do you find those function names? Is that done with prxtool? I looked with IDA, but no such luck for me yet. If I know how, I could help you with the PSP prx library. :)

@Ghostman: It now shows as TA-085 PSP-2001 because that data was in the keys of the Slim you took the dump from. It hasn't regenerated your key, they just happen to be the same (as with many keys that are now restored on it). UMD functions don't work because the keys for UMD decryption are PSP specific, you have another PSPs keys, so they won't decrypt on your's.

SilverSpring, maybe so, but I wonder why that url is hard coded. Could also be a test that Sony does on random select new PSP's.

Btw, how do you find those function names? Is that done with prxtool? I looked with IDA, but no such luck for me yet. If I know how, I could help you with the PSP prx library. :)
Er, NIDs?

That's just DNAS.

DNAS on psp is just like DNAS on ps2, a way to remotely verify and authenticate the user. It's used whenever the psp needs to be authenticated online, for example when enabling WMA or Flash in settings, or updating the time online in settings. Or for infrastructure mode games.

The encryption for it is relatively complex (multiple sigcheck cmds encrypted with the hw prng used as a nonce to make sure all transmissions are never encrypted the same twice). But it does check key0x100 for authentication of the psp (sceMcctrl is the lib responsible for the encryption).

And some new DNAS nids that havent been added onto the prxdocs site yet for anyone that's interested:
0x45c1aaf5 sceDNASGetEventFlag
0x2370130e sceDNASCoreCheckProxyResponse
0xda5939b4 sceDNASCoreGetProxyRequest
0xc54657b7 sceDNASCoreSetProxyResponse
0x26e1e2bd sceDNASCoreSetChallenge
0xb6c76a14 sceDNASCoreCheckChallenge

EDIT:
About the nids, we've been thinking of setting up a LAN.st project for people to help out. Currently, there are around roughly 3-4 people in the entire world (that I know of :p) that are actively searching for new nids. Basically how it'll work, app's will be posted up (bruteforce crackers essentially), and users download them and run them on the PC (for however long they are willing to). Details will come soon...(I hope :p). And if there's enough interest, it might be expanded. Perhaps a distributed cracker even.

@brin_vg

NID's indeed, in C/C++ they are called functions (if I remember it correctly).

@SilverSpring

Thank you for the explanation about DNAS. Could you also enlighten me on that question I asked?

@brin_vg

NID's indeed, in C/C++ they are called functions (if I remember it correctly).



Er, no. The function 'name' refers to the function's NID.

And SilverSpring, I'm sure there are plenty of people (myself included) who are more than willing to help out :)

I thought that the function was named as the NID is. Well, it is nice to know that it isn't so.

NID is a section of the checksum of the name... that's how NID cracking works. Bruteforcing names until the checksum matches the NID.

I thought that the function was named as the NID is. Well, it is nice to know that it isn't so.
I think you mean in this sort of case:
NID - Function Name
0x4C268535 - sceSemawm_4C268535

I'm meaning more like:
NID - Function Name
0x586DB82C - sceUsbActivate

That's why (before the 3.80 NID resolver) programs compiled with an old NID map wouldn't work on newer firmwares, as the function names were the same, but the NIDs were different to how the program was compiled.

NID is a section of the checksum of the name... that's how NID cracking works. Bruteforcing names until the checksum matches the NID.

Oke, I got that. Is it A SHA or MD5 checksum or is there a tutorial on how I do that? Because I would love to help out on this.

Well just casually speaking, I usually use "nid" interchangeably to mean either the 32bit hash or the function name that belongs to that hash.

Technically though, an "nid" is a Name Identifier (SCE's terminology). That is, a value that is used to identify a name. It is a 32bit hex value that is taken from the first 32bits of the SHA1 hash of a name (in little endian format).

Example: for the name "HelloWorld",

the SHA1 hash is:
db 8a c1 c2 59 eb 89 d4 a1 31 b2 53 ba cf ca 5f 31 9d 54 f2

the first 32bits is:
db 8a c1 c2

and in little endian, makes:
0xc2c18adb

So 0xc2c18adb is then the Name Identifier for the name "HelloWorld".

SCE uses these nids to identify the imports/exports of a module. We do not know the original names of these functions. However, since we know the hash of the name of the function (the nids) we can run a dictionary brute force attack on the nids to crack the original names.

Though there's a bit more skill to actually crack them. Firstly, you need to correctly guess the prefix; secondly, you need to be able to differentiate real hits from false positives (since the nid is only using 32bits of the hash, you will get a LOT of false positives); and thirdly, you need to be able to carefully choose a good dictionary (again because of false positives). It also helps to target individual functions, knowing what the function does helps in guessing its name and hence building a good dictionary for it.

EDIT:
From 3.70+ SCE started randomising the nids (well actually not strictly true, they also did so for a few select functions in previous firmwares, typically the ones they were trying to protect like some of the crypto ones as well as dve+hibari once they were cracked and the slim hadnt been publically announced yet). The nid is no longer the SHA1 hash of the original function name, now the nid is a just a random 32bit value assigned to the function. They were randomised again in 3.80 too (and probably will be again in the next firmware update). So these new nids cant be cracked anymore, new functions and new libs will remain unknown (probably forever :(). It also makes it that little bit much harder to disassemble modules.

SilverSpring, when I decompile with IDA, I see words like SceUtilityModule. SceUtilityAppletWorktime, SceUtilityAppletPartition, SceUtilityAppletInit and SceUtilityAppletShutdown in 3.80 Utility.prx. I do not see them in the published library. I do not know if you have found them too.

I could try to decompile some more prx-files.

EDIT:
About the nids, we've been thinking of setting up a LAN.st project for people to help out. Currently, there are around roughly 3-4 people in the entire world (that I know of :p) that are actively searching for new nids. Basically how it'll work, app's will be posted up (bruteforce crackers essentially), and users download them and run them on the PC (for however long they are willing to). Details will come soon...(I hope :p). And if there's enough interest, it might be expanded. Perhaps a distributed cracker even.

Very willing to take part. I have always wanted to... :)

The 3.80 fatmsmod.prx has the words SceFatfsCPTable, SceFatfsMs, SceFatfs, SceFatfsMsins, SceFatfsMsFatCache, SceFatfsMsDirentCache, SceFatfsMsDataBuf, SceFatmsMedia and SceFatfsDetectMedium in the file. I hope that this helps to resolve some more NIDS.

Btw, maybe we should create a separate thread about the NIDS as this isn't something about the ID Storage.

Jachra, those names are not the function names but just enum names or lib names or something like that. Sony don't leave any function names in plaintext any more.

On another note, here is an IdStorage checksum list from a new type Slim PSP (baryon number 0x00234000) which cannot write the battery serial number (fails with a Syscon error code, evidently they changed the Syscon firmware to make it error out when the battery NVM is tried to be written to)

0x0004.bin 53a94e603e899b5532e58b3132121b80
0x0005.bin 3e28ab59c7fa7deacf58020f5718f968
0x0006.bin d257d6b3b48257605843a44254f449d7
0x0007.bin dc500142a1275a365822c2aac0db6aeb
0x0008.bin c0673dbc7ea4d5a0462dcc9f29c3c016

0x000F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0010.bin 16aa17677cf0e51d8bc825afff67e185
0x0011.bin ce2106c38e79ee34181c4e6bc6fea693
0x0012.bin 651b907c7c46668a88069c51c632bec5
0x0013.bin 1936af401baca1e58e3c95a39a6ec5c4

0x0014.bin bf619eac0cdf3f68d496ea9344137e8b
0x0015.bin bf619eac0cdf3f68d496ea9344137e8b
0x0016.bin bf619eac0cdf3f68d496ea9344137e8b
0x0017.bin bf619eac0cdf3f68d496ea9344137e8b
0x0018.bin bf619eac0cdf3f68d496ea9344137e8b
0x0019.bin bf619eac0cdf3f68d496ea9344137e8b
0x001A.bin bf619eac0cdf3f68d496ea9344137e8b
0x001B.bin bf619eac0cdf3f68d496ea9344137e8b
0x001C.bin bf619eac0cdf3f68d496ea9344137e8b
0x001D.bin bf619eac0cdf3f68d496ea9344137e8b
0x001E.bin bf619eac0cdf3f68d496ea9344137e8b
0x001F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0020.bin bf619eac0cdf3f68d496ea9344137e8b
0x0021.bin bf619eac0cdf3f68d496ea9344137e8b
0x0022.bin bf619eac0cdf3f68d496ea9344137e8b
0x0023.bin bf619eac0cdf3f68d496ea9344137e8b
0x0024.bin bf619eac0cdf3f68d496ea9344137e8b
0x0025.bin bf619eac0cdf3f68d496ea9344137e8b
0x0026.bin bf619eac0cdf3f68d496ea9344137e8b
0x0027.bin bf619eac0cdf3f68d496ea9344137e8b
0x0028.bin bf619eac0cdf3f68d496ea9344137e8b
0x0029.bin bf619eac0cdf3f68d496ea9344137e8b
0x002A.bin bf619eac0cdf3f68d496ea9344137e8b
0x002B.bin bf619eac0cdf3f68d496ea9344137e8b
0x002C.bin bf619eac0cdf3f68d496ea9344137e8b
0x002D.bin bf619eac0cdf3f68d496ea9344137e8b
0x002E.bin bf619eac0cdf3f68d496ea9344137e8b
0x002F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0030.bin bf619eac0cdf3f68d496ea9344137e8b
0x0031.bin bf619eac0cdf3f68d496ea9344137e8b
0x0032.bin bf619eac0cdf3f68d496ea9344137e8b
0x0033.bin bf619eac0cdf3f68d496ea9344137e8b
0x0034.bin bf619eac0cdf3f68d496ea9344137e8b
0x0035.bin bf619eac0cdf3f68d496ea9344137e8b
0x0036.bin bf619eac0cdf3f68d496ea9344137e8b
0x0037.bin bf619eac0cdf3f68d496ea9344137e8b
0x0038.bin bf619eac0cdf3f68d496ea9344137e8b
0x0039.bin bf619eac0cdf3f68d496ea9344137e8b
0x003A.bin bf619eac0cdf3f68d496ea9344137e8b
0x003B.bin bf619eac0cdf3f68d496ea9344137e8b
0x003C.bin bf619eac0cdf3f68d496ea9344137e8b
0x003D.bin bf619eac0cdf3f68d496ea9344137e8b
0x003E.bin bf619eac0cdf3f68d496ea9344137e8b
0x003F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0040.bin b36005f9eb6cd328f81329d8c70fbe57
0x0041.bin fe405748cf64d3a22dc22aef56a02c2c

0x0042.bin bf619eac0cdf3f68d496ea9344137e8b

0x0043.bin 050acd6caf4cec9d64f3308a2aefcaa8
0x0044.bin fddc8084a61ae2728a59026582fbdc4f
0x0045.bin e8d17760026c327a2d93fe18a4a50b45

0x0046.bin bf619eac0cdf3f68d496ea9344137e8b

0x0047.bin 6e41a2b4e99b8fc5ea2fe19a8137fe95
0x0050.bin 91222d6f3367e738b0a37ca04956fbaa
0x0051.bin b1913186b5906347f724231b303a4785
0x0052.bin 1f556d20e91e6200d0fceec8fa93275d

0x0053.bin bf619eac0cdf3f68d496ea9344137e8b

0x0054.bin d340f23a7d18057bb02252a3cb40b877

0x0100.bin 9111b8dcb44848fd59be3b4832986289
0x0101.bin f7fb3d8bf6b42ac96391e3cbc0c3f1cb
0x0102.bin c86937485556b83a3be6b388011a0848
0x0103.bin f8cdf12b42d7cac4a39af868ff43a910
0x0104.bin 8ecabd5f5c4a8c86f2934158254d8aea
0x0105.bin 6b6b643df69ed691d6463cbc3a45852d
0x0106.bin 0ed2806dd2652f5a1f929667927abc11

0x0107.bin bf619eac0cdf3f68d496ea9344137e8b
0x0108.bin bf619eac0cdf3f68d496ea9344137e8b
0x0109.bin bf619eac0cdf3f68d496ea9344137e8b
0x010A.bin bf619eac0cdf3f68d496ea9344137e8b
0x010B.bin bf619eac0cdf3f68d496ea9344137e8b
0x010C.bin bf619eac0cdf3f68d496ea9344137e8b
0x010D.bin bf619eac0cdf3f68d496ea9344137e8b
0x010E.bin bf619eac0cdf3f68d496ea9344137e8b
0x010F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0110.bin bf619eac0cdf3f68d496ea9344137e8b
0x0111.bin bf619eac0cdf3f68d496ea9344137e8b
0x0112.bin bf619eac0cdf3f68d496ea9344137e8b
0x0113.bin bf619eac0cdf3f68d496ea9344137e8b
0x0114.bin bf619eac0cdf3f68d496ea9344137e8b
0x0115.bin bf619eac0cdf3f68d496ea9344137e8b
0x0116.bin bf619eac0cdf3f68d496ea9344137e8b
0x0117.bin bf619eac0cdf3f68d496ea9344137e8b
0x0118.bin bf619eac0cdf3f68d496ea9344137e8b
0x0119.bin bf619eac0cdf3f68d496ea9344137e8b
0x011A.bin bf619eac0cdf3f68d496ea9344137e8b
0x011B.bin bf619eac0cdf3f68d496ea9344137e8b
0x011C.bin bf619eac0cdf3f68d496ea9344137e8b
0x011D.bin bf619eac0cdf3f68d496ea9344137e8b
0x011E.bin bf619eac0cdf3f68d496ea9344137e8b
0x011F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0120.bin 9111b8dcb44848fd59be3b4832986289
0x0121.bin f7fb3d8bf6b42ac96391e3cbc0c3f1cb
0x0122.bin c86937485556b83a3be6b388011a0848
0x0123.bin f8cdf12b42d7cac4a39af868ff43a910
0x0124.bin 8ecabd5f5c4a8c86f2934158254d8aea
0x0125.bin 6b6b643df69ed691d6463cbc3a45852d
0x0126.bin 0ed2806dd2652f5a1f929667927abc11

0x0127.bin bf619eac0cdf3f68d496ea9344137e8b
0x0128.bin bf619eac0cdf3f68d496ea9344137e8b
0x0129.bin bf619eac0cdf3f68d496ea9344137e8b
0x012A.bin bf619eac0cdf3f68d496ea9344137e8b
0x012B.bin bf619eac0cdf3f68d496ea9344137e8b
0x012C.bin bf619eac0cdf3f68d496ea9344137e8b
0x012D.bin bf619eac0cdf3f68d496ea9344137e8b
0x012E.bin bf619eac0cdf3f68d496ea9344137e8b
0x012F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0130.bin bf619eac0cdf3f68d496ea9344137e8b
0x0131.bin bf619eac0cdf3f68d496ea9344137e8b
0x0132.bin bf619eac0cdf3f68d496ea9344137e8b
0x0133.bin bf619eac0cdf3f68d496ea9344137e8b
0x0134.bin bf619eac0cdf3f68d496ea9344137e8b
0x0135.bin bf619eac0cdf3f68d496ea9344137e8b
0x0136.bin bf619eac0cdf3f68d496ea9344137e8b
0x0137.bin bf619eac0cdf3f68d496ea9344137e8b
0x0138.bin bf619eac0cdf3f68d496ea9344137e8b
0x0139.bin bf619eac0cdf3f68d496ea9344137e8b
0x013A.bin bf619eac0cdf3f68d496ea9344137e8b
0x013B.bin bf619eac0cdf3f68d496ea9344137e8b
0x013C.bin bf619eac0cdf3f68d496ea9344137e8b
0x013D.bin bf619eac0cdf3f68d496ea9344137e8b
0x013E.bin bf619eac0cdf3f68d496ea9344137e8b
0x013F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0140.bin 5606e6bdab4a51a95806031d1415a23c

bf619eac0cdf3f68d496ea9344137e8b refers to an empty key.

The only static key they changed was key 8. A single byte was changed, this affected the checksum of the data section (see the struct in the first post). Nothing else important changed.

edit: Did a tidyup to the first post again.

Jachra: if you find these strings in the plaintext, theres a 99% chance they are not nids.

A little hint: sce NEVER use uppercase for the first letter in function names. They will use uppercase first letter for things like typedefs, enums, resource names, etc. But never for function names.

Those strings you found are (usually) names assigned to semaphores, event flags, memory pools, callbacks, pretty much any type of resource since you have to specify a name when creating them.

In the past, if you were lucky (especially in early firmwares like 1.00 or 1.50), you might have debug build modules that had asserts/kprintfs left in which exposed the function name in plaintext. But sce has learnt a long time ago to stop doing that. And even then, you were lucky to get only a handful of nids for free.

EDIT:
Also, it would be pretty sloppy of me (and others that were helping out) to have missed nids in plaintext. For a new module, the strings inside are usually the first to be checked (to see if sce are stupid enough to leave them in). Though, there is a very slim chance that you'll find a new nid in some modules, if I (and others) had missed it previously (especially in modules that we do not care much for and hence have not had a proper look at).

SilverSpring, I got that. So they are like global declared variables, structures, etc.
What tools do I need, to find those nids?

Jachra, those names are not the function names but just enum names or lib names or something like that. Sony don't leave any function names in plaintext any more.

On another note, here is an IdStorage checksum list from a new type Slim PSP (baryon number 0x00234000) which cannot write the battery serial number (fails with a Syscon error code, evidently they changed the Syscon firmware to make it error out when the battery NVM is tried to be written to)

0x0004.bin 53a94e603e899b5532e58b3132121b80
0x0005.bin 3e28ab59c7fa7deacf58020f5718f968
0x0006.bin d257d6b3b48257605843a44254f449d7
0x0007.bin dc500142a1275a365822c2aac0db6aeb
0x0008.bin c0673dbc7ea4d5a0462dcc9f29c3c016

0x000F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0010.bin 16aa17677cf0e51d8bc825afff67e185
0x0011.bin ce2106c38e79ee34181c4e6bc6fea693
0x0012.bin 651b907c7c46668a88069c51c632bec5
0x0013.bin 1936af401baca1e58e3c95a39a6ec5c4

0x0014.bin bf619eac0cdf3f68d496ea9344137e8b
0x0015.bin bf619eac0cdf3f68d496ea9344137e8b
0x0016.bin bf619eac0cdf3f68d496ea9344137e8b
0x0017.bin bf619eac0cdf3f68d496ea9344137e8b
0x0018.bin bf619eac0cdf3f68d496ea9344137e8b
0x0019.bin bf619eac0cdf3f68d496ea9344137e8b
0x001A.bin bf619eac0cdf3f68d496ea9344137e8b
0x001B.bin bf619eac0cdf3f68d496ea9344137e8b
0x001C.bin bf619eac0cdf3f68d496ea9344137e8b
0x001D.bin bf619eac0cdf3f68d496ea9344137e8b
0x001E.bin bf619eac0cdf3f68d496ea9344137e8b
0x001F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0020.bin bf619eac0cdf3f68d496ea9344137e8b
0x0021.bin bf619eac0cdf3f68d496ea9344137e8b
0x0022.bin bf619eac0cdf3f68d496ea9344137e8b
0x0023.bin bf619eac0cdf3f68d496ea9344137e8b
0x0024.bin bf619eac0cdf3f68d496ea9344137e8b
0x0025.bin bf619eac0cdf3f68d496ea9344137e8b
0x0026.bin bf619eac0cdf3f68d496ea9344137e8b
0x0027.bin bf619eac0cdf3f68d496ea9344137e8b
0x0028.bin bf619eac0cdf3f68d496ea9344137e8b
0x0029.bin bf619eac0cdf3f68d496ea9344137e8b
0x002A.bin bf619eac0cdf3f68d496ea9344137e8b
0x002B.bin bf619eac0cdf3f68d496ea9344137e8b
0x002C.bin bf619eac0cdf3f68d496ea9344137e8b
0x002D.bin bf619eac0cdf3f68d496ea9344137e8b
0x002E.bin bf619eac0cdf3f68d496ea9344137e8b
0x002F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0030.bin bf619eac0cdf3f68d496ea9344137e8b
0x0031.bin bf619eac0cdf3f68d496ea9344137e8b
0x0032.bin bf619eac0cdf3f68d496ea9344137e8b
0x0033.bin bf619eac0cdf3f68d496ea9344137e8b
0x0034.bin bf619eac0cdf3f68d496ea9344137e8b
0x0035.bin bf619eac0cdf3f68d496ea9344137e8b
0x0036.bin bf619eac0cdf3f68d496ea9344137e8b
0x0037.bin bf619eac0cdf3f68d496ea9344137e8b
0x0038.bin bf619eac0cdf3f68d496ea9344137e8b
0x0039.bin bf619eac0cdf3f68d496ea9344137e8b
0x003A.bin bf619eac0cdf3f68d496ea9344137e8b
0x003B.bin bf619eac0cdf3f68d496ea9344137e8b
0x003C.bin bf619eac0cdf3f68d496ea9344137e8b
0x003D.bin bf619eac0cdf3f68d496ea9344137e8b
0x003E.bin bf619eac0cdf3f68d496ea9344137e8b
0x003F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0040.bin b36005f9eb6cd328f81329d8c70fbe57
0x0041.bin fe405748cf64d3a22dc22aef56a02c2c

0x0042.bin bf619eac0cdf3f68d496ea9344137e8b

0x0043.bin 050acd6caf4cec9d64f3308a2aefcaa8
0x0044.bin fddc8084a61ae2728a59026582fbdc4f
0x0045.bin e8d17760026c327a2d93fe18a4a50b45

0x0046.bin bf619eac0cdf3f68d496ea9344137e8b

0x0047.bin 6e41a2b4e99b8fc5ea2fe19a8137fe95
0x0050.bin 91222d6f3367e738b0a37ca04956fbaa
0x0051.bin b1913186b5906347f724231b303a4785
0x0052.bin 1f556d20e91e6200d0fceec8fa93275d

0x0053.bin bf619eac0cdf3f68d496ea9344137e8b

0x0054.bin d340f23a7d18057bb02252a3cb40b877

0x0100.bin 9111b8dcb44848fd59be3b4832986289
0x0101.bin f7fb3d8bf6b42ac96391e3cbc0c3f1cb
0x0102.bin c86937485556b83a3be6b388011a0848
0x0103.bin f8cdf12b42d7cac4a39af868ff43a910
0x0104.bin 8ecabd5f5c4a8c86f2934158254d8aea
0x0105.bin 6b6b643df69ed691d6463cbc3a45852d
0x0106.bin 0ed2806dd2652f5a1f929667927abc11

0x0107.bin bf619eac0cdf3f68d496ea9344137e8b
0x0108.bin bf619eac0cdf3f68d496ea9344137e8b
0x0109.bin bf619eac0cdf3f68d496ea9344137e8b
0x010A.bin bf619eac0cdf3f68d496ea9344137e8b
0x010B.bin bf619eac0cdf3f68d496ea9344137e8b
0x010C.bin bf619eac0cdf3f68d496ea9344137e8b
0x010D.bin bf619eac0cdf3f68d496ea9344137e8b
0x010E.bin bf619eac0cdf3f68d496ea9344137e8b
0x010F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0110.bin bf619eac0cdf3f68d496ea9344137e8b
0x0111.bin bf619eac0cdf3f68d496ea9344137e8b
0x0112.bin bf619eac0cdf3f68d496ea9344137e8b
0x0113.bin bf619eac0cdf3f68d496ea9344137e8b
0x0114.bin bf619eac0cdf3f68d496ea9344137e8b
0x0115.bin bf619eac0cdf3f68d496ea9344137e8b
0x0116.bin bf619eac0cdf3f68d496ea9344137e8b
0x0117.bin bf619eac0cdf3f68d496ea9344137e8b
0x0118.bin bf619eac0cdf3f68d496ea9344137e8b
0x0119.bin bf619eac0cdf3f68d496ea9344137e8b
0x011A.bin bf619eac0cdf3f68d496ea9344137e8b
0x011B.bin bf619eac0cdf3f68d496ea9344137e8b
0x011C.bin bf619eac0cdf3f68d496ea9344137e8b
0x011D.bin bf619eac0cdf3f68d496ea9344137e8b
0x011E.bin bf619eac0cdf3f68d496ea9344137e8b
0x011F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0120.bin 9111b8dcb44848fd59be3b4832986289
0x0121.bin f7fb3d8bf6b42ac96391e3cbc0c3f1cb
0x0122.bin c86937485556b83a3be6b388011a0848
0x0123.bin f8cdf12b42d7cac4a39af868ff43a910
0x0124.bin 8ecabd5f5c4a8c86f2934158254d8aea
0x0125.bin 6b6b643df69ed691d6463cbc3a45852d
0x0126.bin 0ed2806dd2652f5a1f929667927abc11

0x0127.bin bf619eac0cdf3f68d496ea9344137e8b
0x0128.bin bf619eac0cdf3f68d496ea9344137e8b
0x0129.bin bf619eac0cdf3f68d496ea9344137e8b
0x012A.bin bf619eac0cdf3f68d496ea9344137e8b
0x012B.bin bf619eac0cdf3f68d496ea9344137e8b
0x012C.bin bf619eac0cdf3f68d496ea9344137e8b
0x012D.bin bf619eac0cdf3f68d496ea9344137e8b
0x012E.bin bf619eac0cdf3f68d496ea9344137e8b
0x012F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0130.bin bf619eac0cdf3f68d496ea9344137e8b
0x0131.bin bf619eac0cdf3f68d496ea9344137e8b
0x0132.bin bf619eac0cdf3f68d496ea9344137e8b
0x0133.bin bf619eac0cdf3f68d496ea9344137e8b
0x0134.bin bf619eac0cdf3f68d496ea9344137e8b
0x0135.bin bf619eac0cdf3f68d496ea9344137e8b
0x0136.bin bf619eac0cdf3f68d496ea9344137e8b
0x0137.bin bf619eac0cdf3f68d496ea9344137e8b
0x0138.bin bf619eac0cdf3f68d496ea9344137e8b
0x0139.bin bf619eac0cdf3f68d496ea9344137e8b
0x013A.bin bf619eac0cdf3f68d496ea9344137e8b
0x013B.bin bf619eac0cdf3f68d496ea9344137e8b
0x013C.bin bf619eac0cdf3f68d496ea9344137e8b
0x013D.bin bf619eac0cdf3f68d496ea9344137e8b
0x013E.bin bf619eac0cdf3f68d496ea9344137e8b
0x013F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0140.bin 5606e6bdab4a51a95806031d1415a23cbf619eac0cdf3f68d4 96ea9344137e8b refers to an empty key.

The only static key they changed was key 8. A single byte was changed, this affected the checksum of the data section (see the struct in the first post). Nothing else important changed.

edit: Did a tidyup to the first post again.

hum... looks like they started changing syscon then, still the fact that you can provide us with the idstorage dump hashes of this psp fairly means that they the pandora still works (meaning that they still use the 0xFFFFFFFF serial batteries to trigger the service mode and that our forged block works just as well as it did on earlier models. This obviously means that they did not (or rather could not) change the cpu mask rom codes (they probably have a few thousands to use) The day they need a new batch of cpu is the day pandora stops working. (I hope not before the 03g model)

Being Sony, there will always be a service mode. Virtually everything they make has one, and when they lose the PSPs service mode, they start losing a lot of money in replacements.

Jachra, those names are not the function names but just enum names or lib names or something like that. Sony don't leave any function names in plaintext any more.

On another note, here is an IdStorage checksum list from a new type Slim PSP (baryon number 0x00234000) which cannot write the battery serial number (fails with a Syscon error code, evidently they changed the Syscon firmware to make it error out when the battery NVM is tried to be written to)

0x0004.bin 53a94e603e899b5532e58b3132121b80
0x0005.bin 3e28ab59c7fa7deacf58020f5718f968
0x0006.bin d257d6b3b48257605843a44254f449d7
0x0007.bin dc500142a1275a365822c2aac0db6aeb
0x0008.bin c0673dbc7ea4d5a0462dcc9f29c3c016

0x000F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0010.bin 16aa17677cf0e51d8bc825afff67e185
0x0011.bin ce2106c38e79ee34181c4e6bc6fea693
0x0012.bin 651b907c7c46668a88069c51c632bec5
0x0013.bin 1936af401baca1e58e3c95a39a6ec5c4

0x0014.bin bf619eac0cdf3f68d496ea9344137e8b
0x0015.bin bf619eac0cdf3f68d496ea9344137e8b
0x0016.bin bf619eac0cdf3f68d496ea9344137e8b
0x0017.bin bf619eac0cdf3f68d496ea9344137e8b
0x0018.bin bf619eac0cdf3f68d496ea9344137e8b
0x0019.bin bf619eac0cdf3f68d496ea9344137e8b
0x001A.bin bf619eac0cdf3f68d496ea9344137e8b
0x001B.bin bf619eac0cdf3f68d496ea9344137e8b
0x001C.bin bf619eac0cdf3f68d496ea9344137e8b
0x001D.bin bf619eac0cdf3f68d496ea9344137e8b
0x001E.bin bf619eac0cdf3f68d496ea9344137e8b
0x001F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0020.bin bf619eac0cdf3f68d496ea9344137e8b
0x0021.bin bf619eac0cdf3f68d496ea9344137e8b
0x0022.bin bf619eac0cdf3f68d496ea9344137e8b
0x0023.bin bf619eac0cdf3f68d496ea9344137e8b
0x0024.bin bf619eac0cdf3f68d496ea9344137e8b
0x0025.bin bf619eac0cdf3f68d496ea9344137e8b
0x0026.bin bf619eac0cdf3f68d496ea9344137e8b
0x0027.bin bf619eac0cdf3f68d496ea9344137e8b
0x0028.bin bf619eac0cdf3f68d496ea9344137e8b
0x0029.bin bf619eac0cdf3f68d496ea9344137e8b
0x002A.bin bf619eac0cdf3f68d496ea9344137e8b
0x002B.bin bf619eac0cdf3f68d496ea9344137e8b
0x002C.bin bf619eac0cdf3f68d496ea9344137e8b
0x002D.bin bf619eac0cdf3f68d496ea9344137e8b
0x002E.bin bf619eac0cdf3f68d496ea9344137e8b
0x002F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0030.bin bf619eac0cdf3f68d496ea9344137e8b
0x0031.bin bf619eac0cdf3f68d496ea9344137e8b
0x0032.bin bf619eac0cdf3f68d496ea9344137e8b
0x0033.bin bf619eac0cdf3f68d496ea9344137e8b
0x0034.bin bf619eac0cdf3f68d496ea9344137e8b
0x0035.bin bf619eac0cdf3f68d496ea9344137e8b
0x0036.bin bf619eac0cdf3f68d496ea9344137e8b
0x0037.bin bf619eac0cdf3f68d496ea9344137e8b
0x0038.bin bf619eac0cdf3f68d496ea9344137e8b
0x0039.bin bf619eac0cdf3f68d496ea9344137e8b
0x003A.bin bf619eac0cdf3f68d496ea9344137e8b
0x003B.bin bf619eac0cdf3f68d496ea9344137e8b
0x003C.bin bf619eac0cdf3f68d496ea9344137e8b
0x003D.bin bf619eac0cdf3f68d496ea9344137e8b
0x003E.bin bf619eac0cdf3f68d496ea9344137e8b
0x003F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0040.bin b36005f9eb6cd328f81329d8c70fbe57
0x0041.bin fe405748cf64d3a22dc22aef56a02c2c

0x0042.bin bf619eac0cdf3f68d496ea9344137e8b

0x0043.bin 050acd6caf4cec9d64f3308a2aefcaa8
0x0044.bin fddc8084a61ae2728a59026582fbdc4f
0x0045.bin e8d17760026c327a2d93fe18a4a50b45

0x0046.bin bf619eac0cdf3f68d496ea9344137e8b

0x0047.bin 6e41a2b4e99b8fc5ea2fe19a8137fe95
0x0050.bin 91222d6f3367e738b0a37ca04956fbaa
0x0051.bin b1913186b5906347f724231b303a4785
0x0052.bin 1f556d20e91e6200d0fceec8fa93275d

0x0053.bin bf619eac0cdf3f68d496ea9344137e8b

0x0054.bin d340f23a7d18057bb02252a3cb40b877

0x0100.bin 9111b8dcb44848fd59be3b4832986289
0x0101.bin f7fb3d8bf6b42ac96391e3cbc0c3f1cb
0x0102.bin c86937485556b83a3be6b388011a0848
0x0103.bin f8cdf12b42d7cac4a39af868ff43a910
0x0104.bin 8ecabd5f5c4a8c86f2934158254d8aea
0x0105.bin 6b6b643df69ed691d6463cbc3a45852d
0x0106.bin 0ed2806dd2652f5a1f929667927abc11

0x0107.bin bf619eac0cdf3f68d496ea9344137e8b
0x0108.bin bf619eac0cdf3f68d496ea9344137e8b
0x0109.bin bf619eac0cdf3f68d496ea9344137e8b
0x010A.bin bf619eac0cdf3f68d496ea9344137e8b
0x010B.bin bf619eac0cdf3f68d496ea9344137e8b
0x010C.bin bf619eac0cdf3f68d496ea9344137e8b
0x010D.bin bf619eac0cdf3f68d496ea9344137e8b
0x010E.bin bf619eac0cdf3f68d496ea9344137e8b
0x010F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0110.bin bf619eac0cdf3f68d496ea9344137e8b
0x0111.bin bf619eac0cdf3f68d496ea9344137e8b
0x0112.bin bf619eac0cdf3f68d496ea9344137e8b
0x0113.bin bf619eac0cdf3f68d496ea9344137e8b
0x0114.bin bf619eac0cdf3f68d496ea9344137e8b
0x0115.bin bf619eac0cdf3f68d496ea9344137e8b
0x0116.bin bf619eac0cdf3f68d496ea9344137e8b
0x0117.bin bf619eac0cdf3f68d496ea9344137e8b
0x0118.bin bf619eac0cdf3f68d496ea9344137e8b
0x0119.bin bf619eac0cdf3f68d496ea9344137e8b
0x011A.bin bf619eac0cdf3f68d496ea9344137e8b
0x011B.bin bf619eac0cdf3f68d496ea9344137e8b
0x011C.bin bf619eac0cdf3f68d496ea9344137e8b
0x011D.bin bf619eac0cdf3f68d496ea9344137e8b
0x011E.bin bf619eac0cdf3f68d496ea9344137e8b
0x011F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0120.bin 9111b8dcb44848fd59be3b4832986289
0x0121.bin f7fb3d8bf6b42ac96391e3cbc0c3f1cb
0x0122.bin c86937485556b83a3be6b388011a0848
0x0123.bin f8cdf12b42d7cac4a39af868ff43a910
0x0124.bin 8ecabd5f5c4a8c86f2934158254d8aea
0x0125.bin 6b6b643df69ed691d6463cbc3a45852d
0x0126.bin 0ed2806dd2652f5a1f929667927abc11

0x0127.bin bf619eac0cdf3f68d496ea9344137e8b
0x0128.bin bf619eac0cdf3f68d496ea9344137e8b
0x0129.bin bf619eac0cdf3f68d496ea9344137e8b
0x012A.bin bf619eac0cdf3f68d496ea9344137e8b
0x012B.bin bf619eac0cdf3f68d496ea9344137e8b
0x012C.bin bf619eac0cdf3f68d496ea9344137e8b
0x012D.bin bf619eac0cdf3f68d496ea9344137e8b
0x012E.bin bf619eac0cdf3f68d496ea9344137e8b
0x012F.bin bf619eac0cdf3f68d496ea9344137e8b
0x0130.bin bf619eac0cdf3f68d496ea9344137e8b
0x0131.bin bf619eac0cdf3f68d496ea9344137e8b
0x0132.bin bf619eac0cdf3f68d496ea9344137e8b
0x0133.bin bf619eac0cdf3f68d496ea9344137e8b
0x0134.bin bf619eac0cdf3f68d496ea9344137e8b
0x0135.bin bf619eac0cdf3f68d496ea9344137e8b
0x0136.bin bf619eac0cdf3f68d496ea9344137e8b
0x0137.bin bf619eac0cdf3f68d496ea9344137e8b
0x0138.bin bf619eac0cdf3f68d496ea9344137e8b
0x0139.bin bf619eac0cdf3f68d496ea9344137e8b
0x013A.bin bf619eac0cdf3f68d496ea9344137e8b
0x013B.bin bf619eac0cdf3f68d496ea9344137e8b
0x013C.bin bf619eac0cdf3f68d496ea9344137e8b
0x013D.bin bf619eac0cdf3f68d496ea9344137e8b
0x013E.bin bf619eac0cdf3f68d496ea9344137e8b
0x013F.bin bf619eac0cdf3f68d496ea9344137e8b

0x0140.bin 5606e6bdab4a51a95806031d1415a23cbf619eac0cdf3f68d4 96ea9344137e8b refers to an empty key.

The only static key they changed was key 8. A single byte was changed, this affected the checksum of the data section (see the struct in the first post). Nothing else important changed.

edit: Did a tidyup to the first post again.

hum... looks like they started changing syscon then, still the fact that you can provide us with the idstorage dump hashes of this psp fairly means that they the pandora still works (meaning that they still use the 0xFFFFFFFF serial batteries to trigger the service mode and that our forged block works just as well as it did on earlier models. This obviously means that they did not (or rather could not) change the cpu mask rom codes (they probably have a few thousands to use) The day they need a new batch of cpu is the day pandora stops working. (I hope not before the 03g model)


Pandora bat and stick work indeed!. (its mine psp), but the bat serial writing
can't be executed. So i use a pandorized bat. (made on another slim) to play with.
I was only triggered on this new behaveiour because with 3.80M33 you guys
fixed this +/- 1,5 week ago (the bat serial writing). And i bought a new slim and it coudn't do the trick with the updated softwares (cory1492-hellcat).
So i did release the nand-dump to 2 guys (or girls? :) ).
And your looking at it.
Iam reading along this thread to see were it will stop or have succes.

I find it interresting because as a old TP/delphi programmer in the old days,
I loved to do reverse enginering. Stopped rev. eng. for many years now.. moved on...
New improvements (cat and dog game) stopped mine learning curve and interrest.

Sorry that this is become a personal reply but now you know why i'm
calling out the new findings.

Bagheera
Netherlands.


PS: If i can help with some tricks, just pm. (except opening the psp and scrathing the mobo with a slegdehamer... :) )

Bagheera, welkom. :) Where did you buy that one? Free Recordshop or ..

Bagheera, welkom. :) Where did you buy that one? Free Recordshop or ..

Mediamarkt netherlands

http://www.mediamarkt.nl/1/producten_trends/games/psp/index.php3

Oke, will see if I get them far enough to let me dump a nand. And yes, I live in the Netherlands.

It's key 0x0007 in a Spreadsheet!

Erm, yeah.

EDIT: Updated for Sony's love of 0's.

SilverSpring, I got that. So they are like global declared variables, structures, etc.
What tools do I need, to find those nids?

Well for a start, you could use the nidattack in the pspsdk svn:

http://svn.pspdev.org/filedetails.php?repname=psp&path=%2Ftrunk%2Fnidattack%2Fsrc%2Fmain.c&rev=0&sc=0

@SilverSpring

Thank you. I will compile that and start with it. Compiled it, do you have some input examples?

@brin_vg

Do you want more key 0x07 values for comparison?

@brin_vg

Do you want more key 0x07 values for comparison?


Sure, just include the model/colour if you could.

Oke, will do. Will post them soon.

i have problem regarding 0x100 i dunno if this is missing or corrupt but as what jasonuk stated above that is the reason why i cannot upgrade to 3.80 m33. is there any way to fix this things up?

i have problem regarding 0x100 i dunno if this is missing or corrupt but as what jasonuk stated above that is the reason why i cannot upgrade to 3.80 m33. is there any way to fix this things up?

pomskie, do you have a backup of your nand?

Sorry to sound a little @#$%^ but what about the main topic? How R U guys doing with the ID Storage fixing thing? Dont mean to sound pushy, but it was really interesting when U guys were talking about how it works.

Hey guys

Don't if this has anything to do with IdStorage but I think it might.

I had a full bricked slim with no nand backup so I had nothing to lose by experimenting. So I got someone elses idstorage keys and flashed the nand and wrote those keys to it (since I had corrupt idstorage keys anyway i didn't care) flashed 3.71m33-2 and it would boot but would stop at the waves background and no icons. So i started experimenting on recovery and formated flash1. Still nothing. So I went and disabled Sony Logo on start up and voilá it booted. It doesn't read homebrew or games (it starts them but then freezes on the sony logo). If turn Sony Logo on startup I won't get past the waves and if I turn it off it boots normally but freezes on the sony logo when starting a game or homebrew.

So what happens during the Sony Logo on startup that makes it not boot?

It might be that it reads some of the keys on idstorage?

Just wanted to share this. Don't know if anyone tried this or not but here goes anyway.

Cheers.

elgordoeste: The topic was intended to work out how to regenerate it, but it appears we've hit a dead end until 1) a jigkick is leaked and it gets decrypted and reversed, 2) a miracle, or 3) someone finds a hidden method in the PSP to regenerate the keys.
Don't expect anything to happen within the next month or two... or six.

So what happens during the Sony Logo on startup that makes it not boot?

It might be that it reads some of the keys on idstorage?Maybe, probably it reads a region related key which crashes the logo but doesn't get read at all when skipped.

elgordoeste: The topic was intended to work out how to regenerate it, but it appears we've hit a dead end until 1) a jigkick is leaked and it gets decrypted and reversed, 2) a miracle, or 3) someone finds a hidden method in the PSP to regenerate the keys.
Don't expect anything to happen within the next month or two... or six.

So what happens during the Sony Logo on startup that makes it not boot?

It might be that it reads some of the keys on idstorage?Maybe, probably it reads a region related key which crashes the logo but doesn't get read at all when skipped.
And in the meantime, we are filling in the blanks on parts of IDStorage that have just been introduced, or aren't understood.