1

Based on response APDU. I receives 61XX, which indicate i could read XX bytes (Length 0x00). I wonder, if I want to read 0x0000 in the Le, will always get maximum 61FF which 256 bytes available.

Is it possible to read 0x0000 length in the command APDU and receive all of it?

HelmiB
  • 12,303
  • 5
  • 41
  • 68

3 Answers3

1

You probably want to use T=1 in this case and that would mean no 61XX answers (which is a property of T=0)

Martin Paljak
  • 4,119
  • 18
  • 20
0

61xx suggests, that you currently use T=0. Whether the also supports T=1 (this is not certain, but possible), is coded in the ATR, but hard to derive by humans without 7816-3 knowledge). The problem is, that 61 xx provides only one byte. You can now proceed with two approaches:

  • (cautious) either you try sending a GET RESPONSE with the given value, which again might return an 61 xx status code.

  • (progressive) send a GET RESPONSE using an LE coding of extended length (not all cards support it, but 61 xx does not imply, that your card does not).

guidot
  • 5,095
  • 2
  • 25
  • 37
-1

As you mentioned, "61xx" means you can only get "xx" bytes data from the ICC. The number of returning data byte is controlled by ICC, and it is useless to send other value to ICC unless you wants to get less data from ICC (i.e., <= "xx").

As Martin said, "61xx" only presents in T=0 protocol. For T=1, it will never appear such a status word.

Charles Chen
  • 23
  • 2
  • what possible response i get if I transmit length 0x0111 for example? what the trailer possibly be? – HelmiB Nov 06 '12 at 02:06
  • Sorry to disagree. While not common, 61 xx is perfectly admitted in T=1, see 7816-4 (2005 edition), command GET DATA, or simply the case, that even for a card supporting extended length APDUs more data are available than the dimension of the current I/O buffer. – guidot Nov 08 '12 at 11:37