IDPS: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
= Description =
= Description =


The IDPS is a sequence of bytes which is used as a unical per console ID. The IDPS is contained in EID0. EID0 is on the console internal flash as the file eEID and has multiple sections. rms had made a splitter application (where?). Now, EID is decrypted by metldr, and is passed over to the isolated loader, which may pass it to a self. We can see this in graf_chokolo’s original payload.
The IDPS is a sequence of bytes which is used as a unical per-console Identifier. The IDPS is stored and certified in [[Flash:Encrypted Individual Data - eEID|EID]].


= Structure =
= Structure =

Revision as of 21:55, 27 May 2020

The IDPS is a 16 bytes value that contains console specific information.

Description

The IDPS is a sequence of bytes which is used as a unical per-console Identifier. The IDPS is stored and certified in EID.

Structure

  
                              Chassis Check
                                  ⇓                     
00000000  00 00 00 01 00 89 00 0B 14 00 EF DD CA 25 52 66  .....‰....ïÝÊ%Rf
                       ⇑ ⇑   ⇑ ⇑
                 Product Code  Model type
    (Internal:Product Code)   (Internal: Product Sub Code)

5th and 6th byte represent Product Code.

7th and 8th byte represent Product Sub Code

9th byte represents chassis check

10th byte represents an unknown model identifier

remaining bytes seam to be an identifier generated from some per console data

Dummy Reference Tool IDPS

0x00, 0x00, 0x00, 0x01, 0x00, 0x81, 0x00, 0x01, 0x03, 0xFF, 0xFF, 0xFF, 0x18, 0x43, 0xC1, 0x4D

This is the dummy IDPS that is used when some Reference Tool PS3's IDPS fails to be decrypted from flash. That IDPS belongs to a Reference Tool DECR-1000A. The Reference Tool IDPS from above is static. aim_iso uses it. Retail/3.55 doesn't have it.

00 00 00 01 <- Magic
00 89 <- Product Code
00 0B <- Product Sub Code
14 <- Chassis Check
00 EF DD <- unk0, FF FF FF in the dummy IDPS
CA 25 52 66 <- unk1, some unique ID

Source: rms' blogtext.

Dummy PSP Emulator IDPS

0x00, 0x00, 0x00, 0x01, 0x00, 0x81, 0x00, 0x01, 0x0C, 0x40, 0x00, 0xB1, 0x0E, 0x69, 0x69, 0x78

Found into the emulator_drm.sprx (iso self inside).

IDPS Regex

PS3

0{7}10{2}8[456789ACE]000[6789ABCD][01F][04][0123][0123456789ABCDEF]{13}

Based on 300+ PS3 IDPS dumps.

Chassis Check

The Chassis Check seems to be still a secret, or at least it's not 100% clear what it represents. So my immediate question was of course: if it's not clear what this means, how does the scene even know that it's called "Chassis Check" at all? Where does this information come from? According to the analysis of many different models of PSP, PS3, PSVita and PS4, it is clear that the only possible values are 0x3, 0x4, 0xC, 0x10, 0x14 and 0xF4 (and 0x90 for PSVita).

  • Doing right shift by 2 results in:
    • 0x3 >> 2 gives 0
    • 0x4 >> 2 gives 1
    • 0xC >> 2 gives 3
    • 0x10 >> 2 gives 4
    • 0x14 >> 2 gives 5
    • 0xF4 >> 2 gives 61 <-- that's an exception, found in refurbished PS3

We clearly see that most of PS3 models released at the same period have the same Chassis Check, and that the more the console is released late, the more high the Chassis Check is.

  • Chasis check speculation (bytes 9th and 10th):
    • 9th byte (most common: 0x04, 0x10, 0x14, 0xF4), 0x03 in the "Dummy IDPS"
      • First nibble values: 0, 1, or F
      • Second nibble values: 0, or 4, 3 in the Dummy Reference Tool IDPS
    • 10th byte (seems to be a counter, biggest value found 0x22), 0x40 in the Dummy PSP IDPS, 0xFF in the Dummy Reference Tool IDPS
      • First nibble values: 0, 1, or 2
      • Second nibble values: too random to find a pattern
  • Next 6 bytes speculation
    • 11th and 12th: (0xFF 0xFF in the Dummy Reference Tool IDPS)
    • 13th, 14th, 15th, 16th: per console identifyer ? a hash / encryption of previous bytes ? encrypted timestamp ?

Location

NAND/NOR

The IDPS can be found in EID0 and EID5. See Flash (NAND @ 0x80870 / NOR @ 0x2F070).

registry?

?It can also be found in registry/application_persistent file inside playstation Store folder (as DeviceID)?

PSN

idpstealer (patched since FW 4.70 and deprecated since ps3exploit)

From flatz: Privet, PS3 fans! Once KaKaRoTo published his backup tool I’ve decided to bring a way of getting a Console ID (IDPS) to the community. It can be used on OFW/CFW firmware and you don’t need any additional software/hardware installed on your PS3.

However there are several cons about releasing:

  1. A big company will fix it in the next firmwares.
  2. It can be used to steal other people’s IDPS if you have an access to their consoles.

