Response APDUs of 256 bytes do not work

[joostrijneveld]

I'm using the CLI interface by supplying .apdu files; my command APDU is merely an empty APDU with a custom CLA and INS (that trigger the right Javacard function): 0x80 0xb4 0x0 0x0 0x0 0x0. The behaviour does not change when I alter the value of the Le field.

The Javacard code I'm executing is the following simple proof of concept (where tmp is a sufficiently large array and randomData is a RandomData instance):

apdu.setOutgoing();
short numBytes = (short)256;

randomData.generateData(tmp, (short) 0, numBytes);
apdu.setOutgoingLength(numBytes);
apdu.sendBytesLong(tmp, (short) 0, numBytes);

When I set numBytes to 255 and output an APDU that contains 255 bytes of data, everything works fine, but as soon as I try to output 256 bytes, the response APDU appears to be broken. I then get the response CLA: 80, INS: b4, P1: 00, P2: 00, Lc: 00, Le: 00, SW1: 00, SW2: 03

On my actual physical Javacard, it works as expected.

Is this a known limitation of jcardsim? I looked through the source code, but could not find anything that seems to imply this behaviour.

[paulbastian]

Lc = 0x00 is not allowed according to ISO7816-4 and should not work on any card or simulation. Your command is malformed.

[joostrijneveld]

Fair point - thanks!

When I change my command to 0x80 0xb4 0x0 0x0 0x0; (i.e. omitting the Lc field to indicate an empty data field), I'm not getting back any response at all, i.e. my cfg file looks as follows:

// CREATE APPLET CMD
0x80 0xb8 0x00 0x00 0x10 0x9 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x8 0x09 0x05 0x00 0x00 0x02 0xF 0xF 0x7f;
// SELECT APPLET CMD
0x00 0xa4 0x00 0x00 0x09 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x8 0x09 0x0;
// Send command
0x80 0xb4 0x0 0x0 0x0;

And the output of java -cp jcardsim-2.2.2-all.jar com.licel.jcardsim.utils.APDUScriptTool is

CLA: 80, INS: b8, P1: 00, P2: 00, Lc: 10, 09, 01, 02, 03, 04, 05, 06, 07, 08, 09, 05, 00, 00, 02, 0f, 0f, Le: 09, 01, 02, 03, 04, 05, 06, 07, 08, 09, SW1: 90, SW2: 00
CLA: 00, INS: a4, P1: 00, P2: 00, Lc: 09, 01, 02, 03, 04, 05, 06, 07, 08, 09, Le: 00, SW1: 90, SW2: 00

Alternatively, when I do set the Lc field to 0x01 and supply a byte of data (i.e. 0x80 0xb4 0x0 0x0 0x01 0x0 0x0;), I'm back in the situation I described in the original post, where responding with 256 bytes results in CLA: 80, INS: b4, P1: 00, P2: 00, Lc: 01, 00, Le: 00, SW1: 00, SW2: 03