Full Report
Ciao belli! On the 19th of November 2020, SONY finally released the new PlayStation 5 in the UK. A few days earlier in the US, Japan, and Canada. Of course, Play Station 5 came together with a new Wireless Controller, this time named DualSense. I wanted to see if I could continue my PlayStation controller adventures on this new device, following on my previous work. A few SONY installations available in London for the release of the PlayStation 5. DualSense Wireless Controller The DualSense Wireless Controller presents new features such as:
Analysis Summary
# Research: DualSense Reverse Engineering
## Metadata
- Authors: Emmanuel Cristofaro
- Institution: SensePost (implied by blog source)
- Publication: SensePost Blog
- Date: November 23, 2020
## Abstract
This analysis details the initial reverse engineering efforts conducted on the Sony PlayStation 5 DualSense Wireless Controller (Model CFI-ZCT1W) shortly after its release. The research focuses on understanding the USB Human Interface Device (HID) communication protocol to enable programmatic interaction with the controller's features, specifically for repurposing it within the existing "Dual-Pod-Shock" multimedia/actuator control framework previously developed for the DualShock 4. Key activities included hardware teardown, capturing and decoding HID input reports, and developing a proof-of-concept (PoC) to send output reports to control built-in capabilities such as the speaker, actuators (haptics), and LEDs.
## Research Objective
The primary objective was to explore the connectivity and control mechanisms of the new Sony DualSense controller, specifically continuing prior work on using PlayStation controllers to interact with custom systems (e.g., controlling media playback or mechanical actuators via controller inputs). The implicit question was: How does the DualSense communicate over USB, and can its new features (haptics, speaker, LEDs) be controlled programmatically based on physical input?
## Methodology
### Approach
1. **Hardware Analysis:** Physical teardown of the DualSense controller to identify key components.
2. **Protocol Capture & Analysis:** Connecting the controller via USB and reading raw HID reports sent from the device during specific user interactions (e.g., button presses).
3. **Input Decoding:** Mapping specific bytes within the raw HID reports to corresponding physical inputs (buttons).
4. **Output Control Development:** Iteratively sending arbitrary byte sequences (output reports) to the device via USB to trigger specific functionalities (LEDs, actuators, speaker control).
5. **Feature Integration:** Updating the existing "Dual-Pod-Shock" project to utilize the newly mapped inputs and outputs of the DualSense.
### Dataset/Environment
* Sony DualSense Wireless Controller (Model CFI-ZCT1W).
* Host machine running Linux (tested on Ubuntu 16.04 and Raspberry Pi OS).
* USB connection for host interaction.
### Tools & Technologies
* Custom C code utilizing standard file operations (`open`, `read`, `write`) on Linux device files (specifically `/dev/hidraw0`).
* GStreamer pipeline utilities (`gst-launch-1.0`) for audio encoding/transcoding.
* SBC codec generation tools (using `sbcenc`).
## Key Findings
### Primary Results
1. **Input Report Mapping:** The controller transmits HID reports over USB. Specific face buttons (Square, Cross/Exe, Circle, Triangle) were reliably mapped to a specific byte (byte 8) whose value changed upon activation (e.g., Square $\rightarrow$ `0x18`, Cross $\rightarrow$ `0x28`).
2. **Feature Control Achieved:** The author successfully developed a PoC to send output reports to control the controller’s internal speaker, actuators (haptics), and LEDs based on intercepted button presses.
3. **Stereo Speaker Functionality:** Unlike the previous DualShock 4 (which utilized Mono sound), the DualSense speaker functions in Stereo mode when connected via USB.
4. **Bluetooth Audio Encoding:** To output music via Bluetooth, raw MP3 files needed to be converted into SBC files using GStreamer, with specific SBC header settings (`rate=32000,channels=2,channel-mode=dual,blocks=16,subbands=8,allocation-method=snr`) required for stable playback. The change from the 'loudness' to the 'snr' allocation method improved audio quality.
### Supporting Evidence
* Code snippets demonstrating the raw reading of HID reports from `/dev/hidraw0`.
* Specific hexadecimal values associated with button presses (e.g., Circle $\rightarrow$ `0x48`).
* A table detailing the output commands sent to control actuators and set LED colors based on button presses (e.g., Square maps to Volume Decrease and sets LED to a blue tint: R: FF, G: 14, B: 93).
* The resulting functional demonstration video/image showing the PoC running.
### Novel Contributions
* The foundational decoding of the minimal USB HID input structure for the DualSense controller.
* The first documented method for actively sending output commands via USB to trigger the DualSense's new haptic actuators and onboard speaker functionality.
* Optimization guidance for generating stable SBC audio stream files for Bluetooth transmission via the controller's audio pathway.
## Technical Details
The research method relied on examining the raw binary data stream. The author used a character array buffer to read data from the device file descriptor. The key technical discovery regarding input was the consistent byte mapping for face buttons within the HID reports. For output control, the researcher crafted arbitrary byte sequences and wrote them back to the device file descriptor, observing which sequences triggered actuation, LED changes, or speaker output. The successful audio streaming relied on precise configuration of the SBC encoder parameters, specifically manipulating the SBC header structure (which involved changing bytes from `9c 75 19` to `9c 77 19` as indicated by the header change noted).
## Practical Implications
### For Security Practitioners
* **Device Re-purposing:** Demonstrates that complex, modern input/output devices can often be quickly reverse-engineered via standard USB HID interfaces, allowing for non-standard application use outside official SDKs.
* **Attack Surface Identification:** Understanding the direct control mechanisms over sensory outputs (haptics, speaker, LEDs) is crucial for assessing potential misuse vectors if physical USB access to the device is ever gained in a compromised environment.
### For Defenders
* **Input Validation:** If an application relies on standard controller input, it should be aware that the underlying hardware interface is accessible via raw HID, bypassing higher-level driver abstractions.
* **Firmware Monitoring:** Initial USB interactions are low-level and unauthenticated, highlighting the importance of monitoring unexpected raw HID traffic emanating from or destined for peripherals.
### For Researchers
* **Protocol Expansion:** This work only scratches the surface of the output report structure. Further research is needed to fully map commands for the new Haptic feedback (actuators) and Adaptive Triggers, which likely involve more complex report structures than simple button mapping.
* **Bluetooth Stack Analysis:** Further analysis of the underlying Bluetooth audio stack negotiation used by the PS5 firmware would be beneficial for achieving higher fidelity or lower latency audio output.
## Limitations
* The analysis focused primarily on USB connectivity; wireless (Bluetooth) control mechanisms were not detailed.
* The research only decoded input for the face buttons; full mapping of shoulder buttons, analog sticks, and the microphone remained incomplete.
* The control over the advanced **Adaptive Triggers** feature was not explicitly detailed, suggesting the current output mechanism might not fully support that feature yet.
* The note mentions potential issues regarding CRC32 checks or the need for kernel patching, implying that sustained or complex operations might require deeper driver integration or awareness of integrity checks not explicitly implemented in the PoC.
## Comparison to Prior Work
This research directly builds upon the author’s previous work with the DualShock 4 (DS4). The primary difference is the necessity of re-learning the entire communication protocol, as the DualSense features significant internal hardware changes (e.g., actuators replacing rumble motors, stereo speaker). While the DS4 provided a foundational concept for controller exploitation/repurposing, the DualSense required completely new HID decoding and output command generation.
## Real-world Applications
* **Custom Control Interfaces:** Using the DualSense as an affordable, feature-rich custom input device for industrial control panels or specialized workstations.
* **Interactive Art/Installation:** Leveraging the high-fidelity haptics and speaker for immersive, low-cost kinetic feedback systems.
* **Security PoCs:** Demonstrating physical access compromise leading to sensory output manipulation on commonly deployed gaming hardware.
## Future Work
* Complete reverse engineering of the full HID output report structure to control Adaptive Triggers and fine-grained haptic intensity.
* Investigation into secure or proprietary communication methods used over Bluetooth.
* Developing a stable, cross-platform library for DualSense interaction.
## References
* Previous work on DualShock 4 control: Referenced implicitly via links to the "Dual-Pod-Shock" project.
* GitHub repository containing the finalized PoC code (`sensepost/dual-pod-shock`).