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:
Code: Select all
struct ps4_challenge {
unsigned char nonce[0x100];
};
Response:
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];
};
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.