Closed GoogleCodeExporter closed 8 years ago
[deleted comment]
Could you run pssi in APDU mode (-a) and post all the APDU exchanges?
I found a minimalistic python script [1]. If it works with your card, we could
try to understand what we're doing wrong.
Great to have you on board, we're looking forward to integrating your code!
[1]
http://www.b-eid.com/forum/showthread.php?90-Resolved-Python-support-for-eID-API
&p=367#post367
Original comment by julien.f...@gmail.com
on 12 Dec 2010 at 11:30
Hi, thanks for joining this project. I hope that you will find it helpful, and
that we will soon be able to integrate your plugin into the project!
I have made some changes in the SelectFile function which might correct your
issue. If not, please do as Julien advised, and we will do all we can to help
you.
Original comment by eric.bou...@gmail.com
on 12 Dec 2010 at 9:52
Here are the APDU exchanges:
$ ./pssi.py -a plugins/beid
>> 00 00 00 00
<< / 6d 0
>> 00 A4 08 00 04 DF 01 40 31
<< / 6a 86
ATR : 3B 98 13 40 0A A5 03 01 01 01 AD 13 11
Content
DF ID
ID : File not found
The sample Python script works fine with my card.
Still not working even with Eric changes unfortunately.
Original comment by laurent.leonard.openminds@gmail.com
on 14 Dec 2010 at 6:18
I just commited a little modification. Could you check again and post the APDUs
please ?
Thanks again.
Original comment by eric.bou...@gmail.com
on 14 Dec 2010 at 9:19
[deleted comment]
Once again, I have commited something. Could you check again please ?
Original comment by eric.bou...@gmail.com
on 15 Dec 2010 at 8:00
It works, good job Eric ! But I have an other problem now:
Each piece of data in the EF is preceded by 2 bytes:
- the first byte is a sequence number starting at 0x01 ;
- the second byte is the length of the data.
I can handle this in the plugin with the interpreters if I fetch 2 more bytes
each time and don't show the 2 first one. But I have a problem with variable
length data...
Original comment by laurent.leonard.openminds@gmail.com
on 15 Dec 2010 at 11:30
Perfect!
I am not sure that I understand your last issue. There is indeed a way to
handle variable length data. It is used in the SIM plugin for instance.
In 'structures.py', there is a global array : fieldLength = [0]
Look at this part of the structSMS:
("User data length", FieldType.Final, 1, "", FinalType.SMSLength),
("SMS", FieldType.Final, fieldLength, "", FinalType.SMS),
The interpreter for SMSLength sets the correct value in fieldLength[0], which
is used for the SMS field.
Is this what you needed?
Original comment by eric.bou...@gmail.com
on 15 Dec 2010 at 9:18
I think transparent EF doesn't have the same structure on SIM cards. I tried to
use the global array fieldLength but I always got all the data in the first
field with a variable length... When I fetch a piece of data, I have to fetch 2
bytes before. The first byte I get is a sequence number, the second one is the
length of the piece of data. Here is an example, the 4 first fields in ID EF
(data are false because I use my own eID for the tests):
01 0C --> two bytes that describe the first field (card number), length is 12
36 34 37 32 30 31 34 37 33 32 31 36
02 10 --> two bytes that describe the second field (chip number), length is 16
4C 45 44 4F 13 25 40 19 7D FD 25 04 37 42 18 13
03 0A --> two bytes that describe the first field (card validity date begin),
length is 10
32 35 2E 30 38 2E 32 30 30 38
04 0A --> two bytes that describe the first field (card validity date end),
length is 10
32 35 2E 30 38 2E 32 30 31 33
...
I think that structure doesn't exist on SIM cards, but it shouldn't be handled
by the plugin because it has no sense to show "descriptors" as a field. And
with that strcture there is no need to specify size when fetching a field
because the first two bytes already describes the data...
Original comment by laurent.leonard.openminds@gmail.com
on 15 Dec 2010 at 10:50
You're right, I will add a new FieldType soon.
Original comment by eric.bou...@gmail.com
on 16 Dec 2010 at 9:12
I have just added a new FieldType: FieldType.FinalWithHeader
You could add a structure like this:
structExample = [
("Card number", FieldType.FinalWithHeader, 2, 1, "Card number", FinalType.CardNumber)
]
The digit '2' means that a two-byte-long header is present, and should not be
output. The digit '1' means that the length of the field is at the position 1
in the header (starting at 0).
I hope you will find this useful and that it corresponds to what you were
expecting.
Original comment by eric.bou...@gmail.com
on 19 Dec 2010 at 8:38
There is a problem with that new feature, here is an example:
$ ./pssi.py -v plugins/beid
ATR : 3B 98 13 40 0A A5 03 01 01 01 AD 13 11
Content
DF ID
ID
Card Number :
6472014732 --- 01 0C 36 34 37 32 30 31 34 37 33 32 ()
Card number field is 12 bytes long, but I only get the 10 first bytes.
Original comment by laurent.leonard.openminds@gmail.com
on 19 Dec 2010 at 10:17
Sorry I forgot a line. I hope it is OK now.
Original comment by eric.bou...@gmail.com
on 20 Dec 2010 at 7:10
There is still a problem when the length is 0, in this case I get all the data
from current offset to the end.
Original comment by laurent.leonard.openminds@gmail.com
on 20 Dec 2010 at 6:34
Should be OK now. Sorry for the inconvenience, I have no card with such a
structure.
Original comment by eric.bou...@gmail.com
on 20 Dec 2010 at 7:44
No problem, I'm happy to help you !
I get the following trace since your last change:
Traceback (most recent call last):
File "./pssi.py", line 113, in <module>
main()
File "./pssi.py", line 105, in main
dumper.startDump()
File "/home/trash/pssi-read-only/pssi/dumper.py", line 35, in startDump
content = structure_parser.parseCard(card)
File "/home/trash/pssi-read-only/pssi/structure_parser.py", line 350, in parseCard
card["Content"] = parseCardStruct(connection, plugin.getRootStructure())
File "/home/trash/pssi-read-only/pssi/structure_parser.py", line 215, in parseCardStruct
entry = parseCardStruct(connection, field[3], data+field[2])
File "/home/trash/pssi-read-only/pssi/structure_parser.py", line 239, in parseCardStruct
entry = parseCardStruct(connection, field[3], hexdata)
File "/home/trash/pssi-read-only/pssi/structure_parser.py", line 321, in parseCardStruct
interpretation = interpretFinalField(value, finalType, name)
File "/home/trash/pssi-read-only/pssi/structure_parser.py", line 42, in interpretFinalField
interpretation = interpreterTable[type](value)
File "plugins/beid/interpreters.py", line 42, in interpretString
txt += chr(c)
TypeError: an integer is required
Original comment by laurent.leonard.openminds@gmail.com
on 20 Dec 2010 at 9:29
In structure_parser.py, line 322 (after having updated), under the "if value is
not None:", can you add a "print value" and tell me what it says? And do the
same at the beginning of your interpreter ?
Original comment by eric.bou...@gmail.com
on 20 Dec 2010 at 10:03
Now I get no more crash.
With "print value" in "structure_parser.py" I get some lists containing the
ASCII values, one per field shown. But there is no list for the field with
empty value.
I made a special string interpreter for this field with "print value" at the
first line, but nothing is printed out. The interpreter is never called.
Important detail: the value of the previous field is shown in place of the
empty value, even the values shown with -v are the same for those 2 fields.
Original comment by laurent.leonard.openminds@gmail.com
on 20 Dec 2010 at 11:37
So now the field that should be empty is still shown, but with a wrong value
(the previous field)? Are you sure that you have the latest release (50)?
Original comment by eric.bou...@gmail.com
on 21 Dec 2010 at 7:21
Since revision 50 all fields are correctly shown ! But the field with an empty
value is not shown at all, even the label...
Original comment by laurent.leonard.openminds@gmail.com
on 21 Dec 2010 at 11:05
You would expect the label to be printed, along with a text such as "Entry not
present on the card"?
Original comment by eric.bou...@gmail.com
on 21 Dec 2010 at 2:20
I would expect the label to be printed, with an empty value. The entry exists
on the card, but has no value.
Original comment by laurent.leonard.openminds@gmail.com
on 21 Dec 2010 at 4:48
Done!
Original comment by eric.bou...@gmail.com
on 21 Dec 2010 at 7:03
Everything works now, so I think we can close this issue.
Original comment by laurent.leonard.openminds@gmail.com
on 25 Dec 2010 at 8:10
Original comment by eric.bou...@gmail.com
on 25 Dec 2010 at 8:46
Original issue reported on code.google.com by
laurent.leonard.openminds@gmail.com
on 12 Dec 2010 at 12:12