Exception: Failed: 04af

[maxso-216]

I am very new to GitHub,so I want to thank for everyone who contributes this program. Also, English is not my native language, I'm sorry for any misspelled words.

The program complains about 04af error when I was trying to factory resetting my fingerprint driver. Every time after I run the following code sudo python3 /usr/share/python-validity/playground/factory-reset.py -v (no log produced, sudo validity-sensors-firmware runned, python3-validity.service stopped), sudo systemctl status python3-validity.service complains about 04af error. See the attached file for journalctl -u python3-validity.service -b (very long!)
log.log
You can see it complains about Exception: Failed: 04afwhen I flashing the fingerprint driver. I can not know what the error code mean, and I hope you can troubleshoot the error.

Addition note: I also reset the fingerprint in bios, but it does not work. The fingerprint on ubuntu used to work about 7 months ago, with https://github.com/3v1n0/libfprint/ , but one day I found out it did not work. Until today, I can not figure out why it's not working. I even reinstall ubuntu, switch to Arch linux and run this program, but still no luck.

The following include my hardware information:
OS: ubuntu 20.04
Kernel: 5.13.0-48-generic
Host: 20F9A043HH ThinkPad T460s
Fingerprint: Bus 001 Device 011: ID 138a:0090 Validity Sensors, Inc. VFS7500 Touch Fingerprint Sensor (via lsusb)
DE: Gnome 3.36.8

I thank for everyone who develop this program

[uunicorn]

138a:0090 issue is not trivial, so bear with me.

Background:

1. libfprint project is an official Linux fingerprint driver. It supports heaps of sensors, but lacks Validity(Synaptics) devices support.
2. python-validity project is designed to support Match-On-Chip Validity sensors exclusively. It replaces libfprint.
3. 138a:0090 is very similar to any other Validity sensor (pairing, TLS protocol, internal flash, templates storage, etc), however it is a Match-On-Host device, meaning it can't generate templates or match your finger against them and relies on the Host to do the heavy lifting.
4. @3v1n0 forked the official libfprint project and added partial support for 138a:0090 devices. Granted the device is already paired, his driver can scan your finger image and feed it back to the fprintd framework to do the matching and/or enrollment. There is a problem with calibration data being wrong, but it sort of works anyway as long as the device was at some point initialized/paired with the host (e.g using Windows multi-boot).
5. @3v1n0 also created a snap tool which allows you to initialize/pair the sensor without Windows. This tool is based on python-validity. It does not use any enroll/identify functionality of python-validity, just the flash initialization and pairing part.
6. You must initialize/pair with your sensor each time you do a factory reset.

So, to summarize: python-validity never fully supported 138a:0090. It only supposed to support the initial device pairing so that @3v1n0 's tool can use it.

