support for 138a:0092 Validity Sensors

[zalexua]

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.

[uunicorn]

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.

[j-be]

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?

[Midou36O]

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? :)

[j-be]

@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.

[Midou36O]

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 !)

[Midou36O]

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

[Midou36O]

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).

[Midou36O]

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.

[Midou36O]

any updates?

[zalexua]

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 ?

[zalexua]

@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 ....

[zalexua]

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]

@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.

[zalexua]

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?

[uunicorn]

Let's start with enroll.

[zalexua]

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

[zalexua]

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.

[uunicorn]

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:

1. Factory rest (erases all flash contents)
2. Partition the internal flash
3. Upload the firmware extension (if any)
4. Calibration

Each of the first 3 steps end with a "reboot" command which causes the USB device to become disconnected / reconnected.

[uunicorn]

Looks like it can't find the firmware. Can you confirm you've got the .xpfwext file in the right place?

[zalexua]

Looks like it can't find the firmware. Can you confirm you've got the .xpfwext file 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

[uunicorn]

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

[uunicorn]

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

[Midou36O]

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.

[Midou36O]

I found the driver i used, here it is:

sp110169.zip (sorry i forgot where i downloaded this.)

[uunicorn]

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]

Oh, alright! Here is the file then:

notes.txt

[uunicorn]

@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.

[Midou36O]

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.

[uunicorn]

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.

[Midou36O]

Alright, i will retry and recompile this tommorow on my linux install and retry. (pls don't be dead for months again)

[uunicorn]

pls don't be dead for months again

I'll do my best. :sweat_smile:

[uunicorn]

I've pushed a new version of hacking/validiy-sensor branch on my Wine fork. Also, updated the synaWudfBioUsb-sandbox to split the output into three different files. Changes only work together, so you'll need to rebuild the wine:validity container.

[zalexua]

I've pushed a new version of hacking/validiy-sensor branch on my Wine fork.

should I take it and use for my further attempts? or it's better to continue with current branch?

[uunicorn]

It will be much easier to replay the recorded USB traffic later and to extract the blobs. Right now it looks like the logs are garbled due to multiple threads writing to the same pipe. But we can make sure the firmware issue is resolved first. Can you try hacking the run.sh so that the .xpfwext appears in the right spot?

[zalexua]

Can you try hacking the run.sh so that the .xpfwext appears in the right spot?

Yes, I can and will do. I will also compare how its organized inside my virtualbox VM to be sure it's the same. Then will update docker for wine and we will contine. I'm happy to see that we are on a fast track to get a success soon :)

[uunicorn]

I'm happy to see that we are on a fast track to get a success soon :)

Well.. being able to enroll & identify fingers using a.exe is just a start. Logs generated by a.exe will allow me to debug the Windows driver DLL interactively, without having any access to the real hardware. But adding support for this hardware depends on how different it is. The 009a is very different from 0097. IIRC 0090 (?) turned out to be a Match-On-Host device. Python-validity only supports Match-On-Chip at the moment and I doubt this will ever change.

[Midou36O]

Okay I finished compiling wine, I get new logs now. It seems to be crashing right after sleeping for some reason...? (./run.sh nop) 1651759024.log 1651759024-usb.txt 1651759024-wine.log

(./run.sh identify)

1651759348.log 1651759348-usb.txt 1651759348-wine.log

(./run.sh enroll)

1651759580.log 1651759580-usb.txt 1651759580-wine.log

[zalexua]

Let me note that an older driver sp110169.exe (which I've downloaded a year ago from HP web site) is different. Looks like it used the classic path:

[DestinationDirs]
...
FWextCopy=11       ;copy to \Windows\System32
...

[FWextCopy]
6_07f_hp_8x8pb.xpfwext

URL to download it is on top, in my first comment.

Ok, with your older code, for now. Driver sp88710.exe (suggested for Win7) is fresh one: I edited run.sh to have this: -v $PWD/$XPFWEXT:/root/.wine/drive_c/ProgramData/Validity/fwext/$XPFWEXT \ made sure that it's placed correctly in docker (interactively), what would be like in windows driver properties: (note - on Win7 the C:\ProgramData\ path does not exists anymore, probably automatically deleted after driver installation). After that I ran modified docker 4 times. Here are results logs.zip first time output was really huge and took quite log time before termination. Next times were faster and finished by crashes

Now I'm rebuilding docker to retry with your updated code.

[zalexua]

Ok, new wine + new docker. run.sh updated for custom path /root/.wine/drive_c/ProgramData/Validity/fwext/6_07f_hp_8x8pb.xpfwext Ran 3 times. Last 2 times generated files size looks almost identical, so I stopped. Interesting that in 1st time xxx-usb.txt file size was much bigger than on last 2 runs.

439K May  5 17:59 1651762761.log
775K May  5 17:59 1651762761-usb.txt
249K May  5 17:59 1651762761-wine.log
150K May  5 18:00 1651762803.log
 42K May  5 18:00 1651762803-usb.txt
199K May  5 18:00 1651762803-wine.log
150K May  5 18:00 1651762832.log
 42K May  5 18:00 1651762832-usb.txt
199K May  5 18:00 1651762832-wine.log

zalex-3times-updated-wine_driver-sp88710.zip

[uunicorn]

@zalexua ,

Thanks, we're definitely making some progress.

Here are results logs.zip

• 1651758770-1st-run-with-proper-xpfwext-location.log -- firmware upload completed successfully and ended with a device reboot (as expected).
• 1651759053-2nd-run-crashed.log -- calibration completed successfully but the driver crashed while attempting to create an enrollment (perhaps I missed some required parameter?).
• Remaining logs in are the same.

zalex-3times-updated-wine_driver-sp88710.zip

• 1651762761.log -- calibration completed successfully and results are stored in persistent driver variable. Crashed in the same place as above while creating the enrollment.
• 1651762803.log and 1651762832.log -- calibration data restored from the persistent driver variable. Crashed in the same place as above while creating the enrollment.

1651762761-usb.txt appears to be missing from the zip file. Can you attach it and I will try to recreate the crash locally.

[uunicorn]

@Midou36O ,

It seems to be crashing right after sleeping for some reason...?

Yes, the driver detects the ownership change and tries to do a factory reset. Wine's winusb,c is deliberately crashing the process to prevent this from happening accidentally. See https://github.com/uunicorn/python-validity/issues/77#issuecomment-770462263 and https://github.com/uunicorn/python-validity/issues/77#issuecomment-1117863947 for details.

TL;DR you need to do the factory reset thing. Either by commenting out the if statement in winusb.c or doing it manually via the BIOS setup.

[zalexua]

Ohh, I missed these actually 2 files to add to the zip:

   41K May  5 17:59 CalibrationData.blob
  775K May  5 17:59 1651762761-usb.txt

They were created during 1st run. I missed them to attach because of sorting by mod time and "CalibrationData.blob" less older than "1651762761-usb.txt"

# stat CalibrationData.blob | grep Modify
Modify: 2022-05-05 17:59:33.788740539 +0300

# stat 1651762761-usb.txt | grep Modify
Modify: 2022-05-05 17:59:26.308821028 +0300

[zalexua]

Attached now :) 2files-from-1st-run.zip

