Does a manipulated CAP file can break a Java Card in the installation process?

Question

I have a Java Card that works fine :

GlobalPlatfomPro:: gp -list
AID: A000000003000000 (|........|)
     ISD OP_READY: Security Domain, Card lock, Card terminate, Default selected,
 CVM (PIN) management

I write a simple program to return APDU buffer on reception of each command :

public class BArrayReturner extends Applet {

    public static byte[] theArray={(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff,(byte)0xff};
    public static short arrayLength=0;

    private BArrayReturner() {

    }

    public static void install(byte bArray[], short bOffset, byte bLength)
            throws ISOException {

        new BArrayReturner().register();
        BArrayReturner.arrayLength=(short)bArray.length;
        Util.arrayCopyNonAtomic(bArray, (short)0,BArrayReturner.theArray , (short) 0, BArrayReturner.arrayLength);    
    }

    public void process(APDU apdu) throws ISOException {
        byte[] buffer=apdu.getBuffer();
        Util.arrayCopyNonAtomic(BArrayReturner.theArray, (short)0,buffer , (short) 0, (short)0x40); 
        apdu.setOutgoingAndSend((short)0, (short)255);
    }

}

After converting of the above program to .cap file, I opened the cap file with WinRAR and change one byte of .CAP file as below :

(I replaced 0x78 instead of 0x07 in ninth bye of class.cap).

Click to enlarge :

Now I tried to install this new cap file. But not only the installation failed, but also I can't list contents of my card anymore :

GlobalPlatfomPro:: gp -list -v -d
# Detected readers
[*] ACS CCID USB Reader 0
SCardConnect("ACS CCID USB Reader 0", T=*) -> T=0
SCardBeginTransaction("ACS CCID USB Reader 0")
Reader: ACS CCID USB Reader 0
ATR: 3B68XxXxXxXxXxXx009000
More information about your card:
    http://smartcard-atr.appspot.com/parse?ATR=3B68XxXxXxXxXxXx009000

A>> T=0 (4+0000) 00A40400 00
A<< (0000+2) (20ms) 6F00
SCardEndTransaction()
SCardDisconnect("ACS CCID USB Reader 0", false)
Exception in thread "main" java.lang.IllegalStateException: No selected ISD!
        at openkms.gp.GlobalPlatform.openSecureChannel(GlobalPlatform.java:327)
        at openkms.gp.GPTool.main(GPTool.java:280)

My Question:

What was happened on my smart card by this new generated CAP file? Does anyone have any idea about the byte codes and the meaning of this byte in the origin and manipulated file? Is this a good logical response to installing manipulated files?

Note1:

I tried to install this new cap file my JCOP card also. The installation failed again, but instead of above error, the card mute about 15 minutes. (It must be about 15 minutes in the card reader to be active again!)

Note2:

I tried to change the 10th byte of this file instead of the 9th byte. So I replaced 0x01 with 0x45. After that I installed the new CAP file successfully! Shouldn't the card detect this manipulation after byte-code verification also and prevent installation?

score 3 · Accepted Answer · answered Apr 20 '15 at 09:06

3

You successfully triggered defense mechanisms on the card! Depending what you changes are the byte code verifier either fails and mutes the card or it will pass the test. the cap file is just an container. If you want deeper anaylsis you have to read more about the actual Java Card Byte code

answered Apr 20 '15 at 09:06

Paul Bastian

2,597
11
26

Thanks dear Paul. Doesn't the byte-code verifier add any checksum or something to the program? I mean shouldn't the card prevent installing the CAP file in cases that I changes the 10th byte of the `class.cap file`? In which step the DAP and Signature Tokens add to our program? (after CAP generation and in uploading step or during CAP generation process?) – Ebrahim Ghasemi Apr 20 '15 at 12:00
Wouldn't you be able to recalculate the checksum as well? – Paul Bastian Apr 20 '15 at 12:35
So, how we can prevent manipulating CAP file after generation? How the on-card verifier detects changes? – Ebrahim Ghasemi Apr 20 '15 at 13:30
1

I think global platform supports load file signature verification. Usually applets are installed in a safe environment so this isn't an issue – Paul Bastian Apr 20 '15 at 13:39
When this load files sign? During the installation procedure or during cap file generation? As I understand from the GP Specification 2.2.1 (Pages 26-27-28), GP cards use three mechanism : **1- Load file Data Block Hash** ,**2- Load File Data Block Signature** and **3- Load File Tokens(Is this equal with Delegated Management Tokens?)**. right? is there any other mechanism? When this mechanism implements off-card? In the installation time or in the CAP generation? Does all of them used simultaneously or we select one of them? – Ebrahim Ghasemi Apr 21 '15 at 06:10
You should check first what your card supports – Paul Bastian Apr 21 '15 at 08:56

Does a manipulated CAP file can break a Java Card in the installation process?

1 Answers1