Looking at your log file I can see two types of errors: 0401 (which was happening before you've presumably done a factory reset) and 04af (which must have started happening after that).

0401 error means "unsupported command". And it was a reply to a Match-On-Chip "start enrollment" command. Which is understandable - this is a Match-On-Host device which does not know how to enroll fingers on its own.

04af error is related to https://www.synaptics.com/sites/default/files/fingerprint-sensor-VFS7500-security-brief-2020-07-14.pdf . It indicates that the driver (python-validity) is trying to partition the flash without supplying a valid partition signature. I've added the signature for all other supported devices, however I had no one brave enough to help me extract this signature from the Windows driver logs, or check if a signed partition for some other device would work. Which is understandable - python-validity will likely never fully support MoH devices anyway.

So, this concludes the diagnostics part of this issue. As for the fix - I'm not sure what's next.

I guess, I can remove the stub for 138a:0090 from get_partition_signature in validitysensor/init_flash.py. This will likely allow the device initialization to finish successfully. However python-validity still have no idea how to enroll or identify your fingers on this device. You'll need @3v1n0 's libfprint for that. And you can't have both python-validity and libfprintf installed at the same time. I guess, @3v1n0 can update his tool to send the signature, in which case you won't need python-validity at all.

About 2 years ago I gave it a try to add the MoH support to python-validity. 138a:0090 specifically. I decided that it is only worth doing if I can keep a full compatibility with the Windows driver. Since the template database is stored on-chip, Linux must be able to identify fingers enrolled by Windows and vice-versa. I actually managed to reverse engineer a large portion of the template format. It turns out it is based on a format called "digitalpersona". It is sort of obfuscated by a TEA encryption with a hardcoded key. This format appears to be supported by a libdpfj library. Heaps of android devices are using this library and it's very easy to find a Linux version, but it's not opensource, neither license allows you to re-distribute it. And while technically it's possible, legally we can't use it from python-validity. And even if we could... it does not look like Validity is going to build more MoH devices anyway. All new devices are MoC. So... I finally gave up. The branch devices/0090 is still there in case if some one wants to waste their time on it.

[maxso-216]

Thank for your reply! I I thank you for developing this program again. Well, I don't know what a MoH or MoC is, and I can not fully understand what your last paragraph is talking about. In my understanding, it's due to the lack of signature key and legal reasons so it can not be flashed? I am not a programmer, and can not really do a heavy debugging. Still, maybe I will try to extract the signature from windows log in my free time. According to the search, I just need to open up Event Viewer when I install fingerprint driver on windows, and the signature key will be magically logged? I hope someone will tell me how to extract signature key on windows. Still, thank for your hard-work! I hope you have a nice day

[uunicorn]

That's all right. This topic came up a few times and wanted to write everything up before I forget it.

To finish pairing, you can try this:

• edit /usr/lib/python3/dist-packages/validitysensor/init_flash.py:

diff --git a/validitysensor/init_flash.py b/validitysensor/init_flash.py
index 6cd54ec..7dfd546 100644
--- a/validitysensor/init_flash.py
+++ b/validitysensor/init_flash.py
@@ -40,10 +40,6 @@ crypto_backend = default_backend()
 
 
 def get_partition_signature():
- if usb.usb_dev().idVendor == 0x138a:
- if usb.usb_dev().idProduct == 0x0090:
- return b''
-
 return partition_signature
 
 

• reboot
• go to your BIOS settings and do another factory reset for the fingerprint reader
• boot into Linux, and check the logs (e.g journalctl -u python3-validity.service -b)
• if there are no errors and no python-validity activity for a few minutes, proceed (if you have any concerns at this point, stop here and share the logs)
• remove python-validity, open-fprintd and fprintd-clients packages
• install stock fprintd with @3v1n0 's libfprint fork

[maxso-216]

Thank for your help. If possible, I really hope I can contribute the project by trying to extract the signature key. But before I can do it, maybe I should close the issue? Still, it will be nice if someone tell me how to extract the signature key.

[uunicorn]

If steps above are gonna work, then we won't need a signature. We'll just use the same partition table and signature as for other devices.

[maxso-216]

Ok. I really surprised by your quick respond. I will give it a try in later. But will the program behave better with the signature key?

[uunicorn]

But will the program behave better with the signature key?

Not really. It either works, or it doesn't. On patched devices, the signature prevents you from sending a fake (and possibly malicious) partition table during the pairing. Your device is patched now and it rejects the partition command because it has no signature. By removing those lines from init_flash.py we're gonna send the signature as for all other supported devices. If your device will accept it, then it is going to behave exactly as it was before. If not - we will need to extract it from the Windows driver.

[maxso-216]

Assume the fingerprint accept it, so the signature key will be same with other device?

[uunicorn]

The key is probably the firmware signature key. The private part is kept secret by Validity. A device has the public part of that key which is used to validate the signature. And yeah, I think the key is likely the same for all devices.

[maxso-216]

After editing /usr/lib/python3/dist-packages/validitysensor/init_flash.py, I reboot ,reset fingerprint data in bios and factory do a reset. However, it's still complains about 04af error. It's seem I have to extract the signature key in windows driver.
Here is the journalctl -u python3-validity.service -b log
afterpatchedlog.log
Also, I hope I patch the file correctly. Here is patched /usr/lib/python3/dist-packages/validitysensor/init_flash.py
init_flash.zip

[maxso-216]

And it will be nice if there's some guide to tell me how to extract the signature key.

[uunicorn]

Looking at the logs, I can confirm that you've patched init_flash.py correctly. Which means 0090 uses a different firmware key.
Oh, well.. You were right - we do need to extract the partition+signature blob from the Windows driver. This is not an easy task though. Try setting up this project: https://github.com/uunicorn/synaWudfBioUsb-sandbox

[maxso-216]

I will give it a try. With some compiling learnt experience from linuxfromscratch, I think I can set up this project. And after setting up this project, I can get the keys?

[uunicorn]

The goal is not to get the keys, but to get the partition signature. It should be present in the first set of log files generated by a.exe after the factory reset.

[maxso-216]

I have set up the project, and run a few times. The log is attached, and I have no idea what they are complaining about.
1655064270-wine.log
1655064270-usb.txt
1655064270.log