Keyboard and Mouse for PlayStation 4 Games (second prototype)

Why did you do this?

I like playing shooter games on PC but my laptop is too weak to play them. Game consoles do not support USB keyboards and USB mouse, they only support gamepads. Gamepad controls are not suitable for shooter games, using a keyboard and mouse is much more comfortable for gameplay.

How does it work?

I designed a circuit that features a microcontroller and USB hub. The keyboard and mouse plugs into the USB hub, and then the microcontroller takes the data from the keyboard and mouse, translates them to the data format used by the PlayStation 4. It does the translation in a way as though the mouse was the right thumbstick, and the keys are mapped to buttons (the WASD keys are mapped to the left thumbstick).









Development Story

I wanted to share this story because I am very happy that I finally managed to get this far! Anybody who is attempting this and thought it was impossible to do can now breath a sigh of relief because it definitely can be done.

I have already accomplished a similar project that worked with a PS3 (UsbXlater), something that connected to the PS3 via USB that translated keyboard and mouse data format to gamepad data format.

Once the PS4 launched, I reversed engineered the USB protocol used by the DualShock, and then attempted the same technique. But… … it didn’t work, after trying a few tricks, it still didn’t work.

I started talking with people who are working on similar projects, such as Matlo from GIMX.fr and the creators of XIM. None of us could get PS4 to respond to data coming from USB. What we did was use my circuit as a “proxy”, transparently passing the USB data such that the USB traffic replicated traffic between the PlayStation and DualShock exactly, except with only minor modifications to the bytes that represent the button presses. It did not work, it seemed like only wireless traffic was used by the PlayStation, not USB traffic.

In my reverse engineering, I discovered (by poking around the circuit using an oscilloscope) that the DualShock’s circuit exposes two signals that are actually the UART signals between a Bluetooth module and the DualShock’s microcontroller. I soldered some wires to these signal and determined that it is using H4 HCI over UART at 3 Mbit/s. I connected these signals to my logic analyzer to capture the UART traffic, logged it, and wrote a script to reformat the log into pcap format so the traffic can be analyzed using WireShark (which actually have specific analysis for H4 HCI).

Through this, I learned about how the Bluetooth pairing procedure works. The Bluetooth link key (pretend it’s a 16 byte long pairing code) is the next challenge. But it turns out, the link key is actually exchanged during USB enumeration. I noticed this because I noticed a chunk of bytes that looked random in the USB enumeration traffic, which gave me a hunch to check if it was the same bytes as the link key. So to obtain a link key, my circuit is connected to the PS4 via USB first. That’s how the Bluetooth pairing security problem was solved.

At this point, I wrote a bit of firmware code that allowed me to store things in flash memory. I also implemented wear leveling. The Bluetooth link keys and addresses can now be stored in flash memory, so the user only needs to obtain them once, not every time.

I also noticed 4 bytes of random-looking data appended to every packet, after a few checks, it turns out that these are just a 32 bit CRC that is not a part of official Bluetooth specifications, so Sony must have added them just to be safe. If this was a cryptographic hash or if the CRC used a different seed or used a different polynomial, then spoofing the packets would be much more difficult (impossible to somebody without cryptography skills).

At this point, I had to make a modification to my own circuit so that it included a Bluetooth module. I had several choices but eventually settled on using a common USB Bluetooth dongle (Advantages: fast, certified, cheap. Disadvantage: occupies a USB port. Read about my bad experience with RN-42).

Then I tried to program my own Bluetooth stack firmware (I had to literally learn the entire Bluetooth spec). I almost finished writing one but I was not happy with how complicated it needed to become in order to handle all possible situations. I decided to utilize an open source Bluetooth stack instead, named BTstack. I had to reimplement my USB transport layer for it and make some tweaks to it, but it does the job well enough right now.

