Hi Vasily,
in "what_we_know_so_far.txt", I explicitely marked all bulks that are
changing among different runs. As I said: The bulks you considered:
>> Look at log you've send to me,
>> seq no 277, it's definitely non-encrypted data from sensor!
>> 0x49, 0x44, 0x02 - envelope?
>> 0x0d, 0x00, 0x00 - some multibyte command, no payload
>> 0xe0, 0x22, 0x02 - E-data from sensor, 4 bit per pixel. Exact data
>> starts from 0x22 byte, and looks like it's some 31-byte pattern:
>>
>> 2501 4892 a46d 93ec ff37 816c db7e 5b5a 1280 2449 da36 c9fe 7f13
c8b6 edb7 a5
>> Then after 0x222 bytes:
>> 0xde, 0x10, 0x00 - histogram data
>> After 0x10 bytes:
>> 0xdf, 0x06, 0x00 - authentication message
>>
...are not among them. So...
> Played a bit with my AES1660, and looks like this frame is not
> chaning... It does not matter
> if finger is on sensor...
...yes. They are always the same.
I updated the zip:
- eliminated the mistake in sniff description (upload->download of "bulk
583").
- added Petrs documentation (included zip file)
www.andreas-loos.com/aes1660.zip
One remark concerning Petrs tool: I could not really make it run on my
machine. It contains also parts I do not agree with, for instance a
"switch to raw" sequence which is in fact an exact copy of a part of
what I sniffed in the win driver traffic. Hence there are two
possibilities: The driver works in raw mode under windows (which is
possible according to the last observations) or Petrs "switch to raw"
does not what its name implies.
I did not have the time to produce new usb sniffs, for instance with
covered scanner, but I will do in the next days.
Best,
andreas
On 15.11.2012 20:00, Vasily Khoruzhick wrote:
On Wed, Nov 14, 2012 at 1:51 PM, Vasily Khoruzhick <anars...@gmail.com> wrote:
On Wed, Nov 14, 2012 at 1:05 PM, Andreas <krawat...@andreas-loos.com> wrote:
Dear friends of AES1660,
here you find my analysis of what is happening in the usb traffic between
win driver and AES1660:
http://www.andreas-loos.com/AES1660.zip
The zip contains virtually anything I know so far. Vasily asked for usb logs
with complete traffic that can be compared. For this, take for instance log
2 (my favorite reference), log 5 and log 8.
The good news is that many commands seem to be not encrypted like in AES2550
(or was it AES2850?). To be CORRECT in detail: There *are* in fact lots of
encrypted commands, as Vasily remarks, but for them encryption is obviously
the same in each run. So I think, these parts can be easily reproduced as
black box.
The bad news is that we still cannot switch the thing into raw mode or know
anything about the encryption. (Thanks for your helpful comments, Vasily!
You are probably right, keys are probably not transferred unencrypted and
the 583 byte thing is surely not a single long key.)
Any ideas how to proceed?
Best,
andreas
Look at log you've send to me,
seq no 277, it's definitely non-encrypted data from sensor!
0x49, 0x44, 0x02 - envelope?
0x0d, 0x00, 0x00 - some multibyte command, no payload
0xe0, 0x22, 0x02 - E-data from sensor, 4 bit per pixel. Exact data
starts from 0x22 byte, and looks like it's some 31-byte pattern:
2501 4892 a46d 93ec ff37 816c db7e 5b5a 1280 2449 da36 c9fe 7f13 c8b6 edb7 a5
Then after 0x222 bytes:
0xde, 0x10, 0x00 - histogram data
After 0x10 bytes:
0xdf, 0x06, 0x00 - authentication message
Regards
Vasily
Played a bit with my AES1660, and looks like this frame is not
chaning... It does not matter
if finger is on sensor...
Andreas, could you send me Petr's version of test app?
Regards
Vasily
--
___________________________________
Andreas Loos
Kurt-Exner-Straße 6
10249 Berlin
http://www.andreas-loos.com
___________________________________
_______________________________________________
fprint mailing list
fprint@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/fprint