And it seems that this is the only method of getting ConsoleId without using hardware solutions on the moment. So please, if you want to get an IDPS from your console then do it as fast as possible because I think this method won’t work in the nearly future.

How it works: IDPStealer works as a proxy server and intercepts all network traffic (including SSL traffic via HTTPS over HTTP tunneling) and it tries to get IDPS from it. It doesn’t contains any malicious code and can be safely used like any other proxy server.

Usage: idpstealer.exe [options] <idps file>
Options:
-p <port number> - Port to listen on (default: 1337
-h               - Show this help
Arguments:
<idps file>      - Output file for IDPS
C:\>idpstealer.exe idps.bin
Starting proxy server on 192.168.1.13:1337
IDPS have been successfully written to: idps.bin

https://dl.dropboxusercontent.com/u/35197530/zip/idpstealer.7z

https://web.archive.org/web/20160309135920/http://pastie.org/private/wlakfucps3bc21dfuosdtg

  • This method no longer works because now Sony uses OpenPSID instead of IDPS although the key/algorithm remains the same.
  • This should work also on PS4 and PSVita, but with a different key (not known/public atm)

Changing IDPS

Theory: If you give a slim console a fat IDPS, would that console have 3.15 OtherOS functionality?

I would say it would, because most likely the check is done in firmware to either en/disable that option. However, it would still require a console that can be downgraded to that version (only CECH-20xx/DYN-001, because CECH-21xx/SUR-001 use different drivers for RSX). So classic OtherOS on a CellBE 45nm/RSX 40nm would be impossible (of course you can use OtherOS++).

Obtaining IDPS of a PS3

HEN

With PS3Xploit, just do a flash dump and search inside.

CFW

There are homebrews to dump or even spoof your PS3 IDPS.

Bruteforce

You can verify the IDPS of a PS3 console through 2 ways : param.sfo of savedata or HDD backup from PS3. You would need to bruteforce 7 bytes, if you could take care of all the possibilities for Chassis Check.

Problem: "My old PS3 received the YLOD, however I have a hard drive backup of it, but not longer have the actual unit, but I do have a new PS3. I want to recover all my data to my new PS3, but need to be able to dump all the data from archive2.dat to create a fresh backup with all the data to restore to the new unit. Anyone have any suggestions or know of a way I could crack the IDPS used to encrypt my backup ?"

How is the current state (or former experience) with bruteforcing the IDPS from the IDPS hash of a PARAM.SFO file (second hash iirc). I mean most of the information is known so in the best case you chose your region and model and only have to bruteforce the last six bytes (if the Chassis Check was known better). If the scene could establish some kind of standard or bruteforce blueprint, like a blank PARAM.SFO of the PS3 singstar app, which should look the same on every console, someone could even work on a rainbow table for IDPS. Just some thoughts from zecoxao, someone who just entered the PS3 dev scene, so don't be too harsh please ;)

The easiest would be of course param.sfo of savedata, by manually verifying a certain sha1-hmac made from the file PARAM.PFD with idps as key. I was just looking into that and did a small PoC in c#, which BFs my IDPS. But even with all optimizations (especially for C#) and running on all cores with parallelization it isn't really THAT fast. Moreover, I even cheated and only bruteforced the last six bytes of my (known) IDPS. It's currently still running xD. Using openCL would help, because graphic cards are naturally faster than CPUs. Currently looking into that, but I never worked with openCL before and can't even find a hmac/sha1 kernel for openCL. Like nobody every did that before ... ;) useful?

Tools

PS3 Identification tools

Multiman

IDPS is displayed under setting information in MultiMan.

[Homebrew-App] PS3 Model Detection

Source: http://www.ps3hax.net/2011/01/homebrew-app-ps3-model-detection/]

Dumping PS3 Model Data:

- PS3 System Target ID:     0x85	(Retail - Europe)
- PS3 Motherboard Revision: 0x0B	(JTP-001 Motherboard, Revision 1)
- PS3 BD-Laser Revision:    0x04	(KES-400, SACD supported)

Probable Model: CECH-2504A

Raw Model Data:

  Byte 0:		0x00
  Byte 1:		0x01
  Byte 2:		0x00
  Byte 3:		0x85
  Byte 4:		0x00
  Byte 5:		0x0B
  Byte 6:		0x00
  Byte 7:		0x04

Notes:

  • '7th byte of IDPS' is not Bluray Drive (it was misunderstood at that time). You can see it in the example where it names incorrectly a CECH-25xx as Super Audio CD compatible with a KES-400 laserslide (which in real life has either KES-460A or KES-470A without daughterboard (swap can be done without remarry).
  • Also, it named bytes 0-2 "Byte 0", byte 3 "Byte 1", byte 4 "Byte 2", byte 5 "Byte 3", byte 6 "Byte 4", byte 7 "Byte 5", byte 8 "Byte 6", byte 9 "Byte 7" etc.

[Homebrew-App] IDPS Viewer

Source link

  • Displays the IDPS
  • Shows Product Code
  • Displays Motherboard revision
  • Save IDPS (16 bytes from EID) into dev_hdd0/IDPS.bin file