GIMX
GIMX copied to clipboard
matlo
[PS5] Eventual DualSense (DS5) emulation
Some quick information about it:
- It's using USB HighSpeed (RIP serialusb) (though I doubt that third party will strictly follow this nor will it be enforced by $**y)
- The protocol has a distinctive DS4 feeling to it although different.
- The authentication seems to use the same magic number as DS4 (
0xf0-0xf2but has added bits, namelySET 0xf4andGET 0xf5). Not sure how much the protocol changes compare to DS4 but my auth script for DS4 didn't work and the "status code" changes based on how many nonce packets I sent to the controller.- After some fuzzing with
SET 0xf4,GET 0xf5response changes from initial0000to0111(after 10xf4) then0103.
- After some fuzzing with
The trace on auth
The HID descriptor and lsusb -vd
Real interactions coming soon after I or someone else got the PS5.
Sure. I updated the "HID descriptor" gist to include the lsusb -vd output.
Thanks! It has a device qualifier descriptor, which definitely means it is high speed capable. It is still unsure that high speed will be used and enforced all the time. High speed likely consumes more power, which means charging time would be slower if it is enforced. Full speed is enough to carry the communication of a bluetooth device, which I think is still used here. At the moment I see no reason to go high speed.
Did you actually try serialusb between the Dualsense and a Windows PC? As serialusb stalls device qualifier descriptor requests, it is actually able to force the communication to go full speed.
Did you actually try serialusb between the Dualsense and a Windows PC? As serialusb stalls device qualifier descriptor requests, it is actually able to force the communication to go full speed.
I didn't. However I did try to connect DS5 to PS4 with an OpenVizsla in between and come up with nothing (as in it decodes the high speed traffic but nothing interesting came out).
If it indeed blocks the device qualifier then it should work like you said.
There's a weird 64-bit checksum-y field located at the end of each input report and I can't figure out how it's calculated. It doesn't seem to be one of the crc64 that rahash2 supports. Could be a custom poly or some stronger MAC stuff.
@matlo It's practically impossible to get the same report twice since there are timestamps involved.
I changed my fuzzing technique to be more aggressive and automated (i.e. throwing random bits and see what turns what on) and made some progress on the output report format.
Some update on the bluetooth side of the checksum (last 4 bytes):
The crc32-esque thing is just standard crc32 with custom initial value 0x23fcc4d3 and without flipping all the bits on output (i.e. xor mask is 0)
reveng output:
width=32 poly=0x04c11db7 init=0x23fcc4d3 refin=true refout=true xorout=0x00000000 check=0x1141f36b residue=0x00000000
$ ./reveng -c -i 23fcc4d3 -p 04c11db7 -w 32 -l "$(xxd -r -p | xxd -p | tr -d '\n')"
31 21 7d 80 81 80 00 00 01 08 00 00 00 15 ec 1f
10 f4 ff fb ff 03 00 ec ff 72 1f 4d 05 b5 05 8c
32 0e 82 3a 93 22 80 00 00 00 a0 09 09 00 00 00
00 00 aa 12 8c 32 09 00 00 9c cc 22 e4 28 05 53
46 00 10 00 00 00 00 00 00 00
18c5040c
More info: https://github.com/Ryochan7/DS4Windows/issues/1545#issuecomment-725567002 and below
EDIT: I think it's just regular CRC32 with the Bluetooth HID header included instead of a custom algorithm. Needs further verification on this.
Just saw some real protocol captures from others: the auth sequence seems indeed very different compare to DS4 but looks like it should still be passthrough-able. Might need more confirmations.
Now the biggest thing would be figuring out how those 64-bit trailing data were generated.
Somewhat good news as PS5 supports DS4 I've tried GIMX DS4 BT mode connecting from PC to console over bluetooth works with PS5 I assume wired connection would work too That means PS4 titles can still be played with keyboard an mouse on PS5
Somewhat good news as PS5 supports DS4 I've tried GIMX DS4 BT mode connecting from PC to console over bluetooth works with PS5 I assume wired connection would work too That means PS4 titles can still be played with keyboard an mouse on PS5
That was to be expected since licensed PS4 controllers are supported in PS5 compat mode. Thanks for confirming anyway.
Not sure someone is interested, but there are some info I found:
- DualSense works fine in USB FS mode if no data was tampered
- Each input report seems to have CRC or signature.
- PS5 accepts few tampered HID reports (about 6-8 frames I think), then it enters "I don't give a sh*t" mode untill re-enumeration So, the emulation over USB is not possible?
Not sure someone is interested, but there are some info I found:
- DualSense works fine in USB FS mode if no data was tampered
- Each input report seems to have CRC or signature.
- PS5 accepts few tampered HID reports (about 6-8 frames I think), then it enters "I don't give a sh*t" mode untill re-enumeration So, the emulation over USB is not possible?
Yeah that's what I would expect. Don't have PS5 so I didn't check it myself but I was pretty sure they would check it if they spent time implementing it.
Also Bluetooth packets have this as well. So the best thing to do now IMO is to wait until some 3rd party controller maker forgot to lock their firmware or wait for PS5 firmware decryption (which all could take ages).
Yeah that's what I would expect. Don't have PS5 so I didn't check it myself but I was pretty sure they would check it if they spent time implementing it.
Also Bluetooth packets have this as well. So the best thing to do now IMO is to wait until some 3rd party controller maker forgot to lock their firmware or wait for PS5 firmware decryption (which all could take ages).
Isn't Bluetooth report use plain CRC as you mentioned and discovered earlier? I'm curious why they did what they did, like implementing something entirely different for USB reports. 64 bit checksum doesn't make much sense for me, there must be a salt (although, there are counters and timestamp already)/seed/public key/IV or whatever else it might be. If this stuff requires obtaining some private "keys" (also signed by the manufacturer) from a gamepad, that will be a disaster :(
I hope it is something simple, cuz this kind of reversing isn't for an average Joe.
Isn't Bluetooth report use plain CRC as you mentioned and discovered earlier?
Before the CRC field there's also the 64-bit MAC/checksum stuff.
64 bit checksum doesn't make much sense for me
It could still be something simple if there is performance concern since cryptographically secure stuff usually takes more resources. However if there's a hardware block dedicated to this it might be less of a concern. Still keep in mind that $**y would likely still allow 3rd party controllers and it would add another constraint to how complex this thing could be (unless they went all out and make the ASIC available for 3rd party controller makers for running some sandboxed applets/etc.)
If this stuff requires obtaining some private "keys" (also signed by the manufacturer) from a gamepad, that will be a disaster :(
I thought this possibility as well but IMO it would be unlikely. The MAC/checksum is included way before the auth key exchange and as you pointed out it only takes couple of frames for PS5 to stop responding to the input report. So it is unlikely that the field is linked to the auth identity key. Also 64-bit isn't a lot to work with so I doubt that there would be anything fancier than A traditional MAC.
he MAC/checksum is included way before the auth key exchange and as you pointed out it only takes couple of frames for PS5 to stop responding to the input report.
I was wrong, console accepts few modified input reports, not frames. I was jerking around debugging my smelly "code", while all host requests being NAK'ed by hardware - console still accepts several input reports, even several seconds apart from each other. Wondering, what MCU they are using. I'm sure it is some kind of relabeled mainstream MC, gonna take a deep dive into it.
he MAC/checksum is included way before the auth key exchange and as you pointed out it only takes couple of frames for PS5 to stop responding to the input report.
I was wrong, console accepts few modified input reports, not frames. I was jerking around debugging my smelly "code", while all host requests being NAK'ed by hardware - console still accepts several input reports, even several seconds apart from each other. Wondering, what MCU they are using. I'm sure it is some kind of relabeled mainstream MC, gonna take a deep dive into it.
Still doesn't change much even if it was report instead of frames since iirc auth comes seconds later. Receiving reports after "stalling" sounds normal to me since that's what 8 minute timeout would do on PS4.
As for the micro, hopes are not high. Even later revisions of DS4 start to use obscure Mediatek SoCs that I can't find anything online, not even briefs.
https://patchwork.kernel.org/project/linux-input/patch/[email protected]/
That's a very nice reserved you got there. Good job $**y :P
CXD90064GG == MT3616ECT ??
Probably just rebranded chip. The PCB looks exactly the same to me so it's pretty likely.
(Not so) big oopsie for $**y but we still
can't find anything online, not even briefs
However slightly related: I heard that B***k is also Taiwan based so they might use some help from their Taiwanese friend :stuck_out_tongue_closed_eyes: (half joking half serious).
I have made some progress, but not enough to crack the DS5. So here's where I'm at.
I have a STM32F4 that uses 2 USB full speed ports, one for the DS5 and the other for the PS5. I have set the PS5 to use USB, forget the Bluetooth, for now. I can get the DS5 to send data through the STM32F4 to the PS5 and play games. But I can't inject packets into the USB because of the last 64 bits that are encoded/encrypted. Now we all know that the last 64 bits of the message are the mystery that we have to solve. I don't know if its a CRC or some encryption, but I'm going to assume it's a CRC for now, because encryption seems like it would take too long to encode and decode and a 64 bit CRC is very hard to crack, especially when you consider the initial XOR value, the final XOR value and the polynomial. With all this it might as well be encrypted.
I opened up a DS5 controller and started sniffing the traces, I started with the simple ones that look like they might be I2C. Sure enough they were. I captured the I2C data and then something interesting happened, the DS5 no longer sends the 64 bit CRC. The last 64 bits are filled with zeros for every packet sent from the DS5. The DS5 no longer works with the PS5. The USB works fine, the DS5 sends and receives all USB packets. The DS5 sends the joystick data, the Gyro data but not the 64 bit CRC and so the PS5 ignores all commands from the DS5. Another thing I noticed is that one of the timestamps are also zeroed out, specifically bytes 12 to 15. This leads me to believe that the timestamp is used as a seed, or salt or perhaps the initial/final XOR value.
One problem, I monitored 2 different I2C lines at the same time and I don't know which one caused the problem, so I attached the values I received from both lines. In the attached files, the I2C data only occurs during boot up, after that no data was sent. I've looked through the data and couldn't find any correlation between the I2C data and the security authentication data that is sent over USB between the DS5 and the PS5. Maybe someone else will spot something I've missed. One other thing, I'm not a perfect human being so it is possible that I shorted the I2C lies without knowing it, but the rest of the controller works fine, it even works on my Windows 10. Only the 64 bit CRC is not working. I think there may have been a tamper detection at the hardware level that forced the DS5 to zero out the 64 bit CRC.
Here is the I2C data I sniffed from the DS5:
A PS5 pad converter is on the store now: https://detail.tmall.com/item.htm?id=640910895139&ns=1&abbucket=10
A PS5 pad converter is on the store now: https://detail.tmall.com/item.htm?id=640910895139&ns=1&abbucket=10
Interesting find. Guess someone's Taiwanese friend is really helpful (jk)
Also https://twitter.com/jonyfraze/status/1371945375767130119. Seems they are using an I2C dongle this time to protect their stuff.
@smartcharge Please add more details on what you did to capture the I2C data. Which I2C buses/devices did you probe, the probing technique and the wiring, etc. Also try to only probe 1 I2C device at a time (if they are on separate buses) and try to narrow down.
My guess is that you maybe did something so the I2C bus malfunctions and DS5 can't get the required data to initialize the 64-bit thingy calculator, thus the zeros. It's really hard to detect if there's a probe attached to an electrical connection unless you screwed something up and caused it to fail, which is the more likely scenario.
CXD90064GG == MT3616ECT ??
Also @tpunix I was wondering where did you find this photo/board? I can't seem to find the source so I assume you either took it yourself or it's available on some private chatroom somewhere. Is it some engineering sample of DS5 or later revisions? It seems too odd that they will suddenly ditch their CXD silkscreen and use stock MTK ones instead, especially when it's to confuse the hax0rs (although I admit that a die shot would most likely expose the chip instantly).