[PS5] Eventual DualSense (DS5) emulation

[dogtopus]

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-0xf2 but has added bits, namely SET 0xf4 and GET 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 0xf5 response changes from initial 0000 to 0111 (after 1 0xf4) then 0103.

The trace on auth

The HID descriptor and lsusb -vd

Real interactions coming soon after I or someone else got the PS5.

[matlo]

Could you please share the device and configuration descriptors?

[dogtopus]

Sure. I updated the "HID descriptor" gist to include the lsusb -vd output.

[matlo]

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.

[matlo]

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.

[dogtopus]

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.

[dogtopus]

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]

Do reports with the same content have the same value for this field?

[dogtopus]

@matlo It's practically impossible to get the same report twice since there are timestamps involved.

[matlo]

What's the memory size for these timestamps?

[matlo]

Just found the answer in your gist.

[dogtopus]

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.

[dogtopus]

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.

[matlo]

Thanks for the tip!

[dogtopus]

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.

[InhexSTER]

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

[dogtopus]

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.

[b-desconocido]

Not sure someone is interested, but there are some info I found: 1) DualSense works fine in USB FS mode if no data was tampered 2) Each input report seems to have CRC or signature. 3) 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?

[dogtopus]

Not sure someone is interested, but there are some info I found:

1. DualSense works fine in USB FS mode if no data was tampered
2. Each input report seems to have CRC or signature.
3. 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).

[b-desconocido]

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.

[dogtopus]

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.

[b-desconocido]

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.

[dogtopus]

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.

[dogtopus]

https://patchwork.kernel.org/project/linux-input/patch/20210102223109.996781-2-roderick@gaikai.com/

That's a very nice reserved you got there. Good job $**y :P

[tpunix]

The MCU of dualsense:

[tpunix]

CXD90064GG == MT3616ECT ??

[dogtopus]

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).

[smartcharge]

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:

PS5 I2C.zip

[tpunix]

A PS5 pad converter is on the store now: https://detail.tmall.com/item.htm?id=640910895139&ns=1&abbucket=10

[dogtopus]

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.

[dogtopus]

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).

[tpunix]

I found and buy these board(4pcs) on taobao from a guy. Two CXD90064 and two MT3616. These boards should have problem(bad stick, etc.). I can see a HID device on pc(battery must present).

[twobigbowl]

I found and buy these board(4pcs) on taobao from a guy. Two CXD90064 and two MT3616. These boards should have problem(bad stick, etc.). I can see a HID device on pc(battery must present).

Hi Guy，I am also Analyzing Bluetooth Hid, I need some MT3616 boards, can I provide the purchase website?

[tpunix]

I found and buy these board(4pcs) on taobao from a guy. Two CXD90064 and two MT3616. These boards should have problem(bad stick, etc.). I can see a HID device on pc(battery must present).

Hi Guy，I am also Analyzing Bluetooth Hid, I need some MT3616 boards, can I provide the purchase website?

这板子是我在咸鱼上偶尔看到的. 现在已经没有了. 这两种板子从硬件到软件看上去都是一样的.

[zecoxao]

@tpunix this is from a proto controller. where did you get this? if you can get me photo from proto ps5 motherboard i'll buy you a cookie xD

[dogtopus]

@zecoxao I guess someone unknowingly recycled some broken early devkit DS5s and sold the motherboard on taobao? tpunix said they found those motherboards on taobao and it's not available now.

[tpunix]

