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

[uunicorn]

I don't think you've done a factory reset before starting. Or perhaps you still have python-validity running in the background which tries to immediately pair as soon as you boot. Please disable the python-validity service, do a factory reset via BIOS setup and try again.

[maxso-216]

After disabling python-validity (I have to fully remove the package so it won't start after I reboot, because sudo systemctl disable python-validitydon't stop python-validity starting after reboot, and I forget I can use sudo systemctl mask ) and reset my fingerprint data in bios The log is looking good. Maybe it logged the partition signature? It's look too messy for me. 1655105304.log 1655105304-wine.log 1655105304-usb.txt

[maxso-216]

This is logs log.zip separated with "nop" "identify" and "enroll" option.

[uunicorn]

The first set of logs actually had the partition table. However it lacks a signature. Later in logs the Windows driver received exactly the same 04af error and attempted to force another factory reset as a response. It probably means that you have found an old Windows driver version.

Would be nice to actually verify that it works on Windows first. I think it should be possible to pass-through a usb device to a Windows VM.

[maxso-216]

well...I just find out I use the wrong windows driver. I use the default ships with python-validity (n1cgn08w.exe). On Lenovo website, it has a latter version (n1cgn10w.exe) which version is later. I will re-log with the newer version one.

[uunicorn]

The very first log has the partition+signature. No more logs required.

In fact, better remove them from the comments since they contain your biometric information (you actually successfully completed enroll a few times).

[maxso-216]

Log removed. Now, what's next?

[uunicorn]

Now I need some time to add the partition+signature to python-validity project, then you can use it to complete the pairing with your sensor.

[maxso-216]

Ok, I will wait for your good news

[uunicorn]

I've pushed partition table + signature from your logs. Please

• clone this project
• do a factory reset via BIOS
• follow the "Playground" instructions from the README

You don't need to fully install the project, just start the playground python session as root as PYTHONPATH=scripts:. python3 from the project directory. Repeat until there is no more reboot exceptions.

[maxso-216]

I get 04af error again. I have make sure I have reset fingerprint in bios. Pretty strange. Do I extract the signature keys wrongly? pvlog.log

[uunicorn]

Can you enable tracing before open9x()?

>>> tls.trace_enabled=True
>>> usb.trace_enabled=True
>>> logging.basicConfig(level=logging.DEBUG)

You'll need to do a factory reset again.

[maxso-216]

Oh sorry I don't know how to set the debugging flag. I will do it again later.

[maxso-216]

Here is full log. Why 04af is still presents? I have reset fingerprint in bios. pvlog2.log

[uunicorn]

Weird. Logs actually contain the right signature. I've reviewed the wine/a.exe logs again and noticed that Windows driver has failed the first time with the same error as well, despite the valid signature was present in logs. I wonder if something could have interfered with initialization. Can you double-check that you've removed all the python-validity package bits from your system? Note that the initialization may only happen once after a factory reset. If you do a factory reset and then try to pair with the sensor using wrong software, the error will persist even when you will try to use the right one after that. You need to do a factory reset each time in order to retry.

[maxso-216]

I try it again on my arch linux portable usb. I have reset fingerprint data, and still, 04af still appear. I have make sure python-validity is not installed. Strange, why is it happening? arch-python-validity.log

[maxso-216]

And about why there's some error in wine/a.exe log, I think I have not fully remove python-validity, just sudo systemctl mask python-validity at that time, so some other services may interrupt it. But I am very sure I have removed python3-validity packages for now.( I use sudo apt purge open-fprintd fprintd-clients python3-validity)

[maxso-216]

I don't know what I can help, but here photos of how I try to do a pairing with python-validity. Hope I am doing it correctly. python validity log.tar.xz.gpg.zip.001.zip python validity log.tar.xz.gpg.zip.002zip.zip python validity log.tar.xz.gpg.zip.003.zip Signed with this PPA key public key

[maxso-216]

It's been a long time, but I finally to get it paired. After decide to upgrading (with formatting) to Ubuntu 22.04, and a fingerprint reset, the program displace no error. But now, validity-sensors-tools -t led-dance displace PY_SSIZE_T_CLEAN macro must be defined for '#' formats error. This is due to python 3.10 changing, and related to validity-sensors-tools. For now, it successfully pair, and bugs solved.

