On 18/05/2013 21:17, Sam Duke wrote : > > Very well summarised, thank you. My interpretation of the 90 00 was that it > was part of the ISO7816 standard. however > 90 00 only seems to appear in the "status bytes" section of the spec so I am > now unsure of what is generating them. > Would you still be suspect of the firmware erroneously adding this or could > it be the initiator of the APDU message > (aka the phone)? >
The 90 00 makes no sense as part of the ISO 7816 standard at the end of a Command-APDU message, which is what we are seeing. The 90 00 appears in many (but, I realize now, not quite all responses to ScardControl; this is a strong indication that it is generated NOT as part of the ScardControl gear in the PC (where it would likely never or always be present; also it would be unheard of by me that ScardControl adds a final 90 00 on its own initiative). My guess is that the 90 00 is generated by some layer of the ACR122U firmware, as a trailer to any message from the NXP chip to the PC thru ScardControl. Any other hypothesis (like, the initiator or NXP chip generates it) seems unlikely to me. Now there's the truncation. It could be by the ACR122U firmware when the NXP chip makes big frames, and that's my favorite guess. It could also be in the initiator. That would be unheard of by me. It could also be an artifact of an incomplete implementation of ISO 14443-4 chaining, in the initiator (or even the NXP chip). Chaining splits the Command APDU into two frames, because the ISO 14443-4 makes it necessary for the initiator to make frames of at most 256 bytes, including 2-byte final CRC and 1 to 3 bytes header PCB (CID) (NAD), and thus transfer the C-APDU (of 260 bytes) as two frames; however if that was the cause of the truncation, it should be to 247 bytes (give or take 1) of incoming data, not 239, thus I do NOT believe the frame size is the cause of the truncation. The truncation and 90 00 occur at the same point; the simplest assumption is that there are only one device misbehaving and causing both, and again that points to the ACR122U firmware. As a matter of fact, "long" APDUs have interoperability problems in some contexts. In my experience, anything with at most 128 bytes of incoming or outgoing data works reliably almost everywhere; 160 is still very supported; above that you mileage will vary widely. Francois Grieu > On 16 May 2013 07:46, "Francois Grieu" <[email protected] > <mailto:[email protected]>> wrote: > > About the log at > http://www.sendspace.com/file/ndqiyv > > On 15/05/2013 14:02, Ludovic Rousseau wrote > > 2013/5/15 Sam Duke <[email protected] <mailto:[email protected]>>: > >> The trace begins " 00000062 Control RxBuffer: D5 87 00 00 D6 00 02 FF" > > It is part of the _response_ from the reader. It is not an APDU. > > Sam Duke is using an ACR122U in card emulation mode, using ScardControl. > > The emulated card receives a message from an initiator, that includes > > 1) a TgGetData response header D5 87 00, explained on page 160 of that > public document on the NXP chip (or a similar one) used by the ACR122U > http://www.nxp.com/documents/user_manual/141520.pdf > 2) a Command APDU header CLA/INS/P1/P2/Lc, 00 D6 00 02 FF > 3) some incomplete incoming data (there should be 255 bytes, there are > 239) > 4) 90 00, which is an artifact in all Control RxBuffer in the log. > > The truncation could be > a) by the initiator of the APDU > b) by NXP chip, but the public document quoted indicates that the size > limit of of data block following the TgGetData response header is 262 > bytes. > c) the ACR122U firmware > d) whatever chain is involved in the ScardControl > > Whatever adds the 90 00 is likely the cause of the truncation. > My bets are on the ACR122U firmware. > > Francois Grieu > > _______________________________________________ > Muscle mailing list > [email protected] <mailto:[email protected]> > http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com > > > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
_______________________________________________ Muscle mailing list [email protected] http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
