search

uunicorn / python-validity

Validity fingerprint sensor prototype
MIT License
978 stars 82 forks source link

support for 138a:0092 Validity Sensors #77

Open zalexua opened 3 years ago

zalexua commented 3 years ago

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 commented 2 years ago

Cool, let's keep it this way:

If for some reason we'll be stuck with one of them, we can still keep going with the other.

zalexua commented 2 years ago

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

After I did pairing in Win7 under virtualbox. Just do enable the checkbox and save+reboot: 1 during the reboot it asked to confirm: 2 right after that bios self-rebooted again and I entered bios right away again to see what changed -> the option has disappeared: 3

Midou36O commented 2 years ago

Thanks, i got the logs now:

(nop) 1651780141.log 1651780141-usb.txt 1651780141-wine.log

(identify) 1651780168.log 1651780168-usb.txt 1651780168-wine.log

(enroll) 1651780030.log 1651780030-usb.txt 1651780030-wine.log

Zip compressed logs (if you want to download it all at once) LOGS.zip

uunicorn commented 2 years ago

@Midou36O ,

looks like you've got the same problem with the firmware file location:

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,0x264d0,(nil)): stub
0021:err:eventlog:ReportEventW L"110"

See https://github.com/uunicorn/python-validity/issues/77#issuecomment-1118013219

Check your .inf file for correct .xpfwext file location.

Midou36O commented 2 years ago

Sorry to bother you but how can i do so, like it seems to be correct for me..

Midou36O commented 2 years ago

image Seems like the path is different. (This is windows 11 in a virtual machine)

Midou36O commented 2 years ago

image image image

It is actually correct!

uunicorn commented 2 years ago

@zalexua ,

Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x000000018006f915). Now it's IDA time.

It seems there is one extra IOCTL required by this driver before we can call the create enrollment IOCTL. It corresponds to the WINBIO_SENSOR_INTERFACE.SetMode adapter method.

I've pushed a new version of hello.cc and recompiled a.exe. Can you please:

uunicorn commented 2 years ago

@Midou36O ,

It is actually correct!

Well, the error is still saying that it can't open the firmware file. Can you check if you are using the right driver DLL? SP135737 contains synaWudfBioUsb146.dll instead of synaWudfBioUsb.dll, so you had to rename it.

Sha1s:

zalexua commented 2 years ago

I've pushed a new version of hello.cc and recompiled a.exe. Can you please:

Here it is: 2runs-with-newA-driver-sp88710.zip

 556K May  6 09:39 1651819077.log
 827K May  6 09:38 1651819077-usb.txt
 472K May  6 09:41 1651819077-wine.log
 233K May  6 09:42 1651819337.log
  80K May  6 09:42 1651819337-usb.txt
 348K May  6 09:44 1651819337-wine.log
  41K May  6 09:38 CalibrationData.blob

Here are 2 runs. 3rd run skipped from zip because resulted files looked identical size to 2nd run. Both times wine could not finish and ..-wine.log file was slowly growing by lines ending "....transfer=-7!", speed ~1KB in 5 seconds, I inrterrupted wine by Ctrl+C after 1 minutes and 30 seconds (correspondingly) of such growing.

uunicorn commented 2 years ago

Both times wine could not finish and ..-wine.log file was slowly growing by lines ending "....transfer=-7!",

From what I can see, it was probably waiting for a finger. Can you try again and swipe the finger when you see this transfer=-7?

zalexua commented 2 years ago

From what I can see, it was probably waiting for a finger

