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=3b9f95801f438031e073362113574a330...
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
Hello,
On Wed, Jan 25, 2012 at 11:40, Martin Paljak martin@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
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.
Hello,
On Wed, Jan 25, 2012 at 17:57, jeremy brookfield jeremy.brookfield@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
Hi Martin,
On Wed, Jan 25, 2012 at 06:10:13PM +0200, Martin Paljak wrote:
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.
thanks a lot for your patience and time to debug this. Your fix seems correct and I've applied it to simtrace.git.
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
Hello,
On Wed, Jan 25, 2012 at 19:45, Harald Welte laforge@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).
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
On Wed, Jan 25, 2012 at 20:01, Martin Paljak martin@martinpaljak.net wrote:
On Wed, Jan 25, 2012 at 19:45, Harald Welte laforge@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
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
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
-
Harald Welte -
Holger Hans Peter Freyther -
jeremy brookfield -
Martin Paljak