On Friday 17 March 2006 02:36, Justin Karneges wrote: > I've not yet put this in the code because surely this is much more than > just the initialization. The openct eutron init is 2 exchanges, and this > log shows 10 already. I hope you can make sense of this data and tell me > where the boundary is.
More follow-up: I noticed that on all the exchanges where the size of a packet's content is the third byte, the last byte seems to act like a checksum (XOR'ing all of the bytes in the packet, including the last byte, equals zero). Andreas, is this the "t=1" format you were talking about? Just to experiment, I put all 10 snooped exchanges into the eutron initialization. According to some logging, the card responds with the same exact bytes as it did on Windows. However, as soon as opensc tries to send that 7 (or is it 5?) byte packet, everything fails. And I've not destroyed the card yet, it still works in Windows. :) From the raw snooped SafeSign data: send: 00 00 07 01 a4 00 0c 02 3f 00 93 It looks remarkably similar to this from opensc's output: card.c:221:sc_transceive: Sending 7 bytes (resp. 258 bytes): 00 A4 00 0C 02 3F 00 .....?. If framing data is added to what opensc wishes to send, then the raw data would be the same except for a 1 byte difference (first content byte is 01 in SafeSign, 00 in opensc). However, eutron_send gets this: 00 a4 00 0c 02 This is not "t=1" format. Is opensc forgetting to frame the content before passing to openct? -Justin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
