[Muscle] Cyberflex e-gate 32k install error 6A80

[Jakob Bohm]

On Wed, May 27, 2009 at 03:44:04PM +0200, muscle-bounces at lists.musclecard.com wrote:
> Jakob Bohm a écrit :
> >
> >1. When I try to install the applet using gpshell, the card refuses the
> >"load" command with error 6A80 ("invalid data").
> 
> if the CAP file format is valid (meaning a flat one and not
> he JAR format generated by SUN tools), the error can be due
> to a package referenced by the applet and not present in the
> card runtime, or present with a lower version than requested.
> note that these versions come from the export files used to
> generate the CAP, so you should NOT use the lastest JVC DevKit
> (and thus use the 2.2 instead of 2.2.2) to avoid these mistakes.
> 

As I said, the very same compile and install scripts succeed with
different sources, so I think the file format is OK.

I compiled with the JC 2.1.1 .class and .java files (except
javacardx.* which I took from JC 2.1.2) and with the export files
from JC 2.1.1 exclusively (strangely, JC 2.1.1 included export
files but no .class or .java files for javacardx.*).  For the
compiler and PC side JRE I used the 1.5.x Sun JDK in Debian Lenny
(5.0).

As for the module versions, how do I determine which versions of
the runtime packages are actually on the card?

> >2.4 CardEdge.src does not compile with the JavaCard 2.1.1 kit due to a 
> >small
> >bug in the addition of Extended APDU support.  Here is my patch:
> >
> >     private void ComputeCrypt(APDU apdu, byte[] apduBuffer) {
> > 	byte[] buffer = apduBuffer;
> >+#ifdef WITH_EXT_APDU	
> > 	short dataOffset = apdu.getOffsetCdata();
> >-#ifdef WITH_EXT_APDU	
> > 	short LC = apdu.getIncomingLength();
> > 	short bytesLeft = apdu.setIncomingAndReceive(); 
> 
> this is INVALID. according SUN specification, getIncomingLength
> & getOffsetCdata can be used only AFTER a call to setIncomingAndReceive.
> 

Then it was already invalid!  The only thing I did was to move the
#ifdef line up and add a dummy assignment of the non-extended APDU
constant in the #else branch.

It seems the original EXT_APDU patch was even sloppier than I
thought: It makes the FIRST target in build.xml not compile
(Cyberflex and JS2.1.x do not have APDU.getOffsetCdata()) and on
platforms *with* EXT_APDU support it makes the calls in the wrong
order.

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.