While I was doing this, Matlo is way ahead of me and he already tried to send data to the PS4 via Bluetooth. However the PS4 is ignoring his data and we are both wondering why. Matlo noticed that some very infrequent traffic that we did not understand. This turns out to be the challenges and responses of the authentication procedure. We did not know how to generate the responses (the challenges are 256 bytes of random data, we did not have the cryptography expertise to even start attempting to defeat it). Matlo created a tool called l2cap_proxy that replayed all traffic between two devices exactly. It worked, which is how we discovered the vulnerability that my circuit exploits. (Sony engineers forgot to include a digital signature, if the encryption depended on the Bluetooth address in some way, then the proxy attack would not have worked.)

This means that a real DualShock is required to be connected over Bluetooth at all times, because the PlayStation never actually stops requesting authentication. This is a bit inconvenient. The traffic over Bluetooth is so high that Matlo noticed that his computer will sometimes miss packets. This is a problem if Matlo wants his code working on a small platform such as the Raspberry Pi. The Bluetooth L2CAP traffic still uses the HID PSM so all of the traffic look similar to USB traffic, and the report IDs being used are the same. So I conducted an experiment (using PyUSB) to feed the challenges to the DualShock by USB instead of Bluetooth, then attempt to read the response by USB. It didn’t work, the responses came back all zeros, so that didn’t work, which was disappointing.

The traffic is so high that my own circuit can’t keep up either, I had to prioritize my FIFOs so the important authentication packets are guaranteed to be delivered, the other stuff have 80% chance of being re-routed correctly. When the low priority FIFO gets filled to capacity, packets are lost.

So The final stretch was to code my firmware to work like Matlo’s proxy, except the packets that needed to be modified with new button bytes thumbstick bytes. Since some packets are modified, the CRC need to be recalculated, which is done easily because the STM32 microcontroller I am using has a CRC engine already (which is faster than software implemented CRC).

At one point in this story, the UsbXlater circuit had to be redesigned to include the USB hub. The original USB stack (provided by ST) had to be re-written to provide support for hubs. This took a huge chunk of time as well.

The project is open source, see the UsbXlater github repo for now, it’s not perfect though, there’s still a lot to be done.

I need to redesign the circuit, it needs a 4 port hub instead of 3, and I need to swap the two USB interfaces (the HS interface has 12 host channels and the FS interface has only 8, I need to use the HS interface for the hub). I also need to make a keybinding configuration utility so the control mapping can be adapted to other games.

FAQ for the non-technical people:

This doesn’t sound impressive at all, there are a lot of products out there already that does this for the Xbox 360, Xbox One, and PlayStation 3. What makes this project so special?

The first thing I did was make it work with the PlayStation 3 by spoofing a DualShock 3 connected using the USB connection. This was easy. But the same technique could not be used for the PlayStation 4. The PlayStation 4 seems to ignore data through the USB channel. To overcome this, a USB Bluetooth dongle is connected to my circuit’s USB hub. My firmware spoofs a DualShock 4 over Bluetooth instead of USB.

It sounds too easy still, doesn’t it? Sony implemented a challenge-response authentication procedure. The PlayStation will send an encrypted question to a DualShock, and only a real DualShock will be able to generate the correct answer to the question. If another device attempts to provide a wrong answer, the PlayStation will ignore that device. To overcome this, a DualShock is connected to my circuit, and the questions from the PlayStation are re-routed to the DualShock so that the DualShock tells my circuit the “answer”, and my circuit then re-routes the answer to the PlayStation, thus defeating the authentication.

This is actually an vulnerability, a mistake made by Sony. They forgot to include a digital signature, if the encryption depended on the Bluetooth address in some way, then the proxy attack would not have worked.

I’ve seen some guy solder a DAC/digital-potentiometer inside a DualShock to accomplish this, it sounds much simpler than your method, how is your circuit different?

My circuit is all digital, no analog noise, no input latency from analog-digital conversion, no need to disassemble the DualShock.

