Re: [fprint] New fingerprint reader: 08ff:1680 AuthenTec, Inc.
Petr, I have noticed that the site mentions that transmission from the reader to the computer is encrypted, some mention that this is optional and the readers from DigitalPersona (the 4500 anyway) also employ encryption, is this the general trend and does it make it difficult for us to write drivers? I mean we would have to reverse-engineer the code to decipher a proprietary encryption protocol (I am not a cryptanalyst and I am unsure if I could reverse engineer a relatively complex driver). I do not have a 1660 so I cannot really try out your code but I have purchased a Eikon scanner that incorporates the TCS4C reader, I will try to get that working soon. I will, of course, submit my code here for your perusal. Keep up the good work, I wish you luck. Benjamin. ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
Re: [fprint] New fingerprint reader: 08ff:1680 AuthenTec, Inc.
Hi, the thing is, that I don't know much about the encryption nor about the protocol itself. I was just lucky and I figured out, how to activate the device, so it is transmitting the fingerprint in (almost) plain PGM stripes. I am even not sure, if the original driver is transmitting the fingerprint encrypted (I just can't recognize the data format). It would be nice, if we can use all functions of the device, including the encryption. But right now, all I want to do is to make the device working instead of being dead piece of plastic. I figured the way, how to use PGM mode just by experimenting with the device (it might be so, that the device is not encrypted until it is activated - so my credit might not be so great). I don't think, that the encryption is here for obfuscating the protocol, but it is meant to secure the transmitted data - it might not be difficult to activate unencrypted mode also for other devices, the encryption protocol also might be straightforward (i.e. computer sends it's public key, the device answers with encrypted and signed fingerprint). Dne Wed, 30 Mar 2011 16:25:15 +0200 Ben Green ben.gr...@pktsolutions.com napsal(a): Petr, I have noticed that the site mentions that transmission from the reader to the computer is encrypted, some mention that this is optional and the readers from DigitalPersona (the 4500 anyway) also employ encryption, is this the general trend and does it make it difficult for us to write drivers? I mean we would have to reverse-engineer the code to decipher a proprietary encryption protocol (I am not a cryptanalyst and I am unsure if I could reverse engineer a relatively complex driver). I do not have a 1660 so I cannot really try out your code but I have purchased a Eikon scanner that incorporates the TCS4C reader, I will try to get that working soon. I will, of course, submit my code here for your perusal. Keep up the good work, I wish you luck. Benjamin. ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint -- Petr Dlouhý ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
Re: [fprint] New fingerprint reader: 08ff:1680 AuthenTec, Inc.
Hi, I played with this a little more. I wrote quickdirty prototype based on aes2501 (1). You can download it from [2], it contains also some of the logs I posted previously and some additional logs. I also guessed some of the codes in the communication - they are described in codes.txt file. Now, I am able to make the prototype wait (functions aesStartScan() and aesDetectFinger()) until the a finger is attached to sensor and actually receive (function aesReadFingerprint()) fingerprint data (but the sensor must be left initialized from virtualized Windows). The main issue now, is to determine, the format of fingerprint data. You can get the data from logs/output.txt (log from my prototype) or logs/08ff:1680.usblog (log from Wireshark) files. The fingerprint data are transfered in few (~4) packages 16384 bytes long, first package is always beginning with the header 4954020d. The fingerprints are not transfered in stripes (unlike in other sensors) and might be encrypted. I was also experimenting with initialization of the sensor. I was able to follow (file 1u-my_module-best.txt) the communication along with the original schema (file 1u-init-and-reading.txt). The device successfully went to state 7050080 1625011e, but then it is starting to differ. I am not able to follow it further probably because the communication uses some kind of encryption tokens or so (see vimdiff 1u-init-and-reading-1.txt 1u-init-and-reading.txt). The question is, whether I am able to encrypt the tokens same as the original software. Please have look at the fingerprint data, and try to guess, what is their format. PS: I have found, what type of the sensor I have - I probably have AES1660 (3). [1] http://aes2501-wy.sourcearchive.com/ [2] http://www.uloz.to/8365105/aes1660-prototype-tar-bz2 [3] http://www.authentec.com/a/Production/smartsensors_pc/AES1660.aspx Dne Sat, 19 Mar 2011 23:25:53 +0100 Petr Dlouhý petr.dlo...@email.cz napsal(a): Hi, the files probably didn't went through the mailing list - you can download them at http://www.uloz.to/8352470/fprint-logs-tar-bz2, I also included one log from usbmon (from different session than the Wireshark log). The log captures connection of the device to VirtualBox machine and reading of fingerprints. The individual actions could be separated by the time stamp. I started to look on the log to find more about what happening. I have found, that the large portion of data comes from the device after the package with following data is released from the computer: 13204c01 4b04 00785634 12550700 8042007f 1449 03002000 c8 After this follows response with few (~3) packages with size 16384 B (=128x128), and the last package is smaller, but still has significantly more data than other responses. I highly suspect this part of communication to be actual receiving of the fingerprint. Although, ff the data are really the fingerprint, then it is surprising, that the fingerprint is transfered in once, not by strips as in other sensors. There is another thing, that confuses me highly. During all the communication, there are few repeating sequences of lots of packages with larger portion of data (~200 B) transfered _from_ computer _to_ the device. They are usually confirmed with 42010001 from the device. I would like to know, what is purpose of those packages. I think, there is too much of data transfered to be just control sequences. I was thinking about encryption keys, or firmware, or fingerprint patterns or something like that. Dne Sat, 19 Mar 2011 17:35:21 +0100 Petr Dlouhý petr.dlo...@email.cz napsal(a): -- Petr Dlouhý ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
Re: [fprint] New fingerprint reader: 08ff:1680 AuthenTec, Inc.
Hi, the files probably didn't went through the mailing list - you can download them at http://www.uloz.to/8352470/fprint-logs-tar-bz2, I also included one log from usbmon (from different session than the Wireshark log). The log captures connection of the device to VirtualBox machine and reading of fingerprints. The individual actions could be separated by the time stamp. I started to look on the log to find more about what happening. I have found, that the large portion of data comes from the device after the package with following data is released from the computer: 13204c01 4b04 00785634 12550700 8042007f 1449 03002000 c8 After this follows response with few (~3) packages with size 16384 B (=128x128), and the last package is smaller, but still has significantly more data than other responses. I highly suspect this part of communication to be actual receiving of the fingerprint. Although, ff the data are really the fingerprint, then it is surprising, that the fingerprint is transfered in once, not by strips as in other sensors. There is another thing, that confuses me highly. During all the communication, there are few repeating sequences of lots of packages with larger portion of data (~200 B) transfered _from_ computer _to_ the device. They are usually confirmed with 42010001 from the device. I would like to know, what is purpose of those packages. I think, there is too much of data transfered to be just control sequences. I was thinking about encryption keys, or firmware, or fingerprint patterns or something like that. Dne Sat, 19 Mar 2011 17:35:21 +0100 Petr Dlouhý petr.dlo...@email.cz napsal(a): Hello, I just bought new Asus U36JC with fingerprint reader. The device is not supported by libfprint, and I would like to see it working. I want to put some effort to that (but I might not have enough time). I am not hardware programmer, but still I can do something. As a first step to make the device working, I made log from the USB communication - it is made with Linux Wireshark, while the fingerprint reader is connected to Windows 7 in VirtualBox. I couldn't make Usbsnoop working in Windows 7, and the device has only Windows 7 drivers. I am also attaching lsusb identification. Can somebody give me some hints, how can I make the fingerprint reader working? -- Petr Dlouhý ___ fprint mailing list fprint@reactivated.net http://lists.reactivated.net/mailman/listinfo/fprint