[odyzzeus]

I've pushed partition table + signature from your logs. Please

• clone this project
• do a factory reset via BIOS
• follow the "Playground" instructions from the README

You don't need to fully install the project, just start the playground python session as root as PYTHONPATH=scripts:. python3 from the project directory. Repeat until there is no more reboot exceptions.

Hi there, I've been following your great work hoping I can use the fingerprinting on my X1 1st Gen. I have tried your recipe, but somehow the docker build does not produce a wine bin file, although it terminates "successfully". Could I be doing somethings obviously wrong? (I will upload the log file)

[odyzzeus]

wine-validity.log

[maxso-216]

I am sure you don't need a docker to pair the fingerprint.

To pair the fingerprint (assume 138a:0090), you just need to reset fingerprint data with BIOS, clone the repo, follow the playground instruction. This repo only provide pair tool for 138a:0090, to use it, use 3v1n0 /libfprint libfprint-2-tod-vfs0090. Do not use the initializer tool.

Also, somehow I need to boot into windows to reset the fingerprint. (Just boot and shutdown). I don't know why.

[odyzzeus]

Thanks you for your reply. Since I do not have windows on my machine, I thought the addapted version of wine would allow me to create a valid partition signature. Or am I missing something?

Anyways, the docker does not output a binary file so I could launch the .exe or at least I can't find it.

Any suggestions how to proceed?

[maxso-216]

Are you sure you are looking for correct fingerprint driver? When I check the spec of your laptop (x1 carbon 1st gen?), the fingerprints using is from AuthenTec, not Validity. Please check lsusb​ output for sure. Also, if I remember correctly, the docker is used for debugging use only, and not for any pairing usage. You should not use (and able to use) the docker for pairing. Just follow above instruction to pair your fingerprints. The docker will build a custom wine for capturing signature table in synaWudfBioUsb-sandbox .In other word, the docker should not involved in pairing. So, ignore the docker if you are just pairing the fingerprint.

[udaemon]

hi, I stumbled over this issue just the other day and I curiously followed your conversation bc I just got a thinkpad t460s with that exact fingerprint reader (138a:0090) and I have been fiddling around already for some hours to get it working here. following the steps here I always run into that same error: exception failed: 04af. what I did:

• removed all python-validity, open-fprint, validity-sensors-tools related stuff installed into the system, incl. services
• reset the fpr in bios
• cloned python-validity and eventually got python running (i. e. resolving dependencies like cryptography and pyusb)
• started the the script anew and let it open the fpr: open9x() what I get back is always:

  christoph@T460s ~/D/python-validity (master)> sudo PYTHONPATH=scripts:. python3
  Python 3.11.6 (main, Nov 14 2023, 09:36:21) [GCC 13.2.1 20230801] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from prototype import *
  >>> tls.trace_enabled=True
  >>> usb.trace_enabled=True
  >>> open9x()
  Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/christoph/Downloads/python-validity/validitysensor/init.py", line 50, in open
  open_common()
  File "/home/christoph/Downloads/python-validity/validitysensor/init.py", line 33, in open_common
  tls.parse_tls_flash(read_tls_flash())
                      ^^^^^^^^^^^^^^^^
  File "/home/christoph/Downloads/python-validity/validitysensor/flash.py", line 170, in read_tls_flash
  return read_flash(1, 0, 0x1000)
         ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/christoph/Downloads/python-validity/validitysensor/flash.py", line 134, in read_flash
  assert_status(rsp)
  File "/home/christoph/Downloads/python-validity/validitysensor/util.py", line 12, in assert_status
  raise Exception('Failed: %04x' % s)
  Exception: Failed: 04af
  >>> 

