python-validity
python-validity copied to clipboard
uunicorn
Support for 06cb:00c7
Has anyone been able to get 06cb:00c7 to work?
I am happy to help if someone can guide me on how to do it.
@giovannicaligaris some sensors are capable of identifying a finger without exposing any biometric information to the host computer. Those are Match-on-Chip. Can you share a link to a Windows driver for your sensor?
@uunicorn You can download the HID drivers from here:
https://novacustom.stackstorage.com/s/s2zVcQyd004hRQJ?dir=%2FPC50D-PC70D%2FDrivers&node-id=176677
The model of the laptop is Clevo PC50DD2
Your driver seems to be here. It is not quite clear from the .inf file if it is MoH or MoC.
If you manage to set up the synaWudfBioUsb-sandbox project and gather some logs it could be possible to add support for this sensor.
Hi, I try to setup the sandbox, but the driver does not seem to contain the *.xpfwext file?
Hi, I try to setup the sandbox, but the driver does not seem to contain the *.xpfwext file?
Can you capture some packets? Some drivers are pretty easy to reverse engineer. If it doesn't have a firmware file, it might be in that case.
Sry took some time till i could look into this again, and tomorrow i'm on holiday so my next answer will be in the new year
I managed to setup the sandbox, i removed the lines for the xpfwext file from the run script an altered the device command as the device is called just "Synaptic" and not "Synaptic Fingerprint" but sadly the driver crashes. log is attached
Installed a windows test partition with wireshark on the device. Now i can sniff usb packets. What am I looking for exactly?/What information do you need to support the device?
I found one packet with 35kb, so I guess it's a match on host device? However throwing both file and binwalk at the extracted payload did yiel no image format whatsoever, it did yield nothing at all to be precise. I read that some synaptic sensors encrypt the image. Could this be the case?
Almost all the USB communication between the sensor and the host is TLS encrypted. There are two ways to work around it.
- Use Windows debugger to extract the session keys from the running driver
- Use a fake Windows environment which logs all encryption operations so that you can see the cleartext for a the comms.
I think the original Validity90 instructions go with the first approach. If you manage to extract the session keys, you can decrypt the traffic which you've captured with Wireshark. However it is not easy. I think original instructions are specific to the driver version and won't work as-is on any other driver/device without some extensive reverse engineering.
With synaWudfBioUsb-sandbox I've used the second approach. I've hacked Wine sources to make them intentionally insecure and log all the crypto operations. It is a more generic approach, however it still assumes a lot about the nature of the driver and it could be challenging to get it working.
I've looked at the logs from your previous comment (1608738488.log) it appears that the a.exe can't load the driver's dll for some reason. Can you list the contents of your folder where you were running it and the contents of the script?
I found one packet with 35kb, so I guess it's a match on host device?
Not necessary, the match-on-chip devices exchange some chunky blobs which contain no biometric data.
The folder got deleted by accident so I cloned and ran the sandbox again
$ ls -la
insgesamt 3064
drwxrwxr-x 3 test test 4096 Jan 13 10:40 .
drwxr-xr-x 17 test test 4096 Jan 13 10:36 ..
-rw-rw-r-- 1 test test 27550 Jan 13 10:40 1610530840.log
-rwxrwxr-x 1 test test 1159527 Jan 13 10:23 a.exe
-rw-rw-r-- 1 test test 3023 Jan 13 10:23 breakpoints.c
-rw-rw-r-- 1 test test 252 Jan 13 10:23 breakpoints.h
-rw-rw-r-- 1 test test 98 Jan 13 10:23 .env
drwxrwxr-x 8 test test 4096 Jan 13 10:23 .git
-rw-rw-r-- 1 test test 57 Jan 13 10:23 .gitignore
-rw-rw-r-- 1 test test 82966 Jan 13 10:23 hello.cc
-rw-rw-r-- 1 test test 265 Jan 13 10:23 mk
-rw-rw-r-- 1 test test 56576 Jan 13 10:23 notes.txt
-rw-rw-r-- 1 test test 1868 Jan 13 10:23 README.md
-rwxrwxr-x 1 test test 305 Jan 13 10:26 run.sh
-rw-rw-rw- 1 test test 18440 Apr 17 2020 SetupInf.exe
-rw-rw-rw- 1 test test 40 Apr 17 2020 SetupInf.ini
-rw-rw-rw- 1 test test 186440 Apr 17 2020 synaFpAdapter115.dll
-rw-rw-rw- 1 test test 12694 Apr 17 2020 synaumdf.cat
-rw-rw-rw- 1 test test 1517136 Apr 17 2020 synaWudfBioUsb115.dll
-rw-rw-rw- 1 test test 5959 Apr 17 2020 synaWudfBioUsbUwp.inf
-rw-rw-r-- 1 test test 10 Jan 13 10:17 usb.txt
I altered the run script to ignore the missing xpfwext file and hard coded the device path because the awk command didn't work:
$ cat run.sh
#!/bin/sh
set -e
DEVICE="/dev/bus/usb/001/003"
PWD=$(pwd)
BASENAME=$(basename "$PWD")
docker run --rm -it \
--device $DEVICE \
--env-file .env \
-v $PWD:/$BASENAME \
-v $PWD/usb.txt:/root/.wine/drive_c/usb.txt \
wine:validity wine64 "/${BASENAME}/a.exe" "$@" | tee "$(date +%s)".log
Try renaming synaWudfBioUsb115.dll to synaWudfBioUsb.dll and running the script again. a.exe looks for synaWudfBioUsb.dll file.
got WppRecorderUM.dll from the windows test partition and api-ms-win-devices-config-l1-1-2.dll from https://www.dll-files.com/api-ms-win-devices-config-l1-1-1.dll.html because i couldn't find it on my windows install?
However it now finds WppRecorderUM.dll but api-ms-win-devices-config-l1-1-1.dll is still not loaded
ah the library exists in a 32-bit and 64-bit version thats why it didn't get loaded (needed the 64-bit version, the website only has the 32-bit version) and i uses the find command and forgot that it is case sensitive by default thats why i didn't found the dll on my windows partition
another step further: DllGetClassObject was not exported from the synawudfbiousb.dll
That's odd. Can you share a link to the driver which you are using?
the one you referenced here: https://github.com/uunicorn/python-validity/issues/40#issuecomment-692373686
but i found another version on the clevo website, will test it now
Ok the driver from the clevo website yielded the same result but the nongamma driver from here https://novacustom.stackstorage.com/s/s2zVcQyd004hRQJ?dir=PC50D-PC70D%2FOptions%2F02_Finger&node-id=0 got a result
This looks more promising. Can you check that the device path is calculated correctly in run.sh?
DEVICE=$(lsusb | grep 'Fingerprint' | awk -F '[^0-9]+' '{ print "/dev/bus/usb/" $2 "/" $3 }')
Edit: this one does not work on my hardware because the device name has no "Fingerprint" word in it:
Bus 001 Device 024: ID 138a:0097 Validity Sensors, Inc.
Maybe you have a similar problem.
Actually do you want to have a discord server @uunicorn ? Issue seems not to be a good place to do experiments.
Yes I have:
Bus 001 Device 004: ID 06cb:00c7 Synaptics, Inc.
But I already recognized it and hard coded the path in run.sh:
DEVICE="/dev/bus/usb/001/003"
edit: and made a typo by doing it, lol
Ok it seems to interact now with the device:
it hangs at "All done, sleeping" till i press ctrl + c
after that i can't rerun the script without rebooting first
Ok, I think there are a few problems.
I guess you'll need to get the DEVICE variable to work properly first. As part of initial pairing the sensor is rebooted several times. When this happens the host detects USB reconnect and allocates a new device number, so your hardcoded /dev/bus/usb path no longer works. Whenever device is rebooted so is the Windows driver. Windows driver expects to be "activated" by the framework, but instead of framework we have this a.exe, so you would probably need to run it a few times. Each time the logs may look differently.
Another unrelated problem: according to the logs, flash partition command resulted in an error. Not sure why yet.
@himekifee , I've created a python-validity Discord server, but I'm not very familiar with Discord.