Category: PS4

Posted on

GIMX PS4 support – status 4

GIMX is now able to talk to a PS4 🙂

I worked on adding bluetooth proxy capabilities to GIMX. Before connecting to the PS4, GIMX waits for a Dualshock 4 to connect. Then it forwards HID control transfers, and it directly handles SDP and HID interrupt transfers.

I had to solve an issue with the SDP: the DS4 sends a 708-byte service attribute search response, which is larger than the 672-byte outgoing L2CAP MTU. As the Linux kernel rightly refuses to send L2CAP packets larger than the outgoing L2CAP MTU, I had to go to a lower level in the bluetooth stack so as to directly send ACL packets.

I now have to see how to achieve a high packet rate (800 packets per second). It seems a single bluetooth dongle will not be enough to handle twice this packet rate (from the DS4 + to the PS4).

Posted on

GIMX PS4 support – status 3

I kept working on the bluetooth protocol and I found that there is an authentication process carried over the HID control channel. It consists in a sequence of bluetooth transfers that lasts about 30 seconds, and that restarts after 30 seconds. If this sequence fails 8 times in a row, the PS4 stops taking inputs.

This means GIMX will require a genuine Dualshock 4 to control a PS4. It will have to stay connected as the authentication sequence is periodical.

I also worked on writing an AVR USB firmware that can emulate the pairing procedure of the Dualshock 4. It allows to pair any bluetooth device address with the PS4. I spent more time than I thought on this because of a problem in the USB transfers that only seems to happen with the PS4 as USB host. Frank from eleccelerator helped me to fix this issue.

This firmware is designed to work with a tool called ds4tool that can do the following tasks:

  • read the bluetooth device address from a real or emulated DS4
  • read the PS4 address from a real or emulated DS4
  • write the PS4 address and the link key of a real or emulated DS4
  • write the bluetooth device address of an emulated DS4
  • read the link key from an emulated DS4
Posted on

GIMX PS4 support – status 2

My current task consists in reverse engineering the Bluetooth HID protocol used by the PS4 and the DS4. I’m sharing the result of this work on the DS4 page of Frank’s wiki. This is not a trivial task but I made it easier since I have a L2CAP proxy that allows man-in-the-middle operations, like skipping specific transfers or modifying specific bytes within specific transfers.

The most difficult transfers to understand are those that are carried over the HID control channel (SET and FEATURE reports). The transfers that are carried over the HID interrupt channel are easier to understand: input reports carry axes and buttons states from the DS4 to the PS4, and output reports carry rumble, led and audio data from the PS4 to the PS4.

This work will eventually allow to cleanly implement the DS4 protocol in GIMX.

Posted on

GIMX PS4 support – status 1

The HCI UART captures reveal the use of bluetooth authentication, which is based on a shared secret between both between the PS4 and the DS4. This shared secret is called the link key and is the result of the pairing. The link key can be seen plain-text in the HCI UART traffic. Knowing both the bluetooth device address and its associated link key is enough to spoof a DS4.

I managed to talk to a PS4 using a bluetooth proxy that I’m sharing in my git repository. This bluetooth proxy can forward the traffic between a DS4 and a PS4, using two bluetooth dongles. I also was able to modify the reports sent to the PS4. The only thing to do is to modify the desired axes and buttons, and update the last four bytes which are a CRC32 of the first 75 bytes.

Extracting the link key from a DS4 is fortunately not the only way to get a valid link key. Frank from eleccelerator discovered that the link key is sent over USB the first time the DS4 is wired to the PS4. Which means it should be possible to get a valid link key for any bluetooth device address, using a USB development board (a teensy for example) running a firmware emulating a DS4. It seems it should also be possible to use a standard bluetooth pairing: the DS4 can be turned into a discoverable device holding the share button and PS button at the same time, and then paired using the PS4 UI.

Posted on

HCI UART sniffer

These last days I have developed a tool to sniff the UART of the Bluetooth module that is located inside a DS4 controller. Credit goes to Frank from eleccelerator for finding the UART, the test points, and the transmission parameters.

The following picture shows the test points:
hci uart test points
The blue wire is Gnd, and the others are Rx & Tx.

Knowing the UART transmission parameters (8N1, 3Mbps), it is possible to sniff the traffic using the Rx lines of two USB to UART adapters. CP2102-based adapters only support baudrates up to 2Mbps, but FT232RL-based adapters support up to 3Mbps.

The following picture shows two FT232RL adapters (one is a duemilanove arduino with the AVR chip removed) connected to a DS4:
ft232rl uarts

I wrote a tool that reads the data coming from the adapters. It translates a byte stream into a packet stream according to the HCI transport specification. It can either write the packets into a capture file that can be opened with wireshark, or write them to its standard output, so that it can feed the standard input of wireshark for a live display.

hci uart wireshark

The only drawback of this method compared to logic probes is that it can’t give precise timestamps, and it can’t guarantee that the packets are in the right order.

Posted on

The PS4 is not taking inputs from USB devices…

Good news: the goal of $550 was reached!

Sadly, it turns out I won’t be able to reach the initial goal which was to create a firmware for the DIY USB adapter. The reason for this is that the PS4 is not taking inputs from USB devices: it only takes inputs from the bluetooth side. This was confirmed by the developer of the USBXlater and the developer of the XIM.

Nonetheless, I should be able to make GIMX talk to the PS4 over bluetooth, using a cheap dongle. My plan is to make it work in Linux first as the bluetooth stack is much more opened on this platform (which means faster development). I’ll try to make it work on Windows in a second step. It should work in a virtual machine in the meantime.

Since the initial goal will not be reachable in the near future (Sony may allow USB controllers some day…), I am ready to make a refund. The early fundraisers have two weeks to ask for it.

Posted on

Fundraising for GIMX PS4 / Xbox One support

As I can’t afford buying both the PS4 and the Xbox One, I started a fundraising for GIMX PS4 / Xbox One support.
The initial goal will be to build two firmwares for the DIY USB adapter, one for the PS4, and the other for the Xbox One.
Bluetooth support for the PS4 will be optional.
If you want to donate you can click on the links below:

UPDATE 2015-04-21:

I bought a second-hand Xbox One for 300€, so I’m updating the funding goal for the Xbox One. Xbox One support should land in GIMX 4.0, which I’ll try to release before the end of the month. Please keep donating to reach the funding goal!

UPDATE 2014-07-29:

I’m updating the funding goal for the Xbox One since there is a cheaper bundle with no Kinect.

UPDATE 2014-01-08:

I received my PS4 earlier than expected 🙂

UPDATE 2014-01-03:

I canceled my order and bought a PS4 Killzone pack that I should receive on 01/13/2014.

UPDATE 2013-11-30:

I ordered a PS4 on Amazon. I have no precise delivery date. Amazon is saying “not before January”.

UPDATE 2013-11-25:

Bad news: according to the developer of the USBXlater and the developer of the XIM, the PS4 isn’t taking inputs from USB devices. Since I will not be able to make GIMX talk to the PS4 over USB, I will try over bluetooth.

I will not be able to reach the initial goal which was to build a firmware for the DIY USB adapter. If you are an early fundraiser (i.e. you donated before today – 2013-11-25), you can ask for a refund within two weeks (you should receive a mail from me later today).