Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Sam Duke (samduke474gmail.com)
Date: Sat May 18 2013 - 14:17:16 CDT
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)?
On 16 May 2013 07:46, "Francois Grieu" <fgrieugmail.com> wrote:
> About the log at
> On 15/05/2013 14:02, Ludovic Rousseau wrote
> > 2013/5/15 Sam Duke <samduke474gmail.com>:
> >> 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
> 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
> 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
Muscle mailing list