4

我有一个 SpringCard 通过我的计算机在卡仿真模式下运行，并带有一个日志控制台。

一旦我用我的安卓手机（API 4.1.2）和NFC（没有应用程序运行）检查它，我的手机就会将这些数据发送到模拟卡：

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

这些命令究竟是什么？它们是否与我的 Android 有关，它试图发现模拟卡使用什么技术？

编辑

其实我已经了解第二组是什么（APDU SELECT）。

但似乎第一组是来自 Android 的专有 APDU 命令。这可能与 NPP（NDEF 推送协议）有关吗？

4

1 回答 1

9

这些命令是什么？

第一个命令 ( 90 60 00 00 00) 是 MIFARE DESFire GetVersion 命令（包装命令集）。这似乎特定于基于 NXP 的 Android NFC 堆栈，而不是典型 NFC 标签检测程序的一部分。

第二个命令 ( 00 A4 04 00 07 D2 76 00 00 85 01 01 00) 是一个 SELECT APDU，它尝试通过其 AID 选择 NFC Forum Type 4 标签应用程序（2.0 版）。这是基于 ISO 14443-4 (ISO-DEP) 的标签/智能卡的典型标签检测程序的一部分。

为什么在通知应用程序存在标签之前发送这些命令，即使根本没有应用程序处于活动状态？

典型的 NFC 设备会自动发现包含 NDEF 消息的 NFC 标签的存在。通常，此类 NDEF 消息会触发设备上的操作（例如启动应用程序）。由于您的标签似乎是符合 ISO 14443-4 (ISO-DEP) 的标签/智能卡，因此启动了 NFC Forum Type 4 标签的 NDEF 发现过程。此过程通常包含以下步骤：

  1. 选择 NFC Forum Type 4 标签应用程序（2.0 版）

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

  2. 如果应用选择成功，继续读取能力容器文件和 NDEF 数据文件。

  3. 如果应用选择失败，请继续选择 NFC Forum Type 4 标签应用（1.0 版）

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

  4. 如果应用选择成功，继续读取能力容器文件和 NDEF 数据文件。

  5. 如果应用选择失败，则标签不是 NFC Forum Type 4 标签。

  6. 通常，此时会重置与标签的连接，以便应用程序与标签执行的任何通信都会在重新激活标签后立即开始。

步骤 1 之前的附加命令表示 NXP 的 NFC 堆栈另外尝试找出 Type 4 标签是否是 NXP 产品（NXP 的 MIFARE DESFire 或 DESFIRE EV1）。它与点对点模式协议无关。

关于 Broadcom NFC 堆栈的备注：在 Android 4.4 上似乎仍然存在一个已知问题：即使在将标签传递给应用程序并且应用程序启动 IsoDep 通信之后，NFC 堆栈也会任意发送与应用程序通信交错的 READ BINARY 命令。由于无效的命令序列，这经常导致协议错误。恩智浦的 NFC 堆栈不会发生这种情况。

我可以阻止标签的这种初始处理吗？

是的，但仅从 Android 4.4 开始。在该平台上，您可以使用 NfcAdapter 的enableReaderMode方法使设备进入读取器模式，而无需发现 NDEF。

于 2014-01-14T20:56:38.530 回答