Struggling to verify enrolled finger.

[brys0]

Hello. I am currently working on writing a version of this PoC in Go due to better stability of libusb in go (using gousb) and knowledge I have of go. I have successfully communicated with the device even creating the verify, abort, and enrolled fingers commands thanks in part with your help, and creation of this project :)

I however am having issues with the verify fingerprint command working when I enroll my finger in linux. Weirdly, running Windows Hello and enrolling my finger through windows, and then trying the verify command (on linux, with my driver) works absolutely fine. Weirder still copying the exact payload windows hello created for the commit command sent to the reader, and then trying to run that on my linux driver does also not work, even though the payload is the exact same, byte for byte. I am pretty stumped and have no idea what could be causing this issue. I double checked that the "finger_info_all" command shows the exact same data set on the finger too. But for some reason it only works enrolling my finger on windows, not on linux.

[brys0]

If you could give me any guidance or help that'd be very appreciated.

Thank you for your time.

[brys0]

Adding some further data here to help you.

Windows Hello Finger enroll commit command

0000   40 ff 11 f5 01 05 00 00 00 00 00 05 15 00 00 00
0010   9a ad 9f b0 a5 54 eb db 73 a3 57 db e9 03 00 00
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040   00 00 00 00 00 00 00 00

My Linux Driver fingerprint enroll commit command:

0000   40 ff 11 f5 02 05 00 00 00 00 00 05 15 00 00 00
0010   9a ad 9f b0 a5 54 eb db 73 a3 57 db e9 03 00 00
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040   00 00 00 00 00 00 00 00

As you can see it is the exact same. I am at quite a loss.

[brys0]

Okay, I think I finally have it working. I have two questions however.

In the enroll command what is the purpose of starting the payload with BBBB ?

Then for the commit command what is the purpose of starting the payload with BB and then 0xf0 and why do we have to add +5 to the finger_id?

Any help would be appreciated as I am rather confused why these things seem to be required.

[depau]

Hey @brys0,

In the enroll command what is the purpose of starting the payload with BBBB ?

It does not start with BBBB, that's the format string: https://docs.python.org/3.8/library/struct.html#format-strings

It just means it should pack 4 unsigned bytes into the payload.

Then for the commit command what is the purpose of starting the payload with BB and then 0xf0 and why do we have to add +5 to the finger_id?

Same here for BB. I add 5 because that's what the Windows driver seems to do according to my captures. I have no idea why that's needed but it works that way.

[depau]

As per your other questions in the previous posts I'm not sure what could be causing that. You can try comparing WireShark captures from both Windows and Linux and see if there are any differences.

[brys0]

Thank you so much! I haven't yet managed to figure out why the exact payload didn't work, but as long as something works it's better than what it was before.

I don't know if you ever tried implementing this but is it possible to get an image from the reader? I tried sending it 00 09 I believe it was to capture an image, and it seemed like it worked, and now trying to send that command causes it go unresponsive, but the other commands do work. I'm confused on how to implement something like seeing your fingerprint and any guidance would be greatly appreciated!

Thank you again for your time and expertise

[depau]

I don't know if it's possible. I extracted some commands from my Windows driver, they are listed here: https://github.com/depau/Elan-Fingerprint-0c4c-PoC/blob/main/elanfp.py#L80-L93 The Windows driver has some registry keys that suggest it might be possible but I couldn't get anything of the sort to work with my reader.

If it goes unresponsive it might be a good sign: maybe try listening on another USB endpoint after sending the command, for instance EP 4.