Posts

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

Bluetooth latency issues

As the PS4 only supports bluetooth controls, I decided to work on the latency issues that occur when controlling a PS3 over bluetooth with GIMX:

  • Latency when using a slim/superslim PS3 and GIMX in Ubuntu 12.04+.
  • Latency when using a bluetooth headset or several controllers at the same time.

As I only had a fat PS3, I had to get a slim PS3. I bought one with a defective blu-ray lens for 60€ (about 80$).

I discovered several problems:

  • A change in the Linux 3.1 kernel: the bluetooth transmitter was forced to go into the active mode instead of remaining in the sniff mode.
  • Bluetooth packets not properly synced: the IN report has to be sent immediately after receiving the OUT report.

These problems are both related to the bluetooth sniff mode, which is used to reduce the power consumption.
To simplify, each device in the piconet is active during a fixed window:

X+0 - the master sends a packet to slave 1
X+1 - slave 1 sends a packet to the master and reduces its power till its Tsniff period is over (11250µs)
X+2 - the master sends a packet to slave 2
X+3 - slave 2 sends a packet to the master and reduces its power till its Tsniff period is over (11250µs)
...
X+18 - the master sends a packet to slave 1
...

The master sends OUT reports, and the slaves IN reports.
If an IN report is not sent at the right time, it gets retransmitted later.
If the IN report period is slightly lower than the OUT report period, the IN reports will be gradually buffered, thus generating a latency that slowly increases.

The current GIMX design can’t guarantee that the IN reports are sent in the right slot, because the OS can interrupt the program and schedule another task.

The following improvements could be made:

  • Merge emu and emuclient: this would prevent the kernel from interrupting emu to run emuclient (this can happen just after receiving an OUT report and before sending the IN report…). This would improve GIMX performances especially on single core CPUs (like the Raspberry Pi). This would still not ensure a 100% perfect sync, but I believe this is the only possible improvement without adding extra hardware.
  • Handle the Bluetooth protocol with a DIY adapter: PC —USB— AVR USB —UART— BT module —BT— PS3.