bytes automatically send by Android - NFC to an emulated card

Question

I have a SpringCard running in Card Emulation mode via my computer with a log console.

As soon as I check it with my Android phone (API 4.1.2) with NFC on (no app runnig), my phone send these data to the emulated card :

1st set -> 90:60:00:00:00
2nd set -> 00:A4:04:00:07:D2:76:00:00:85:1:1:0

What precisely are these commands ? Are they related to my Android which try to discover what tech does the emulated card use ?

EDIT

Actually I have understand what the 2nd set is (APDU SELECT).

But it seems that the 1st set is an proprietary APDU command from Android. Could this be related to NPP (NDEF Push Protocol) ?

Answer 1

What are these commands?

The first command (90 60 00 00 00) is a MIFARE DESFire GetVersion command (wrapped command set). This seems to be specific to the NXP-based Android NFC stack and is not part of a typical NFC tag detection procedure.

The second command (00 A4 04 00 07 D2 76 00 00 85 01 01 00) is a SELECT APDU that tries to select the NFC Forum Type 4 tag application (version 2.0) by its AID. This is part of the typical tag detection procedure for ISO 14443-4 (ISO-DEP) based tags/smartcards.

Why are these commands sent before apps are notified about the presence of a tag and even if no app is active at all?

A typical NFC device will automatically discover the presence of NFC tags that contain NDEF messages. Usually such NDEF messages then trigger actions on the device (e.g. start an app). As your tag seems to be an ISO 14443-4 (ISO-DEP) compliant tag/smartcard, the NDEF discovery procedure for an NFC Forum Type 4 tag is started. This procedure normally contains of the following steps:

1. Select the NFC Forum Type 4 tag application (version 2.0)

   00 A4 04 00 07 D2 76 00 00 85 01 01 00
   

2. If application selection is successful, continue with reading the capability container file and the NDEF data file.

3. If application selection fails, continue with selecting the NFC Forum Type 4 tag application (version 1.0)

   00 A4 04 00 07 D2 76 00 00 85 01 00 00
   

4. If application selection is successful, continue with reading the capability container file and the NDEF data file.

5. If application selection fails, tag is not an NFC Forum Type 4 tag.

6. Typically the connection to the tag is reset at this point so that any communication that an app performs with a tag is started right after a fresh activation of the tag.

The additional command before step 1 indicates that the NXP's NFC stack additionally tries to find out if the Type 4 tag is an NXP product (NXP's MIFARE DESFire or DESFIRE EV1). It is not related to peer-to-peer mode protocols.

Remark on the Broadcom NFC stack: There is a known issue that seems to still exist on Android 4.4: Even after the tag is passed to an app and the app started IsoDep communication the NFC stack arbitrarily sends READ BINARY commands interleaved with the app's communication. This frequently results into protocol errors due to invalid command sequences. This does not happen with NXP's NFC stack.

Can I prevent this initial processing of a tag?

Yes, but only since Android 4.4. On that platform you can use the NfcAdapter's enableReaderMode method to bring the device into a reader mode without NDEF discovery.