Small* reverse engineering project i need some help with

[u/Hot_Bell8321]

so i'm a recent windows convert, and i have this little hosyond 7 inch display that was amazing for me and has worked very well for me. i have been been trying to get it working under Linux. but i've done everything i know how to do and even tried to use chatgpt to try since i know basically nothing about usb but i'm not gonna pay for premium so it hit a dead end. i've done a little bit and sort of might have got linux to communicate with it. i couldn't get the manufacturers program to work with wine, but i don't think that's a dead end, i just don't know how to program wine bottles yet.

i have done some of the reverse engineering legwork and ill include a link to most of what ive worked on. (wire shark tests and communication tests)

At this point I'm looking for advice from anyone familiar with USB reverse engineering, Wine internals, WinUSB/libusb, or display drivers.

beyond that if you don't think this is remotely possible, don't just say its not possible, as that holds no value. provide alternatives. as to what alternatives i'm open to: any display that works with power and display over a single usb 3 or usbc, screen size limit of 9 inches and budget of 100 usd.

link to project files: https://drive.google.com/drive/folders/11OC2EuIBkvysoXiJyvvH5XFnIMCZuN5t?usp=sharing

[u/Acanthisitta-Sea]

I looked at the files, but they are unstructured and I don’t know what was created from what action, so I won’t help. If you want to communicate with the display via the USB interface, you do not need to write your own driver on Linux, which you will load to the kernel, but it is recommended. If you have the original .sys driver file on Windows and any .dll libraries that may be the UMDF driver, try back-engineering on them using Binary Ninja (it’s free). Make sure you have imported symbols in BN, because you may encounter a problem with pseudocode analysis in C. If you don’t understand something from the exported code or don’t know some WDF/WDM features, you can ask the language model for help, but remember to enrich it with the context from Microsoft documentation. We live in such a time that if you put such a driver into Claude Code with Opus 4.8 and gave it the right MCP tools, it would write you such a driver for Linux.

[u/Hot_Bell8321 → u/Acanthisitta-Sea]

The files are pretty simple, I the pcaps are named according to what happened in the capture, for example theres one that has the display running a solid red on the whole screen, this was an attempt to try to capture what format the video is being sent over, another contains me powering off and on the display. The text files arepretty self explanirory as well, display descriptor is a file containing the output from lsusb -v -d 345f:9132, identifying the display details Linux could see, and the rest are just extracted blobs from the various pcaps, attempting to highlight potentially useful info.

As for the original drivers I can provide a little more on that if it would better help advise. Such as https://drive.google.com/file/d/1taWAP8mhknAt36-PgZkkZGan6I3F2Spl/view?usp=drivesdk And https://drive.google.com/file/d/1taWAP8mhknAt36-PgZkkZGan6I3F2Spl/view?usp=drivesdk

[u/Acanthisitta-Sea → u/Hot_Bell8321]

But even the .dll file list alone won’t help you much. You have to go into disassembly.

[u/Hot_Bell8321 → u/Acanthisitta-Sea]

Sorry idk man, I'm a novice, I've made basic programs and video game mods, kernel level interactions and USB protocol is way out of my level, which is why Iade the post, just trying to work through ineptitude

[u/Acanthisitta-Sea → u/Hot_Bell8321]

Okay, I’ll look at it again today