[fprint] image format challenges

[Daniel Drake]

Working on sniffed data from the windows driver of the currently 
unsupported 147e:2016 UPEK device...

The protocol is very different from the upekts devices, and doesn't seem 
to have similarities with upektc either.

My initial suspicions are that the image data is not encrypted or 
scrambled as there are some patterns. Anyone interested in digging further?

If so, I've attached some raw data from the device. It repeatedly sends 
chunks of 4096 bytes of data, I've just included the first two in a 
single file (this is just the start of a scan).

The obvious pattern is that it is split up into 64-byte blocks, where 
the first 2 bytes of each block are a big endian sequence number 
(starting at 000c for the first block, 000d for the second, etc).

If we trim off the sequence numbers with a program as follows:

int main(void)
{
	unsigned char buf[8192];
	FILE *fd = fopen("147e2016.raw", "r");
	int i;
	int blocks = 8192 / 64;

	fread(buf, 1, 8192, fd);
	fclose(fd);

	fd = fopen("noseqs.raw", "w");
	for (i = 0; i < blocks; i++) {
		unsigned char *blk = buf + (i * 64);
		fwrite(blk + 2, 1, 62, fd);
	}
	fclose(fd);
}

and then plot noseqs.raw as 8 bit greyscale at resolution 96x82, you can 
clearly see patterns (attached as proc.gif).

Anyone interested in digging further? :)

Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 147e2016.raw
Type: application/octet-stream
Size: 8192 bytes
Desc: not available
Url : http://lists.reactivated.net/pipermail/fprint/attachments/20071126/fb2cc3e8/147e2016-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc.gif
Type: image/gif
Size: 6965 bytes
Desc: not available
Url : http://lists.reactivated.net/pipermail/fprint/attachments/20071126/fb2cc3e8/proc-0001.gif