控制在Android全APDU与NFC软件卡仿真 [英] Control full APDU with NFC Software Card Emulation on Android
问题描述
我忙一个应用程序来模拟一个的Nexus 7与CM10.1到ACR122U102读/写器正常APDU通信。我发现这个博客了解软件卡仿真并写了一个应用程序，使我的设备（关系），显示为卡。现在，我尝试发送邮件来回这种设备和ACR122u之间。到目前为止，我只设法通过发送D4 40 01（ InDataExchange 第127页）APDU的。对于我写的应用程序，这应该是足够了。
I'm busy with an app to emulate normal APDU communication on a Nexus 7 with CM10.1 to an ACR122U102 reader/writer. I found this blog about software card emulation and wrote an app to make my device (the nexus) appear as a card. Now I'm trying to send messages back and forth between this device and the ACR122u. So far, I've only managed to communicate with the nexus 7 by sending D4 40 01 (InDataExchange page 127) APDU's. For the application I'm writing, this should be sufficient.
问题在我从设备发送给读者的答案奠定。使用transcieve功能（<一个href=\"https://github.com/CyanogenMod/android_frameworks_base/blob/ics/core/java/android/nfc/tech/IsoPcdA.java\"相对=nofollow> android.nfc.tech.IsoPcdA 与反思），我可以用长度的字节数组> 0，这将出现在像一个正常的InDataExchange响应读者的高端回复（如： D5 41 00 01 02 03含{01 02 03}被供给到transcieve函数字节数组）。但我无法控制的状态字节也不是SW在响应（D5 41 XX和两个SW的）字节。有没有被发现，除了左右源头code本身这个IsoPcdA类文档。
The problem lays in the answer I send from the device to the reader. Using the transcieve function (android.nfc.tech.IsoPcdA with reflection), I can reply with a byte array of length > 0. This would show up on the reader-end like a normal InDataExchange response (e.g: D5 41 00 01 02 03 with {01 02 03} being the byte array supplied to the transcieve function). But I can't control the status byte nor the SW bytes in the response (D5 41 XX and both SW's). There's no documentation to be found about this IsoPcdA class except the source code itself.
我希望能够做的就是改变XX我选择的字节，发送长度为0的答案（例如：D5 41 01没有任何额外的数据）。这可能吗？
What I want to be able to do is change the XX to a byte of my choice and to send answers of length = 0 (e.g: D5 41 01 without any extra data). Is it possible?
推荐答案
我不完全相信你正试图在这里实现的目标。不管你用IsoPcdA的收发方式收发完成的APDU（如ISO / IEC 7816-4，或者说了ISO-DEP传输协议中的任何PDU定义）。所以收发的返回值是一个完整的C-APDU（命令APDU）和收发的字节数组参数是一个完整的R-APDU（响应APDU），包括状态字的两个字节（SW1 | SW2）。因此，该参数的最后两个字节的状态字。在您的例子SW1是02和SW2将是03。
I'm not exactly sure what you are trying to achieve here. Whatever you transceive with IsoPcdA's transceive method are complete APDUs (as defined in ISO/IEC 7816-4, or rather any PDU within the ISO-DEP transport protocol). So the return value of transceive is a full C-APDU (command APDU) and the byte array parameter of transceive is a full R-APDU (response APDU) including the two bytes of the status word (SW1 | SW2). Thus, the last two bytes of that parameter are the status word. In your example SW1 would be 02 and SW2 would be 03.
你看到的如PN532 NFC控制器的InDataExchange命令状态字节是不是APDU的状态字，但PN532 NFC控制器中的命令执行的状态。这种状态字节为您提供了有关缓冲区溢出，通信超时等，而不是由卡方返回的东西。
What you see as status byte in the InDataExchange command of the PN532 NFC controller is not the status word of the APDU but the status of the command execution within the PN532 NFC controller. This status byte gives you information about buffer overflows, communication timeouts, etc and is not something that is returned by the card side.
编辑：样品code +测试命令：
上的Galaxy Nexus（CM 10）样品code运行：
Sample Code running on Galaxy Nexus (CM 10):
try {
Class isoPcdA = Class.forName("android.nfc.tech.IsoPcdA");
Method isoPcdA_get = isoPcdA.getDeclaredMethod("get", Tag.class);
final IsoPcdA techIsoPcdA = (IsoPcdA)isoPcdA_get.invoke(null, tag);
if (techIsoPcdA != null) {
if (mWorker != null) {
mInterrupt = true;
mWorker.interrupt();
try {
mWorker.join();
} catch (Exception e) {}
}
mInterrupt = false;
mWorker = new Thread(new Runnable() {
public void run () {
try {
techIsoPcdA.connect();
byte[] command = techIsoPcdA.transceive(new byte[]{ (byte)0x90, (byte)0x00 });
Log.d(CardEmulationTest.class.getName(), "Connected.");
while (!mInterrupt) {
Log.d(CardEmulationTest.class.getName(), "C-APDU=" + StringUtils.convertByteArrayToHexString(command));
command = techIsoPcdA.transceive(command);
}
} catch (Exception e) {
Log.e(CardEmulationTest.class.getName(), "Exception while communicating on IsoPcdA object", e);
} finally {
try {
techIsoPcdA.close();
} catch (Exception e) {}
}
}
});
mWorker.start();
}
} catch (Exception e) {
Log.e(CardEmulationTest.class.getName(), "Exception while processing IsoPcdA object", e);
}
测试（使用ACR122U）：
Test (using ACR122U):
InListPassivTargets（在106kbps 1目标）
InListPassivTargets (1 target at 106kbps)
> FF00000004 D44A 0100 00
< D54B 010100046004088821310578338800 9000
InDataExchange与DATA = 0×01
InDataExchange with DATA = 0x01
> FF00000004 D440 01 01 00
< D541 00 01 9000
所以，我们从读卡器获取为0x00错误code（InDataExchange命令的情况;没有实际响应APDU的一部分），我们得到0×01作为响应（这是IsoDepA响应APDU），我们得到0×9000的状态code的读卡器包装APDU（而不是实际响应APDU的一部分）。
So we get an error code of 0x00 from the card reader (status of InDataExchange command; not part of the actual response APDU), we get 0x01 as the response (this is the IsoDepA response APDU) and we get 0x9000 as the status code for the card reader wrapper APDU (not part of the actual response APDU).
InDataExchange与DATA = 0×01 0×02
InDataExchange with DATA = 0x01 0x02
> FF00000005 D440 01 0102 00
< D541 00 0102 9000
所以，我们从读卡器获取为0x00错误code，我们得到0×01 0×02作为响应（这是IsoDepA响应APDU）和我们（InDataExchange命令的状态而不是实际的应答APDU的一部分）得到0×9000的状态code的读卡器包装APDU（而不是实际响应APDU的一部分）。
So we get an error code of 0x00 from the card reader (status of InDataExchange command; not part of the actual response APDU), we get 0x01 0x02 as the response (this is the IsoDepA response APDU) and we get 0x9000 as the status code for the card reader wrapper APDU (not part of the actual response APDU).
InDataExchange与DATA = 0×01 0×03 0×02
InDataExchange with DATA = 0x01 0x02 0x03
> FF00000006 D440 01 010203 00
< D541 00 010203 9000
所以，我们从读卡器获取为0x00错误code;，我们得到0×01 0×02×03的反应（这是IsoDepA响应APDU）（InDataExchange命令的状态而不是实际的应答APDU的一部分）和我们得到0×9000的状态code的读卡器包装APDU（而不是实际响应APDU的一部分）。
So we get an error code of 0x00 from the card reader (status of InDataExchange command; not part of the actual response APDU), we get 0x01 0x02 0x03 as the response (this is the IsoDepA response APDU) and we get 0x9000 as the status code for the card reader wrapper APDU (not part of the actual response APDU).
InDataExchange与DATA = 0×01 0×03 0×02×04
InDataExchange with DATA = 0x01 0x02 0x03 0x04
> FF00000007 D440 01 01020304 00
< D541 00 01020304 9000
所以，我们从读卡器获取为0x00错误code;，我们得到0×01 0×02×03×04的反应（这是IsoDepA响应APDU）（InDataExchange命令的状态而不是实际的应答APDU的一部分）我们得到0×9000的状态code的读卡器包装APDU（而不是实际响应APDU的一部分）。
So we get an error code of 0x00 from the card reader (status of InDataExchange command; not part of the actual response APDU), we get 0x01 0x02 0x03 0x04 as the response (this is the IsoDepA response APDU) and we get 0x9000 as the status code for the card reader wrapper APDU (not part of the actual response APDU).
于是，我们得到完全taht我们作为APDU命令发送的响应APDU（注意，没有这些的APDU的数据被格式化根据ISO 7816-4，但是这并不重要的IsoPcdA卡仿真与任何ISO 14443- 4传输协议格式）。
Thus, we get exactly the data taht we send as command APDU as response APDU (note that none of these APDUs is formatted according to ISO 7816-4, but that doesnt matter as the IsoPcdA card emulation works with any ISO 14443-4 transport protocol format).
的状态code的 0×9000 的属于读卡器APDU封装（ CLA = FF INS = 00 P1P2 = 0000 LC [PN542命令]乐= 00 的所需要的ACR122U的PN532）在CCID（PC / SC）接口进行访问。这是纯粹的阅读器命令封装和无关超过ISO-DEP通信。
The status code of 0x9000 belongs to the card reader APDU encapsulation (CLA=FF INS=00 P1P2=0000 Lc [PN542 COMMAND] Le=00) that is required as the ACR122U's PN532 is accessed over the CCID (PC/SC) interface. These are pure reader command encapsulation and have nothing to do with the communication over ISO-DEP.
的 D440 01 [数据] 的是PN532命令来交换数据（例如APDU的）在ISO-DEP和的 D541 00 [数据] 的是相应的响应。
The D440 01 [DATA] is the PN532 command to exchange data (e.g. APDUs) over ISO-DEP and the D541 00 [DATA] is the associated response.
这篇关于控制在Android全APDU与NFC软件卡仿真的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