How did you trick the DualShock and PlayStation to connect to your circuit instead of each other?

The Bluetooth device address (basically the MAC address) is given to the DualShock first via USB. You connect the DualShock to my circuit to do this step. The link key is also given to the DualShock this way (a link key is similar to a pairing code, but not exactly).

The Bluetooth device address and link key of the PlayStation is also obtained by connecting my circuit to the PlayStation by a USB cable. My circuit goes into USB device mode that pretends to be a DualShock to accomplish this.

All of this information is stored in flash memory so it only needs to be done once.

What about the touch pad and motion sensors?

Since the traffic is being “proxied”, the DualShock still works as the input device, the keyboard and mouse input is mixed in. This means the touch pad data and motion data are not modified, so the DualShock still works. Because of my proxy technique, the LED colours and vibration data are not modified so they still work in games.

But nothing is stopping me from modifying the touch pad and motion data. I just didn’t have time.

What about audio?

The DualShock uses HID for audio, which is weird. I expected A2DP to be used for audio but apparently the audio data is mixed in with the HID data. I don’t know why. As I have mentioned before, there are packets being lost, which means audio data will be lost. Hence, audio does not work with my circuit, sorry. It’s simply too much data to process on a microcontroller (and Matlo had trouble with the data rate even on a full PC).

How did I remove acceleration from the thumbstick controls?

I took a video of BF4′s minimap spinning at different speeds, plot that speed vs stick curve, flip the curve to generate a look-up-table.

How about the Hori Pad? It works over USB, how come your circuit can’t?

I have no idea how they do it, but since the Hori Pad is an official Sony licensed product, Sony can make some sort of exception for it in the PS4′s operating system. I purchased a Hori Pad and I will reverse engineer it once I get it.

Have you attempted to look inside the DualShock’s firmware?

No, I have not. I did see two test points on the DualShock’s PCB that may have been the SWDIO and SWCLK pins for a SWD interface, but if Sony locked the firmware and I attempted to read it, it would cause the microcontroller to wipe itself (self destruct the firmware). It would brick the DualShock and make me waste $60.

What tools did you use to analyze the USB traffic and Bluetooth traffic?

For the USB traffic, I used a Total Phase Beagle USB 12. For Bluetooth, I tried to use an Ubertooth One, but was unsuccessful because it could not perform the neccessary frequency hopping correctly for some reason. However, after the discovery of the H4 HCI UART signals, I didn’t need the Ubertooth because HCI traffic contains all the information I needed (in an unencrypted form too, which is a bonus).

Why does the circuit board look so weird?

It was designed to go into a specific project box (one that is off the shelf).

Where’s the love for Xbox?

I don’t have one… It can totally be done, but Xbox uses WiFi Direct, not Bluetooth.

