[fprint] Writing a driver for138a:003c (VFS471)

[Vasily Khoruzhick]

On Mon, Oct 13, 2014 at 9:31 PM, Jonathan Daniel
<jonathandaniel at email.com> wrote:
> Hello,

Hi Jonathan,

Firstly, please don't use HTML formatting in your messages to mail list.

> I have started the journey to write a driver for this device (138a:003c), I
> own this device, its
> built in to the HP Elitebook 8560w. From what i've gathered I need to sniff
> the USB data
> from a working driver and send/receive the right data at the right moment
> with libusb.
>
> So i'm currently dumping all the traffic, and when I scan a finger, I get
> ~84059 bytes from
> the device back to the host, sometimes twice or thrice. There is more data
> sent and received
> but this is the biggest bulk, so i'm thinking this is the image itself, is
> that a solid assumption
> or could it be the device sends something else this large. Also, how can I
> check if it's true, is there
> a way to transform the bytes into an image just to see if its right? How can
> I make sure it's not encrypted,
> and if it's encrypted what are my options?

Take a look at those bytes, it's very likely that sensor is 8bpp or
even 4bpp, so image pixels should contains similar values (at least at
the beginning and at the end of image). If they look like a random
data - then it's very likely that protocol is protect with encryption.

There could be 2 options: whole protocol is encrypted or only image
payload is encrypted.

If image is encrypted, you should analyze traffic and figure out (with
a lot of tries :)) which one command enables encryption. Usually, I'm
omitting a single transfer and then just capturing traffic again to
see if there're differences.

If whole traffic is encrypted, it's very likely that you won't be able
to replay whole sequence with a device, and it'll be close to
imposible to reverse engineer protocol without disassembling Windows
driver.

Regards
Vasily

>
> Thanks in advance,
> J. Daniel