GIMX stands for Game Input MultipleXer or Game Input MatriX. The purpose of this software is to control a video game console with a PC. It works with the PS3 and the Xbox 360.
¤ over bluetooth: works with Linux (PS3) only. A compatible bluetooth dongle is required.
¤ over usb: works with Linux and Windows (PS3, 360). A USB adapter is required.
The application gets data from the PC peripherals (mice, keyboards and joysticks) and sends controls to the PS3 over bluetooth or usb. Other controls such as gesture or voice are possible through the use of external software that emulate PC peripherals.
Fundraising for PS4/Xbox One support: http://blog.gimx.fr/fundraising-for-gimx-ps4-xbox-one-support/
I pushed gimx-config & gimx-fpsconfig updates in the git repository.
In gimx-config, there is a new “Type” menu that allows to change the controller type. Setting the right controller type allows to display controller-specific axis and button names.
I will now work on merging gimx-serial and gimx-bluetooth in a unified launcher that will also support the PS4.
I pushed touchpad support in the git repository.
People that already cloned the source can run the following commands to update GIMX:
sudo make install
I wrote a configuration for KillZone Shadow Fall that showcases this touchpad support. It can be downloaded via gimx-serial or gimx-bluetooth, using the “Help>Get Configs” menu (the file is named PS4_KillZoneShadowFall.xml). Key ‘f’ controls finger presence and the mouse axes control finger coordinates.
I will now work on updating the GUIs.
I managed to send touchpad inputs using a button and two axes (a mouse). The button controls the finger presence, and the axes control the finger coordinates. This allows me to control the drone modes in Killzone! The source code needs some refactoring before landing into the git repository.
A few products (venom x, xim4, titan) have announced PS4 support over USB. They are mixing the USB transfers from the Hori pad and from the DS4. They all lack touchpad support, and there is no evidence touchpad inputs can work over USB.
Things are going slowly. Touchpad support is on its way.
I wrote a helper script to simplify the setup. The PS4 wiki page explains how to use it.
As it may take some time before everything can be run from a GUI, I wrote a few instructions for anyone wanting to try early PS4 support in GIMX.
Those instructions can be read on the wiki.
It may seem quite complex, but once the pairing is done, starting GIMX is as simple as running a single command in a terminal.
GIMX is only able to run at 100Hz for now, I’ll try to improve this later. I’m currently working on adding touchpad support.
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).
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
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.
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.
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:
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:
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.
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.