Hi Alain,

On Thu, Dec 29, 2022 at 11:21 AM Alain Carlucci
[off-list ref] wrote:

Hi Roderick,

quoted

Give this patch a try. It is against hid-playstation, which as of 6.2
supports DS4. Let me know if it works. You can see the sensors working
through evdev on the motion sensors device.

Thank you for the patch, just tried. I think there is a typo in the
condition of the for-loop that sanitizes the input.
Instead of `; i < ARRAY_SIZE()` it's written `; ARRAY_SIZE()`,
which always evaluates to true. The loop then overflows the array and
crashes the kernel.

Ooh oops. It was a quick patch I wrote without testing.

By the way, the DualSense code has similar calibration code and also
there the input is not sanitized.
I think it's quite easy to create a fake DualSense device with
an Arduino that emulates the protocol up to calib_denom=0, just to
exploit that and crash every linux machine is plugged in. Or even
worst, exploit that via bluetooth.

You are right it probably won't hurt to duplicate the logic there.

quoted

If you want to dig deeper, you can play around with
dualshock4_get_calibration_data in hid-playstation. The particular
report (though not fully documented in the driver) does contain a lot
of device info (firmware info, manufacturing dates, various strings).
You can probably find the details online. Some data there might be
weird or not populated.

Thank you! Just discovered that this strange DS4 (CUH-ZCT2E) replies
all zeros both to HID request 0x02 (get calibration data) and as the
BT address (request 0x12, Pairing Info), which explains why BT is not
working.

There is definitely something weird with your device. Something must
have gotten wiped somehow.

I tried to request version info (0xa3), the response seems the same as
another fully-working and original CUH-ZCT2E:
"""
Build Date: Sep 21 2018 04:50:51
HW Version: 0100.b008
SW Version: 00000001.a00a
SW Series:  2010
Code Size:  0002a000
"""

Anyway, I have seen that request 0xA2 puts the DS4 in an alternate
boot mode, probably DFU mode, where the device reboots as 054c:0856
and waits for data, which seems totally undocumented online.
Do you know anything about this mode?
It would be amazing to be able to reflash the original firmware,

Unfortunately I can't disclose any of that information. I can say that
on DS4 it wasn't common to update firmware (as opposed to DualSense)
while out in the wild. Some of these requests and others are probably
used to initiate firmware programming and programming of MAC address,
calibration data and other settings. It is probably quite involved and
hard to get right without bricking your device.

Thanks,
Alain

Thanks,
Roderick