[uunicorn]

Thanks, CalibrationData.blob is the storage for the driver's persistent variable. It corresponds to the following in logs:

SetNamedValue CalibrationData=65

Blob value: 41020: ....

So, it will be recreated if I try to replay the same usb script which was written while the file was originally created.

[uunicorn]

Yay, got the same crash:

Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x000000018006f915).
Register dump:
 rip:000000018006f915 rsp:0000000002364140 rbp:00000000023641c0 eflags:00010202 (  R- --  I   - - - )
 rax:0000000002364190 rbx:0000000000000000 rcx:0000000000000000 rdx:0000000000000000
 rsi:0000000000000000 rdi:0000000000022f90  r8:000000000001fb08  r9:00000000000413c8 r10:0000000000000000
 r11:0000000002364000 r12:0000000000000002 r13:0000000000000010 r14:000000000237fba0 r15:0000000000000000

Now it's IDA time.

[Midou36O]

@Midou36O ,

It seems to be crashing right after sleeping for some reason...?

Yes, the driver detects the ownership change and tries to do a factory reset. Wine's winusb,c is deliberately crashing the process to prevent this from happening accidentally. See #77 (comment) and #77 (comment) for details.

TL;DR you need to do the factory reset thing. Either by commenting out the if statement in winusb.c or doing it manually via the BIOS setup.

alright, and after this? will Windows not be able to use the fingerprint? (not that i really mind this. But it can be reusuable after right?)

[uunicorn]

@Midou36O ,

It will blow away all the fingers you've enrolled in Windows so far. Also, if you boot Windows again after pairing with a.exe, Windows will detect another ownership change, and force another factory reset.

[Midou36O]

@Midou36O ,

It will blow away all the fingers you've enrolled in Windows so far. Also, if you boot Windows again after pairing with a.exe, Windows will detect another ownership change, and force another factory reset.

Alright, this looks fine to me, i will try to factory reset the fingerprint, @zalexua do you happen to know where can i reset the fingerprint from the bios? I'm kinda tired of recompiling wine over and over.

[zalexua]

One more detail about drivers:

Currently, I have 3 drivers to try, here are names for installation files downloaded from HP site:

1. sp110169.exe <- I downloaded a year ago. Our friend @Midou36O reported here that currently he is using/trying it, while his laptop has a little different model. This driver installer currently is not suggested by HP's support portal at all.

2. sp88710.exe <- current/fresh installer from HP site for my HP EliteBook 1040 G4 if select Windows7x64. This is what I'm using all the time last days here. Why for Win7? -> because when a.exe is crashing, I see kind of "Version: Windows 7" at the end. So I thought this driver is the best candidate for current troubleshooting. This driver is complicated that I should place .xpfwext file to a custom location.

3. sp135737.exe <- fresh installer for Windows10x64 from HP site for my HP EliteBook 1040 G4. And, also I checked that the same installer is suggested for @Midou36O 's laptop HP EliteBook x360 1030 G2. I did not collect logs/blobs with this driver and @Midou36O also seens not tried it. But we both could switch to this driver for troubleshooting if it makes sense. @uunicorn let us know please about that. This driver uses classic system32 path for .xpfwext file, I've checked.

p.s. full URLs or these 3 files can be searched in current discussion.

[Midou36O]

sp135737.exe <- fresh installer for Windows10x64 from HP site for my HP EliteBook 1040 G4. And, also I checked that the same installer is suggested for @Midou36O 's laptop HP EliteBook x360 1030 G2. I did not collect logs/blobs with this driver and @Midou36O also seens not tried it. But we both could switch to this driver for troubleshooting if it makes sense. @uunicorn let us know please about that. This driver uses classic system32 path for .xpfwext file, I've checked.

Actually, this is what i am using now, right after @uunicorn told us to update the wine docker image and synaWudfBioUsb-sandbox.