Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Ludovic Rousseau (ludovic.rousseaugmail.com)
Date: Tue Jun 22 2010 - 03:47:47 CDT
2010/6/22 Drasko DRASKOVIC <drasko.draskovicgmail.com>:
> On Tue, Jun 22, 2010 at 3:00 AM, <muscle-requestlists.musclecard.com> wrote:
>> Message: 1
>> Date: Mon, 21 Jun 2010 11:26:29 +0200
>> From: Ludovic Rousseau <ludovic.rousseaugmail.com>
>> Subject: Re: [Muscle] Suggestion for the big CCID reader matrix.
>> To: MUSCLE <musclelists.musclecard.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 2010/5/25 Ludovic Rousseau <ludovic.rousseaugmail.com>:
>>> The 3 lists Supported , Should work  and Unsupported  now
>>> contains for each reader the CCID release adding support of the
>>> The information is also present in the big matrix  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 :
> 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"  software. It uses the Perl
>> PC/SC wrapper .
> 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 :
> 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 ?
>> You can also use my online ATR parsing .
>>> 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
>> 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.
Dr. Ludovic Rousseau
Muscle mailing list