18 thoughts on “Keyboard and Mouse for PlayStation 4 Games (second prototype)

  1. jacks

    Hi! awesome work you’ve done! i will definately keep some money aside to buy such device. But my question to you is : why you draw Sony’s attention with this? you’re telling us how they failed, they did a mistake, it’s vulnerable etc.

    Knowing them, now they will probably block this vulnerability/mistake in their next update. Or am i wrong?

    Reply
    1. Admin Post author

      It is unlikely for them to patch this vulnerability. To change the way that the encryption works on the DualShock, they would have to do a firmware update on the DualShock.
      Think of how many DualShocks they’ve already manufactured. How many are just sitting on a store shelf or in a warehouse waiting to be sold with a old firmware. Think about how to tell all the customers to perform a firmware update.
      What happens if somebody screws up the update? Power surge, lightning strike, static electricity, cosmic radiation, etc, can cause the firmware update to fail, even if it’s 0.0001%. You get a ton of unhappy people, who might want repairs.
      If you don’t update absolutely 100% of all DualShocks and allow both old and new firmware to work, then people who want to use my hack will just buy one that has the older firmware. Making the new firmware pointless.
      Developing and then testing the new firmware, and then testing the new firmware update process, will not be cheap for Sony either.
      Another thing, the HoriPad is an officially licensed (approved by Sony) 3rd party wired controller for PS4 that has a similar vulnerability. If the DualShock’s vulnerability gets fixed, I can just stop using the DualShock and use a HoriPad instead. Do you think HoriPad will also have firmware updating capabilities? How about all the 3rd party products current in development that we don’t know about yet?

      Reply
  2. PatchAdams

    Hello there, could something similar be done for the 360 with a wired 360 controller? Also could you use a Raspberry pi as the board instead?

    Great project BTW :)

    Reply
    1. Admin Post author

      The Pi can be a USB host but not USB device, how is it going to pretend to be a XB360 controller when you can’t plug it into the XB360? (the USB micro-B connector doesn’t actually have any signals connected, just power)

      So you would need another microcontroller to become the USB device, and somehow also listening to the Pi for commands. This can be done by either getting a microcontroller with two USB device interfaces (one for the Pi, one for the Xbox), or use the serial port of the Pi.

      If you get a microcontroller that has two USB interfaces anyways, then what is the point of using the Raspberry Pi anymore? The microcontroller can just do everything, and with less latency. The only advantage the Raspberry Pi has is that it has video output that might make reconfiguring it easier.

      Reply
  3. PatchAdams

    Thanks for the answer, that makes sense. Iv’e been looking for a cheap solution to get a Mouse/Keyboard working on my 360 and thought since I already had a Pi here I hoped it could be used instead :P
    I read about Gimx a while ago but wasn’t sure if it worked on Windows or not and Xim is too expensive for me :)

    Reply
  4. VeRrUeCkTeR_IWAN

    Hey,
    I really like the idea for this adapter.

    My question is:
    Would it be possible to use a smartphone instead of your board?
    Mordern smartphones have Bluetooth and UTG (Usb-to-Go), so you can plug in a n USB hub to use your mouse and keyboard and still be able to connect it with your playstation and your controller (as long as you need a controller for the authentication code)

    Reply
    1. Admin Post author

      It is certainly possible. I am not sure how much access you have to the deeper Bluetooth and USB stuff on Android or iOS. That is the main challenge.

      I am not sure if the latency will be acceptable.

      But projects like GIMX can run on small embedded platforms like the Raspberry Pi.

      Reply
  5. leo_ck

    Hey great work on this! I just received my ps4 and I found your page from hackaday. Congratz for your success!

    I have a question is it possible to run this thru the STM32 Nucleo STM32F401 series? Because I have 2 of them laying around. I would love to support your project!

    Reply
    1. Admin Post author

      Yes, it can be done, but it’ll need some changes. Your F401 only has one USB interface, which you will use as a host to use the keyboard, mouse, and the Bluetooth module. This means you don’t have a USB device interface, which is needed to retrieve the link key from the PS4.

      You can get around this in two ways, one way is to manually pair with the PS4 using the PS4′s menu, which is super annoying. The other way is to have the USB interface switch between host and device roles, so it retrieves the link key once and then store it for use later.

      Reply
      1. leo_ck

        Wouldn’t switching between the roles slow down the process? Because I read your post stating that “because the PlayStation never actually stops requesting authentication. This is a bit inconvenient.” So I was probably thinking that switching the roles every single time would cause a some delay. What about increasing the number of usb by using some usb host controller like MAX3421E?

        Reply
        1. Admin Post author

          You would only need to switch roles once, because you only need the link key once, it never changes. The authentication is different, it sends a different challenge every time, but you don’t need to change USB roles for authentication because it is transmitted over Bluetooth.

          Reply
  6. spig

    I really wish I had any idea how to do this, I love my console but hate controllers so much. I really hope that you sell this or sell manuals on how to DIY or someone sells something that will make this a reality for the rest of us :)

    Awesome work.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>