No proto motherboard found on taobao:( Can we find the debug port on DS5?

[zecoxao]

@tpunix my friend who is a pro at distinguishing chips says it's likely just a cheap variant of the MT8516

[stealth-alex]

https://www.psxhax.com/threads/ps5-dualsense-controller-firmware-dumped-decryption-by-scene-devs-required.10163/

[dogtopus]

https://www.psxhax.com/threads/ps5-dualsense-controller-firmware-dumped-decryption-by-scene-devs-required.10163/

This is just the DFU firmware image sent over the USB right? Not a proper dump since we still need to wait for PS5 DS5 hacks to reveal the encryption key.

(Also holy s*** beagle 5000 I want that (looks at my openvizsla))

[fraca7]

Hello. Here are my 2 cents for now.

The 64-bits checksum at the end of the report actually only covers the first 16 bytes of the report. I configured an Arduino as USB passthrough and flipped the bits of each report byte, one at a time, testing the 63 bytes by hand to see if reports were still accepted to confirm that. Obviously I can't tell if the report ID is covered as well since changing this would invalidate the report anyway.

It doesn't seem to be a CRC64; reveng does not find its parameters anyway.

The 32 bits counter at offsets 12-16 seems to start from a random value that changes every time you unplug the Dualsense, so it's kind of difficult, but I'm currently capturing a shitload of reports so I can answer the following questions:

1. Is the checksum the same when the first 16 bytes are the same
2. Is the checksum dependent on the controller
3. More specifically, is it dependent on the currently paired MAC and link key. There are few other controller-specific parameters I can actually set myself.

I also should be able to get two reports that only differ by the least significant bit in the last 16-bytes payload. Not sure if that could help. The dump is running and it will probably take a few days to get something usable.

[fraca7]

Correction: tested the 63-8 bytes of course, changing the checksum itself produces the obvious result :)

[smartcharge]

I can play PS5 games for 8 minutes. To be clear, I'm using the STM32F4 as a USB pass through and the DS4 to play PS5 games.

It turns out you do not need the 64 bit CRC at the end of the USB report to hack the PS5. I am completely ignoring the 64 bit CRC and just padding it with zeros. I am able to play Astro's Playground that shipped with the PS5 using my DS4.

The trick is to load the PS4 descriptor then another random descriptor using a USB vendor ID that is unknown to the PS5. This worked for me, with one catch: the DS4 disconnects after 8 minutes. The reason for this seems to be the authentication packets. Every couple of minutes the PS5 sends authentication packets and I don't know what response I'm suppose to give so the DS4 disconnects.

This is one step closer since I couldn't get the PS5 to respond to any of my packets a few months ago.

[dogtopus]

Woah that's a big discovery. Althought it sounds like a bug that $**￥ might fix and we are still restricted to DS4 features.

[smartcharge]

Agreed, but right now its all I got. Also, it might lead us to other discoveries and eventually a reliable hack.

[fraca7]

I'm not sure I understand; the Dualshock (DS4) did not include that 64-bits checksum in its reports anyway AFAIK ?

[smartcharge]

The USB packet looks like this This works for me. I can play PS5 games with the DS4 but for only 8 minutes. Its just as dogtopus surmised: its a bug in the PS5. But its a bug that works...for now.

[fraca7]

Yes, but I mean, this is different from the Dualsense checksum problem. The Dualshock reports do not have this kind of signature; then end of the report is just touchpad data IIRC. It's still interesting to be able to play PS5 games with a Dualshock though.

The 8 minutes timeout (8m30s I think actually) is indeed because of the authentication challenge. BTW why don't you just pass through the auth reports (0xf0, 0xf1 and 0xf2 IIRC) to the Dualshock ?

[smartcharge]

I changed the DS4 packet. My setup is using an STM32F4 (note: This microcontroller has 2 USB ports) with a DS4 plugged into the first USB port and the second USB port is plugged into the PS5. So I read the DS4 USB packet and change it before sending it to the PS5. The image I posted shows the data I am sending to the PS5 after I have changed it.

What do you mean when you say "why don't you just pass through the auth reports (0xf0, 0xf1 and 0xf2 IIRC) to the Dualshock ?" Can you explain in more detail?

[fraca7]

I mean, if you pass-through the control endpoint data in both directions (ps5 -> ds4 and ds4 -> ps5) the auth challenge should just work right ? That's essentially what I do in dsremap (https://github.com/fraca7/dsremap).

[HelloDJGaming]

does you guys have any idea of how cool do you look like for a normal guy ?not a programmer ,like me . Well you look cool AF talking in codes and making small and steady progress over the same topic and sharing your researchs ,good job living the dream❤