I have a question.
I am making an applet.
Into the Select command, I think my applet cannot get the Le data.
The Le value has always '00' even though the select command Le value has been changed.
First, in order to get the Le, I used the apdu.setOutgoing(), which returns Le, and then I checked the Le != 0.
However, I think the setOutgoing() always returns '00' in my applet, and the applet does not perform the checking Le statement.
I guess my testing environment or performing follow has a problem, but I am not sure.
I want to hear your opinion and how to test in this case.
short idl = apdu.setIncomingAndReceive();
byte apduBuffer = apdu.getBuffer();
short le = (short)(apdu.setOutgoing() & (short)0x00ff);
if(apduBuffer[ISO7816.OFFSET_CLA] != CLASS_ISO)
Util.arrayCopy(fileControlInformation, (short)0, transientData, TD_OFF_FILE_CONTROL_INFORMATION, (short)fileControlInformation.length);
if((apduBuffer[ISO7816.OFFSET_P1]!=(byte)4) || ((apduBuffer[ISO7816.OFFSET_P2]!=(byte)0)))
if((apduBuffer[ISO7816.OFFSET_LC] == (byte)0) || (idl == (short)0) || (apduBuffer[ISO7816.OFFSET_LC] != (byte)idl) || (le != (short)0))
Although wrong Le is added, the applet returns 9000.
I know why the applet returns 9000.
The point is how to test it correctly.
글 수정: Jin
not really, "select application" can return whatever you like, and most applets do return something: a file control information template (fci) giving the AID and other info (for an example, try to select a card manager). That's a good practice: because you can select an application with only part of an AID, the applet usually replies with this complete AID. [tell the card: "Hello ath", she will respond "Hello, understood, but if you want to know, my full name is Athena" :) ]
Jin, can you post your whole process() algorithm for the select command, including: how are you returning data? do you use apdu.SendBytes() ?
if you have a contactless card it is possible that Le is always zero, because according to iso7816 zero means "all available data".
why? because a contactless card (or a T=1 card) can return any length without prior indication, so it does not need Le.
or it might be a bug in your javacard implementation...
You can use apdu.SetOutgoingLength() to indicate the real length of the response, and usually the card OS (below javacard) relies on that to create a 6CXX response if there's a problem.
A workaround can be: Read Le in the apdu buffer at the correct offset, and send a 6CXX SW yourself if you're not satisfied with it.
I'm expecting more details from you to fully understand the problem.
should be He will respond :P
Well i was talking about the usual behavior of the SELECT command that it just tells you weather an applet is select successfully. But yes you are right, I was unaware of getting data bank from selection. I also get something useful from your post :)
Thank you Sebastien~~
Posting whole process() is a little bit complicated because It is still work in progress with a company, which makes a contract.
I think a little bit posting is okay. I need to check.
This applet can be supported on both contact and contactless interfaces. However, it focuses on the contact interface as a payment application.
In order to indicate real length of the response, I will have to test the Le using the apdu.SetOutgoingLength() as you mentioned. :)