@maxso-216 do you have any further hints for me? I tried to have a look at the info you posted above (https://github.com/uunicorn/python-validity/issues/129#issuecomment-1161603518) but wasn't able to open it.

when I get you right I don't have to go through the procedure described here: https://github.com/uunicorn/synaWudfBioUsb-sandbox, right?

[maxso-216]

Let me recall my memory what I do to get the fingerprint work on T460s.... Here is a background information, the T460s has Windows preinstalled, so I shrink the windows partition and install a Ubuntu 20.04 alongside when I got the laptop.

Here what I do to get my fingerprint working on that time:

1. reset fingerprint data in BIOS
2. Boot into windows, do nothing, and reboot into linux system (Sound odd, but this is what I do. You can use a Windows VM to perform this action(?))
3. clone the repo git clone https://github.com/uunicorn/python-validity and set up playground cd python-validity && sudo PYTHONPATH=scripts:. python3 , in python terminal input: from prototype import *, then type open9x()
4. If the command open9x() return nothing about error, you have correctly set up the fingerprint
5. return to home direction cd ~, clone fork of 3v1no/linfprint (because the result is more accurate, thanks @Shade30 for your fork) git clone https://github.com/Shade30/libfprint
6. build and install forked libfrpint meson libfprint libfprint/_build && sudo ninja -C libfprint/_build install

The above instruction is what I do to get my fingerprint work. Hope it help in your case

[udaemon]

hey, thanks for your quick reply @maxso-216 ! I followed all of these steps as described by you - until 3. here I always run into the error. only difference to your procedure is I boot into a windows-vm instead. could that be the issue? I attach a log of two trials, one without prebooting into windows-vm, one with. log_python-validity.log

maybe @uunicorn is up to have a look at it and even willing to give another hint. thanks! :) have a good afternoon!

[maxso-216]

Hmm...I have not encounter any issue as I run the steps again. Maybe make sure you uninstall any libfprint related thing before pairing?

[maxso-216]

Hey @udaemon , it is possible to use windows vm to pair with fingerprint, but it requires more work to finish. So, the problem with using windows vm is, the VM does not emulate the host BIOS information, so if pairing is occurred in VM, signature will be different than the host. To solve the problem, we need to emulate the host BIOS information.

Assume you are using VirtualBox and name your windows vm called "windows10", follow these steps when you go into step 2 in above instruction.

1. Install dmidecode. This tool is used to find out the BIOS information of the host (T460s)
2. run sudo dmidecode. You will find it will output a lot of information, scoll up to session type 0.
3. we are now going to input BIOS information into VM. Replace windows10 with your name of the windows VM, and value of the string. Below step would just follow the pattern vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/something" "something", make sure you do not input incorrect information, otherwise you have to reset fingerprint again and redo the step.

If you input wrong, you would receive message when running VM. To remove wrong data, input vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVersio" "" # replace DmiSystemVersio with value to be remove

Open a new terminal and type: vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" "LENOVO" # Should be same as mine... unless you are not using a lenovo laptop vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVersion" "N1CET86W (1.54 )" #replace with your own value vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseDate" "12/06/2021" # replace with your own value

4. Scroll down to session type 1 to input system information.

vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" "LENOVO"' # Should be same.... vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct" "20F9A043HH" # replace with yours if value is different vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVersion" "ThinkPad T460s" # replace with yours value if value is different vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemSerial" "PC0E4WUK" # replace with your own value vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemSKU" "LENOVO_MT_20F9_BU_Think_FM_ThinkPad T460s" # replace with your value vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemFamily" "ThinkPad T460s" # replace with your value if differnt vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiSystemUuid" "b1b1abcc-328e-11b2-a85c-c86361a47c52" # replace with your value

5. Scoll down to session type 2 to input board information

vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiBoardVendor" "LENOVO" vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiBoardProduct" "20F9A043HH" # replace with your value if different vboxmanage setextradata windows10 "VBoxInternal/Devices/pcbios/0/Config/DmiBoardSerial" "L1HF65W01H5" # replace with your own value

if you finish typing all these, congratulations you finish the difficult part.

6. Boot into your VM, install fingerprint driver. If installed already, just boot , login and shutdown.
7. If open9x() return error in step 3, reset fingerprint in BIOS and redone the steps. Make sure you type the correct value. If it is still return error, inform me so I can investigate what wrong in the above steps.

[udaemon]

whohoo! @maxso-216, that worked like a charm! thanks so much. I can't believie it works. :)