sidsatx102 / cardpeek

Automatically exported from code.google.com/p/cardpeek
Other
0 stars 0 forks source link

The GSM SIM script doesn't work with Hutchison 3G UK Ltd. ("3") SIM cards #10

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Insert a 3 (U)SIM card into a reader
2. Launch CardPeek
3. Attempt to run the GSM script

What is the expected output? What do you see instead?

I expect to see data corresponding to the contents of the card. Instead, I 
receive a dialogue stating "This does not appear to be a GSM SIM card. 
Halting", and the following output in the "logs" tab:

0400 INFO    Reader maximum input length is 261 bytes
0401 INFO    Connection successful, protocol is T=0
0402 INFO    ATR is 22 bytes: 3B9F95801FC78031E073FE211B63E207A7830F900089
0403 INFO    ATR is 22 bytes: 3B9F95801FC78031E073FE211B63E207A7830F900089
0404 INFO    send: A0A40000027F20 [3S]
0405 INFO    Recv: 9404  [** Unkown error code **]
0406 INFO    Testing if response code starts with 9F
0407 INFO    Disconnected reader

What version of the product are you using? On what operating system?
CardPeek 0.7 on Ubuntu 11.04.

Please provide any additional information below.

It seems that the "usimtool.py" script at 
http://ace-host.stuart.id.au/russell/files/python-pcsclite/examples/usimtool.py 
(and also supplied as part of the Python-PCSCLite package) is capable of 
interfacing with these cards successfully.

Original issue reported on code.google.com by tyson....@gmail.com on 4 Jan 2012 at 6:15

GoogleCodeExporter commented 9 years ago
If it helps, I've just had a play with the "trace:on" option of the USIMTool 
script, and was able to obtain the following partial APDU log:

a0a40000023f00=9f16, a0c0000016=000093a03f000100000000000931020b0800000000009000
tree:/ = 3f00    DF pins=1+2
a0a40000023f00=9f16, a0c0000016=000093a03f000100000000000931020b0800000000009000
a0a40000020000=9404
a0a40000020001=9404
a0a40000020002=9f0f, a0c000000f=0000000f000204000bb0bb010200009000
tree://0002 = 0002    EF   15 trn AW,Ab,Ab,AW,Ab,Ab
a0a40000020003=9404
a0a40000020004=9404
a0a40000020005=9404
a0a40000020006=9404
a0a40000020007=9f0f, a0c000000f=0000000b000704000aa0aa010200009000
tree://0007 = 0007    EF   11 trn AW,Aa,Aa,AW,Aa,Aa

Original comment by tyson....@gmail.com on 4 Jan 2012 at 6:22

GoogleCodeExporter commented 9 years ago
I was also able to obtain the following APDUs and responses (with unsuccessful 
ones removed), using the "printtree" mode:

a0a40000023f00=9f16, a0c0000016=000093a03f000100000000000931020b0800000000009000
printtree:/ = 3f00    DF pins=1+2
a0a40000023f00=9f16, a0c0000016=000093a03f000100000000000931020b0800000000009000
a0a40000020002=9f0f, a0c000000f=0000000f000204000bb0bb010200009000
a0b000000f=0600bb80d51804114aff7021ffff029000
printtree://0002 = 0600bb80d51804114aff7021ffff02
a0a40000020007=9f0f, a0c000000f=0000000b000704000aa0aa010200009000
a0b000000b=47413730323820203030319000
printtree://0007 = 4741373032382020303031

Original comment by tyson....@gmail.com on 4 Jan 2012 at 6:26

GoogleCodeExporter commented 9 years ago
Thanks for the feedback and the precious data.

There's indeed a bug in the script. It attempts to access the GSM DF and if 
that doesn't work, the script halts. However some modern USIM cards (3G) 
apparently do not have that GSM DF and make the script fail. 

I've made a fix (update 195) in the GSM script to change that behavior. 
However, the current GSM script is still very beta and does not handle USIM 
card (3G) data, so there won't be much to see on those cards except for very 
basic stuff.

I will work on an implementation of USIM soon.

Original comment by L...@gmx.com on 22 Jan 2012 at 11:01

GoogleCodeExporter commented 9 years ago
Thanks! It seems that I can successfully read some of the card's contents with 
the modified script.

Original comment by tyson....@gmail.com on 23 Jan 2012 at 2:28

GoogleCodeExporter commented 9 years ago
I'll close this for now. Taking USIM improvement as a future project.

Original comment by L...@gmx.com on 28 Feb 2013 at 11:19