Jakob Bohm a écrit :
according to GP 2.1.1, the load command does not throw 6A80, but the install
command can.
well, it does....
of course it can! if the 'C4' tag is missing, if some lengths are
badly DER encoded, if a mandatory component is missing, if a required
package is not present in card, if a package-version is too high, ...
I hadn't know that, and I used those, so in response to your post
I tried removing the -nvCodeLimit option, and then I got 6A80
after just a few bytes of code. The I tried upping the limit from
8500 to 18500, and then more code got downloaded followed by a new
error code (still during load):
6985: Conditions of use not satisfied
there is may be a different reason.
select -AID a0000000030000
open_sc -security 1 -keyind 0 -keyver 0 <GP ISK>
delete -AID a00000000101
<-- 6A88
delete -AID a000000001
<-- 6A88
install_for_load -pkgAID a000000001 -nvCodeLimit 8500
--> 80E602001705A00000000107A00000000300000006EF04C60221400000
<-- 009000
80 E6 02 00 17
05 A000000001 -- package AID
07 A0000000030000 -- card domain AID
00 -- no File Data Hash
06 -- load parameters length
EF 04 -- load parameters field
C6 02 2140 -- 8512 bytes of EEPROM required
00 -- no Load Token
if the "-nvCodeLimit" parameter is supposed to build the
load parameter field it is quite strange that it chooses
to change 8500d to 8512d.
may be that value is too small, according empiric computation
(based on the begining of your CAP file present hereafter)
the on-card required size for your package is about 8300 bytes,
it is too close to not be a potential error, try with 9 or 10k.
load -file CardEdge.cap.transf
file name CardEdge.cap.transf
-->
80E80000EFC4822CE801000FDECAFFED0102050C0005A00000000102001F000F001F000A00290242006C1F51000A03D50000068B00060000000004010004002904000107A0000000620101010107A0000000620102010107A0000000620201000107A000000062000103000A0106A00000000101009406006C00800314000D0404000500D4FFFF00B700F005C205DF05FE061D0647008300020001011100001A941B0A1B311BE81BF51C181C531C5D1C651C6E1C751C821C8D1C981CA11CB21CC3008300030001010D00001CDF1D371D591D9C1DAC1DBC1DDC1E901EA41EB51EC41ED21F36071F51000640188C002C1803880010
<-- 6A80
this APDU contains the directory, applet & import components,
according the last the applet requires:
A0000000620101 vers. 1.0 ie javacard.framework JVC 2.1
A0000000620102 vers. 1.1 ie javacard.security JVC 2.1.1
A0000000620201 vers. 1.1 ie javacardx.crypto JVC 2.1.1
A0000000620001 vers. 1.0 ie java.lang JVC 2.1
select -AID a0000000030000
open_sc -security 1 -keyind 0 -keyver 0 <ISK>
install_for_load -pkgAID a000000001 -nvCodeLimit 12500
--> 80E602001705A00000000107A00000000300000006EF04C60230E00000
<-- 009000
ok, you did it.
load -file CardEdge.cap.transf
file name CardEdge.cap.transf
-->
80E80000EFC4822CE801000FDECAFFED0102050C0005A00000000102001F000F001F000A00290242006C1F51000A03D50000068B00060000000004010004002904000107A0000000620101010107A0000000620102010107A0000000620201000107A000000062000103000A0106A00000000101009406006C00800314000D0404000500D4FFFF00B700F005C205DF05FE061D0647008300020001011100001A941B0A1B311BE81BF51C181C531C5D1C651C6E1C751C821C8D1C981CA11CB21CC3008300030001010D00001CDF1D371D591D9C1DAC1DBC1DDC1E901EA41EB51EC41ED21F36071F51000640188C002C1803880010
<-- 9000
[all intermediate load steps OK]
--> 80E880301C6810F0056811000568009004443103443006B444410544B410034B2000
<-- 6985
this is the very last APDU (P1 == 80) some other tests occur at this
stage, and I so think that this is a different error than the previous
6A80 that was solved by an higher EEPROM space request.
there is no obvious explanation for this '6985', the CAP file is valid
I succesfully load it into a CosmopolIC card.
I have no clue for Cyberflex, expect not using a Cyberflex.
Sylvain.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
