How to reverse engineering usb windows captures

[albfan]

@scarburato, @Kimplul: To add missing features, like combined pedal models , we need to a guide to read usb captures. (sorry if this is already described elsewhere, I look around but didn't find much info)

I add here a capture of range change: from 900 to 140, then to 1080 and then to 900 again, so this is a feature already covered in range property.

• 
• 
• 

t150-range_140_1080_900.zip

Then, I'm adding a capture for change pedals from default (separate mode) to combined pedals (that means accel and brake is always in the middle, and accel reduces brake axis, while brake increases brake axis

• 
• 

t150-combined_pedals.zip

NOTE: Captures are in pcapng format and in txt (with bytes) so should be easy to recognize patterns and filter pings and responses from host to device to isolate codes to setup device.

[albfan]

Well that was quick:

hid-t150/attributes.c

	range = DIV_ROUND_CLOSEST((range * 0xffff), 1080);

	t150_set_range(t150, range);

so 1080 is 0xffff, looking into captures:

No.     Time           Source                Destination           Protocol Length Info
    251 9.181664       host                  1.5.1                 USB      31     URB_INTERRUPT out

Frame 251: 31 bytes on wire (248 bits), 31 bytes captured (248 bits) on interface \\.\USBPcap1, id 0
USB URB
HID Data: 4011ffff

0000  1b 00 a0 da 13 c1 8f e1 ff ff 00 00 00 00 09 00   ................
0010  00 01 00 05 00 01 01 04 00 00 00 40 11 ff ff      ...........@...

then to confirm:

hid-t150/settings.c

	errno = t150_settings_set40(t150, SET40_RANGE, range, buffer);

and SET40_RANGE=0x11, and t150_settings_set40 has

	buffer->code = 0x40;

confirming code 4011ffff

So after compare two capture sessions, I would say combine pedals happens when a HID Data appears, so filtering on t150-combined_pedals.txt looks like there's some noise for:

HID Data: 077f81ff03ff03ff0300000000000f

so removing that I only see to HID Data events, and that match with what I did, change from separate to combined and back to separate:

$ rg "HID Data" t150-combined_pedals.txt | grep -v "0000000000f"
HID Data: 4205
HID Data: 4205

I see set_gain using 0x43, so probably this is correct

[Kimplul]

(sorry if this is already described elsewhere, I look around but didn't find much info)

I have a short tutorial over in https://github.com/Kimplul/hid-tmff2/wiki#how-to-capture-what-usb-packets-the-driver-sends-to-the-device, but no worries.

I see set_gain using 0x43, so probably this is correct

Nice work. Out of curiosity, in which situations are combined pedals useful? Flight simulators come to mind, but are wheels typically used in those cases?

[albfan]

I have a short tutorial over in https://github.com/Kimplul/hid-tmff2/wiki#how-to-capture-what-usb-packets-the-driver-sends-to-the-device, but no worries.

Those notes are cool, I would love to code some dissector: https://www.golinuxcloud.com/wireshark-dissector-tutorial/ at some point

The part to run under a virtual machine is super! didn't expect I can do that, I just use another laptop with Windows, so this can speed up things a lot

Looking for what combined pedals are helpful, I found it is probably to support old games:

https://www.reddit.com/r/LogitechG/comments/nu30t0/recent_update_to_logitechs_lghub_broke_combined/

A bit of context: older racing games generally don't support clutch pedals very well, as steering wheels used to only have two pedals (I think it's because they emulated a gamepad's axis, only two available).

For this reason, Logitech implemented a "Combined Pedals" mode into LGHUB, which makes the game recognize both the throttle and brake as positive and negative values of a single axis, with the clutch having it's own separate axis. This works by having the combined axis value being 0 when no pedal is being pressed, between 0 and 1 when pressing the throttle and between 0 and -1 when pressing the brake. Like this (link may or may not work, tell me if it doesn't).

I don't really need this functionality, just trying to cover all features device provide. Out of curiosity, is thrustmaster collaborative on this? does anyone tried to send an email to ask for protocol definition?

[Kimplul]

Looking for what combined pedals are helpful, I found it is probably to support old games:
[...]
I don't really need this functionality, just trying to cover all features device provide.

I see. Sure, makes sense.

Out of curiosity, is thrustmaster collaborative on this? does anyone tried to send an email to ask for protocol definition?

I tried asking, but was promptly ignored. This person claims that he was forwarded to their R&D department, but haven't heard any updates in a while: Kimplul/hid-tmff2#58 (comment).

[albfan]

I open a thrustmaster account and open a new ticket! probably kernel people supporting hid_thrustmaster knows better. I think scarburato/hid-tminit#11 will get some light on what we can expect.

I think work on wiki and try to create a wireshark dissector are the way to go.

Info collected. Let's close this by now

[albfan]

From https://github.com/scarburato/t150_driver/blob/master/hid-t150/packet.h#L1

#define STATE_PACKET_INPUT 0x07

so

usbhid.data[0] != 07

looks like a great start to filter packets

@scarburato I don't have permissions to edit wiki, can you grant me those?

[scarburato]

done

[albfan]

I try to improve wireshark to autoselect last packet: Details on https://gitlab.com/wireshark/wireshark/-/issues/18948