Working with 06cb:009a Synaptics, Inc.

[javierfileiv]

Hi there, I'm trying to make work this fp.

I saw that there are blobs_90.py are blobs_97.py . Are these binary blobs taken from the firmware extracted from the windows installer?

How can I know which one is init_hardcoded , init_hardcoded_clean_slate, etc ?

Thanks for your reply

[uunicorn]

Are these binary blobs taken from the firmware extracted from the windows installer?

I'm quite confident these blobs are pieces of code which Windows driver dynamically uploads and executes on the device. They are hard-coded inside the driver .dll.

How can I know which one is init_hardcoded , init_hardcoded_clean_slate, etc ?

You can use this project https://github.com/uunicorn/synaWudfBioUsb-sandbox to snoop on Windows driver to see which blobs are loaded into your device and when.

[storm1ng]

The firmware's name for 009a is 6_07f_lenovo_mis_qm.xpfwext (extracted from nz3gf07w.exe.

I will try and extract the blobs. Let's see how it goes.

[javierfileiv]

Thanks @mjenny , could you please share after the extract? :)

[storm1ng]

@javierfileiv sure, if I'm able to extract them. :)
I'm currently in the process of compiling wine.

[uunicorn]

I can assist you in finding the blobs if you can manage to get synaWudfBioUsb-sandbox running.
In addition to the firmware file itself, you will also need to extract synawudfbiousb.dll from your Windows diver.
If all good, wine64 a.exe will spit tons of output. Redirect it to a file and upload somewhere so I can have a look.
Good luck.

[storm1ng]

@uunicorn I already have the DLL and the firmware extracted. I will let you know as soon as I have wine up and running.

I am currently compiling wine inside a VM running on my Lenovo X1 Extreme. Not sure if that will be sufficient. If not I will install Arch Linux or Linux Mint for a faster install. 😄

[storm1ng]

Hm... I should have tried to passthrough the fingerprint reader earlier. I guess Intel Secure Guard Extension is a problem or the fact that I have enabled WSL2 and have to go through Hyper-V.

[storm1ng]

@uunicorn do I have to put the firmware file somewhere to run a.exe?

[uunicorn]

Both .xpfwext and .dll should be placed in the same directory with a.exe.

I'm no expert, but if you're running a host on Windows, it may be hard to pass the reader USB device to a Linux guest. Windows diver may have claimed the same device and could interfere with a communication. But yeah, IDK, I never tried that.

[storm1ng]

@uunicorn I installed Linux Mint for now. Will do everything over again.
Am I still supposed to compile wine myself (regarding hacks)?

[uunicorn]

Yes. Hacks have a bunch of printfs sprinkled all over the crypto routines. Those are actually used to dump all the communication between a device and a driver. Including the missing blobs.
Hacks also include a fake winusb.dll implementation which lets synawudfbiousb.dll talk to a real USB device. Vanilla wine does not have this DLL.

Which reminds me that you'd probably want to change this line before building Wine:
https://github.com/uunicorn/wine/blob/7ed3db9743a525228fb6306ab0d8d0f8b4163e00/dlls/winusb/winusb.c#L16

[storm1ng]

I'm currently back to building wine with the aforementioned changes.

[storm1ng]

@uunicorn I successfully built wine and it worked fine so far. However, I don't have a wine64 executable. And when running WINEARCH=~/.wine-fingerprint wine a.exe I get a wine: Bad EXE format for Z:\home\mjenny\wine\a.exe..

I assume that a.exe which I downloaded directly from your repo (I didn't build it myseld) is using 64-bit, right (a.exe: PE32+ executable (console) x86-64, for MS Window)?

Do I have to build wine differently?

[storm1ng]

Nvm, I missed --enable-win64...

[storm1ng]

Ok, I have everything running.

@uunicorn how do I know that a.exe was successfully run? I am now getting a Program Error during execution.
There seems to be an Unhandled page fault:

USB >>>>>>>>>> In DllMain reason=1
USB >>>>>>>>>> WinUsb_Initialize
wine: Unhandled page fault on read access to 0x00000040 at address 0x7f1005121a44 (thread 0009), starting debugger...