simtrace January 2012

simtrace@lists.osmocom.org

12 participants
9 discussions

Getting started - unable to connect to the device

by Mat

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I have a v1.1p production board, and I am having problems getting started. I am running Arch Linux, so some things may be different from a Debian base. I have not yet tried interfacing the board from a Ubuntu/Debian workstation. I have succesfully compiled SIMtrace and its dependencies. The problem is at no point have I gotten a connection to the board. dmesg shows nothing and lsusb never shows the device. I have libusb configured on this system and programmed other avr devices. I tried to access the board with SAM-BA by following the firmware page. I only see the red LED faintly light when I'm jumping VCC to test, but nothing once I reconnect USB. I am right to assume that with a newly acquired board, I have to flash it with the firmware? Do you have any clues to help me talk to the SIMTrace board? I haven't found much explanation of bootloader and reset buttons on the wiki... Should I simply try with and Ubuntu/Debian workstation? Thanks, Mat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8ks/kACgkQsluIOvRklphpcQEAvZNvtBPS376K5emsLfsYQhhk pQTKYwNy7US8/W8Z4GwBAKE8Qyu8URJmF4gZ1kzJgdzFQuo2918GmNaXSCTvT0nS =5g4w -----END PGP SIGNATURE-----

12 years, 7 months

Problems

by Martin Paljak

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

12 years, 7 months

LTE SIM traces, anyone?

by Harald Welte

Hi all, I was wondering if anyone has access to a LTE device (like a 4G USB dongle) and has been able to trace the communication between the SIM card and the device yet. If so, it would be great to get some traces. Feel free to patch out the IMSI, PIN number or any other private details (or simply filter those messages, if you care to). Thanks in advance, 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)

12 years, 7 months

apdu_split issue described (was: Re: Problems)

by Martin Paljak

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

12 years, 7 months

Patching Wireshark-1.6 with simcard-for-wireshark-1.6.patch is failing

by Jan Henrik Krågtorp

I am having problems patching Wireshark with the simtracer patch. I am using a Debian VM: root@osmocom:/home/omsocom/simtrace/host# uname -a Linux osmocom 2.6.32-5-686 #1 SMP Thu Nov 3 04:23:54 UTC 2011 i686 GNU/Linux == The patching == root@osmocom:/home/osmocom/wireshark-1.6# cat simcard-for-wireshark-1.6.patch | patch -p 0 patching file epan/dissectors/packet-card_app_toolkit.c patching file epan/dissectors/packet-gsm_sim.c patching file epan/dissectors/packet-gsmtap.c Hunk #2 FAILED at 300. 1 out of 3 hunks FAILED -- saving rejects to file epan/dissectors/packet-gsmtap.c.rej patching file epan/dissectors/Makefile.common == The reject file of the patching attempt == root@osmocom:/home/osmocom/wireshark-1.6# cat epan/dissectors/packet-gsmtap.c.rej --- epan/dissectors/packet-gsmtap.c (revision 38554) +++ epan/dissectors/packet-gsmtap.c (working copy) @@ -300,6 +301,13 @@ col_set_str(pinfo->cinfo, COL_PROTOCOL, "GSMTAP"); + /* Some GSMTAP types are completely unrelated to the Um air interface */ + switch (type) { + case GSMTAP_TYPE_SIM: + call_dissector(sub_handles[GSMTAP_SUB_SIM], payload_tvb, pinfo, tree); + return; + } + if (arfcn & GSMTAP_ARFCN_F_UPLINK) { col_append_str(pinfo->cinfo, COL_RES_NET_SRC, "MS"); col_append_str(pinfo->cinfo, COL_RES_NET_DST, "BTS"); Any advice on how to solve this issue? regards Jan H

12 years, 7 months

No output when tracing a Gemalto Cryptoflex ,NET card

by jeremy brookfield

This is my first post to this list so a little introduction, I work in security engineering for a large company that uses smart cards for authentication and encryption. I am having trouble trying to use smart cards from an OSX client over Citrix. The same cards work from a Windows client. Hence the interest in being able to trace all APDUs in a non-OS specific format. When I use simtrace with e.g. Gemalto Cyberflex cards, the APDU are shown as I would expect. However, when the card type is a Gemalto Cryptoflex .NET alI see is the ATR APDU. The Cryptoflex .NET cards are newer and supports a higher baud rate. Could this explain why the APDUs are not shown? There's a somewhat vague statement in the simatrace documentation to this effect.

12 years, 7 months

git repository up to date?

by Myonium

Hi Which version of the firmware is on git repository "git://git.gnumonks.org/openpcd.git"? There are v.02 , v.03 and v.04 firmwares mentioned. But I could not find any branches nor version information in the master branch ... I would like to patch the latest osx branch with the ATR /APDU patch ... [1] http://lists.osmocom.org/pipermail/simtrace/2011-December/000193.html However I get strange effects: Only a few bytes are shown on Smartcard inserts and the ATR's reported back to the application on the Mac are incorrect . Btw. does firmware version and simtace client version have to match? Thanks, Ben

12 years, 7 months

MitM firmware status

by Dominique Parolin

Hi, as I could not find any udpates since July 2011 about MitM capable firmware here, or on the Wiki page I wanted to check if there is currently active development of a MitM firmware ? I would like to use it to manipulate fields from a physical SIM / UICC in real-time, e.g. non user editable fields like EF OPLMNwAcT. As a next step I would like to develop a tool that simulates a UICC with several applications on it, so that only the authentication is being made by the real UICC / SIM and utilize the simtrace HW as the physical interface. However the key to this is a proper firmware to interact with the ME <-> UICC communication in real time. I have written some classes and decoder for specific fields in Python (using Smartcard and a PCSC compatible reader) that can read and write, authenticate etc. however I lack the ability to write the firmware on my own. Regards, Dominique

12 years, 8 months

Upgrading from v0.3 to v0.4

by Holger Hans Peter Freyther

Hi all, for the OSX USB fix (ZLP) I changed the signature of functions provided by the DFU/bootloader part of the firmware. The following procedure works for me. $ sudo dfu-util -a 1 -D ./dfu.bin $ sudo dfu-util -a 0 -D ./main_simtrace.bin reset the device

12 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace January 2012