You correctly adjusted P1 and P3 for the last block of data. However, P2 ,that is the block number, is incremented too, suggesting in this way that this last block is identical in size with previous ones.
I can not guaranty that my suggestion will work because I never worked with CyberFlex Access 32K cards, but if I would be you I would try to reset the block counter:
So, instead of :
80 E8 80 29 26 0D 0A 09 09 0A 0F 12 0C 0E 17 0B
14 21 03 0B 0A 0E 04 08 09 12 1A 0A 0C 14 14 03
0D 03 09 0F 03 06 0F 0A 12 09 10
I suggest you try:
80 E8 80 00 26 0D 0A 09 09 0A 0F 12 0C 0E 17 0B
14 21 03 0B 0A 0E 04 08 09 12 1A 0A 0C 14 14 03
0D 03 09 0F 03 06 0F 0A 12 09 10
The cursor should be set already at the end of already successfully loaded data, so the load APDU command should basically concatenate this last block of length 0x26 with the previous one of length 0xFF.
Good luck,
Michaela
----------------------------------------------
Michaela Iorga, Ph.D.
NIST - Computer Security Division
301-975-8431
At 01:33 PM 3/26/2003, you wrote:
So, I was looking at this again. The ADPU that was failing looks wrong to
me:
> 80 50 00 00 08 95 B9 7C 79 CE 59 38 0C 1C
there are 9 data bytes, but the P3/Lc value is only 8.
If I convince the IFD to ignore that problem, the process gets much farther
but does not complete.
CFlexAccess32Loader appears to successfully authenticate, tries deleting an
old instance of the applet (which fails), succeeds in sending an 0x80 0xE2
command (Appears to be "create record") and sends 40 255 byte blocks of
data.
When it tries sending the last (partial) data block to the card, the card
returns 0x69 0x85, which may or may not mean 'conditions of use not
satisfied'
Complete output at
http://www.contrib.andrew.cmu.edu/~cg2v/unreleased/cflexloader.output-2
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.musclecard.com/mailman/listinfo/muscle
