[PS5] Eventual DualSense (DS5) emulation #672
Comments
|
Could you please share the device and configuration descriptors? |
|
Sure. I updated the "HID descriptor" gist to include the |
|
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. |
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. |
|
Do reports with the same content have the same value for this field? |
|
@matlo It's practically impossible to get the same report twice since there are timestamps involved. |
|
What's the memory size for these timestamps? |
|
Just found the answer in your gist. |
|
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):
$ ./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
18c5040cMore info: Ryochan7/DS4Windows#1545 (comment) 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. |
|
Thanks for the tip! |
|
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 |
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:
|
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. |
Before the CRC field there's also the 64-bit MAC/checksum stuff.
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.)
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. |
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. |
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 |
|
The MCU of dualsense: |
|
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
However slightly related: I heard that B***k is also Taiwan based so they might use some help from their Taiwanese friend 😝 (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: |
|
Added more info and HID commands here also: |
|
Is it already possible to have an original DS5 connected, pass all its data through and then alter some data? Or is it still not known how to circumvent the ps5 from detecting that the data has been tempered with? |
We might as well look into the Besavior U5. It isn't banned from what I know and can passthrough the key. Another option is this, it already seems to work for PS4 controllers to PS5 but not for PS5 controllers https://github.com/jfedor2/paaas On hacked PS5 consoles you have a debug option to enable PS4 controllers in native PS5 games. There are also commands found to do the calibration:
|
@Glomby what do you know about this? How did you figure this out? Where do you track this information? I've been doing a lot of work recently with libusb and gadgetfs. I just ran into this. The second you modify the data, it just stops working. I just bought a Cynthion device from great Scott gadgets. Honestly, I've been looking for a trove of information much like this thread. There's such a wealth of knowledge, here that this is going to do me very well. One of my plans, and who knows how well it's gonna work, is to feed all of these byte streams into an LLM. So I'm gonna save and replay a ton of stuff. Then I'm wondering if the LLM be able to tell me some commonality or set of bytes that seems to be related and see if I can't target some sort of pattern. |
Oh I was asking if it is possible yet. Myself I have a setup where I pass all the USB data between two MCUs. One handles the controller side and the other the console side. Altering anything from a DS5 will make the PS5 disconnect the controller after like 1 second, I was able to alter like 30 packets and let 1 unaltered through and not have the PS5 disconnect the controller but it seems like the console will completly disregard every altered packet anyways. Currently I am looking at the newest besavior adapter which works with a PS5 and as far as I can tell it simply uses a generic (or maybe not so generic, I dont know yet) HID controller which for whatever reason works with a PS5. I am now trying to implement that in my setup and pass the data from a DS5 into this HID controller instead. I dont have anything working yet but I hope I can test this new setup soon.
That is actually something I was planning to do next too, but not with an LLM (I dont think LLMs will be useful here but maybe Im wrong) but with a custom model which can be trained on altered and unaltered data because I can easly generet tens of thousends of USB packets from a real controller. The only problem would be, even if the model figures out the code, I wont be able to impelement this on a regular MCU. |
|
Another solution might be the Playstation 5 adaptive controller. Or the PSVR2 controller hib which MCU was dumped. Since it allows for input as well from the VR controllers. |
I hope I don't sound like an idiot. I'm only halfway past fisher price babys first device descriptor. The only way you could really know what they're doing is to get debug on the console and see how it's detecting it. I figured myself there's a back channel. I want to say EP82 is doing a ton of isync transfer and this has to be how it knows? EP84 does the regular writes. LLMs fill in the blank right? They do "what comes next". If you train an LLM with all the time coupled streams, it might be able to identify, one, at the very least what bytes need to be changed to match if not outright being able to generate them. Or it's doing funky encryption which will probably be beyond me, but who knows. I'm figuring out some cool stuff these days. I read the besavior uses cloned razer chips. It's actually illegal? They probably just don't care. |
I tried to identify one of the Besavior chips but the chip markings are scratched off. Where did you find this info? The authentication goes through a PEM certificate. That's how GP2040-CE does it. |
|
Yeah but the auth isn't the problem. We can pass that through just fine. Somehow it knows that the original stream was tampered with and that's just raw bytes. There HAS to be some sort of nonce, hash, something that is being communicated on a back channel that says the inital stream has been tampered with. There's just no other way.
I tried finding it again. I wanna say I read that on some random forum, and then it was pretty much verified by some manager from the Besavior forums saying something like "you think they would block razer?". The other thing I'm looking into is the mod packs you can buy and unless they're going to chip the controller components, see if I can mod the stick with some sort of analog over air type of concept. I've got the besavior coming. I've got the cynthion coming. Mod packs next. |
|
So I made some progress with the Besavior Adapter. Im basically just identifying as the Besavior and the PS5 accepts that and doing so allows me to change the controller inputs in any way I want. I made a little script to press some buttons and move the sticks to test it. So compared to passing through the DS5 and then changing inputs, is does not know anything has be altered and keeps accepting the inputs. However this only works for like 30-60 seconds because the PS5 is sending its authentication sequence which I can't answer. I looked at the sequence from the original DS5 controller and compared it with the besavior adapter and it looks the same:
So I thought I could only passthough these questions and answers to the original DS5 and I do get answers from the DS5 but it is not accepted, instead of passing it, it repeats the sequence a bunch of times and then stops accepting the inputs. I only get this far in the sequence:
So I guess the last two reports are for when you can pass the authentication. This approach allows to change input data for quite some time but still stops working after a little bit, where as the DS5 passthorugh approach can pass the sequence but you can't change the input data even for a second. It seems like the PS5 knows it is not talking to a DS5 and has slightly different data or something. I am trying to see if you can make the PS5 send the same sequence it would send to the DS5 normally, because this should be answerable. One curios thing with the Besavior adapter is one "Get Feature Report [ID 3]" request right after initialisation that I dont know what it is for. I cant pass it to the DS5 because it does not know to answer this, but the PS5 needs this. |
|
Try to capture from a Brook Gaming FGC. It does seem to work on ps5 without passthrough auth. Not sure why https://x.com/tsongihy/status/1842086430488895872?t=uDajns1icJPMtwXlu3M7SQ&s=19 |
You can’t buy this yet correct? I will definitely buy one when it’s out. But it has no passthrough auth means the PS5 does not ask any of its questions at all? Because the Besavior doesn’t passthrough anything as well, it just knows how to answer it itself. But if the brook does not need to answer any of these sequences and the rest works the same way as the besavior then it should just work, but that would totally open the floodgates for third party controllers, which would be great though. |
|
According to their product manager the Cronus Zen does ask for an auth controller but their FGC solution does not. Brook doesn't have the best track record in keeping up with firmware updates though. They simply throw the product in the bin, release a v2 with slightly different firmware. I understand that firmware development isn't free as in beer but if you buy one of their adapters now for 50 it might not work in the future. The only way is to reverse engineer it and hope the ps5 firmware does not patch it? Or mimic the dualsense perfectly? I'm hoping Cronus has not stopped development but I have a hard time telling myself that they will fix it. Their last patch was a minor one. |
|
I mean we do have some solutions available now. I think I will get the FGC2 when it’s out and I will also get a Cronus Zen. Maybe something can be learned by comparing the Besavior, Zen and FGC2 solutions. I might also get a Razer Controller to see if the Besavior is indeed using the same chip. |
|
i've been following this thread for a while and i just noticed mayflash f700 hasn't been mentioned yet, it claims to support astro's playroom so presumably it's emulating ds5: https://www.mayflash.com/FAQ/MAYFLASH_F700_PS5_Games_Compatibility_List.html |
|
I got the Razer PS5 Controller and got some observations now. First I couldn't even use my sniffer with it, it always crashed when I connect the controller. The only solution was to connect a USB Hub to the sniffer and connect the controller to that. The one thing I wanted to really look at is the one "Get Feature Report" request with ID 0x03. This one does not exist in the original DS5 controller but the PS5 asks for this report when I connect the Besavior Adapter and I also see it with the Razer controller. And not only that but the answer from the controller is a 48 byte report that never changes and is identical to the Besavior one. It seems like third party controllers or specifically Razer identifies with this report. This could possibly explain why I can not pass the auth sequnence to the DS5 when I try I emulate the besavior adapter, instead I might have to pass it to the Razer controller instead. I wanted to test this next but sadly I can't connect the controller with the hub to my adapter and without the hub it doesn work. But this indicates that the auth sequence is different for third parties. I also got the chronus zen now and want to take a look at that and see if they do something different. So far it looks like the rumors might be true and the besavior somehow uses the actual razer controller MCU. @inakilbss I might take a look at this one when Im done with the chronus zen but it looks like the none fighting games list is very limited, so they probably are not really emulating the full Dualsense here. |
|
@Glomby true, the f700 can't input right stick, touch or motion, but i'd be surprised if the protection behaved differently for each kind of input, and partial emulation is better than none anyway |
|
checked mayflash's offerings again, they've released a version of the f700 that supports xbox series instead of ps5, rather than adding to the existing support |
|
@Glomby Can you use the same sniffer on the Brook Wingman FGC2 and XB3 also? |
Yes I already have the FGC2 on order and will definitly take alook at it as soon as I get it. I'm also still not done with checking out the chronus zen but I already have one here. |
|
I'm eager to learn why Cronus team goes the route of Remote Play again (like Besavior did before) with their new Cronus Link. When the cheaper U5 works. I mean Cronus can do that do and their chip might be not as powerfull as the Titan Two but it should be able to do Dualsense emulation? |
|
According to infomation from leaked PS5 tools(Dualsense_checker), the last 8 bytes in inputReport is aes-cmac. |
|
Dualsense checker has more information for investigation I'm sure about it. |
|
Hi @smartcharge and everybody here, |
|
Sadly at some point in the last year it appears Sony has FORCED dualsense controller firmware updates (I guess via a system OS update). Only choice on non updated controllers is to Turn off controller, or update 😞 This is an uphill battle (screenshot for proof)
|
|
The firmware string might be spoofable. Dualsense checker just checks for a version number. |
|
I'm lost in the thread. I'm finishing some stuff up and the I have to get a job or something idk. I don't think this was published when I made my comment so that's fun This is up my ally. I have a cynthion from greatscott gadgets, and various raw gadget write ups. Dump all the byte streams, train the llm, let it tell you what comes next. I have no idea the scope or training requirements of their models. I'm finishing up some vision space stuff and idk what I'm doing then. I need to apply for funding for my company. It's just unlikely ya know? But if that happens I keep going and I pull that apart next. |
|
The other thing I wanted to explore was that aes-cmac. What is that? Is it fancy, you only got so many bytes. All the auto guys figured this stuff out hacking the ECU's. There's repos out there. What is it called? iv duping? Is that the same concept? |
Probably just from Crypto.Hash import CMAC
from Crypto.Cipher import AES
cobj = CMAC.new(either_preshared_negotiated_or_derived_key, ciphermod=AES) # Once or every report
cobj.update(input_report[:16])
input_report[-8:] = cobj.digest()[:8] |
and others
Some quick information about it:
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.SET 0xf4,GET 0xf5response changes from initial0000to0111(after 10xf4) then0103.The trace on auth
The HID descriptor and lsusb -vd
Real interactions coming soon after I or someone else got the PS5.
The text was updated successfully, but these errors were encountered: