Forums GAMERGEN

Flat_z Wrote:Hi, guys. Several days ago I've worked on the SSL traffic decryption used in communication with PSN and have got some interesting information regarding the way how can Sony determine consoles with non original console ID. Well, it is just a theory but the principle laid in it can be used to ban your spoofed console with 100% probability. So my words can be read as "If I worked at Sony, I would use this information for banning people". A new algorithm will show you that buying another console ID to use with your console is not safe anymore and I think that all purchased console IDs will be useless soon. Okay, let's start.

At October 23rd, 2012, Sony releases a new firmware for Playstation 3 (version 4.30) which includes only few changes if you've read its changelog. But now I know that they have introduced a new hidden feature which allows them to determine if you are legal user or not. It is compared with the code which some games like "Call of Duty" use to tell Sony that you are using a custom firmware. Sony did some changes at the algorithm for PSN authorization. You can remember that they use PSN passphrase to log into their network and you also should know that they are sending your console ID in a HTTP query. And now they use two passphrases; a new passphrase is encoded with base64 and is sent via custom HTTP header ("X-I-5-Passphrase"). If you'll try to decode it then you'll see that it have a size of 512 bytes which are looks as random data. It is encrypted per console data and it is different each time you log into a network. It includes a random header, your user ID, console ID, two ECDSA signatures from the first section of EID0 (I remind you that the first ECDSA signature used at lv1ldr to check if your console is converted from CEX to DEX manually which causes a brick) and account ID. Besides that, data is hashed with SHA-256 algorithm and encrypted with AES-128-CBC. Using random header and CBC mode of operation gives them an unique passphrase each time.

Now Sony can use the following simple algorithm on their server to check your console's legality:
1. Compare console ID stored in the HTTP GET request with the console ID stored inside the passphrase;
2. Validate two ECDSA signatures;
3. If steps above are okay then your console ID is legal.

They didn't made a mistake in ECDSA signature computation for EID0 so we are unable to get a private key to generate custom signatures. But if you have an access to EID root key and EID0 section of another console then you can decrypt its EID0 and grab all neccessary data from it. In such case you can generate a spoofed passphrase but you need some sort of runtime memory patching to replace original passphrase with the new one. Or you can try to replace signatures and console ID inside decrypted EID0 section of your console and then encrypt it back. But I doubt that any purchased console IDs came with EID root key.

The last thing I want to talk about is does Sony actually use this method at the moment or they are waiting for something? Maybe they collect all information and will start to ban people in the future? I don't know and I doubt that someone else knows about it. For example, they can use this method and start to ban people when they are playing some games after several days/weeks/months, etc.

Flat_z Wrote:It is NOT safer to change the IDPS in EID0. You need to change the entire EID0 section and encrypt it with your root key.

Flat_z Wrote:Today I've received a private message about SSL traffic decryption so I've decided to write here if someone want to ask me again.

In a past time we used a method with custom certificates (if I remember correctly this trick was used in F*ckPSN, for example). We could create a custom certificate with known private/public key pair and then replace existing certificate with ours. After that console will start using our keys to encrypt all traffic, so we can easily decrypt it on the PC.

But in latest firmwares (4.xx or later) Sony have started to hash their certificates with SHA-1 and these hashes are stored inside vsh.elf and libssl.prx (so you can compute hash from any certificate and try to find it there). Besides that, I think they checks parameters of certificate (for example, serial numbers, owner, etc) but I didn't look at this part.

My method is slightly different, I've created a payload for dumping premaster secret (PMS) of any SSL section (random bytes which are used later to generate a bunch of keys) from VSH's memory directly. Then I've wrote a script to generate the master secret (MS) using client and server randoms and premaster secret. After that you can use a packet analyzer (like Wireshark) to decrypt sniffed data using generated master key.

Such method is applicable for decryption of the game's traffic.