python-validity
python-validity copied to clipboard
Add support for 06cb:00a2
I'm working on adding support for device 06cb:00a2.
Following the guides in https://github.com/uunicorn/wine and https://github.com/uunicorn/synaWudfBioUsb-sandbox, I've successfully compiled and ran a.exe
and have the debug output from all three commands (nop
, enroll
, identify
). Not sure if the output is even meaningful but it seems to be successfully reading, encrypting, and decrypting some data from the sensor. I've managed to extract what looks like the init blob from the output and added it to validitysensor/blobs_a2.py
, but I'm not sure how or where to look for the rest.
Given the sensitivity of the data it might be unwise to post it here in its entirety. How can I share the output securely?
Help with extracting the right blobs and putting them in the right places would be very appreciated.
Thanks for all your work. I've been waiting to use this sensor for years!
Given the sensitivity of the data it might be unwise to post it here in its entirety. How can I share the output securely?
You can use my PPA key to encrypt your logs before uploading.
Cool, done logs.tar.gz
Thanks, I've checked the logs. Unlike 0097 and 009a devices, this one is a Match-on-Host device. In fact it looks very similar to the 0090.
Right now python-validity
lacks any finger recognition logic, so it only supports Match-on-Chip devices. I've done some preliminary analysis for 0090 devices, but it does not look very promising. Validity uses a 3rd party library (DigitalPersona / u.are.u) which implements custom template format and custom matching algorithm. I have found a way to convert DigitalPersona templates to a common NIST FMR format and a generic matching algorithms seems to work quite well on them, however it looks like some of the information is lost during this conversion. This means that the generic open source matching algorithm likely performs slightly worse than the proprietary one which is a part of Windows Validity driver. I can't quantify how much though. Another problem - at this point I'm not sure if it is even possible to convert FMR templates back to DigitalPersona format in such a way that will allow fingers enrolled in Linux to work in Windows and/or pre-boot auth. In theory it should be possible to reverse engineer and re-implement the DigitalPersona algorithms. This will solve potential problems described above, however it will most likely violate some IP rights. Another option is to depend on DigitalPersona shared library, which the user would have to download from somewhere else, but personally I don't like the idea of depending on binary blobs.
All in all, at this stage I think it would be easier just to add support for this device to libfprint
. As far as I understand libfprintf
was originally designed to support MoH devices. It has a simple driver API based on raster images produced by a device.
I see, thanks for checking this out.
lsusb
even reports that it's a match-on-host device:
$ lsusb -d 06cb:
Bus 001 Device 011: ID 06cb:00a2 Synaptics, Inc. Metallica MOH Touch Fingerprint Reader
Makes sense re: similarity to 138a:0090, in fact it's right there in the INF from the Lenovo driver (WBF_Drivers/synaWudfBioUsbLenovoSGXProd.inf
):
[Synaptics.NTamd64.10.0]
; TODO: Change the VendorID (VID) and ProductID (PID) to match your device
%WBDIUsbDeviceName%=Biometric_Install_10, USB\VID_138A&PID_0090
%WBDIUsbDeviceName%=Biometric_Install_10, USB\VID_06CB&PID_00A2
Next I'll try @3v1n0's fork to see if I can get any further. Thanks again, I appreciate the effort!
There is still some value in this PR, even if python-validity
may never support enrolling/matching on MoH devices. It could still be used for pairing and factory resets. I think @3v1n0 has taken this approach in his 0090 libfprint
fork.
How can I test this? I'm excited to see some progress on support for this particular fingerprint sensor :+1: My laptop is running Manjaro Gnome
@NovaViper I don't think there is much that can be done for this sensor due to the issues indicated by the author. I've since decided that it might be easier to replace the sensor with a match-on-chip part. Replacement parts are available online and appear to be the same form factor.
@oofnikj Awh ok. Do you happen to know any that fits for Thinkpad devices? Mine's a Thinkpad L390 Yoga
@NovaViper @oofnikj Same Laptop, same problem here (L390 Yoga). I would be very interested in knowing which keywords I need to search for to find a replacement for the sensor, so I can replace that ****** thing. In particular, which size is it? Which connector to the mainboard is needed? Which cable length and shape? And where to search for fingerprint sensors in general? Amazon?
@redweasel I haven't a clue, but the instruction manual shows you how to take it apart:
And it seems to be similar to the newest T490 Thinkpads, haven't tried it myself though
@oofnikj Awh ok. Do you happen to know any that fits for Thinkpad devices? Mine's a Thinkpad L390 Yoga
Sorry, haven't made much progress on this. I'm hesitant to order a replacement part for a different model and perform experimental surgery on my daily driver... Perhaps others will be more bold.
I see, thanks for checking this out.
lsusb
even reports that it's a match-on-host device:$ lsusb -d 06cb: Bus 001 Device 011: ID 06cb:00a2 Synaptics, Inc. Metallica MOH Touch Fingerprint Reader
Makes sense re: similarity to 138a:0090, in fact it's right there in the INF from the Lenovo driver (
WBF_Drivers/synaWudfBioUsbLenovoSGXProd.inf
):[Synaptics.NTamd64.10.0] ; TODO: Change the VendorID (VID) and ProductID (PID) to match your device %WBDIUsbDeviceName%=Biometric_Install_10, USB\VID_138A&PID_0090 %WBDIUsbDeviceName%=Biometric_Install_10, USB\VID_06CB&PID_00A2
Next I'll try @3v1n0's fork to see if I can get any further. Thanks again, I appreciate the effort!
Hi @oofnikj did you have any success in getting this working with the 0088 device? I'm hoping to get it working but not seeing a lot of success across the web.
Any progress on this?