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...

[storm1ng]

@uunicorn here is the link to the logfile: logfile.txt

[uunicorn]

@mjenny it looks like it crashed because it failed to find your USB device.

Can you check that the device vendor and the product id in /dlls/winusb/winusb.c are actually matching your hardware?

By default it is

#define MY_VENDOR   0x138a
#define MY_PRODUCT  0x0097

which corresponds to 0097 device. If you have a 009a, you should probably change MY_PRODUCT to 0x009a, but it would be best if you can double check with lsusb:

$ lsusb 
...
Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc. <---- my device
...
$ 

how do I know that a.exe was successfully run?

a.exe should let you enroll a finger.

[storm1ng]

I should have known it better... I was thinking about changing #define MY_VENDOR to 06cb which is what my lsusb is printing:

...
Bus 001 Device 003: ID 06cb:009a Synaptics, Inc.
...

I'll rebuild wine then and let you know how it goes.

[storm1ng]

@uunicorn It looks better know. Do I have to run wine64 as root to be able to access the USB device?

0009:trace:reg:NtQueryValueKey (0x60,L"SignatureKeyPair",2,0x332d20,256)
USB >>>>>>>>>> In DllMain reason=1
USB >>>>>>>>>> WinUsb_Initialize
!!!!!!!!!!!! Found device 06cb:009a
libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/003: Permission denied
libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes.
Failed 'libusb_open(dev_list[i], &info->dev)': -3 - LIBUSB_ERROR_ACCESS
0010:trace:reg:open_key ((nil),L"\\Registry\\Machine\\System\\CurrentControlSet\\Control\\ComputerName",20019,0x7df700)
0010:trace:reg:open_key <- 0xb8
0010:trace:reg:open_key (0xb8,L"ActiveComputerName",20019,0x7df708)
0010:trace:reg:open_key <- 0x15c
0010:trace:reg:NtQueryValueKey (0x15c,L"ComputerName",2,0x7df750,44)
0010:trace:reg:open_key ((nil),L"\\Registry\\Machine\\System\\CurrentControlSet\\Control\\ComputerName",20019,0x7df700)
0010:trace:reg:open_key <- 0x168
0010:trace:reg:open_key (0x168,L"ActiveComputerName",20019,0x7df708)
0010:trace:reg:open_key <- 0x15c
0010:trace:reg:NtQueryValueKey (0x15c,L"ComputerName",2,0x7df750,44)
002e:trace:reg:RegDeleteTreeW (0x24, L"Winedevice1")
002e:trace:reg:open_key (0x24,L"Winedevice1",20019,0x1c7fa98)
002e:trace:reg:open_key <- (nil)
0010:trace:reg:RegDeleteTreeW (0x24, L"Winedevice2")
0010:trace:reg:open_key (0x24,L"Winedevice2",20019,0x7dfaa8)
0010:trace:reg:open_key <- (nil)

[uunicorn]

I've got a custom udev rule:

/etc/udev/rules.d/10-fpreader.rules:ATTRS{idVendor}=="138a", ATTRS{idProduct}=="0097", OWNER="unicorn"

But you can chown it manually. It's gonna be reset after reboot or when device re-connects.

[storm1ng]

@uunicorn I chowned the device and the logfile.txt looks promissing: logfile.txt However, I still was not able to enroll a finger.

>>>>>>>>>>> xfer Failed - LIBUSB_ERROR_NO_DEVICE

[uunicorn]

That could mean that device just finished pairing and has restarted. Chown again and give it another go. It may take a couple of tries.

[uunicorn]

Or may be not. I can't see it's sending any firmware. But the last message the host sent to a device was a "reboot" command (which caused USB device to disconnect):

USB a03700 >>>>>>>>>> WinUsb_WritePipe PipeID=1
>>> 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
rc=0 send=98

You may need to put the firmware file in some other place, where the driver is looking for it. Not sure where though.

[storm1ng]

I couldn't find anything in regards to that inside synaWudfBioUsbLenovoMiSSGXProd.inf (which is the only inf file I could find): synaWudfBioUsbLenovoMiSSGXProd.inf

[uunicorn]

What do you mean? Here it is:

[DestinationDirs]
...
WinBioSensorAdapterCopy=11, WinBioPlugins; copy to \Windows\System32\WinBioPlugins
FWextCopy=11
...
[FWextCopy]
6_07f_lenovo_mis_qm.xpfwext
...

Try copying it to \Windows\System32\WinBioPlugins in your Wine prefix. E.g ~/.wine/driver_c/Windows/System32/WinBioPlugins/ You may need to create WinBioPlugins directory.

[storm1ng]

Dang, I missed that completely... It is now using the firmware file from what I can tel. However, the result is the same, no matter how many times I try. The pairing is working fine and it will be recognized as new USB device for which my user is still the owner. ls -la /dev/bus/usb/001 Before the run:

total 0
drwxr-xr-x 2 root   root     160 Jun 22 06:53 .
drwxr-xr-x 6 root   root     120 Jun 22 05:56 ..
crw-rw-r-- 1 root   root 189,  0 Jun 22 05:56 001
crw-rw-r-- 1 root   root 189,  1 Jun 22 05:56 002
crw-rw-r-- 1 root   root 189,  3 Jun 22 05:56 004
crw-rw-r-- 1 root   root 189,  4 Jun 22 05:56 005
crw-rw-r-- 1 root   root 189,  5 Jun 22 05:56 006
crw-rw-r-- 1 mjenny root 189, 16 Jun 22 06:53 017

After the run:

total 0
drwxr-xr-x 2 root   root     160 Jun 22 06:54 .
drwxr-xr-x 6 root   root     120 Jun 22 05:56 ..
crw-rw-r-- 1 root   root 189,  0 Jun 22 05:56 001
crw-rw-r-- 1 root   root 189,  1 Jun 22 05:56 002
crw-rw-r-- 1 root   root 189,  3 Jun 22 05:56 004
crw-rw-r-- 1 root   root 189,  4 Jun 22 05:56 005
crw-rw-r-- 1 root   root 189,  5 Jun 22 05:56 006
crw-rw-r-- 1 mjenny root 189, 16 Jun 22 06:54 018

logfile.txt I'll continue to try.

[storm1ng]

Do you think that the new device number is the issue and that xfer can no longer find the device?

[uunicorn]

No, host is requesting device to reboot before it disconnects. USB comms are fine. By the looks of it, the device was not partitioned properly yet. I'll have a closer look in a while, thanks for trying - some of the blobs are already in the output. Did you capture the output from all your attempts?

[storm1ng]

No, but I can create a few more and upload them if it helps.

[uunicorn]

Can you use factory-reset.py and try again? Try to log everything when running a.exe, as the device has a state and running it twice in a row may give different results.