python-validity
python-validity copied to clipboard
uunicorn
support for 138a:0092 Validity Sensors
Laptop HP EliteBook 1040 G4
# lsusb | grep 138
Bus 001 Device 005: ID 138a:0092 Validity Sensors, Inc.
The :0092 was not mentioned in other issues, so reporting new one.
Tried to run https://github.com/uunicorn/synaWudfBioUsb-sandbox and received this error: 1612094659.log looks like a.exe. crashes for any mode [ nop | identify | enroll ], but it printed some blobs already. Driver downloaded from here https://ftp.hp.com/pub/softpaq/sp110001-110500/sp110169.exe and extracted it on a win machine by executing it (it's not inno packaged).
What result I should expect? How to move forward?
Reporting here in attempt to implement support.
1612094659.log
It appears that your device was previously paired with something (perhaps Windows from another partition). Whenever the Windows driver detects that a device was paired with another computer, it automatically tries to perform a factory reset. The reason why the driver thinks it is running on a different computer is because of hardcoded DMI tables in the Wine hacks branch. My fake winusb implementation intentionally crashes the process whenever the driver tries to perform a factory reset. It helps to analyze why it is happening. To proceed with a.exe approach you still need to do a factory reset yourself - either via BIOS settings or via the factory-reset.py script provided in this repo. Alternatively you can hardcode your real DMI values here: https://github.com/uunicorn/wine/blob/c855f17092a1e8373e477846dcbeb389e1d69e98/dlls/kernel32/cpu.c#L357 and rebuild the docker image.
I just got a HP Pro x2 612 G2, which telling from lsusb also uses a 138a:0092 Validity Sensors, Inc..
Now, since this is a tablet, fingerprint support would be super nice to have.
Is there any way I can contribute to get the 0092 officially supported? If not: how would I go about building my own support for it? Is this even worth attempting?
Is this even worth attempting?
If you find it useful for yourself wouldn't that be enough to make you motivated to work on it? :)
@Midou36O sure is :smile: and I'd be more than happy to tinker around with it.
Problem is: I have not the slightest of clue how and where to start. I figured I'd need to at least come up with something like this for the 0092? Not sure what else would be needed.
So, if this is one of those "yeah, you'll need a logic analyzer to dump i2c traffic" kind of tasks, then it is way beyond what I have at my disposal - and hence it wouldn't even be worth trying.
I'd probably look first for windows drivers and see if it contains anything interesting in it :P (I'm also looking to add this sensor to the supported list, so we are two !)
I believe you have to start by following these instructions. (look at the top of the post): https://github.com/uunicorn/synaWudfBioUsb-sandbox I currently am building wine through docker, i'll let you know when i'm reaching the phase where i have to enroll
Here are the 3 logs: 1647374744_nop.log 1647374795_identify.log 1647374654_enroll.log They all successfully ran. I'm not sure what is the next step, but if @uunicorn is willing to help us i'd be more than happy to do the necessary things (as long as it's not hardware related, like soldering).
I realised the real content is in notes.txt it has the blobs, but for security reasons i'll wait for the project owner to come and see how can i send him the data.
I'm back to this, trying again (do I really need this? ...). I did reset fingerprint from Bios and now the option disappeared, so I assume I really did reset it! I've also upgraded bios to recent one, just in case.
Trying to ruin it again and I again have basically identical crashes of a.exe . I've checked HP's web site and discovered that there are new (updated?) drivers. I downloaded both, tried both, any do not work, provided the same crash. Here are links just in case: if select Win7x64 drivers: Synaptics VFS7552 WBF Touch Fingerprint Driver 5.2.5019.26 Rev.A 36.0 MB Jun 26, 2018 https://ftp.hp.com/pub/softpaq/sp88501-89000/sp88710.exe if select Win10x64 drivers: Synaptics VFS7552 WBF Touch Fingerprint Driver 5.2.5030.26 Rev.A 6.7 MB Oct 12, 2021 https://ftp.hp.com/pub/softpaq/sp135501-136000/sp135737.exe
Hey @Midou36O , what is your laptop and can you post a link to driver download you used? Did you get notes.txt generated after successful a.exe execution? Or you have interrupted it? (I can see ^C characters at the end of your log files, which might indicate you interrupted it).
Could you share your blobs, so I could possibly continue with that ?
@uunicorn a year ago you suggested me to use factory-reset.py to do a factory reset. But how it can be used for not yet supported chips?
As I see in code, it tries to search a USB device across already implemented devices (class SupportedDevices), of course it could not find my 0092.
Then function factory_reset() needs to use "reset_blob" which of course is missing too, for the same reason.
I noted in the previous comment that I used BIOS way already and it did not change things.
So, I'm stuck that I cannot get a.exe working ....
Ok, I have an update here... I've passed the validity sensor to Win7 VM running on virtualbox, installed drivers pack Driver 5.2.5019.26 Rev.A and was able to configure it there. I could successfully login or unlock the win VM then. After that I could see an "Fingerprint Reset on Reboot" option in my BIOS again. Did the reset, I made sure the option disappeared from BIOS. After that, using that 5.2.5019.26 Rev.A driver in the docker, the a.exe did not crash anymore, wow!
But here is a new issue, when I run the docker container, I get this error all the time: for "identify":
=====================================
SetNamedValue UpdateFirmwareFailureCount=23
VT_UINT: 1
=====================================
ResumeIdle
USB >>>>>>>>>> In DllMain reason=3
sizeof(*params)=32
about to IOCTL_BIOMETRIC_CAPTURE_DATA
GetDeviceIoControlParameters 0000000002364340 00000000023642b8 0000000002364358
GetInputMemory
MyMem::Release
GetOutputMemory
MyMem::Release
MarkCancelable
USB >>>>>>>>>> In DllMain reason=2
GetDeviceIoControlParameters 0000000009defbd8 0000000009defbf8 0000000009defbe8
GetInputMemory
MyMem::Release
GetOutputMemory
MyMem::Release
StopIdle
=====================================
GetNamedValue CalibrationData
=====================================
Loaded 0 bytes of calibration data
USB >>>>>>>>>> WinUsb_QueryPipe alt-if=0 pipe=0
USB 9df3700 >>>>>>>>>> WinUsb_WritePipe PipeID=1
blackbox: usb 1 >>> 6f000e000000000000
rc=-4 send=0
>>>>>>>>>>> xfer Failed - LIBUSB_ERROR_NO_DEVICE
for "enroll":
=====================================
SetNamedValue UpdateFirmwareFailureCount=23
VT_UINT: 1
=====================================
ResumeIdle
USB >>>>>>>>>> In DllMain reason=3
about to Create Enrollment
GetDeviceIoControlParameters 00000000023641f0 00000000023641f8 0000000002364188
GetInputMemory
MyMem::Release
GetOutputMemory
MyMem::Release
StopIdle
=====================================
GetNamedValue CalibrationData
=====================================
Loaded 0 bytes of calibration data
USB >>>>>>>>>> WinUsb_QueryPipe alt-if=0 pipe=0
USB 7f3a8e93bb80 >>>>>>>>>> WinUsb_WritePipe PipeID=1
blackbox: usb 1 >>> 6f000e000000000000
rc=-4 send=0
>>>>>>>>>>> xfer Failed - LIBUSB_ERROR_NO_DEVICE
and probably reason of that is in the output of
$ lsusb -d 138a:
Bus 001 Device 035: ID 138a:0092 Validity Sensors, Inc.
the number of "Device XXX" is changing/increasing right at the when error appears.
It's changing also for "nop" command, which finishes this way:
=====================================
SetNamedValue UpdateFirmwareFailureCount=23
VT_UINT: 1
=====================================
ResumeIdle
USB >>>>>>>>>> In DllMain reason=3
about to de-init
USB 7fd8bc9aab80 >>>>>>>>>> WinUsb_ControlTransfer c0 14 0 0 2
Before: 0000
rc=-4
0009:fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0xc0010005,(nil),0x0001,0x00000000,0x237f870,(nil)): stub
0009:fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0xc0010005,(nil),0x0001,0x00000000,0x241e0,(nil)): stub
0009:err:eventlog:ReportEventW L"WinUsb_ControlTransfer: 0"
0009:trace:crypt:CryptGetHashParam (0x26080, 4, 0x237fa64, 0x237fa68, 00000000)
0009:trace:crypt:RSAENH_CPGetHashParam (hProv=00000002, hHash=00000003, dwParam=00000004, pbData=0x237fa64, pdwDataLen=0x237fa68, dwFlags=00000000)
0009:trace:crypt:CryptGetHashParam (0x26080, 2, 0x241e0, 0x237fa64, 00000000)
0009:trace:crypt:RSAENH_CPGetHashParam (hProv=00000002, hHash=00000003, dwParam=00000002, pbData=0x241e0, pdwDataLen=0x237fa64, dwFlags=00000000)
0009:trace:bcrypt:BCryptFinishHash 0x2cec0, 0x2a418, 104, 00000000
0009:fixme:bcrypt:BCryptFinishHash BCryptFinishHash: flags=0, alg_id 7
Hash out: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
0009:trace:bcrypt:BCryptDestroyHash 0x2cec0
0009:trace:crypt:CryptDestroyHash (0x26080)
0009:trace:crypt:RSAENH_CPDestroyHash (hProv=00000002, hHash=00000003)
USB >>>>>>>>>> In DllMain reason=3
USB >>>>>>>>>> WinUsb_Free
USB >>>>>>>>>> In DllMain reason=0
0009:trace:crypt:CryptReleaseContext (0x21ff0, 00000000)
0009:trace:crypt:RSAENH_CPReleaseContext (hProv=00000001, dwFlags=00000000)
0009:trace:crypt:CryptReleaseContext (0x21f50, 00000000)
0009:trace:crypt:RSAENH_CPReleaseContext (hProv=00000002, dwFlags=00000000)
0009:fixme:advapi:DeregisterEventSource (0xcafe4242) stub
0009:fixme:ntdll:EtwUnregisterTraceGuids deadbeef: stub
not sure is this an error or successful termination.
Each time a resulted log file is quite big - ~200KB. I could attach it if needed.
What's next? ....
@uunicorn a year ago you suggested me to use factory-reset.py to do a factory reset. But how it can be used for not yet supported chips?
The reset blob is the last one which is loaded right before the driver tries to run the "factory reset" command. From your 1612094659.log :
blackbox: usb 1 >>> n0602t000001d2fa601br3f7a293eb2b494430b9f07y80... --- this is the reset blob, although it looks garbled. Likely because the line was interleaved with some other output
...
blackbox: usb 1 >>> 10000000000000000000000000000.... --- this is the factory reset command (it was never executed. winusb.c prevents the reset by raising the SIGABRT signal which crashes the process instead)
Another way is to let a.exe to perform the factory reset by commenting out the if statement which is forcing it to crash instead: https://github.com/uunicorn/wine/blob/c855f17092a1e8373e477846dcbeb389e1d69e98/dlls/winusb/winusb.c#L375
the number of "Device XXX" is changing/increasing right at the when error appears.
This could be expected during the pairing / the initial device configuration.
Windows driver is intended to be triggered when the USB device is connected and enumerated.
It is smart enough to detect the current state of the initialization and continues where it left of.
Unfortunately a.exe is not smart enough to detect device connect/disconnect events, so the idea is to manually restart it a few times (each time saving the logs, as it goes through different phases of initialization).
Each time a resulted log file is quite big - ~200KB. I could attach it if needed.
Please. upload them. I'll have a look.
Please. upload them. I'll have a look.
With which command ( nop | identify | enroll ) I should try run it multiple times? For which of the commands I should upload the log?
I ran "./run.sh enroll" 10 times, all repeats generated log files size is almost identical (+- up to 5 bytes). Here is last (10th run) one 1651696432.zip
Interesting detail about initial device self-disconnections. I recall when I "attached" the 138a:0092 USB device to virtualbox with Win7 and installed driver - something happened and it became unattached from virtualbox itself. I wan surprised. I attached it again, and after some X seconds it self-unattached again. I repeated to attach probably 3-4 times, until it stayed that way attached constantly. After that I ran a dedicated Synaptic tool (installed together with driver) to added my finger prints.
all repeats generated log files size is almost identical
That's probably because something is broken. I'll have a look, thanks.
I repeated to attach probably 3-4 times
Yes, this is expected. There are a few steps which must happen during the pairing / the initialization:
- Factory rest (erases all flash contents)
- Partition the internal flash
- Upload the firmware extension (if any)
- Calibration
Each of the first 3 steps end with a "reboot" command which causes the USB device to become disconnected / reconnected.
Looks like it can't find the firmware. Can you confirm you've got the .xpfwext file in the right place?
Looks like it can't find the firmware. Can you confirm you've got the
.xpfwextfile in the right place?
Of course, here is content of folder:
-rw-rw-rw- 1 zalex zalex 306201 May 21 2018 6_07f_hp_8x8pb.xpfwext
-rwxr-xr-x 1 zalex zalex 1159527 Jan 31 2021 a.exe
-rw-r--r-- 1 zalex zalex 3023 Jan 31 2021 breakpoints.c
-rw-r--r-- 1 zalex zalex 252 Jan 31 2021 breakpoints.h
-rw-r--r-- 1 zalex zalex 82966 Jan 31 2021 hello.cc
-rw-r--r-- 1 zalex zalex 265 Jan 31 2021 mk
-rw-r--r-- 1 zalex zalex 56576 Jan 31 2021 notes.txt
-rw-r--r-- 1 zalex zalex 1868 Jan 31 2021 README.md
-rwxr-xrwx 1 zalex zalex 387 Jan 31 2021 run-docker-only.sh
-rwxr-xrwx 1 zalex zalex 444 Jan 31 2021 run.sh
-rw-rw-rw- 1 zalex zalex 2857408 May 21 2018 synaWudfBioUsb.dll
-rw-r--r-- 1 zalex zalex 10 Jan 31 2021 usb.txt
I've also checked that the 6_07f_hp_8x8pb.xpfwext file properly exported to docker (run-docker-only.sh - modified run.sh to not execute wine64 and stay in docker session interactivelly):
# ./run-docker-only.sh
root@59c0cfe9a181:~# ls -l /root/.wine/drive_c/system32/
total 300
-rw-rw-rw- 1 1000 1000 306201 May 21 2018 6_07f_hp_8x8pb.xpfwext
This is from driver for Win7x64: Synaptics VFS7552 WBF Touch Fingerprint Driver 5.2.5019.26 Rev.A 36.0 MB Jun 26, 2018 downloaded here https://ftp.hp.com/pub/softpaq/sp88501-89000/sp88710.exe From this official page https://support.hp.com/us-en/drivers/selfservice/hp-elitebook-1040-g4-notebook-pc/11623738
From the logs it is stuck in the step 3 of the list above.
It detects that the flash was partitioned correctly and the pairing keys are loaded.
It manages to start the TLS session successfully, proving that the keys are correct and belong to the "owning" computer.
Next, it tries to get the list of modules for the loaded .xpfwext on the flash (cmd 4302) and the device responds with an error (b004) which means "no firmware was loaded yet". At this stage the driver supposed to start uploading the firmware. Instead it sends the reboot command (cmd 050200) and sets the persistent driver value UpdateFirmwareFailureCount to 1.
So, yeah, I think the driver can't find the firmware file. Looking at the .inf from the driver you've referenced, the correct location for .xpfwext is not in system32:
[DestinationDirs]
...
FWextCopy=24, ProgramData\Validity\fwext; copy to "system drive"\ProgramData\Validity\fwext
...
[FWextCopy]
6_07f_hp_8x8pb.xpfwext
Further, from logs:
0021:fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0xc004000b,(nil),0x0001,0x00000000,0x60afc60,(nil)): stub
0021:fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0xc004000b,(nil),0x0001,0x00000000,0x2d1e0,(nil)): stub
0021:err:eventlog:ReportEventW L"110"
This happens immediately before the reboot command.
From the synaWudfBioUsb.dll RT_MESSAGETABLE:
MessageId = 0xc004000b
Fingerprint Sensor firmware extension update failed: %1.\r\n\000\000
Don't know what exactly "110" means, but my guess it's (windows/winerror.h):
#define ERROR_OPEN_FAILED 110
Hey @Midou36O , what is your laptop and can you post a link to driver download you used? Did you get notes.txt generated after successful a.exe execution? Or you have interrupted it? (I can see ^C characters at the end of your log files, which might indicate you interrupted it). Could you share your blobs, so I could possibly continue with that ?
My Laptop is a "HP EliteBook x360 1030 G2", I don't know where did i put the driver but i will check later on my devuan VM (after restoring it).
Yes i got a notes.txt file, i could send it to you but i'd like to avoid sending my fingerprints :P, as for the interruptions it's because the program tells me it finished and doesn't do anything else, thus why interrupted it (look at the picture below).
Going back to the the notes.txt, if you got a way to send it to you safely let me know! (i am on matrix as @midou:projectsegfau.lt) If you need anything else let me know! I really want to make the fingerprint work on my Linux laptop.
Hi @Midou36O , notes.txt is a part of the project and is under a revision control. a.exe neither reads nor writes into it.
I used this file to document my analysis of the protocol.
@Midou36O ,
Looking at your logs:
1647374744_nop.log 1647374795_identify.log 1647374654_enroll.log
It appears that the very first command "get ROM info" (cmd 01) is always failing with an error 0104 (dunno what that means). The driver then tries to open a window, but that fails as well (probably because it's running inside a docker container without any access to an X server running on the host, or maybe because Wine was built without a gui support):
0022:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0022:err:winediag:nodrv_CreateWindow The graphics driver is missing. Check your build!
In any case, something weird is happening with your sensor since it can't even answer the basic "ROM info" request.
The driver then tries to open a window, but that fails as well (probably because it's running inside a docker container without any access to an X server running on the host, or maybe because Wine was built without a gui support)
Indeed it was built inside a docker container. This is expected.
It appears that the very first command "get ROM info" (cmd 01) is always failing with an error 0104 (dunno what that means).
That's weird, maybe it could be bcause i'm using VMWare to test this out? I got a linux install as dual boot so i could retry on linux if it is needed.
That's weird, maybe it could be bcause i'm using VMWare to test this out? I got a linux install as dual boot so i could retry on linux if it is needed.
Yep, this could be the reason. Once a driver have established a TLS connection between a device and a host, any "clear text" commands will fail.
Alright, i will retry and recompile this tommorow on my linux install and retry. (pls don't be dead for months again)