How to send 7816 APDUs using libnfc

I have made some progress by selecting the card first with

nfc_reader_list_passive(pdi,IM_ISO14443A_106,...

and sending an APDU as follows:

        byte cmd[]={
            0x00,0xa4,0x04,0x00,
            0x07,0xd4,0x10,0x00,0x00,0x03,0x00,0x01,
            0x00};
        byte buf[256];
        ui32 i=0;
        byte resp[256];
        ui32 respLen=sizeof(resp);
        buf[i++]=2;
        memcpy(buf+i,cmd,sizeof(cmd));
        i+=sizeof(cmd);

        if (nfc_reader_transceive_bytes(pdi,buf,i,resp,&respLen))
        {
             if (respLen > 19)
             {
                printf("\nCard ID: ");
                print_hex(resp+9,8);
             }
        }

Where "cmd" is what I consider to be the APDU command. To send it I prefixed the 0x02. What is the definition of this byte?

The response also has a similar prefix byte, I've seen both 0x02 and 0x03, what do these mean?

Thanks,

snapdev

Hi, thanks for the quick response.

I am using the NZ Snapper cards with the Snapper "feeder" device based on the PN531 chip.

We have two different types of cards here, a plastic card and also a USB based card that will work as a USB plugin, or as an RF device.

I've found different behaviour between the two card devices. Most importantly I find that I can talk to the plastic card with your default

byte pncmd_exchange_raw_data[266]={0xD4,0x42};

followed by my appending an 0x02 byte before the APDU. The response has a prefixed byte as mentioned in the earlier post.

This approach fails with the USB card device when used as an RF card. Here I have to change your libnfc.c to

byte pncmd_exchange_raw_data[266]={0xD4,0x40};

then append an 0x01 byte before my APDU. The response then has no extra byte prefixed.

Ironically this {0xD4,0x40,0x01} then also works with the plastic card, but means a change to libnfc.c. What does this code actually represent and what should be the strategy to deal with this given this is common code?

While on the topic, these global buffers are not thread safe.

The SAK (SEL_RES) as returned by the plastic card is 0x20, and for the USB card is 0x28. What do these bits mean?

I tried compiling the libnfc on Solaris 10 u7 i386 and can happily report it working.

EDIT:

The changes makes me think of...

#define PN5XX_TRANSMIT_FRAME      "\xD4\x42"
#define PN5XX_TRANSMIT_MIFARE     "\xD4\x40\x01"

So are MIFARE frames standard APDU messages?

Last edited by snapdev (2009-06-24 02:49:47)

Further testing revealed that the one type of message doesn't work with both types of cards and I need to change the type of message depending on the result  received from the card identification.

The plastic card identifies itself as follows:

Connected to NFC reader: PN531USB

The following (NFC) ISO14443A tag was found:

 ATQA (SENS_RES): 04  00
    UID (NFCID1): 08  0e  1c  9c
   SAK (SEL_RES): 20
       ATS (ATR): 08  57  80  02  01  10  00  09

The USB/RF card identifies itself slightly differently

Connected to NFC reader: PN531USB

The following (NFC) ISO14443A tag was found:

 ATQA (SENS_RES): 04  00
    UID (NFCID1): 20  7f  47  ab
   SAK (SEL_RES): 28
       ATS (ATR): 0d  38  33  b1  4a  43  4f  50  33  31  56  32  32

My solution has been to add a new API where I also pass in the result from the identification allowing the API to select the appropriate way of sending an APDU.

bool nfc_reader_transceive_apdu(const dev_info* pdi,
    const tag_info *ti,
    const byte* pbtTx, 
    const ui32 uiTxLen, 
    byte* pbtRx, 
    ui32* puiRxLen)
{
  byte buf[266];
  ui32 replyOffset=1;
  ui32 i=0;

  /* Same check as for nfc_transceive_bytes */

  if (!pdi->bPar) return false;

  /* use the information from the card to determine how to send the APDU */

  if (ti->tia.btSak & 0x8)
  {
      buf[i++]=0xD4;
      buf[i++]=0x40;
      buf[i++]=0x01;
  }
  else
  {
      buf[i++]=0xD4;
      buf[i++]=0x42;
      buf[i++]=0x02;
      replyOffset=2;
  }

  memcpy(buf+i,pbtTx,uiTxLen);

  i+=uiTxLen;

  /* as per nfc_transceive_bytes */

  if (!pn53x_set_tx_bits(pdi,0)) return false;

  /* send the frame with the appropriate header */

  if (!pn53x_transceive(pdi,buf,i)) return false;
 
  /* the prefix to the reply is different depending on the header used */

  if (uiRxLen <= replyOffset) return false;

  *puiRxLen=uiRxLen-replyOffset;
  memcpy(pbtRx,abtRx+replyOffset,*puiRxLen);

  return true;
}

I will have to do some digging to find out exactly why the protocol is different and hence which bit from the tag_info to use.

I have found the documents http://www.waazaa.org/download/fcd-14443-3.pdf and http://www.waazaa.org/download/fcd-14443-4.pdf which describes all the bytes for SAK and ATS.

What is the difference that 0xD4,0x42,0x02 and 0xD4,0x40,0x01 do to the actual RF protocol sent to the device? From that we can back track to the bytes returned from the cards.

After looking at the documentation for a PN532, we now know that

0XD4,0X40 is InDataExchange

It takes a single byte parameter of target logical number and then the APDU data.

0xD4,0x42 is InCommunicateThru

This just takes the data and makes a message out of it, so the first byte is actually the PCB.

Hence the difference is that InDataExchange generates the PCB, whereas InCommunicateThru requires the host to provide the PCB and returns the PCB as part of the response.

My theory is that where the card claims it has a CID, the original code is asking the PN531 to
handle the CID, where the card does not have a CID the code is saying alright,  I can keep things simple and provide a simple "I-block" PCB.

We can only say if this is true if somebody can watch the RF data that gets sent to the card and see if the CID was actually included after the PCB.

Why that makes a difference in reality and whether the work around is because of the cards or the reader I can't tell.

Gymerus,

I wrote some code that will let you do this.  Grab the pynfc.py script out of RFIDIOt, either the latest version at www.rfidiot.org, or my hacked up version at www.lateralsecurity.com/OurTools.html

If you call pynfc.py directly it allows you to manually send APDUs.  Or you can use it in your own code.

I'm also trying to send APDUs.
First, I'm confused by what I read here: on one hand I read in this thread that I should transmit 0xD4 0x40 0x01 before the APDU.
On the other end, I don't see any such prefix in ifd-nfc.h.
So could anyone please point me to addotional information on the APDU frame?

My sequence is

nfc_list_devices (pnddDevices, MAX_DEVICE_COUNT, &szDeviceFound);
pnd = nfc_connect(&(pnddDevices[j]));
nfc_initiator_init(pnd);
nfc_configure(pnd,NDO_ACTIVATE_FIELD,false);
nfc_configure(pnd,NDO_INFINITE_SELECT,false);
nfc_configure(pnd,NDO_HANDLE_CRC,true);
nfc_configure(pnd,NDO_HANDLE_PARITY,true);
nfc_configure(pnd,NDO_ACTIVATE_FIELD,true);
nfc_initiator_list_passive_targets (pnd, NM_ISO14443A_106, anti, MAX_TARGET_COUNT, &szTargetFound);

at his point I may output the nai
print_nfc_iso14443a_info (anti[n].nai);

Connected to NFC reader: Philips / PN531 - PN531 v4.2

1 ISO14443A passive target(s) was found:
    ATQA (SENS_RES): 00  04
       UID (NFCID1): fd  52  09  37
      SAK (SEL_RES): 28
          ATS (ATR): 78  80  a4  02  00  73  c8  40  13  00  90  00
     Compliant with: ISO/IEC 14443-4

then I would like to send an APDU as in
nfc_initiator_transceive_bytes( pnd, TxBuffer, RxBuffer,&rl);

But I don't know how to construct the APDU frame.
(I have to put the frame, right? If I don't I get an error)
thanks in advance, Ullrich

Last edited by Ullrich (2010-10-20 12:25:26)

@frankmpunkt:
I have looked at it, but unfortunately I need it on Windows and it seems that the autoconf stuff is for linux only. Even worse, under windows I don't need the ifdhandler interface but the winscard interface and I can't use pc/sc-lite to get that since windows has it's own pcsc subsystem.
Therefore I had the hope that I could read it and then produce some windows code.
Do you think that I could compile ifdnfc  with MinGW?

Anyway, I think this is an issue in the libnfc documentation. There should be a simple sample code that sends an APDU, even if this code will be replaced by your ifdhandler in a real application. Therefore my request: Could you or someone else please post a valid sequence to send an APDU?
thank you,
Ullrich

When I try to send an APDU, the APDU sent (as seen in pcscd -adf) is always prefixed with 0xff 0x00 0x00 0x00 & 3-4 bytes.

Is this supposed to be the case?

hi every body ? I think i am late here any body can tell me the theme of discussion ?