simtrace

simtrace@lists.osmocom.org

346 discussions

apdu_split issue described (was: Re: Problems)
by Martin Paljak 25 Jan '12

25 Jan '12

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

1 0

Patching Wireshark-1.6 with simcard-for-wireshark-1.6.patch is failing
by Jan Henrik Krågtorp 21 Jan '12

21 Jan '12

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

2 1

No output when tracing a Gemalto Cryptoflex ,NET card
by jeremy brookfield 16 Jan '12

16 Jan '12

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.

3 5

git repository up to date?
by Myonium 14 Jan '12

14 Jan '12

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

2 1

MitM firmware status
by Dominique Parolin 12 Jan '12

12 Jan '12

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

5 5

Upgrading from v0.3 to v0.4
by Holger Hans Peter Freyther 10 Jan '12

10 Jan '12

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

1 0

simtrace install on ubuntu 11.10
by vette 23 Dec '11

23 Dec '11

I have a fresh ubuntu 11.10 installation and cannot get the simtrace package to install. this command works and I get the expected results: sudo add-apt-repository ppa:holger+lp/osmocom this works too: sudo apt-get update as well as this: sudo apt-get install wireshark but when I do simtrace on the install line by itself or with wireshark, I get: E: Unable to locate package simtrace I see the ppa on launchpad.net has an entry for simtrace under oneiric (ubuntu 11.10), but it isn't finding it.

2 4

a problematic sim?
by Lukas Kuzmiak 18 Dec '11

18 Dec '11

Hello there, I've been playing with simtrace a lot lately, works almost flawlessly :) now i got to a simcard which behaves somehow weirdly: Lukass-MacBook-Air:host lukash$ ./simtrace simtrace - GSM SIM and smartcard tracing (C) 2010 by Harald Welte <laforge(a)gnumonks.org> Entering main loop ATR APDU: 3b 16 95 d0 00 45 f7 01 00 a0 a4 00 00 02 a4 7f 20 9f 20 a0 c0 00 00 20 c0 00 00 00 00 7f 20 02 00 00 00 00 00 13 33 00 18 04 00 83 8a 83 8a 00 01 00 00 06 fd 00 00 00 00 90 00 a0 a4 00 00 02 a4 3f 00 9f 20 a0 a4 00 00 02 a4 7f 20 9f 20 a0 c0 00 00 16 c0 00 00 00 00 7f 20 02 00 00 00 00 00 13 33 00 18 04 00 83 8a 83 8a 90 00 a0 a4 00 00 02 a4 6f b7 94 04 a0 a4 00 00 02 APDU: a4 6f 05 9f 0f a0 c0 it's everytime just this, exactly the same - there's an ATR and some select APDUs mixed together, something's not right. Nothing more appears even if I'm entering the pin, then the phone successfully initializes and authenticates to the network nothing is displayed, I've spent quite some time restarting, reflasing, recompiling everything because I thought my setup was somehow incorrect, but when I left everything as it was and only changed the sim for a different one, everything works just fine. Any idea what might be causing this? I can provide some debug info, just not sure what can be helpful, I have the ftdi cable for osmocom so I can try to connect it and see what's there if needed. P.S.: software and firmware are the latest what's in the git right now, I've patched the sources with that mac os x usb init patch as I only have a mac here. thanks, lukash

3 10

class C (+1.8V) capabilities
by Kevin Redon 18 Dec '11

18 Dec '11

Hi, I found out why class C (+1.8V) capable UICC are still used as class B (+3.3V). This is because the board provides +3.0V on VCC_PHONE, forcing the phone to use class B. this voltage is coming from VCC_SIM. Normally VCC_SIM should only get the power from VCC_PHONE (in sniffing mode), through the power switch FPF2005, or from the LDO AP3332 (in card reader). Currently both are enabled (bug). This should be prevented in software as there is no hardware mechanism to prevent that (fail). Some power from the LDO is going backwards though the power switch, providing +3.0V on VCC_PHONE (another hardware fail). Also, SIMtrace will not be able to decode +1.8V traffic because Vih (voltage input high level) is at +2.3V. One solution would be to power VDDIO at 1.8V, but this is a bad solution as the USB will not work anymore. For the v2 board I intend to have the following: - 1 translator/level shifter for SIM<->CPU, with selectable 1.8/3.3 - 1 translator/level shifter for PHONE<->CPU, with selectable auto/1.8/3.3 - VCC_SIM can be set to VCC_PHONE,1.8V,3.3V - power forward with diode behaviour any correction, comments or recommendation are welcome, kevin

2 2

[PATCH] Respect wLength/window size for USB
by Holger Hans Peter Freyther 17 Dec '11

17 Dec '11

From: Holger Hans Peter Freyther <zecke(a)selfish.org> This still needs to receive some more testing (untested on Windows right now) and also consideration how/if we want to upgrade this in the field. If we consider reflashing the DFU part safe enough. I would argue that there is still SAMBA to fix things up if someone breaks the bootloader. Holger Hans Peter Freyther (1): usb: Do not send ZLP when we have filled the window firmware/src/dfu/dfu.c | 46 ++++++++++++++++---------------- firmware/src/dfu/dfu.h | 2 +- firmware/src/os/pcd_enumerate.c | 54 +++++++++++++++++++++------------------ 3 files changed, 53 insertions(+), 49 deletions(-) -- 1.7.7.2

4 11

← Newer
1
...
27
28
29
30
31
32
33
34
35
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

simtrace