Here are my findings regarding the ID formats for the PlayStation 2, now that DNAS is dead. There are two IDs for every PlayStation 2 unit, which are issued by SONY: i.Link and console. The i.Link ID contains both the unique ID, which is used in the EUI-64 ID that the console uses for i.Link/IEEE1394 communication. The CDVDMAN driver takes the unique ID and appends it to the SONY OUI of 08 00 46, when a program requests the i.Link (EUI-64) ID. Only the fields for the EMCS IDs, Model IDs, unique ID and the serial number are officially known, from disassembling the SONY service tools and CDVDMAN. Everything else was arbitrarily named. Console ID: MM MM XX XX SS SS SS EE MM: Model ID. This is a different version. XX: Unknown. Seems to be always 0x11 0x01. SS: Serial number, in decimal. EE: EMCS ID The EMCS ID field of the console ID contains 0x00 for most Pre-Dragon models, but has a non-zero value (either 1 or 2) for those "Made in China" Pre-Dragon models. The Dragon models have the actual EMCS IDs recorded there. The serial number is in decimal. For example, 0x13 0xe6 0x05 is 0x05E613, which is my SCPH-39006's serial number of 0386579. i.Link ID: EE MM MM MM UU UU UU TT EE: EMCS ID, but always 0x7 in pre-Dragon models. MM: Model ID UU: The unique part of the EUI-64 ID, which is the serial number that is obfuscated. TT: Type of the console (and region?) Known Type values: 0x80: XOR 0xFF (All Dragon CEX) 0xA0: XOR 0xFF (All Dragon DEX) 0xB0: XOR 0xFF (PSX) For example, my SCPH-77006 has a type of 0x80 and an unique ID of 0x0a 0xc9 0xa2 0xa2 ^ 0xFF = 0x5D 0xc9 ^ 0xFF = 0x36 0x0a ^ 0xFF = 0xF5 ...which gives 0x5D36F5, which is the serial number of 6108917. If anyone understands how to logically decrypt the serial numbers for other models, please share here.
I guess that the lower 4 bits of the pre-Dragon hint values represent the region, although I don't know what logic was used to decrypt the serial numbers: 0 - Japan (00) 1 - US (01) and UK (03) 2 - Asia (06) 3 - Europe (04) The pre-dragon DEX seems to have 0x30 as the hint, all the time. I don't have information on pre-dragon consoles from Oceania (02), Korea (05), Taiwan (07) and Russia (08). Neither do I have enough records to determine whether this pattern is indeed true or not.
Just to add to what you're cooking here, MAC addresses for iLINK are usually mathematically derived from the serial number.
If people (privately) submitted to you some of the IDs, serials and model numbers from their systems, would this help you with your research?
Thanks, but I do have some IDs. The problem is that I haven't been able to figure out all the patterns, over the years. Hence why I am just asking for information, if anyone has actually figured out how to decrypt the older serial numbers. Finding patterns has never been my strong point. It seems like the serial number is obfuscated in different ways, across the various regions. I am not going to be surprised if the model number actually matters too...
It does, by letting you know what kind of "algorithm" you need to apply to the S/N to get the MAC address for iLINK. Knowing the algorithms they could enforce checking for properly formatted IDs on the DNAS servers. As an example: SCPH-10000 S/N 000550681 Offset 0x01C0 of the eeprom: 0700001AD9590510 01D2110119670800 (little endian) Converted into human readable numbers: 1A000007 100559D9 0111D201 00086719 Analyzing them a little bit we get: 1A000007 *10* 0559D9 iLink 350681 0111D201 *00* 086719 CID (please notice that S/N and iLink unique portions are likely to be 24bits, not 32 bits.) Applying some silly basic math we get: 550681 - 350681 = 200000 The result was 200000 on every single 10K I tested this. It's hard to notice if you stare to the numbers as HEXADECIMAL but are pretty obvious when viewed in decimal.
Thanks. You told me that it also applied to your SCPH-18000 consoles too, hence why there is a problem here; it spreads across multiple console models. The pattern breaks after the SCPH-18000, but seems to get used again for one of the SCPH-30000 models (GH-016). Now that you mentioned it, the "Hint" value doesn't seem to be a hint: all CEX consoles had 0x10 set in that field, regardless of what region they were from (and how their serial numbers were obfuscased). DEX units had 0x20 set as well. Hence it is likely just a type field of some sort. This also means that the method of encryption is likely done with the model ID itself, as it is the only thing that can vary with the obfuscation of the serial number. The two DNAS functions in CDVDMAN are meant to retrieve the GUID (EUI-64 address) and the model ID separately, so it would make sense for any operations on the serial number to be done with the model ID.
