This content has been marked as final. Show 3 replies
You can't force java card, you need to behave it according to its standards.
Hello 799335 ,
In "GlobalPlatform Card Specification" Version 2.2.1.
Section A.1: T=0 Transmission Protocol
i read the info as "+If the data is less than the data expected by the terminal, the OPEN will store the data and output a '6Cxx' response code and wait for the CAD to re-issue the command with the correct length. When the re-issued command is received the JCRE will manage the outputting of the stored data+".
May be this is also the reason to getting 6CXX.
Hope this will help you.
Answering my own question for those who might stumble upon it.
Say I have commands 00 12 00 00 00 and 00 12 00 00 64 and 0A bytes of data to send back (all numbers are hex).
This is a case 2 APDU, thus P3 is supposed to be Le, not Lc, with the Le semantics as described in ISO (00 = "all data available up to 256"). I would like to process Le to send different SW-s with the data if necessary (like 6282 if called with the second command, where 0A < 64).
Calling setIncomingAndReceive is thus not supposed to be called when implementing this command, as there is not supposed to be any input from the host (case 2)
Calling setOutgoing* will result in an otherwise proper command-cycle with P3=00, but with 6CXX instead of 61XX.
Thus it is needed to "eat away" the Le byte as empty (zero) Lc with setIncomingAndReceive if P3 == 00, after what setOutgoing will not have a reference value for the expected Le and setOutgoing* will result in 61XX response in T=0 mode (and of course, proper functioning in T=1 as well).
Probably obvious, but made me wonder for a while.