Probably, but they also found the way for the X1 and Switch gamepads
PS 4 - Controller Authentication
Re: PS 4 - Controller Authentication
Re: PS 4 - Controller Authentication
Hi,
Is there a public dump of a successful PS4-DS4 authentication? The Wiki articles that cover the auth packets are wrong / incomplete.
Is there a public dump of a successful PS4-DS4 authentication? The Wiki articles that cover the auth packets are wrong / incomplete.
Re: PS 4 - Controller Authentication
Hi,
Authentication is based on symmetric cryptography. Replaying a successful authentication will not work.
Authentication is based on symmetric cryptography. Replaying a successful authentication will not work.
GIMX creator
Re: PS 4 - Controller Authentication
Hi Matlo,
I was wondering, because it all looked too simple - get nonce, sign nonce, send nonce. After getting a dump it seems its actually quite different.
The console sends the 0x100 (256) bytes long nonce, but the controller responds with two messages (separate by padding), 528 and 256 bytes respectively, spanned across 17-18 packets.
Note: ignore this post, check the post below for more information.
I was wondering, because it all looked too simple - get nonce, sign nonce, send nonce. After getting a dump it seems its actually quite different.
The console sends the 0x100 (256) bytes long nonce, but the controller responds with two messages (separate by padding), 528 and 256 bytes respectively, spanned across 17-18 packets.
Note: ignore this post, check the post below for more information.
Last edited by billy.joe on Wed Apr 11, 2018 12:09 pm, edited 1 time in total.
Re: PS 4 - Controller Authentication
For the sake of Googlers passing by, the auth works as following for the USB controllers:
- Console sends a nonce in 5 packets type 0xF0
- DS4 sends one ACK packet type 0xF2 that's its prepping the data (probably because RSA is compute-heady and that microcontroller on the gamepad needs some time)
- DS4 sends one ACK packet type 0xF2, but this time, removes the flag, indicating that its ready to send commands.
- DS4 sends 19 packets type 0xF1.
Challenge:
Response:
signature is a PSS signature of the nonce, signed by the private key of DS4
serial_num is the controller/cert serial number.
n is the Public Key's prime number
e is the Public Key's exponent
casig is a PSS signature (signed by Sony's CA private key) of the serial_num, n and e. This is what prevents you from generating your own keys and this is why you need a valid DS4 dump.
You'll have to get a dump of the DS4 in order to get valid serial_num, n, e, casig and private_key with which to sign the nonce. I'm not sure if the capability is present/active, but Sony might be able ban known/public DS4 dumps. Similar to how Certificate Revocation works in TLS.
Why so many packets?
The controller's descriptors set the maximum packets size at 64 bytes. Usable data (without the checksum and the header) is 56 bytes.
What is sequence and packet counters?
The console sends auth requests periodically, in order to know which request you're answering, you have a sequence counter. This counter is set by the console and does not change, until a new auth request is issued.
Packet counter is the packet number within the sequence. As data is split in multiple packets, the console needs to keep track of the order.
- Console sends a nonce in 5 packets type 0xF0
- DS4 sends one ACK packet type 0xF2 that's its prepping the data (probably because RSA is compute-heady and that microcontroller on the gamepad needs some time)
- DS4 sends one ACK packet type 0xF2, but this time, removes the flag, indicating that its ready to send commands.
- DS4 sends 19 packets type 0xF1.
Challenge:
Code: Select all
struct ps4_challenge {
unsigned char nonce[0x100];
};
Code: Select all
struct ds4_response {
unsigned char signature[0x100];
unsigned char serial_num[0x10];
unsigned char n[0x100];
unsigned char e[0x100];
unsigned char casig[0x100];
};
serial_num is the controller/cert serial number.
n is the Public Key's prime number
e is the Public Key's exponent
casig is a PSS signature (signed by Sony's CA private key) of the serial_num, n and e. This is what prevents you from generating your own keys and this is why you need a valid DS4 dump.
You'll have to get a dump of the DS4 in order to get valid serial_num, n, e, casig and private_key with which to sign the nonce. I'm not sure if the capability is present/active, but Sony might be able ban known/public DS4 dumps. Similar to how Certificate Revocation works in TLS.
Why so many packets?
The controller's descriptors set the maximum packets size at 64 bytes. Usable data (without the checksum and the header) is 56 bytes.
What is sequence and packet counters?
The console sends auth requests periodically, in order to know which request you're answering, you have a sequence counter. This counter is set by the console and does not change, until a new auth request is issued.
Packet counter is the packet number within the sequence. As data is split in multiple packets, the console needs to keep track of the order.
Last edited by billy.joe on Wed Apr 11, 2018 12:09 pm, edited 3 times in total.
Re: PS 4 - Controller Authentication
@billy.joe
Iam trying to find out why the Hori Pad FPS4 behaves different to a Sony DS4 controller.
- First of all, the Hori controllers does not use CRC's in the 0xF2 and 0xF1's replies. they are left blank 00 00 00 00
- The Hori controller seems to accept 0xF0's without a valid CRC. The DS4 bails out (ACK reply 0xF2 is not 0x00 or 0x10, but different)
Another thing.. When i emulate the PS4 communication to the controller, having a static nonce will result in a different signature every time (even when i leave the sequence counter the same value!!). I would expect them to be the same. This only occurs when i write all the 0xF0 SetReports (the last one will exectute the signature calculation, because when i skip that packet, the output does is the same as the last challenge)
P.S. obfuscated some values for the obvious reason.
Anyone a suggestion?
Iam trying to find out why the Hori Pad FPS4 behaves different to a Sony DS4 controller.
- First of all, the Hori controllers does not use CRC's in the 0xF2 and 0xF1's replies. they are left blank 00 00 00 00
- The Hori controller seems to accept 0xF0's without a valid CRC. The DS4 bails out (ACK reply 0xF2 is not 0x00 or 0x10, but different)
Another thing.. When i emulate the PS4 communication to the controller, having a static nonce will result in a different signature every time (even when i leave the sequence counter the same value!!). I would expect them to be the same. This only occurs when i write all the 0xF0 SetReports (the last one will exectute the signature calculation, because when i skip that packet, the output does is the same as the last challenge)
P.S. obfuscated some values for the obvious reason.
Anyone a suggestion?
Re: PS 4 - Controller Authentication
I think CRC was added for ensuring data integrity with bluetooth mode.
GIMX creator
Re: PS 4 - Controller Authentication
USB's packets are CRCed by architecture so that might be possible.
But what about the authentication. I thought (read it that way) that a random nonce is signed by the controller and that you can verify the signature by using the 2048 bit public key (which also comes with the reply) to decrypt it back to the nonce. However the nonce does not change, the public key does not change, but the signature does. it makes no sense to me.
what am i missing here?
But what about the authentication. I thought (read it that way) that a random nonce is signed by the controller and that you can verify the signature by using the 2048 bit public key (which also comes with the reply) to decrypt it back to the nonce. However the nonce does not change, the public key does not change, but the signature does. it makes no sense to me.
what am i missing here?