25 Jan
2012
25 Jan
'12
10:40 a.m.
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.
The SIM card is:
http://smartcard-atr.appspot.com/parse?ATR=3b9f95801f438031e073362113574a33…
Everything seems to work every now and then (I got a successful trace
of the things that interest me yesterday) but it doesn't seem to be
predictable.
After following the "a problematic sim" thread I added more logging to
the simtrace application and generated a log.
The symptom is that everything works from phone startup, but then
stalls. After some time (when starting the OTA SIM application)
simtrace ends with "error usb bulk in .. -9"
The serial debug console doesn't show more than the initial startup.
Do I understand correctly that the fix proposed in "a problematic sim"
is for the firmware, which is not yet present in my version?
I attach the output from simtrace with the additional logging.
Any ideas? Is it OK to use simtrace from virtual machine or is bare
hardware required/best ?
Thanks,
Martin
25 Jan
25 Jan
2:55 p.m.
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
4:57 p.m.
Hi Martin,
I'm seeing a similar issue when running with certain card types.
After a few,correctly parsed APDUs, Simtrace is reporting the APDU as 2 bytes more than it
actually is.
In your trace 90 00 00 0a is reported at the end of a payload
90 00 is often the last two bytes of a response and 00 0a is a common begin to a new APDU
(00 0a often indicates a "select" instruction.)
Jeremy
On Jan 25, 2012, at 2:55 PM, Martin Paljak wrote:
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.
5:10 p.m.
Hello,
On Wed, Jan 25, 2012 at 17:57, jeremy brookfield
<jeremy.brookfield(a)percula.com> wrote:
Hi Martin,
I'm seeing a similar issue when running with certain card types.
After a few,correctly parsed APDUs, Simtrace is reporting the APDU as 2 bytes more than
it actually is.
In your trace 90 00 00 0a is reported at the end of a payload
90 00 is often the last two bytes of a response and 00 0a is a common begin to a new APDU
(00 0a often indicates a "select" instruction.)
The problem and solution is actually pretty simple in my case.
A patch is attached.
Next task: fix some "malformed packets" in Wireshark, which seem to be
unhandled opcodes for sim toolkit (?).
Martin
6:45 p.m.
Hi Martin,
On Wed, Jan 25, 2012 at 06:10:13PM +0200, Martin Paljak wrote:
thanks a lot for your patience and time to debug this. Your fix seems
correct and I've applied it to simtrace.git.
90 00 is often
the last two bytes of a response and 00 0a is a
common begin to a new APDU (00 0a often indicates a "select"
instruction.)
The problem and solution is actually pretty simple in my case.
A patch is attached. Next task: fix some "malformed packets" in
Wireshark, which seem to be
unhandled opcodes for sim toolkit (?).
yes, that may very well be the case. Feel free to share your pcap files
(or only those messages that don't parse).
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
7:01 p.m.
Hello,
On Wed, Jan 25, 2012 at 19:45, Harald Welte <laforge(a)gnumonks.org> wrote:
Hereyougo. The first one is the one needing parsing most.
Actually I'd like to extend parsing to some payloads as well, but I'm
100% new to wireshark dissectors.
Martin
Next task: fix
some "malformed packets" in Wireshark, which seem to be
unhandled opcodes for sim toolkit (?).
yes, that may very well be the case. Feel free to share your pcap files
(or only those messages that don't parse).
10:08 p.m.
On Wed, Jan 25, 2012 at 20:01, Martin Paljak <martin(a)martinpaljak.net> wrote:
On Wed, Jan 25, 2012 at 19:45, Harald Welte
<laforge(a)gnumonks.org> wrote:
>> Next task: fix some "malformed packets" in Wireshark, which seem to be
>> unhandled opcodes for sim toolkit (?).
>
> yes, that may very well be the case. Feel free to share your pcap files
> (or only those messages that don't parse).
One more (or same, from the same trace)
Martin
26 Jan
26 Jan
6:17 p.m.
On 01/25/2012 06:45 PM, Harald Welte wrote:
thanks a lot for your patience and time to debug this. Your fix seems
correct and I've applied it to simtrace.git.
Hi,
I updated the simtrace/wireshark OBS, new packages for SuSE, Mandriva, Fedora,
CentOS) are already available, I will need to update the PPA for Ubuntu and
will do so tonight.
Thanks for the patch!
holger
27 Jan
27 Jan
12:02 a.m.
On 01/26/2012 06:17 PM, Holger Hans Peter Freyther wrote:
On 01/25/2012 06:45 PM, Harald Welte wrote:
I updated the simtrace/wireshark OBS, new packages for
SuSE, Mandriva, Fedora,
CentOS) are already available, I will need to update the PPA for Ubuntu and
will do so tonight.
I updated the natty and oneiric PPA but it will take until the 28th that the
new package will be built by the launchpad infrastructure.
cheers
holger
4477
days inactive
4481
days old
9 comments
4 participants
participants (4)
-
Harald Welte -
Holger Hans Peter Freyther -
jeremy brookfield -
Martin Paljak