FlexScan EV 2795

[helgek]

Hi,

I have this device and would be happy to help analyze the communication with the device. I'm on Win 10 and I'm running a virtual Win 11 using Hyper-V. I could install InStyle in this instance as well. I'd just need rough guidance how to analyze the traffic.

Best, Helge

[markbolhuis]

Hi there

I'm unfamiliar with how USB capture works on Windows with Hyper-V, but the Wireshark wiki should be able to help you: https://wiki.wireshark.org/CaptureSetup/USB

Once you have capture working I'd first capture and save the packets sent back and forth on the screen in-style software startup and shutdown. Eizo have a rather unique setup where a secondary HID report descriptor is exchanged when the software detects a monitor. You can see this functionality reimplemented in my driver here: https://github.com/openeizo/openeizo/blob/61521a7740a126b31a319d5173a16aa48f7bf0ae/src/eizo.c#L268

This descriptor is much larget than the standard one and describes most of the commands that a monitor supports.

From there I'd then capture and save packets for each interaction you do - change brightness, contrast, inputs etc...

[ndim]

I have only once analyzed a (relatively simple) USB protocol of a completely unrelated device by examining the USB traffic generated by proprietary MacOS software running on a Mac in another country, but this may still help you.

I first tried generating a script like

 1.     start wireshark USB dump, wait 10s
 2.     start software, wait 30s
 3.     click function 1, wait 20s
 4.     click function 2, wait 20s
 ...
 (n-1). stop software, wait 30s
 n.     stop wireshark USB dump

the idea being that the pauses in the dump file would make analyzing the protocol easy. As it turns out, following such a protocol is quite error prone, and analyzing such dumps is also not easy, so I stopped using strict script timing to correlate software actions with USB communication.

Instead, I recorded videos of the screen with me using the software while the USB dump was active. This also required some synchronization point, but then allowed more flexibility for what software actions to perform and record. Of course, adding pauses between actions to separate actions in the time domain in the USB dump also helps here, but the main difference is the recording of what actually happened when, as opposed to what the script says should have happened when.

With a few video recordings and accompanying USB comm dumps as well as a bit of related research, I figured out the device functionality and the USB communication protocol as documented here: https://github.com/socratools/socradoc/blob/main/doc/soundcraft-notepad-usb-protocol.md

If you have a good video/comm dump pair of files, you can share that (possibly not on Github, because Gigabytes) and ask other people to participate in the protocol analysis.

[helgek]

Thanks a lot for your remarks! Unfortunately I had to postpone this a bit because of other things but it's on my to do list and I will definitely come back to you. It just could take some time.

[ndim]

Looking forward to seeing what strategies you came up with.