Decoding G402 data dumps #3
Comments
|
@dslul honestly I don't grok wireshark dump's formatting. I've been mostly using direct usbmon dumps. If you can locate the firmware file itself inside the updater you can fairly easily grep the logs for known data. |
|
I agree on the wireshark dumps, I ended up exporting as text file and isolating the data packets sent by the logitech application. This way I managed to find some interesting things (on the g402): These two packets work even without entering the aforementioned "edit mode". G LOGO LED: To test packets I used this https://github.com/cvuchener/g500/tree/master/src (the send-raw-request program) in conjunction with a bash script to send a batch of hex packets from a file easily: #!/bin/bash if [ ! -f $1 ]; then while read p; do exit 0 |
|
I'm curious how you place meaning on this "edit mode" you describe. I'm going through a similar dig based upon the Logitech G102 and I see a number of packets that I can't place meaning on that I'd be interested to mapping to the work you're doing. I note that the core of my dumps suggests that the G102 has a radically different configuration format than the mouse tested here. Just as a brief example, lighting information is sent twice to two different ?registers? on the mouse, with one byte setting the mode, three bytes of RGB data, with brightness information further on ranging from 0 to 0x64. |
|
Can you upload your dumps so I can compare with mine? (One when application start and one when you enter the lightning section and modify something) |
|
Another good tool is the hidapi's python binding. it offers a sort of shell you can use to interactively |
|
@dslul I stuck my recent dumps over here. They're currently stripped Wireshark dumps (I used tshark with a filter to remove all of the extra crap on the bus), but if there is a prefered way that you've been working with text dumps I can dump things that way. I've personally been using the pip pcapfile library with a primitive USB layer to extract data from packets. I have some confidence as to how most of the lighting data makes it's way onto the G102, but I hadn't bothered trying to manually manipulate it. Based upon a few things in this thread I think I can start tinkering. With regard to the version string, I think that the version is sent as a device descriptor when it's initally pluged in. In your dumps only the device name looks like it's going over the wire ("Gaming Mouse G402" Descriptor ID #2), but in my dumps I see descriptor #1 contains "Logitech", #2 "G102 Prodigy Gaming Mouse", #3 some sort of number (I think it's an encoded serial number or something), and after I start the Logitech gaming software a descriptor with index #4 containing the string "U107.01_B0013". I suspect this number corresponds to the software version. |
|
I discovered there are some information on the protocol here https://drive.google.com/open?id=0BxbRzx7vEV7eU3VfMnRuRXktZ3M |
|
@dsul Could you post dumps of your profile memory? I would like to see exactly how the profile structure change for different "profile format" values. libratbag treats format 1, 2, and 3 in the same way. or if you have a doubt on the page count: For your information, the profile structure is defined in libratbag: https://github.com/libratbag/libratbag/blob/master/src/hidpp20.c#L1650 For comparison, one profile from the G502 spectrum (profile format is 2):
|
|
@cvuchener here it is: I also tried to dump using libratbrag, but I don't understand why there is a distinction between ROM and FLASH: |
|
I see I have a bug when reading data after offset 256 (0x100). I will fix that but it is okay: the profile fits in the first 256 bytes, I have the data I wanted. Yes there is a ROM, you can use the PS: I edited your message to hide the useless repeated data. |
|
So your profile is very similar to the G502: About the first two reserved bytes, on the G502 the three default flash profiles have The data from 0xd0 may be related to leds, but the format is different. Maybe you can see some similarities with the format used for effects in feature 0x1300 "LED Control".
|
|
The data from 0xd0 doesn't change when I make modifications to led settings, so it should not be related to them. I also can't find the checksum on the dumps, but it is clearly sent by LGS. |
From your previous post, my tool was retrieving 1024 bytes of data, but 4 times the same first 256 bytes (because of a overflowing 8 bit offset). It should be fixed now. Please, write a bug report if it still doesn't work as expected. libratbag should have the same problem since it uses 8 bit offsets and hard-coded page size of 256 bytes. Because the profile fits in the first 256 bytes, it works for reading the profile. But the CRC is written at the end of the first 256 bytes instead of the end of the page. That means the profiles written by libratbag on the G402 would not work. Is it the case? |
libratbag hard-code parameter byte 4 to 0x01, but your case it is 0x04. Byte 4 and 5 could be data length in big endian (0x100 = 256 bytes, 0x400 = 1024 bytes). I'll test that and fix my code. |
|
I confirm that byte 4 and 5 are actually the length of the data to write. Fixed in cvuchener/hidpp@ad5c918 |
|
Great, now it reads 1kiB per page! I think I discovered what the first two "reserved" bytes of the profile are for: it is a number in |
The data at the start of page 0 is the profile list. It is a array with 4 bytes per profile : memory type ( The remaining space can be used to store macros or whatever you want. LGS usually writes macros in the first page after the profiles (page 2 for you), but they can be anywhere. On older HID++1.0 devices like the G500 or G9x, LGS used to store metadata after the profile or profile list (macro/profile names).
You meant little endian? That would make sense: the highest number is the profile I tweaked the most. |
|
I assume the g502 has a separate page for each profile, doesn't it? |
|
I had a closer look at your profile data and I have doubts that the data from 0xd0 is related to the profile. On page 1 of the ROM, the data from 0xa0 is a copy of page 0 (from the beginning), including the profile list. The data from 0xd0 to 0xef from page 1 in the flash memory is an exact copy of the ROM (so the same data as page 0 with the first 48 bytes overwritten by the name). I think the data was copied accidentally and is not actually part of the profile structure. I cannot say if page 0 of ROM is its proper place or not. I does not look like the macro format I know. I missed some of your questions.
Yes: one profile at the beginning of each page 1, 2 and 3. Macro data begins at page 4.
HID++1.0 devices have an offset in the profile list. But HID++2.0 (and later) uses 16 bit offset, it would not fit, except if only the most significant byte is stored. In ROM on the G502, the fourth byte is 0xff instead of 0, it does not look like an offset. |
I am trying to decode some information sent from the Logitech app and firmware updater, but without any luck for now...did you manage to get something for the other models? I can't figure out how the firmware updater (separate from the main app) gets the version...I am attaching a wireshark dump in plain text, maybe you can confront it with other devices (current mouse firmware version: 90.3.20).
updater.txt
EDIT: I've just noticed that lsusb shows the correct firmware version (bcdDevice); however, I still cannot understand what the logitech app does. When I click on Illumination (to set the leds configuration of the mouse), it starts to send an infinite amount of packet as long as I remain in that section (even without changing a single configuration). Do you think this is an expected behaviour? It's kinda hard to reverse engineer the packets when they are covered by so much (apparently) useless information
The text was updated successfully, but these errors were encountered: