Hi Harald,<div><br></div><div>I've generated some more data by putting in couple more osmo_hexdump()s.</div><div><br></div><div>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()).</div>
<div><br></div><div>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.</div>
<div><br></div><div><div style>ATR of that card from a pcsc reader (pcsc_scan as Holger wanted):</div><div style>Reader 0: Gemalto GemPC Twin 00 00</div><div style><div>Card state: Card inserted, </div><div>ATR: 3B 16 95 D0 00 45 F7 01 00</div>
</div></div>
<div><br></div><div>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.</div><div><br></div><div>Cheers,</div>
<div>Lukas<br><br><div class="gmail_quote">On Fri, Dec 16, 2011 at 12:53 AM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Thu, Dec 15, 2011 at 10:24:14PM +0100, Lukas Kuzmiak wrote:<br>
> - I've connected a osmocom-like ftdi cable and gathered a trace from there<br>
> (not sure if i can somehow enable more debug msgs, haven't done any special<br>
> setup, if you want me to take it with some more verbosity being set somehow<br>
> - please let me know. trace is attached).<br>
<br>
</div>enabling more debugging requires some code changes and recompilation of<br>
the firmware, sorry.<br>
<br>
The trace you have attached looks pretty normal, i.e. reasonable Fi/Di<br>
values, and no RST flood or something like that.<br>
<div><br>
> - I've put one printf() into the apdu_split_in method, it seems the buffer<br>
> is somehow getting scrambled from the beginning, it shows something like:<br>
><br>
> Lukass-MacBook-Air:host lukash$ ./simtrace<br>
> simtrace - GSM SIM and smartcard tracing<br>
> (C) 2010 by Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>><br>
><br>
> Entering main loop<br>
> unknown simtrace msg type 0xa4<br>
> apdu_split_in() reached.<br>
> APDU: a4 6f 05 9f 0f a0 c0<br>
> apdu_split_in() reached.<br>
> apdu_split_in() reached.<br>
> .... and so on (tons of times).<br>
><br>
> so the APDUs are somehow going back and forth (as apdu_split_in is being<br>
> called over and over) but simtrace is having some troubles<br>
> displaying/parsing them.<br>
<br>
</div>the interesting question would be to actually print the new APDU bytes<br>
as they come in from USB, i.e. what goes into the splitter. Just<br>
osmo_hexdump() the buffer so we can see if the APDU splitter is broken<br>
or the information coming from the SIMtrace hardware/firmware is already<br>
broken.<br>
<br>
I guess you know this: But please also make sure that you always capture<br>
from the very first power up of the SIM card, i.e. plug in simtrace and<br>
start the PC program before you power up the phone. OTherwise there may<br>
be some initial handshake (PPS/PTS) that we miss and thus decoding fails<br>
<div><br>
> I've found some more simcards behaving like this, Harald - if you want me<br>
> to send you one for testing please send me your address, I'll be happy to<br>
> do that - or I can bring it to 28c3 too - I'll leave that up to u.<br>
<br>
</div>I don't know where you are located and how lon a letter would take to<br>
reach Berlin. My address can be found at<br>
<a href="http://bb.osmocom.org/trac/wiki/Contact" target="_blank">http://bb.osmocom.org/trac/wiki/Contact</a><br>
<br>
28c3 would of course also work, but I cannot promis I will find time to<br>
look at it during the event itself.<br>
<div><div><br>
Regards,<br>
Harald<br>
<br>
--<br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
(ETSI EN 300 175-7 Ch. A6)<br>
</div></div></blockquote></div><br></div>