From: Ludovic Rousseau (ludovic.rousseaugmail.com)
Date: Tue Jun 22 2010 - 03:47:47 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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>
>> Message-ID:
>>        <AANLkTinnTdSRpbVRLTGBC4mmMWyV-FtzwD9Lj_zTYQ_3mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> 2010/5/25 Ludovic Rousseau <ludovic.rousseaugmail.com>:
>>> 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
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]