14 Dec
2011
14 Dec
'11
2:42 p.m.
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
14 Dec
14 Dec
4:07 p.m.
Hi Lukas,
On Wed, Dec 14, 2011 at 02:42:29PM +0100, Lukas Kuzmiak wrote:
I've been playing with simtrace a lot lately,
works almost flawlessly :)
now i got to a simcard which behaves somehow weirdly:
sorry to hear that.
it's everytime just this, exactly the same -
there's an ATR and some select
APDUs mixed together, something's not right.
indeed, it's weird.
you don't happen to have a compatible serial cable (for the 2.5mm
headphone style jack)? They are called motorola T191 cables and we use
them a lot in OsmocomBB.
Using that cable, you could observer some debug printout from the
firmware while it is running.
Any idea what might be causing this?
not really at this point. If you have an extra simcard of that type,
you could mail it to me and I could look into it.
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)
4:45 p.m.
On 12/14/2011 04:07 PM, Harald Welte wrote:
Hi,
no idea if you already tried this. It appears that the communication between
phone and SIM is working (e.g. entering PIN and such), so maybe it is the
apdu_split.c in the host utility that fails to behave? You could verify that
'apdu_split_in' is called?
Any idea what might be causing this?
not really at this point. If you have an extra simcard of that type,
you could mail it to me and I could look into it.
15 Dec
15 Dec
10:24 p.m.
Hi Harald, Holger,
I've tried couple of things, here are the results:
- I've connected a osmocom-like ftdi cable and gathered a trace from there
(not sure if i can somehow enable more debug msgs, haven't done any special
setup, if you want me to take it with some more verbosity being set somehow
- please let me know. trace is attached).
- I've put one printf() into the apdu_split_in method, it seems the buffer
is somehow getting scrambled from the beginning, it shows something like:
Lukass-MacBook-Air:host lukash$ ./simtrace
simtrace - GSM SIM and smartcard tracing
(C) 2010 by Harald Welte <laforge(a)gnumonks.org>
Entering main loop
unknown simtrace msg type 0xa4
apdu_split_in() reached.
APDU: a4 6f 05 9f 0f a0 c0
apdu_split_in() reached.
apdu_split_in() reached.
.... and so on (tons of times).
so the APDUs are somehow going back and forth (as apdu_split_in is being
called over and over) but simtrace is having some troubles
displaying/parsing them.
I've found some more simcards behaving like this, Harald - if you want me
to send you one for testing please send me your address, I'll be happy to
do that - or I can bring it to 28c3 too - I'll leave that up to u.
Cheers,
Lukas
On Wed, Dec 14, 2011 at 4:45 PM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On 12/14/2011 04:07 PM, Harald Welte wrote:
Hi,
no idea if you already tried this. It appears that the communication
between
phone and SIM is working (e.g. entering PIN and such), so maybe it is the
apdu_split.c in the host utility that fails to behave? You could verify
that
'apdu_split_in' is called?
Any idea what might be causing this?
not really at this point. If you have an extra simcard of that type,
you could mail it to me and I could look into it.
10:48 p.m.
On 12/15/2011 10:24 PM, Lukas Kuzmiak wrote:
- I've put one printf() into the apdu_split_in method, it seems the buffer is
somehow getting scrambled from the beginning, it shows something like:
Hi,
so let me claim the issue is in our split method... could you generate the
hexdump of the bytes added? we could then feed APDU split ourselves. The other
part would be, do you have a PCSC Card reader? you could send us the ATR as
reportede by pcsc_scan.
11:13 p.m.
Hi Holger,
ATR of that card from a pcsc reader:
Reader 0: Gemalto GemPC Twin 00 00
Card state: Card inserted,
ATR: 3B 16 95 D0 00 45 F7 01 00
seems to be much shorter than usual ATR I've seen, but _all_ o2-cz and
o2-sk, postpaid, prepaid have that same ATR (since like 2-3 yrs old till
few months ago - meaning bought from o2).
wasn't so sure where to stick the hex-dump so I've put it into main.c,
process_usb_msg, diff is below just in case you need to be sure about the
exact location.
trace i got is attached, it seems some of the APDU data are getting marked
as part of ATR with SIMTRACE_FLAG_ATR flag and since then all the data
don't make sense to the parser anymore (imho).
Cheers,
Lukas
diff --git a/host/main.c b/host/main.c
index 4fbac8d..377868a 100644
--- a/host/main.c
+++ b/host/main.c
@@ -92,6 +92,7 @@ static int process_usb_msg(uint8_t *buf, int len)
switch (sh->cmd) {
case SIMTRACE_MSGT_DATA:
+ printf("dump: %s\n", osmo_hexdump(payload, payload_len));
/* special treatment for ATR */
if (sh->flags & SIMTRACE_FLAG_ATR) {
printf("ATR ");
On Thu, Dec 15, 2011 at 10:48 PM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On 12/15/2011 10:24 PM, Lukas Kuzmiak wrote:
- I've put one printf() into the apdu_split_in method, it seems the
buffer is
somehow getting scrambled from the beginning, it
shows something like:
Hi,
so let me claim the issue is in our split method... could you generate the
hexdump of the bytes added? we could then feed APDU split ourselves. The
other
part would be, do you have a PCSC Card reader? you could send us the ATR as
reportede by pcsc_scan.
16 Dec
16 Dec
12:53 a.m.
On Thu, Dec 15, 2011 at 10:24:14PM +0100, Lukas Kuzmiak wrote:
- I've connected a osmocom-like ftdi cable and
gathered a trace from there
(not sure if i can somehow enable more debug msgs, haven't done any special
setup, if you want me to take it with some more verbosity being set somehow
- please let me know. trace is attached).
enabling more debugging requires some code changes and recompilation of
the firmware, sorry.
The trace you have attached looks pretty normal, i.e. reasonable Fi/Di
values, and no RST flood or something like that.
- I've put one printf() into the apdu_split_in
method, it seems the buffer
is somehow getting scrambled from the beginning, it shows something like:
Lukass-MacBook-Air:host lukash$ ./simtrace
simtrace - GSM SIM and smartcard tracing
(C) 2010 by Harald Welte <laforge(a)gnumonks.org>
Entering main loop
unknown simtrace msg type 0xa4
apdu_split_in() reached.
APDU: a4 6f 05 9f 0f a0 c0
apdu_split_in() reached.
apdu_split_in() reached.
.... and so on (tons of times).
so the APDUs are somehow going back and forth (as apdu_split_in is being
called over and over) but simtrace is having some troubles
displaying/parsing them.
the interesting question would be to actually print the new APDU bytes
as they come in from USB, i.e. what goes into the splitter. Just
osmo_hexdump() the buffer so we can see if the APDU splitter is broken
or the information coming from the SIMtrace hardware/firmware is already
broken.
I guess you know this: But please also make sure that you always capture
from the very first power up of the SIM card, i.e. plug in simtrace and
start the PC program before you power up the phone. OTherwise there may
be some initial handshake (PPS/PTS) that we miss and thus decoding fails
I've found some more simcards behaving like this,
Harald - if you want me
to send you one for testing please send me your address, I'll be happy to
do that - or I can bring it to 28c3 too - I'll leave that up to u.
I don't know where you are located and how lon a letter would take to
reach Berlin. My address can be found at
http://bb.osmocom.org/trac/wiki/Contact
28c3 would of course also work, but I cannot promis I will find time to
look at it during the event itself.
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)
9:51 a.m.
Hi Harald,
I've generated some more data by putting in couple more osmo_hexdump()s.
Please find attached git diff to know which data was printed where and the
data themselves, I've already sent something yesterday, not sure if you've
seen it, however this prints more (the whole buff coming from usb, being
passed to process_usb_msg()).
But as I said yesterday, it seems some bytes from the actual data seems to
be marked with ATR flag in the firmware itself and since then the data come
somehow scrambled or shifted and parser can't put it together anymore.
Correct me if I'm mistaken but from what I've observed the first message
coming from USB always contains only ATR and has that ATR flag, I don't see
how simtrace sw could parse ATR from data bytes.
ATR of that card from a pcsc reader (pcsc_scan as Holger wanted):
Reader 0: Gemalto GemPC Twin 00 00
Card state: Card inserted,
ATR: 3B 16 95 D0 00 45 F7 01 00
Let me know if this is sufficient somehow or you think the SIM will be
better, I can mail you the sim even today if you think it'll help more than
this trace.
Cheers,
Lukas
On Fri, Dec 16, 2011 at 12:53 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Thu, Dec 15, 2011 at 10:24:14PM +0100, Lukas
Kuzmiak wrote:
- I've connected a osmocom-like ftdi cable
and gathered a trace from
there
(not sure if i can somehow enable more debug
msgs, haven't done any
special
setup, if you want me to take it with some more
verbosity being set
somehow
- please let me know. trace is attached).
enabling more debugging requires some code changes and recompilation of
the firmware, sorry.
The trace you have attached looks pretty normal, i.e. reasonable Fi/Di
values, and no RST flood or something like that.
- I've put one printf() into the
apdu_split_in method, it seems the
buffer
is somehow getting scrambled from the beginning,
it shows something like:
Lukass-MacBook-Air:host lukash$ ./simtrace
simtrace - GSM SIM and smartcard tracing
(C) 2010 by Harald Welte <laforge(a)gnumonks.org>
Entering main loop
unknown simtrace msg type 0xa4
apdu_split_in() reached.
APDU: a4 6f 05 9f 0f a0 c0
apdu_split_in() reached.
apdu_split_in() reached.
.... and so on (tons of times).
so the APDUs are somehow going back and forth (as apdu_split_in is being
called over and over) but simtrace is having some troubles
displaying/parsing them.
the interesting question would be to actually print the new APDU bytes
as they come in from USB, i.e. what goes into the splitter. Just
osmo_hexdump() the buffer so we can see if the APDU splitter is broken
or the information coming from the SIMtrace hardware/firmware is already
broken.
I guess you know this: But please also make sure that you always capture
from the very first power up of the SIM card, i.e. plug in simtrace and
start the PC program before you power up the phone. OTherwise there may
be some initial handshake (PPS/PTS) that we miss and thus decoding fails
I've found some more simcards behaving like
this, Harald - if you want me
to send you one for testing please send me your address, I'll be happy to
do that - or I can bring it to 28c3 too - I'll leave that up to u.
I don't know where you are located and how lon a letter would take to
reach Berlin. My address can be found at
http://bb.osmocom.org/trac/wiki/Contact
28c3 would of course also work, but I cannot promis I will find time to
look at it during the event itself.
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)
18 Dec
18 Dec
1:45 a.m.
On 12/16/2011 09:51 AM, Lukas Kuzmiak wrote:
Hi Harald,
Hi all,
tnt has had some issues as well... it looks like if for prot_t_supported==1
the data will not be sent immediately. E.g. a "ih->rctx_must_be_sent = 1;"
appears to work around this. This means that a mixed ATR/APDU URB will be
generated and our adpu_split host code will not be called.
static enum iso7816_3_state
transition_to_tck(struct iso7816_3_handle *ih)
{
if (ih->prot_t_supported == 0x01) {
/* If only T=0 supported, there is no TCK but we
* immediately transition to APDUs */
set_atr_state(ih, ATR_S_DONE);
return ISO7816_S_WAIT_APDU;
My idea of a proper patch was to move a lot into the ATR_S_DONE state
(rctx_must_be_sent, scheduling the tc_etu_set_wtime) but this does not appear
to work properly. So the easiest patch is to add "ih->rctx_must_be_sent = 1"
to the above code path.
cheers
holger
2:05 a.m.
Hi,
I've quickly tried this with the problematic simcards and it seems to do
the trick, works just fine.
nice work.
Cheers,
Lukas
On Sun, Dec 18, 2011 at 1:45 AM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On 12/16/2011 09:51 AM, Lukas Kuzmiak wrote:
Hi Harald,
Hi all,
tnt has had some issues as well... it looks like if for prot_t_supported==1
the data will not be sent immediately. E.g. a "ih->rctx_must_be_sent = 1;"
appears to work around this. This means that a mixed ATR/APDU URB will be
generated and our adpu_split host code will not be called.
static enum iso7816_3_state
transition_to_tck(struct iso7816_3_handle *ih)
{
if (ih->prot_t_supported == 0x01) {
/* If only T=0 supported, there is no TCK but we
* immediately transition to APDUs */
set_atr_state(ih, ATR_S_DONE);
return ISO7816_S_WAIT_APDU;
My idea of a proper patch was to move a lot into the ATR_S_DONE state
(rctx_must_be_sent, scheduling the tc_etu_set_wtime) but this does not
appear
to work properly. So the easiest patch is to add "ih->rctx_must_be_sent =
1"
to the above code path.
cheers
holger
9:56 a.m.
Hi Lukas,
On Fri, Dec 16, 2011 at 09:51:20AM +0100, Lukas Kuzmiak wrote:
I've generated some more data by putting in couple
more osmo_hexdump()s.
thanks.
But as I said yesterday, it seems some bytes from the
actual data seems to
be marked with ATR flag in the firmware itself and since then the data come
somehow scrambled or shifted and parser can't put it together anymore.
Correct me if I'm mistaken but from what I've observed the first message
coming from USB always contains only ATR and has that ATR flag, I don't see
how simtrace sw could parse ATR from data bytes.
yes, all the traffic is in your trace, it is simply a matter of not
detecting properly where the ATR / APDU boundary is.
Let me know if this is sufficient somehow or you think
the SIM will be
better, I can mail you the sim even today if you think it'll help more than
this trace.
I think the trace is fine, I just need to find some time to actually
look harder at the traces and the code. I'm not sure when that will be,
things are quite crazy here right now :/
--
- 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)
4521
days inactive
4525
days old
10 comments
3 participants
participants (3)
-
Harald Welte -
Holger Hans Peter Freyther -
Lukas Kuzmiak