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@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
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
On 12/14/2011 04:07 PM, Harald Welte wrote:
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.
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?
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@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@freyther.de> wrote:
On 12/14/2011 04:07 PM, Harald Welte wrote:
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.
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?
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.
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@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.
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@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
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@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@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@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
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@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
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 -
Holger Hans Peter Freyther -
Lukas Kuzmiak