0

So, as I move forward, not getting what SHOULD be a relatively simple task. I'm working with a Gemalto smartcard reader. I am using C#, Xamarin working on an Android.

I have proper recognition of the device, card, and get Power On, get ATR, set configuration etc., all coming back as successful process.

So, I am trying to do a UsbConnection.BulkTransfer to send a request to SELECT MasterFile (root) from the given smart card. From reading over many posts, I find the APDU commands and found many options and have tried them all. They have all given me a result SW1/SW2 of 0x01 0x00 which is obviously wrong from what I have been reading.

Below are the following byte attempts I have been sending and each come back same response.

CLA INS P1 P2 Lc Data  Le
00  a4  00 00 02 3f 00 00
00  a4  00 00 02 3f 00
00  a4  00 00 02 00 00 00
00  a4  00 00 02 00 00
00  a4  00 00 00
00  a4  00 00 
00  a4  

From what I read, if you do not post P1/P2 nor data, it should default to the first file (master record) on the card, hence I tried from all bytes down to just the 00 a4.

I then tried the same combination changing the class from 00 to A0 as found in other documentation findings. Below is a short stub of code that is specific to me sending the bytes and getting the bytes back. Each byte array is based on above.

The byte response coming back are all the same with

00 00 00 00 00 63 00 65 01 00

Here is the code snippet

public byte[] TrySelectFile(byte[] outByteBuffer)
{
    var bufferLen = outByteBuffer.Length;
    var howManyBytesSent = _myUsbDeviceConnection.BulkTransfer(_myOutEndpoint, outByteBuffer, bufferLen, READER_TIMEOUT);

    var inByteBuffer = new byte[_myInEndpoint.MaxPacketSize];
    var howManyBytesBack = _myUsbDeviceConnection.BulkTransfer(_myInEndpoint, inByteBuffer, inByteBuffer.Length, READER_TIMEOUT);

    return inByteBuffer;
}
DRapp
  • 47,638
  • 12
  • 72
  • 142

1 Answers1

0

You cannot send APDUs directly to the reader. You need to use the CCID protocol. See my previous answer.


For example (use correct sequence numbers, those are just illustrative):

Send PC_to_RDR_IccPowerOn (message 0x62):

-> 62000000000008010000

And receive RDR_to_PC_DataBlock (message 0x80) with ATR:

<- 801200000000080000003bfb1300ff10800031c164089862290f9000

Set parameters for T=0 protocol with PC_to_RDR_SetParameters (message 0x61):

-> 610500000000090000001300020a00

And receive RDR_to_PC_Parameters (message 0x82):

<- 820500000000090000001300020a00

And then you can send SELECT APDU (in bold) with PC_to_RDR_XfrBlock (message 0x6f)

-> 6f05000000000a00000000a4040000

And receive response APDU (status word only, in bold) in RDR_to_PC_DataBlock (message 0x80):

<- 8002000000000a0000006c3f

Then you will need to re-send the APDU with correct Le, as needed for T=0 protocol: 00a404003f. See the complete trace below...


Here is a base-64 encoded wireshark USB trace performing a SELECT APDU command on a T=0 card in GemPC Twin Reader (decode it to binary file and open it in Wireshark, then right-click any packet and select "Decode As...", change to "USB Device" tab, select "USBCCID" protocol and click "OK"):

-----BEGIN PCAP-NG CAPTURE FILE-----
H4sICIi1SGMAA2NjaWRfdDAucGNhcG5nAOPi5eWSYWBg8LXRlmIE0v+hACQG4usA8R0GEGBhYGJg
ZygtTsrNzzNg4ATKsjFAAEgNiJ0D5X96xcqw1XuKnReQDcIHxLoWnZn0/38wM5MCI4Muw5opHskg
dVtPsDH0Au3iArK5GHCDJDDJAXIO2A6QXTVIdp38NcUuBsiOQbLLmbkJxa6T5exg9TJQjAGYIFSD
ENguILb+LczwX6CBwfBgCseMJE3+CWA7QXYXINn9e91lO38gG4Qdqt+dOI3kzw1Qu38rcYL9yQ9k
8+PxZyIriOQEYmEGJi6IPej2eW9G2NdwZPpbZL/C7PNW5wSrx2kf1K9NRNgntIWw/4Q0iPNfPtg+
cEwvYWFA2IecbmrOXLbzAbJB2EEONS5h9tU4QPzHA8W4/NfABLMvxx6WbpD9dvEMwm8HhFHTKMyu
iw6k+I0b6jd7uN/WINlXpXbFrhvIBmEGSex+q5oF8Zs3FOP0myPMvnzbFo4FQJoZiJcazs/TMiAa
zE9l/D8B4kZWtHiIYPO1ZwTmFOf80ryS1KJihYKi/LLMlNQUhaRKhZTS3ILkxAImYD4BqT1z3MyO
GcoOAOpjAbJTmCFmsYLzEgKA7AAA5cD28HQEAAA=
-----END PCAP-NG CAPTURE FILE-----

(Note: Card response to select is redacted)

vlp
  • 7,811
  • 2
  • 23
  • 51