Clearing byte array field
Hello all,
I've encountered a problem in trying to reset fields in my applets which I just can't figure out, I'd appreciate some help with it.
Basically I have a method in a base class for my applets which sets the fields in my card. This works fine, the problem I have is when I tried to alter this method so that if the command APDU received does not contain the data field(i.e. a Case 2 APDU, 5 bytes long), then the designated byte array is set to null. The code is shown below.
// Method in applet
public void setSurname(APDU apdu) {
surname = setByteArrayVariable(apdu);
}
// Method in applets' base class
public byte[] setByteArrayVariable(APDU apdu) {
byte[] apduBuffer = apdu.getBuffer();
short len = apduBuffer[ISO7816.OFFSET_LC];
byte[] arrayname = null;
if(len != (short)0){
arrayname = new byte[len];
// copy buffer data into byte[]
short bytesRead = apdu.setIncomingAndReceive();
short Offset = (short)0;
while (bytesRead > 0) {
Util.arrayCopy(apduBuffer, ISO7816.OFFSET_CDATA, arrayname, Offset, bytesRead);
Offset += bytesRead;
bytesRead = apdu.receiveBytes(ISO7816.OFFSET_CDATA);
}
}
return arrayname;
}
What happens when I send the Case 2 APDU to the applet is that the CLA and INS bytes direct the apdu to the proper method to set the field and the byte array is set to null(success). At this point I expect the JCRE to return the sw 9000, however what actually happens is the applet throws the ISOException defined in the default case of the process method. Also I checked this method in the gemplus simulator and it works as expected, its only when I tried it in a GXP211_PK_IS card that the problem occurred, I've asked the Gemplus support about this but as yet have not heard anything in response. I cannot explain why this is happening, has anybody got any suggestions? Thanks,
Tony
[1984 byte] By [
Tonyf1] at [2007-9-27 18:32:40]
What is the status word on the exception ?
So if LC is 0 this is what your code would look like !
// Method in applet
public void setSurname(APDU apdu) {
surname = setByteArrayVariable(apdu);< this returns null on Case 2
}
// Method in applets' base class
public byte[] setByteArrayVariable(APDU apdu) {
byte[] apduBuffer = apdu.getBuffer();
short len = apduBuffer[ISO7816.OFFSET_LC];
byte[] arrayname = null;
return arrayname;
}
I'm guessing that you check for surname != null later on ?
- Side note --
Rule #1. allocate memory in the Applet.install()/constructors. 15 yard penalty !
The status word which is returned is 6D00(INS not supported), as this is what I throw in the process method when the switch doesn't match the INS byte with any of the cases. This is where my confusion comes from, if the method is called(through matching the CLA and INS bytes) how is it that after the method is completed(successfully, as the field is set to null) that the exception is thrown form the process method as if the method wasn't found? I have a workaround whereby instead of throwing the 6D00 I throw the ISO7816.SW_NO_ERROR in the default case of my process method, this can only be a temporary workaround though!!
>>I'm guessing that you check for surname != null later on ?
I do check this but only when I'm trying to retrieve the surname from the card, basically, if(surname == null)ISOException.throwIt(ISO7816.SW_FILE_NOT_FOUND);
Doesn't sound like thats what you're getting at though?
(Will sort out the memory allocation, cheers.)
TIA for any help you can provide, leaving now for the day but hoping to hear from you tomorrow :)
Tony
As you are finding out, on card debugging isn't pretty ! Simulators are nice tools, but what happens on card could have different behavior or a bug. Don't rely on simulators, it's the card that counts !
Here are some suggestions:
Exception handling Insert some try..catches in your methods.
Data Dumps Use the response APDU to echo some data back to you so you can see what's going on. For example, for your default processing, send a response APDU with the INS it says is incorrect.
Exceptions as breakpoints Throw exceptions with user-defined status words so you know how far you've gotten. Then you can use the data dump and see what's going on.
I've had a problem like yours with the INS dropping out. I think it had to do with the way I was handling the switch..case statement.
