Monthly Archives: February 2014

Weekly Report February 23 2014

Since the RN42HCI does not support SSP (see previous weekly report post), I’ve switched to using a USB Bluetooth dongle to perform the spoof. This will allow me to get a huge data rate improvement, but at the cost of an USB port. I’ve made massive improvements to the USB host code, and my Total Phase Beagle USB 12 Analyzer really proved itself by telling me exactly how many tokens were sent and how many NAKs were received, which allowed me to gage my maximum sample rate, and see noticeable differences when I make code changes.

But the bad news is that I can only see these tokens and NAK events as “collapsed records”, which means I can see that in the span of 2 seconds, I have gotten X amount of NAK from device A, Y amount from device B. But I can’t see if I get them in the order A B A B or A A B A A B. I’ve contacted Total Phase support about this, and it turns out that their more expensive analyzers support “packet view”. I asked if this was a hardware limitation, they stated that it was not, and I can capture the packets myself if I use their API that they provide. I asked them to update their software to add the support for my model, and they said they’ll pass on the request to their engineers and they’ll consider it.

Progress on the DualShock 4 spoof is great. I managed to get a reliable connection between the DualShock and my UsbXlater circuit via Bluetooth, and my UsbXlater circuit to the PlayStation via Bluetooth. I have a basic man-in-the-middle Bluetooth proxy working completely. The only problem now seems like the PlayStation doesn’t want to take the input yet, although I can see the data being passed, the PlayStation does not respond. The bigger issue is that the data being passed is coming so fast that my monstrous STM32F405RG chip is actually running out of RAM, I need to figure out whether or not this is indeed a performance issue or maybe I’m stupid and caused a memory leak.

Here I have my debug output a millisecond timestamp with the amount of RAM left, then it crashes

8000 FreeRAM 98132
10000 FreeRAM 88364
12000 FreeRAM 80868
14000 FreeRAM 72460
16000 FreeRAM 63092
18000 FreeRAM 53836
20000 FreeRAM 46428
22000 FreeRAM 37364
24000 FreeRAM 27756
26000 FreeRAM 17788
28000 FreeRAM 10068
30000 FreeRAM 716

Exception Handler, source: 1
r0: 0xF0127C08, r1: 0x2000293C, r2: 0x0000000A, r3: 0x0000000A, r12: 0x000002FF
LR: 0x00000000, PC: 0x20002948, PSR: 0xA1000200,

Neat… I’ve worked all weekend on this and got this far, I’m going to take a break and work on something else now. But my next goal is to figure out if I am freeing memory correctly, then maybe improve USB performance even more, and then implement flow control. Once the system doesn’t crash, I can focus on why the PlayStation doesn’t respond.

Weekly Report February 9 2014

I am playing around with BTstack (an open source Bluetooth stack) as a part of my on-going efforts to spoof a DualShock 4. After a bit of coding, I got it compiled into the UsbXlater firmware and now I am testing it.

One huge problem I ran into is that the RN42HCI I purchased from Microchip does not seem to support SSP (simple secure pairing). The Microchip website clearly states that the RN-42 is a “Fully certified Class 2 Bluetooth 2.1 + EDR module”. But using the read_local_version_information and read_local_supported_features commands, it is revealed that it does not support SSP and the version is actually Bluetooth 1.0b.

The PlayStation 4 uses SSP, this means the RN-42 cannot be used. I am hoping that Microchip will owe up to their mistake and either provide a replacement or a firmware update. Meanwhile, I will try doing some hacking to see if I can avoid the pairing problem, and also upgrade my USB stack a bit to see if using a USB BT dongle is still a viable option.

EDIT: According to Microchip tech support: “The current RN42HCI module does not support SSP. Updating the RN42HCI to BT3.0 for SSP support will have implications for our existing RN42HCI customers that do not use SSP.” So I was right, they are falsely advertising the product.

Weekly Report February 2 2014

Spoke too soon about the DualShock 4’s Bluetooth security, although the link level authentication is figured out, it seems like Sony employed a challenge and response authentication mechanism over the HID channel itself. It was hard to spot because it occurs periodically at a slow rate, and it seems to tolerate up to 16 failed attempts before the PlayStation stops responding to an unauthenticated DualShock. 16 failed attempts is 8 minutes, and when I am doing reverse engineering, I only capture a few seconds worth of data. Matlo from GIMX pointed this out to me. Thanks!

This is bad news, the challenge key is huge, cracking it is out of the question. We also tried feeding it the challenge through USB and extracting the response from USB, but the response came back blank, which seems to indicate that the response calculation hasn’t been triggered. We tried replicating the exact series of transaction and it still would not trigger the calculation.

But the good news is that the challenge and response can be passed through. This means that “man in the middle” injection of data is still possible. This is my next goal, because my final goal is to make keyboard and mouse work on the PS4. Thus my next goal is to get Bluetooth passed through, establish a connection to both a DualShock and a PlayStation, becoming the man in the middle. Modify the gaming input packets from the DualShock before sending it to the PlayStation, while passing through all other traffic. Thus, the authentication packets are untouched, which does work because Matlo has already implemented this system as a test.