25 Jan
2012
25 Jan
'12
3:58 p.m.
Hello again.
I took the place where simtrace fails to produce meaningful output and
continued manually.
Does the included file and comments make any sense?
It will take me some time to bite through the concept of parsing the
bytestream into APDU-s in the existing apdu_split code, maybe somebody
more familiar recognizes a possible issue or a solution.
Best,
Martin
On Wed, Jan 25, 2012 at 15:55, Martin Paljak <martin(a)martinpaljak.net> wrote:
Hello,
On Wed, Jan 25, 2012 at 11:40, Martin Paljak <martin(a)martinpaljak.net> wrote:
Hello,
I have a v1.1p running Version 0.4 compiled 20120113-094258 by
ich@sanmingze, connected between a Nokia 1616 and a macbook pro.
Host side software (including libusb) is from Git and running inside a
VMWare Fusion Debian 6 32bit VM.
This seems to be a problem of the apdu_split method. After studying
the protocol a bit and taking the URB-s from the generated log file
and feeding it through some python, I can construct APDU-s that
actually look sensible, but which are badly parsed by simtrace (not
parsed at all, thus the "deadlock" feeling without extra logging) or
some bytes get lost in between and the state machine breaks. I'm
looking into it, maybe I can come up with a patch. Here is the
troublesome part from the traffic:
URB 20: 01 00 00 00 ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f ff 6f 07
61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02
8a 01 05 8b 03 6f 06 05 80 02 00 09
88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00 1d c0
62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f 06 05
80 02 01 2c 88 00 90 00 00 b0 00 00 00
b0 ff ff ff ff ff ff ff ff ff ff ff ff
process_usb_msg(), payload: ff ff ff ff ff 90 00 00 a4 08 04 04 a4 7f
ff 6f 07 61 1e 00 c0 00 00 1e c0 62 1c 82 02 41 21 83 02 6f 07 a5 03
da 01 02 8a 01 05 8b 03 6f 06 05 80 0
2 00 09 88 01 38 90 00 00 a4 08 04 04 a4 7f ff 6f 32 61 1d 00 c0 00 00
1d c0 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a 01 05 8b 03 6f
06 05 80 02 01 2c 88 00 90 00 00 b0
00 00 00 b0 ff ff ff ff ff ff ff ff ff ff ff ff
APDU: 00 b0 00 00 10 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00
APDU: 00 a4 08 04 04 7f ff 6f 07 61 1e
APDU: 00 c0 00 00 1e 62 1c 82 02 41 21 83 02 6f 07 a5 03 da 01 02 8a
01 05 8b 03 6f 06 05 80 02 00 09 88 01 38 90 00
APDU: 00 a4 08 04 04 7f ff 6f 32 61 1d
APDU: 00 c0 00 00 1d 62 1b 82 02 41 21 83 02 6f 32 a5 03 da 01 02 8a
01 05 8b 03 6f 06 05 80 02 01 2c 88 00 90 00
URB 21: 01 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
URB 22: 01 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4
process_usb_msg(), payload: ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90 00 00 a4
URB 23: 01 00 00 00 00 04 02 a4 6f 40 61 20 00 c0 00 00 20 c0 62 1e 82
05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03 6f 06 06
80 02 00 78 88 00 90 00 00 a4 00 04 02 a4 6f 3b 61 20 00 c0 00 00 20
c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a 01 05 8b
03 6f 06 07 80 02 0d 48 88 00 90 00 00 a4 00 04 02 a4 6f 49 61 20 00
c0 00 00 20 c0 62 1e 82 05 42 21 00 22 0a 83
process_usb_msg(), payload: 00 04 02 a4 6f 40 61 20 00 c0 00 00 20 c0
62 1e 82 05 42 21 00 18 05 83 02 6f 40 a5 03 da 01 02 8a 01 05 8b 03
6f 06 06 80 02 00 78 88 00 90 00 00 a4 00 04 02 a4 6f 3b 61 20 00 c0
00 00 20 c0 62 1e 82 05 42 21 00 22 64 83 02 6f 3b a5 03 da 01 02 8a
01 05 8b 03 6f 06 07 80 02 0d 48 88 00 90 00 00 a4 00 04 02 a4 6f 49
61 20 00 c0 00 00 20 c0 62 1e 82 05 42 21 00 22 0a 83
How exactly is the stream from the device supposed to be split into
APDU-s, a la PC/SC, with a request and a response? The current format
confuses me a bit. I understand that this is right now totally the
reponsibility of the parser.
I'm fairly new to the GSM/SIM world, but fairly well versed in layers
above PC/SC (and some CCID), is there some documentation on how to get
a grip on this?
Best,
Martin