2010/6/22 Drasko DRASKOVIC <[email protected]>: > On Tue, Jun 22, 2010 at 3:00 AM, <[email protected]> wrote: >> >> Message: 1 >> Date: Mon, 21 Jun 2010 11:26:29 +0200 >> From: Ludovic Rousseau <[email protected]> >> Subject: Re: [Muscle] Suggestion for the big CCID reader matrix. >> To: MUSCLE <[email protected]> >> Message-ID: >> <[email protected]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> 2010/5/25 Ludovic Rousseau <[email protected]>: >>> The 3 lists Supported [1], Should work [2] and Unsupported [3] now >>> contains for each reader the CCID release adding support of the >>> reader. >>> The information is also present in the big matrix [4] in the 'release' >>> column (the last one). > > Hi Ludovic, > thank you very much for the very detailed answers. > > I checked "supported" devices, and I decided to order USB Shell Token > V2 from Gemalto : > http://support.gemalto.com/index.php?id=61
Good choice. > This one should be supported, and my idea is to use your pcsc-tools to > interrogate SIM card and have idea about results which my embedded SIM > controller driver should get... > >>> 2) Are there some Linux applications that you recommend that can be >>> used to easily read and analyze content of the SIM card ? >> >> You can try my "SIM explorer v3.0" [3] software. It uses the Perl >> PC/SC wrapper [4]. > > OK, thanks, I'll give it a try. > > Does it manipulate just phone book, or I can use it to browse/modify > all other files on the SIM ? Just dump the phone book. > I am not very familiar with SIM development yet, but surfing around I saw : > http://www.dekart.com/products/card_management/sim_explorer/ > > It seems like a tool which can explore contents of the SIM, and can > help during development phase. > > Is there some Linux equivalent that you know about ? No. >> You can also use my online ATR parsing [5]. >> >>> How can I analyze this this sequence and confirm at least that it is >>> in good shape (my concern is that I think that it should have 13 >>> historical chars (T0 char is 0x9d), but it seems that it list them 15 >>> here). >> >> I can't use your ATR without reformatting. You should give it on one >> line only like: 3B 02 14 50 > > Wow, great tool ! Thank you very much. > > Using it I have gotten something like this : > > Parsing ATR: 3B 9D 94 80 1F C7 80 31 E0 65 D0 00 2B E6 08 73 FE 21 13 CF > > TS = 0x3B Direct Convention > T0 = 0x9D Y(1): b1001, K: 13 (historical bytes) > TA(1) = 0x94 Fi=512, Di=8, 64 cycles/ETU (62500 bits/s at 4.00 > MHz, 78125 bits/s for fMax=5 MHz) > TD(1) = 0x80 Y(i+1) = b1000, Protocol T=0 > ---- > TD(2) = 0x1F Y(i+1) = b0001, Protocol T=15 > ---- > TA(3) = 0xC7 Clock stop: no preference - Class accepted by the > card: (3G) A 5V B 3V C 1.8V > ---- > Historical bytes 80 31 E0 65 D0 00 2B E6 08 73 FE 21 13 > Category indicator byte: 0x80 > (compact TLV data object) > Tag: 3, Len: 1 (card service data byte) > Card service data byte: 224 > - Application selection: by full DF name > - Application selection: by partial DF name > - BER-TLV data objects available in EF.DIR > - EF.DIR and EF.ATR access services: by GET RECORD(s) command > - Card with MF > Tag: 6, Len: 5 (pre-issuing data) > Data: D0 00 2B E6 08 > Tag: 7, Len: 3 (card capabilities) > Selection methods: 254 > - Record number supported > - Short EF identifier supported > - Implicit DF selection > - DF selection by file identifier > - DF selection by path > - DF selection by partial DF name > - DF selection by full DF name > Data coding byte: 33 > - Behaviour of write functions: proprietary > - Value 'FF' for the first byte of BER-TLV tag fields: valid > - Data unit in quartets: 1 > Command chaining, length fields and logical channels: 19 > - Logical channel number assignment: by the card > - Maximum number of logical channels: 3 > TCK = 0xCF (correct checksum) > Possibly identified card: UNKNOWN > > > Correct checksum in the end gives me a little bit confidence that this > ATR is possibly the real one and well received. > > However, T=15 protocol is something that confuses me. Do you have any > idea why it is used, as I have seen so far that only T=0 and T=1 are > used, and the rest is reserved for future uses. > Could this rather be an error in ATR reception ? T=15 is not a communication protocol. Just ignore this part of the ATR. Bye -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