ohh, indeed! When I touch and THEN remove finger, in console (that's what goes to "${NOW}.log" I guess) I see activity for a few seconds. I can repeat a few/many times, it's in a loop. What I should do? (I'd not want to attach blobs of fingers scanned here :) )

uunicorn commented 2 years ago

It's an enrollment, so repeat it until it's happy to commit the enrolled finger. May take a few scans.

uunicorn commented 2 years ago

It could be using wrong ioctls though, in which case it will never succeed. Try 10 scans, if still no luck - ^C and upload the logs.

uunicorn commented 2 years ago

What I should do? (I'd not want to attach blobs of fingers scanned here :) )

I can share a certificate so you can smime the logs, if you concerned about your personal biometric data.

uunicorn commented 2 years ago

Or better yet, search for uunicorn on https://keyserver.ubuntu.com/ and GPG zipped logs using the key. You can email them to address associated with the key.

zalexua commented 2 years ago

You can email them to address associated with the key.

Ok, I touched probably 13 times (or 12 or 14, could count +-1) and a.exe finished itself succesfully. Did it only once.

 1951354 May  6 13:05 1651831454.log
 1494212 May  6 13:05 1651831454-usb.txt
 1220628 May  6 13:05 1651831454-wine.log
   41020 May  6 13:04 CalibrationData.blob

I hope I encrypted a zip correctly. Sent now to the email.

uunicorn commented 2 years ago

Awesome. Got the whole enroll exchange and can replay it as well. Can you repeat for identify: once with correct and once with incorrect fingers?

Midou36O commented 2 years ago

@Midou36O ,

It is actually correct!

Well, the error is still saying that it can't open the firmware file. Can you check if you are using the right driver DLL? SP135737 contains synaWudfBioUsb146.dll instead of synaWudfBioUsb.dll, so you had to rename it.

Sha1s:

* SP135737: da1c9dc2cadfb0f28e786779d66c38a49db2a998

* SP88710: f218a72a632dad96c5c6b63c691e5476ca27c458

@uunicorn

No dice, that did not work (I checked the checksum, they are correct, renamed the file to the appropriate name).

zalexua commented 2 years ago

Can you repeat for identify: once with correct and once with incorrect fingers?

For each log I touched each finger 2 times!!! Touched 2 times to get a.exe exited itself. 1st log - correct (if I remember correctly :) ) finger. 2nd log - incorrect one.

  270752 May  6 17:57 1651849005.log
   88444 May  6 17:57 1651849005-usb.txt
  472688 May  6 17:57 1651849005-wine.log
  270752 May  6 17:57 1651849047.log
   88444 May  6 17:57 1651849047-usb.txt
  472814 May  6 17:57 1651849047-wine.log

Logs sent to the email.

uunicorn commented 2 years ago

It looks like it failed to find a matching template your finger in both runs.

zalexua commented 2 years ago

How it should look like in console when it actually finds a match?

uunicorn commented 2 years ago

There should be fewer zeroes at the start of the Got back 0x880 bytes line. E.g:

match:
Got back 0x880 bytes: 030000001c000000010500000000000515000000c5698517bcff12e72496b763ed04000000000000000000000000000000000000000000000000000000000000000000000000000000000000f7000000000000000d67079ae5e98149c509f1de7b07790b9f4fde7357621a829cd10de782c9a48a000000000800000000000000556e69636f726e0000000....
no match:
Got back 0x880 bytes: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f800980000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
uunicorn commented 2 years ago

Ok, good news:

Bad news: Sensor type is 0x0d51 and it is not present in the generated_tables.py. This likely means that I will have to revisit this monstrosity https://github.com/uunicorn/python-validity/issues/3#issuecomment-650517276 but in the new DLL to figure out how to construct calibration/capture/identify script.

zalexua commented 2 years ago

Tried to play with "identify". Looks like even single touch is enough to get a.exe finished, but there is a delay after touching and termination. So my steps are with timing in seconds: 0 - starting docker with "identify" +5 - a.exe printed a lot in console and now is waiting. 0 - I touch by finger here and keep it touched on sensor. Right after I touch, in console ~20 short lines are printed and now again a.exe is waiting something. +6 - console huge output is resumed, ended by: Got back 0x880 bytes: 000000000000000......zeroes here ........ I remove finger here.

I tried to not keep finger on the sensor and the behavior is basically the same.

I tried to "enroll" a few times for other fingers and then test "identify" - behavior is the same.

Waiting for further instructions form @uunicorn

Midou36O commented 2 years ago

So:

Basically my conclusion is to first find why the drivers does not work on windows first before going any further.

uunicorn commented 2 years ago

I've created a device/0092 branch to capture what we've found so far. It may even work a little. At least all the blobs seems to be correct. Can you give it a go?

Midou36O commented 2 years ago

@uunicorn 

( midou  |  python-validity | (branch) device/0092 | python 3.10.4 ) >  sudo PYTHONPATH=.:scripts/ python3 
Python 3.10.4 (main, Mar 25 2022, 16:46:29) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from prototype import *
>>> open9x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 48, in open
    open_common()
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 33, in open_common
    upload_fwext()
  File "/home/midou/git_rep/python-validity/validitysensor/upload_fwext.py", line 24, in upload_fwext
    fwi = get_fw_info(2)
  File "/home/midou/git_rep/python-validity/validitysensor/flash.py", line 99, in get_fw_info
    assert_status(rsp)
  File "/home/midou/git_rep/python-validity/validitysensor/util.py", line 10, in assert_status
    raise Exception('Signature validation failed: %04x' % s)
Exception: Signature validation failed: 044f

What does 044f mean?

>>> factory_reset()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/sensor.py", line 85, in factory_reset
    assert_status(usb.cmd(reset_blob))
  File "/home/midou/git_rep/python-validity/validitysensor/util.py", line 12, in assert_status
    raise Exception('Failed: %04x' % s)
Exception: Failed: 0315
>>>

Factory reset throws 0315 error code

uunicorn commented 2 years ago

@Midou36O , Dunno, none of these errors making any sense to me. Can you try doing the factory reset from BIOS first?

Midou36O commented 2 years ago

@uunicorn

Can you try doing the factory reset from BIOS first?

I already did, i could redo it, maybe that will solve it... (Making fingeprint working really is confusing)

uunicorn commented 2 years ago

Ok, Failed: 0315 means "trying to run clear-text command while TLS is already established". Which makes sens, since the previous failed command was trying to upload the firmware. Why the firmware upload has failed and what is error 044f is probably the right question.

Midou36O commented 2 years ago

So to clear things up: (factory reset from bios is already done from this stage) first start and run comes with this (expected behavior)

Python 3.10.4 (main, Mar 25 2022, 16:46:29) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from prototype import *
>>> open9x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 48, in open
    open_common()
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 29, in open_common
    init_flash()
  File "/home/midou/git_rep/python-validity/validitysensor/init_flash.py", line 166, in init_flash
    reboot()
  File "/home/midou/git_rep/python-validity/validitysensor/sensor.py", line 81, in reboot
    raise RebootException()
validitysensor.sensor.RebootException

after that running factory reset:

>>> factory_reset()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/sensor.py", line 85, in factory_reset
    assert_status(usb.cmd(reset_blob))
  File "/home/midou/git_rep/python-validity/validitysensor/usb.py", line 104, in cmd
    self.dev.write(1, out)
  File "/usr/lib/python3.10/site-packages/usb/core.py", line 989, in write
    return fn(
  File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 837, in bulk_write
    return self.__write(self.lib.libusb_bulk_transfer,
  File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 938, in __write
    _check(retval)
  File "/usr/lib/python3.10/site-packages/usb/backend/libusb1.py", line 604, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 19] No such device (it may have been disconnected)

I guess this is also expected behavior because it tells me reload the python REPL

Midou36O commented 2 years ago

Restarting the python repl now greets me with an error:

Python 3.10.4 (main, Mar 25 2022, 16:46:29) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from prototype import *
>>> open9x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 48, in open
    open_common()
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 33, in open_common
    upload_fwext()
  File "/home/midou/git_rep/python-validity/validitysensor/upload_fwext.py", line 54, in upload_fwext
    write_flash_all(2, 0, fwext)
  File "/home/midou/git_rep/python-validity/validitysensor/flash.py", line 154, in write_flash_all
    write_flash(partition, ptr, chunk)
  File "/home/midou/git_rep/python-validity/validitysensor/flash.py", line 145, in write_flash
    assert_status(rsp)
  File "/home/midou/git_rep/python-validity/validitysensor/util.py", line 12, in assert_status
    raise Exception('Failed: %04x' % s)
Exception: Failed: 0403

(if DEBUG logs are needed let me know)

Midou36O commented 2 years ago

the 3rd time i quit and re-run the python REPL we get to the error i reported earlier that does not makes much sense (for now):

Python 3.10.4 (main, Mar 25 2022, 16:46:29) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from prototype import *
>>> open9x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 48, in open
    open_common()
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 33, in open_common
    upload_fwext()
  File "/home/midou/git_rep/python-validity/validitysensor/upload_fwext.py", line 24, in upload_fwext
    fwi = get_fw_info(2)
  File "/home/midou/git_rep/python-validity/validitysensor/flash.py", line 99, in get_fw_info
    assert_status(rsp)
  File "/home/midou/git_rep/python-validity/validitysensor/util.py", line 10, in assert_status
    raise Exception('Signature validation failed: %04x' % s)
Exception: Signature validation failed: 044f

It stays on this error now after trying over and over.

uunicorn commented 2 years ago

Ah, now I think I can see the whole picture:

  1. the first step of initialization (partition the flash) has completed successfully and ended with the reboot command
  2. the second step - upload firmware extension.
    • First we use the get_fw_info (4302) commad to check if the firmware was already uploaded.
    • If this command fails with error 04b0, it means the firmware partition is blank
    • we start uploading the firmware extension in chunks
    • one of the chunks has failed with Failed: 0403
  3. the next time you try to open the device, the get_fw_info (4302) command notices that the firmware partition is no longer blank, but because we never finished writing the firmware, validation has failed with an error 044f.

Note that working with real hardware is rarely idempotent. I need to know the full history to of what was going on to make any sense of it. Best if you enable debugging output as well.

So the real problem was the Failed: 0403 during the firmware upload phase. My guess is that the firmware partition is too small. I'll check what are the partition sizes in the a.exe logs.

Midou36O commented 2 years ago

Yes, one moment, i will reboot and retry the same procedures, with debug enabled this time.

uunicorn commented 2 years ago

6_07f_hp_8x8pb.xpfwext is 306201 bytes long, 286016 of which is the actual firmware. Current firmware partition size in validitysensor/init_flash.py is declared as 0x0003e000 == 253952, which was based on 009a and 0097 devices.

uunicorn commented 2 years ago

Wait, I'm gonna push the fix soon-ish.

uunicorn commented 2 years ago

Nope, I can;t find logs for the very first initialization step which does the partitioning. We'll need to wait for @zalexua to do the factory reset and run a.exe again.

uunicorn commented 2 years ago

Actually, you can do it @Midou36O . This step goes before the firmware upload, so your setup should be good.

Midou36O commented 2 years ago

That's what i'm trying now, i hope it doesn't get stuck like last time because i'm really out of ideas on fixing this right now.

uunicorn commented 2 years ago

It does not matter if it stuck. We need the very first log after the factory reset.

Midou36O commented 2 years ago

1651968708-wine.log 1651968708-usb.txt 1651968708.log (nop command) Here they are (right after the factory reset, fingerprint reader was untouched.)

uunicorn commented 2 years ago

Yep, that the right stuff, thanks.

uunicorn commented 2 years ago

Pushed the partition size fix on device/0092 branch. Please factory reset and test.

Midou36O commented 2 years ago

first run: (factory reset done before running this command)

Python 3.10.4 (main, Mar 25 2022, 16:46:29) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from prototype import *
>>> open9x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 48, in open
    open_common()
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 29, in open_common
    init_flash()
  File "/home/midou/git_rep/python-validity/validitysensor/init_flash.py", line 159, in init_flash
    erase_flash(5)
  File "/home/midou/git_rep/python-validity/validitysensor/flash.py", line 126, in erase_flash
    assert_status(tls.cmd(pack('<BB', 0x3f, partition)))
  File "/home/midou/git_rep/python-validity/validitysensor/util.py", line 12, in assert_status
    raise Exception('Failed: %04x' % s)
Exception: Failed: 04ae

Second run after restarting the REPL:

Python 3.10.4 (main, Mar 25 2022, 16:46:29) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from prototype import *
>>> open9x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 48, in open
    open_common()
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 32, in open_common
    tls.open()
  File "/home/midou/git_rep/python-validity/validitysensor/tls.py", line 137, in open
    self.make_keys()
  File "/home/midou/git_rep/python-validity/validitysensor/tls.py", line 160, in make_keys
    pre_master_secret = skey.exchange(ec.ECDH(), self.ecdh_q)
AttributeError: 'Tls' object has no attribute 'ecdh_q'

I have to sleep now so you will have to wait for tomorrow so I can continue, my apologies

uunicorn commented 2 years ago

Oh, my bad. Partition 5 is gone now.

Midou36O commented 2 years ago

Oh, my bad. Partition 5 is gone now.

That surely doesn't mean bad news... does it?

uunicorn commented 2 years ago

Not really. Just pushed a fix.

Midou36O commented 2 years ago

This time it seems to be working, no error except from the expected validitysensor.sensor.RebootException

UPDATE:

Python 3.10.4 (main, Mar 25 2022, 16:46:29) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from prototype import *
>>> open9x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 48, in open
    open_common()
  File "/home/midou/git_rep/python-validity/validitysensor/init.py", line 34, in open_common
    sensor.open()
  File "/home/midou/git_rep/python-validity/validitysensor/sensor.py", line 244, in open
    raise Exception('Device %s is not supported (sensor type 0x%x)' %
Exception: Device 57K0 FM- 154-001    is not supported (sensor type 0x1825)
>>>