Help decoding ZKsoftware Stand-alone fingerprint reader protocol

Question

Hi!

I just purchased a Stand-alone, linux-based fingerprint reader for T&A purposes from dealextreme. http://www.dealextreme.com/p/x628-staff-time-attendance-system-1500-user-standalone-linux-network-fingerprint-4966

The hardware seems good enough, but the naive guy I am, I thought that with this thing being Linux-based, it would have some kind of open API to download the data stored on the device. But the rather nasty software that comes with the product (even made Avast shout out that something is wrong) is Windows-only, and not at all what I need in order to integrate this puppy into my other programs.

I contacted zksoftware.com, but haven't received a reply yet, and am a bit pessimistic about their collaboration, judging by their website, and the fact that I couldn't find their Linux source code anywhere (GPL violation?)

So I did the next logical thing and simply used the included software to download the "punches" that were stored on the machine, and recorded the transaction with Wireshark - but I am a bit at a loss about what to do now. There are some promising ASCII characters in the dump, but I still can't make heads or tails out of this and would appreciate any help anyone could give me with this.

My plan is to write a (perl) module that would provide some kind of basic API, so that I, and anyone else, can "talk" to these devices. I would of course share my scripts online, for free.

I uploaded the conversation to: http://gometa.org/fingerprint.pcap

The first approx. 5 seconds of traffic resulted from me clicking "connect".
The following data (20.44+ secs) seem to be related to the downloading of 32 records, each of which should include a timestamp, and a userid (000001 to 000006).

thanks for any help!

M.

Answer 1

1

Maybe the following helps? http://www.scribd.com/doc/54798939/Communication-Protocol-Manual-CMD

answered 18 May '11, 17:56

cmaynard ♦♦
9.4k●10●38●142
accept rate: 20%

Thanks that API description is a bot longer than another one I found, but they do share the problem of being in a language utterly, but not quite, completly unlike english! :)

Especially the checksum, which I would figure would be one the first things to get running, eludes me:

--SNIP--

Verification and (CheckSum) algorithm: According to unsign short integer accumulate the entire packet, till over 2147483648 (long 4 bytes), gains the low 2 byte values continue to add together again, depending on the position that the value is obtained to get ones complement, and transform it into the short integer (unsigned short 2 bytes), namely obtains the verification sum.

--SNAP--

Do you or anyone else know whether this might be some "standard" checksumming protocol? Or someone with more checksumming experience than me might be able to translate this into a more understandable way?

Cheers,

M.

(18 May '11, 19:39) schweini

1

It sounds to me like a description of the standard Internet checksum algorithm; to quote the description of that algorithm in RFC 793:

Checksum: 16 bits

The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header and text.  If a
segment contains an odd number of header and text octets to be
checksummed, the last octet is padded on the right with zeros to
form a 16 bit word for checksum purposes.  The pad is not
transmitted as part of the segment.

See epan/in_cksum.c in the Wireshark source for a C implementation.

(18 May '11, 19:59) Guy Harris ♦♦