Java Card cap File loading Failure Without Any Error

Java Card cap File loading Failure Without Any Error - javacard

I'm trying to install a big applet (about 40 KB) applet on my Java Card. But It fails without any special error:
GPP:> gp -install e:\applet.cap -v -d -i
//Useless Info Censored
Reader: ACS ACR1281 1S Dual Reader PICC 0
ATR: 3B8680014B4F4E4110809C
More information about your card:
http://smartcard-atr.appspot.com/parse?ATR=3B8680014B4F4E4110809C
A>> T=1 (4+0000) 00A40400 00
A<< (0018+2) (13ms) 6F108408A000000003000000A5049F6501FF 9000
[DEBUG] GlobalPlatform - Auto-detected ISD AID: A000000003000000
[DEBUG] GlobalPlatform - Auto-detected block size: 255
***** Card info:
A>> T=1 (4+0000) 80CA9F7F 00
A<< (0045+2) (13ms) 9F7F2A47906C1482415046C7225077005179978161481050771180507700000000000000000000000000000000 9000
Card CPLC:
ICFabricator: 4790
ICType: 6C14
OperatingSystemID: 8241
OperatingSystemReleaseDate: 5046
OperatingSystemReleaseLevel: C722
ICFabricationDate: 5077
ICSerialNumber: 00517997
ICBatchIdentifier: 8161
ICModuleFabricator: 4810
ICModulePackagingDate: 5077
ICCManufacturer: 1180
ICEmbeddingDate: 5077
ICPrePersonalizer: 0000
ICPrePersonalizationEquipmentDate: 0000
ICPrePersonalizationEquipmentID: 00000000
ICPersonalizer: 0000
ICPersonalizationDate: 0000
ICPersonalizationEquipmentID: 00000000
***** CARD DATA
A>> T=1 (4+0000) 80CA0066 00
A<< (0078+2) (18ms) 664C734A06072A864886FC6B01600C060A2A864886FC6B02020101630906072A864886FC6B03640B06092A864886FC6B040215650B06092B851086486402010366
0C060A2B060104012A026E0102 9000
Unknown tag: 4c
***** KEY INFO
A>> T=1 (4+0000) 80CA00E0 00
A<< (0020+2) (13ms) E012C00401FF8010C00402FF8010C00403FF8010 9000
VER:255 ID:1 TYPE:DES3 LEN:16
VER:255 ID:2 TYPE:DES3 LEN:16
VER:255 ID:3 TYPE:DES3 LEN:16
Key version suggests factory keys
A>> T=1 (4+0008) 80500000 08 **************** 00
A<< (0028+2) (81ms) 00005077005179978161FF02******************************** 9000
[DEBUG] GlobalPlatform - Host challenge: ****************
[DEBUG] GlobalPlatform - Card challenge: ****************
[DEBUG] GlobalPlatform - Card reports SCP02 with version 255 keys
[DEBUG] PlaintextKeys - session keys:
ENC: Ver:0 ID:0 Type:DES3 Len:16 Value:******************************** KCV: ******
MAC: Ver:0 ID:0 Type:DES3 Len:16 Value::******************************** KCV: ******
KEK: Ver:0 ID:0 Type:DES3 Len:16 Value::******************************** KCV: ******
[DEBUG] GlobalPlatform - Verified card cryptogram: ****************
[DEBUG] GlobalPlatform - Calculated host cryptogram: BCCB4A3FE7C72337
A>> T=1 (4+0016) 84820100 10 BCCB4A3FE7C72337BEE53FC6E96E3CF0
A<< (0000+2) (47ms) 9000
CAP file (v2.1) generated on Fri Jul 01 12:45:19 IRDT 2016
By Sun Microsystems Inc. converter [v3.0.2] with JDK 1.7.0_21 (Oracle Corporation)
Package: testPack v1.0 with AID 0102030405
Applet: TestApp with AID 010203040501
Import: A0000000620101 v1.4
Import: A0000000620201 v1.4
Import: A0000000620102 v1.4
Import: A0000000620001 v1.0
Total code size: 14249 bytes (15230 with debug)
SHA256 (code): 62692AE1D5DED46F582E9D4A70147D4673A6ADE61AB4FFBE9BF9DCFF738301AE
SHA1 (code): 987035C59C6F9D55B833982A49F6B26B42A8F1DB
A>> T=1 (4+0010) 84F28002 0A 4F008A7CB7FC9CFD273A 00
A<< (0019+2) (24ms) E3114F08A0000000030000009F700101C5019E 9000
A>> T=1 (4+0010) 84F24002 0A 4F0036BEC9929973C2B9 00
A<< (0000+2) (32ms) 6A88
[WARN] GlobalPlatform - GET STATUS failed for 80F24002024F0000 with 6a88
A>> T=1 (4+0010) 84F22002 0A 4F00B25292932F0404B7 00
A<< (0000+2) (38ms) 6A88
[WARN] GlobalPlatform - GET STATUS failed for 80F22002024F0000 with 6a88
A>> T=1 (4+0010) 84F21002 0A 4F0065BAD8E85186FFAD 00
A<< (0000+2) (39ms) 6A88
[WARN] GlobalPlatform - GET STATUS failed for 80F21002024F0000 with 6a88
A>> T=1 (4+0026) 84E60200 1A 05010203040508A000000003000000000000DAEC6F17D8E21A55
A<< (0001+2) (65ms) 00 9000
A>> T=1 (4+0255) 84E80000 FF C48237A901000FDECAFFED010204000105010203040502001F000F001F000A00290182004E09E529EE018A000003D20031000829CC040100040029040
40107A0000000620101040107A0000000620201040107A0000000620102000107A000000062000103000A0106010203040501079706004E0080030C0009041D0000093BFFFFFFFF07AB001
900CD010F011D0142019001CE01E8021E023402980306043004AF04D604EE0519052D057105BD05E406060629063F066300830000FF00010000000709E503025680090261001605E6800D0
5F50016068D80EE077D003404307C001C600C1D046A081169858D000C1D73009B00000002F7DD3E606A4D07D7
A<< (0001+2) (1s486ms) 00 9000
A>> T=1 (4+0255) 84E80001 FF 000D003B006E1E61117B0017AD0003068E04002106A800851E046B127B0017AD00031101008E0400210770701167008D000C70687B00240303381E611
07B002CAD0003068E0400210670511E046B127B002CAD00031101008E04002107703D1167008D000C70351E61107B0030AD0003068E0400210670241E046B127B0030AD00031101008E040
0210770101167008D000C7008116B008D000C7A04207C001C60081169858D000C1D75002D00020000000D0001001D7B0036AD00031101008E0400370670187B0036AD00031101008E04003
7077008116B008D000C7A03107B0038AD00038E03000B047A03201D7500210002000000180C4D9A28B7D518D5
A<< (0001+2) (72ms) 00 9000
A>> T=1 (4+0255) 84E80002 FF 0001000DAD017B0038048B000D700BAD017B0038058B000D7A0430198B000E3B1E75004500020000000D000100287B0017AD00038E030021043B19068
B000F19AD0003068B0010701F7B0017AD00038E030021053B191101008B000F19AD00031101008B00107A05207C001C600C1D046A081169858D000C1D75002B00020000000D0001001DAD0
0037B0011031101008D00123B7010AD00037B0013031101008D00123B7A0420198B000E3B191101008B000F197B0011031101008B00107A03307C001C600C1D046A081169858D000C1D750
01D0002000000150001000D7B0014031E3870107B0015031E387008116B008D000C7A0420A10CAE830FD9854D
A<< (0001+2) (73ms) 00 9000
A>> T=1 (4+0255) 84E80003 FF 198B000E3B19048B000F197B001503048B00107A03321D73005A00000002000D0044004F1E610DAD027B0017058B000D70471E046B1FAD027B0036048
B000D70382E1B8B00182904116D001604558D000C7026116B008D000C701EAD027B002C058B000D7013AD027B0030048B000D7008116B008D000C7A06117B002405256108116B218D000C1
805048B0019AD027B0013031101007B001A038B001B3B7B002CAD00038E030021053BAD03AD00031101008B001DAD037B001403047B001E038B001F3B7B001A1100E07B001E0310208D002
0301D610A7B00240304387008116B208D000C7A0431190725327C001C613B1E75002F000201FA3832808C186D
A<< (0001+2) (67ms) 00 9000
A>> T=1 (4+0255) 84E80004 FF 0000000D0001001EAD048B0022AD04190810088B0023A80102AD058B0022AD051908100C8B0023A800F1116B008D000CA800E87C001C046B517B00240
325046B0A7B00140325046A08116B218D000C1E75002F00020000000D0001001EAD048B0022AD04190810088B0023A800ADAD058B0022AD051908100C8B0023A8009C116B008D000CA8009
31F75008900020010000D0014004CAD04190810088B00256013AD048B0022AD0419100D10088B00237068AD048B00266110116B50AD048B0026558D000C7053116B50AD048B0026558D000
C7045AD051908100C8B00256013AD048B0022AD0419101110088B00237029AD058B002661FA81E55604281391
A<< (0001+2) (68ms) 00 9000
A>> T=1 (4+0255) 84E80005 FF 0E0780001C116B228D000C7016116B40AD058B0026558D000C7008116A808D000C7A0631190725321E75007100020000000D0001003B1F10086A08116
7008D000C7B002405AD04190810088B0025387B00240525614C116B50AD048B0026558D000C703E1F100C6A081167008D000CAD051908100C8B00253BAD058B0026610E0780001C116B228
D000C7016116B40AD058B0026558D000C7008116B008D000C7A05207C001C60081169858D000C19072510146A081167008D000C19087B00270310148D00123B7A0420198B000E3B1910148
B000F197B00270310148B00107A02107C001C75002500020000000D000100130480001C70E3257112B620785F
A<< (0001+2) (72ms) 00 9000
A>> T=1 (4+0255) 84E80006 FF 147B00140325046A08116B218D000C0580001C7A0321198B00282D1A037C001C381903048B00297A05227B002403256108116B218D000C198B00282D1
98B002A3B1A0725100A6A081167008D000C7B002B031A08100A8D0020321F610A7B00240404387008116A808D000C7A0520AD067B002B03100A8B002D1804038B00197B002B03AD001100F
6100A8D002E3BAD00031100F6038D002F3B18AD00AD078B0031198B000E3B191101008B000F19AD07031101008B00107A04201803048B001918AD00AD078B0031198B000E3B19100A8B000
F19AD071100F6100A8B00107A0632AD0219031101001A038B001B3B70122E1B8B00182904FBDC64F8BD56146B
A<< (0001+2) (73ms) 00 9000
A>> T=1 (4+0255) 84E80007 FF 116D001604558D000C7A05107C001C046A107B00140325046A08116B218D000CAD00037B003203078D00123B7A0420198B000E3B19078B000F197B003
203078B00107A05107C001C046A107B00140325046A08116B218D000CAD00037B003303100F8D00123B7A0420198B000E3B19100F8B000F197B003303100F8B00107A0512188C003518038
908180389091803890A08110800038D0039940000377F003607110800038D0039940000217F001707110800038D0039940000217F003007110800038D0039940000217F002C100E1100800
38D00399400000B7F0038110100900B7F0011110100900B7F001A1020900B7F001E04900BFD1B512EB0542728
A<< (0001+2) (66ms) 00 9000
A>> T=1 (4+0255) 84E80008 FF 7F001504048D003A7F0014110100048D003A7F001307048D003B7F002418110400900B87071014900B7F002718110100058D003A870018100E038D003
C870118100C038D003C870218048D003D87061807038D003E8703188F003F3D0810088C00408704188F003F3D100A100C8C00408705100A048D003A7F002B07900B7F0032100F900B7F003
3701B2C1995000016601319940000168B001831116B001E558D000C7A05308F00413D8C0042181D0441181D258B00437A0427188B004460037A7C001C076B08116B228D000C198B00282D1
A0325321A042529041A052529051A062529061A07251100FF532907082908160475014E008C6C44CDFCEC427F
A<< (0001+2) (68ms) 00 9000
A>> T=1 (4+0255) 84E80009 FF 17FF88012F00000061001000800011008B001200AF0013009E0014010000200094002200BA002300A7002401070025010E003100C9003200D7003300C
2004000E5004100EC0042012200430128004401150045011B005000F3005100F9198B002A3B1605610A181A8C0045A800E5160504A300DF181A8C0046A800D718160516068B0047A800CC1
816058B0048A800C3181916058B0049A800B91816058B004AA800B018198B004BA800A818160516068B004CA8009D18198B004DA80095188B004EA8008E198B002A3B181A16058B004F707
F198B002A3B181A16058B00507071181A8B0051706A18198B00527063188B0053705D1819D38B8013E988435A
A<< (0001+2) (74ms) 00 9000
A>> T=1 (4+0255) 84E8000A FF 8B0054705618198B0055704F18198B0056704818198B00577041188B0058703B18198B00597034188B005A702E18198B005B7027198B000E3B193B8D0
05C8D000C191103E88B000F197B005D031103E88B0010116D008D000C7A0310AD048B005EAD058B005E7B00240403387B00240303387B00240503387A0522190625311907251100FF53321
E61171908AD07031F8D00123B18AF0A8908181F890A701E1908AD07AF081F8D00123B183D8508AF0A418908183D850A1F41890A7A0522190625311907251100FF53321E61161908AD00031
F8D00123B181F8909181F890A701D1908AD00AF091F8D00123B183D85091F418909183D85DEC4E7535D7EB5F1
A<< (0001+2) (73ms) 00 9000
A>> T=1 (4+0255) 84E8000B FF 0A1F41890A7A0110188C005F7A0829EE00310018000803019000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000FEE24BE9596DB9EA
A<< (0001+2) (82ms) 00 9000
A>> T=1 (4+0255) 84E8000C FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000003006400000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000F7B29CBD53AB9986
A<< (0001+2) (54ms) 00 9000
A>> T=1 (4+0255) 84E8000D FF 000000000000000000000000000000000000000000000000000000000000000000000300C800000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000307D0000000000000001C0988E5D39797AC
A<< (0001+2) (53ms) 00 9000
A>> T=1 (4+0255) 84E8000E FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000F2AF0956992CD99F
A<< (0001+2) (54ms) 00 9000
A>> T=1 (4+0255) 84E8000F FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000009DF362EF8C2B2464
A<< (0001+2) (54ms) 00 9000
A>> T=1 (4+0255) 84E80010 FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000008B76B8B8ECEF4F41
A<< (0001+2) (53ms) 00 9000
A>> T=1 (4+0255) 84E80011 FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000002D0C66BD5BF2CFD1
A<< (0001+2) (134ms) 00 9000
A>> T=1 (4+0255) 84E80012 FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000005B7E028BBDB42BD0
A<< (0001+2) (54ms) 00 9000
A>> T=1 (4+0255) 84E80013 FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000C15ABC8BA9501A44
A<< (0001+2) (54ms) 00 9000
A>> T=1 (4+0255) 84E80014 FF 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000AA4C06B675784615
SCardEndTransaction()
SCardDisconnect("ACS ACR1281 1S Dual Reader PICC 0", true)
GPP:>
As you see above, the last APDU command that contains a block of my cap file, doesn't received any response, and so my applet can't installed. Why?
Note that I can load and install it on another card successfully. and note that if I remove some not-used big class variables, then I can load my cap file. But Why?
There are the not used variables:
public class FileSystem {
public static byte[] var0= new byte[400];
public static byte[] var1= new byte[100];
public static byte[] var2= new byte[200];
public static byte[] var3= new byte[2000];
public static byte[] var4= new byte[2000];
public static byte[] var5= new byte[2000];
public static byte[] var6= new byte[2000];
public static byte[] var7= new byte[2000];
}
Is there any limitation on cap file size other than the EEPROM capacity?

Related

QtNFC neard Error in dmesg: "invalid frame" "Poll complete error -5"

I'm trying to communicate with an ACR122U nfc reader using Qt 5.15.2 and neard 0.18 on Ubuntu 22.04 by running the code below but nothing happen when presenting a tag. Slots never get called and no error is printed.
NFCHandler::NFCHandler(QObject *parent)
: QObject{parent}
{
manager = new QNearFieldManager(this);
if (!manager->isAvailable()) {
qWarning() << "NFC not available";
return;
}
connect(manager, &QNearFieldManager::targetDetected,
this, &NFCHandler::targetDetected);
connect(manager, &QNearFieldManager::targetLost,
this, &NFCHandler::targetLost);
manager->setTargetAccessModes(QNearFieldManager::NdefReadTargetAccess);
if (!manager->startTargetDetection()) {
qWarning() << "Starting detection failed during startup";
}
}
I enabled qt.nfc.neard logging category which print:
qt.nfc.neard: org.neard.Adapter found for path "/org/neard/nfc0"
qt.nfc.neard: starting target detection
qt.nfc.neard: adapter is already powered
qt.nfc.neard: successfully started polling
And this when stopping:
qt.nfc.neard: stopping target detection
qt.nfc.neard: successfully stopped polling
I noticed there was an error in dmesg. After enabling debug prints this is what i get from dmesg -x (Not all messages are included):
kern :debug : [20439.162016] usb 1-6: Sending command 0x32
kern :debug : [20439.162020] usb 1-6: __pn533_send_async Queueing command 0x32
kern :debug : [20439.162022] PN533 TX: 6b 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4
kern :debug : [20439.162024] PN533 TX: 32 01 02
kern :debug : [20439.171701] PN533 RX: 83 04 00 00 00 00 00 02 81 00 d5 33 90 00
kern :debug : [20439.185997] usb 1-6: pn533_wq_poll cancel_listen 0 modulation len 0
kern :debug : [20439.186018] usb 1-6: pn533_send_poll_frame mod len 0
kern :debug : [20439.186021] usb 1-6: Sending command 0x56
kern :debug : [20439.186024] PN533 TX: 6b 2a 00 00 00 00 00 00 00 00 ff 00 00 00 25 d4
kern :debug : [20439.186025] PN533 TX: 56 01 02 07 00 ff ff 00 03 01 fe c6 17 05 76 26
kern :debug : [20439.186026] PN533 TX: 95 ff ff 46 66 6d 01 01 11 04 01 96 03 02 00 01
kern :debug : [20439.186027] PN533 TX: 02 02 07 ff
kern :debug : [20439.530001] PN533 RX: 83 05 00 00 00 00 00 02 81 00 d5 57 01 90 00
kern :debug : [20439.530079] usb 1-6: Sending command 0x32
kern :debug : [20439.530101] usb 1-6: __pn533_send_async Queueing command 0x32
kern :debug : [20439.530102] PN533 TX: 6b 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4
kern :debug : [20439.530103] PN533 TX: 32 01 02
kern :debug : [20439.539773] PN533 RX: 83 04 00 00 00 00 00 02 81 00 d5 33 90 00
kern :debug : [20439.554018] usb 1-6: pn533_wq_poll cancel_listen 0 modulation len 0
kern :debug : [20439.554022] usb 1-6: pn533_send_poll_frame mod len 0
kern :debug : [20439.554025] usb 1-6: Sending command 0x8c
kern :debug : [20439.554028] PN533 TX: 6b 3d 00 00 00 00 00 00 00 00 ff 00 00 00 38 d4
kern :debug : [20439.554029] PN533 TX: 8c 02 01 01 00 00 00 40 01 fe 4c f0 e7 db 21 5c
kern :debug : [20439.554030] PN533 TX: 00 00 00 00 00 00 00 00 ff ff 01 fe 4c f0 e7 db
kern :debug : [20439.554031] PN533 TX: 21 5c 00 00 11 46 66 6d 01 01 11 04 01 96 03 02
kern :debug : [20439.554045] PN533 TX: 00 01 02 02 07 ff 00
kern :debug : [20441.570323] usb 1-6: Listen mode timeout
kern :debug : [20441.590175] usb 1-6: pn533_wq_poll cancel_listen 1 modulation len 2
kern :debug : [20441.590180] usb 1-6: pn533_send_poll_frame mod len 2
kern :debug : [20441.590182] usb 1-6: Sending command 0x4a
kern :debug : [20441.590184] usb 1-6: __pn533_send_async Queueing command 0x4a
kern :debug : [20444.691762] PN533 RX: 83 00 00 00 00 00 00 02 fe 00
kern :err : [20444.691817] usb 1-6: NFC: Received an invalid frame
kern :err : [20444.691903] usb 1-6: NFC: pn533_poll_complete Poll complete error -5
kern :err : [20444.691918] usb 1-6: NFC: Error -5 when running poll
kern :err : [20444.691925] usb 1-6: NFC: Polling operation has been stopped
kern :debug : [20444.691940] PN533 TX: 6b 09 00 00 00 00 00 00 00 00 ff 00 00 00 04 d4
kern :debug : [20444.691946] PN533 TX: 4a 01 00
kern :debug : [20444.787575] PN533 RX: 83 05 00 00 00 00 00 02 81 00 d5 4b 00 90 00
kern :debug : [20444.787652] usb 1-6: Polling has been stopped
According to https://www.usb.org/sites/default/files/DWG_Smart-Card_CCID_Rev110.pdf the invalid frame is a RDR_to_PC_Escape message. The error message "NFC: Received an invalid frame" is caused by the pn533/usb.c file in the pn533 driver because data length is 0 (the 4 bytes after 83).
Am I doing something wrong with the code ?
Could the product be deficient ?

reading data from bluetooth thermometer with gatttool

I stumbled upon this Question: Reading Thermometer Data with Bluez Bluetooth Low Energy
and was following it trying to read data from a bluetooth thermometer that I got.
I was able to extract and read all handles with this command:
gatttool -b 00:11:22:33:44:55 -I
[00:11:22:33:44:55][LE]> connect
Connection successful
[00:11:22:33:44:55][LE]> primary
attr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0008, end grp handle: 0x000b uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0x001e uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle: 0x001f, end grp handle: 0xffff uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-desc 0x0001 0x0001
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-desc 0x0001 0x0007
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0004, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb
handle: 0x0006, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-read-hnd 01
Characteristic value/descriptor: 00 18
[00:11:22:33:44:55][LE]> char-read-hnd 02
Characteristic value/descriptor: 02 03 00 00 2a
[00:11:22:33:44:55][LE]> char-read-hnd 03
Characteristic value/descriptor: 54 68 65 72 6d 6f 42 65 61 63 6f 6e
[00:11:22:33:44:55][LE]> char-read-hnd 04
Characteristic value/descriptor: 02 05 00 01 2a
[00:11:22:33:44:55][LE]> char-read-hnd 05
Characteristic value/descriptor: 00 00
[00:11:22:33:44:55][LE]> char-read-hnd 06
Characteristic value/descriptor: 02 07 00 04 2a
[00:11:22:33:44:55][LE]> char-read-hnd 07
Characteristic value/descriptor: 50 00 a0 00 00 00 e8 03
[00:11:22:33:44:55][LE]> char-desc 0x0008 0x000b
handle: 0x0008, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0009, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000a, uuid: 00002a05-0000-1000-8000-00805f9b34fb
handle: 0x000b, uuid: 00002902-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-read-hnd 08
Characteristic value/descriptor: 01 18
[00:11:22:33:44:55][LE]> char-read-hnd 09
Characteristic value/descriptor: 20 0a 00 05 2a
[00:11:22:33:44:55][LE]> char-read-hnd 0a
Error: Characteristic value/descriptor read failed: Attribute can't be read
[00:11:22:33:44:55][LE]> char-read-hnd 0b
Characteristic value/descriptor: 00 00
[00:11:22:33:44:55][LE]> char-desc 0x000c 0x001e
handle: 0x000c, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x000d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000e, uuid: 00002a23-0000-1000-8000-00805f9b34fb
handle: 0x000f, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0010, uuid: 00002a24-0000-1000-8000-00805f9b34fb
handle: 0x0011, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0012, uuid: 00002a25-0000-1000-8000-00805f9b34fb
handle: 0x0013, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0014, uuid: 00002a26-0000-1000-8000-00805f9b34fb
handle: 0x0015, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0016, uuid: 00002a27-0000-1000-8000-00805f9b34fb
handle: 0x0017, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0018, uuid: 00002a28-0000-1000-8000-00805f9b34fb
handle: 0x0019, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001a, uuid: 00002a29-0000-1000-8000-00805f9b34fb
handle: 0x001b, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001c, uuid: 00002a2a-0000-1000-8000-00805f9b34fb
handle: 0x001d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001e, uuid: 00002a50-0000-1000-8000-00805f9b34fb
[00:11:22:33:44:55][LE]> char-read-hnd 0c
Characteristic value/descriptor: 0a 18
[00:11:22:33:44:55][LE]> char-read-hnd 0d
Characteristic value/descriptor: 02 0e 00 23 2a
[00:11:22:33:44:55][LE]> char-read-hnd 0e
Characteristic value/descriptor: 5e 0b 00 00 00 00 f4 00
[00:11:22:33:44:55][LE]> char-read-hnd 0f
Characteristic value/descriptor: 02 10 00 24 2a
[00:11:22:33:44:55][LE]> char-read-hnd 10
Characteristic value/descriptor: 4d 6f 64 65 6c 20 4e 75 6d 62 65 72
[00:11:22:33:44:55][LE]> char-read-hnd 11
Characteristic value/descriptor: 02 12 00 25 2a
[00:11:22:33:44:55][LE]> char-read-hnd 12
Characteristic value/descriptor: 53 65 72 69 61 6c 20 4e 75 6d 62 65 72
[00:11:22:33:44:55][LE]> char-read-hnd 13
Characteristic value/descriptor: 02 14 00 26 2a
[00:11:22:33:44:55][LE]> char-read-hnd 14
Characteristic value/descriptor: 46 69 72 6d 77 61 72 65 20 52 65 76 69 73 69 6f 6e
[00:11:22:33:44:55][LE]> char-read-hnd 15
Characteristic value/descriptor: 02 16 00 27 2a
[00:11:22:33:44:55][LE]> char-read-hnd 16
Some of them like for example 4d 61 6e 75 66 61 63 74 75 72 65 72 20 4e 61 6d 65 reads Manufacturer Name letter by letter when converted with HEX to ASCII converter but some of them like for example 02 1c 00 2a 2a read ** with some blank squares
I also tried converting to decimal some of the numbers to try to get a temperature value but with no luck.
The values stay the same every time I read them so I guess this is no way to read the temperature value.
Do I have to somehow request that data from those handles. How do I find the termperature value from this data that I have above?
While I was reading this temperature was from 19.8 to 20.2°C, something like that (in case it is hidden somewhere in those values I have listed above)
I just want to read out the temperatur value from it nothing else.
UPDATE:
After turning scan on on bluetoothctl I am getting this packets from bluetooth thermometer:
[CHG] Device 00:11:22:33:44:55 RSSI: -81
[CHG] Device 00:11:22:33:44:55 TxPower: 0
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 24 0c 43 01 75 04 f3 5b ..^.....$.C.u..[
01 00 ..
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 23 0c 43 01 79 04 02 5c ..^.....#.C.y..\
01 00 ..
[CHG] Device 00:11:22:33:44:55 RSSI: -63
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 8c 01 2a 3d 00 00 34 01 ..^.......*=..4.
c3 40 01 00 .#..
[CHG] Device 00:11:22:33:44:55 RSSI: -81
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 24 0c 44 01 75 04 22 5c ..^.....$.D.u."\
01 00 ..
[CHG] Device 00:11:22:33:44:55 RSSI: -54
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 8c 01 2a 3d 00 00 34 01 ..^.......*=..4.
c3 40 01 00
Lets take the first set of data:
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 24 0c 43 01 75 04 f3 5b ..^.....$.C.u..[
01 00
I noticed by skipping the first 2 Bytes 55 44 33 22 11 00 MAC address of the device but in reverse.
After that 24 0c part repeats simiraly in other sets like for example in next one its 23 0c.
The next 2 Bytes (43 01) are the ones that I noticed change when temperature in my room changes and are the bytes that represent the temperature. Here is how I calculated temperature. Reverse the byte order -> 01 43 -> 0x0143 -> 323 in decimal -> 323/16 -> 20.1875 which is 20.2 rounded up. This is the exact temp that is on my thermometer and I tried it when temp was higher and lower and it always shows the exact temp.
Similarly the next two 75 04: 0x0475 -> 1141 in decimal -> 1141/16 = 71.3125 which is 71% rounded down -> humidity shown on thermometer
Is this the right interpretation?
What confuses me is the 3rd set of data which is longer and the data packets alternate between those two:
[CHG] Device 00:11:22:33:44:55 RSSI: -63
[CHG] Device 00:11:22:33:44:55 ManufacturerData Key: 0x0011
[CHG] Device 00:11:22:33:44:55 ManufacturerData Value:
00 00 55 44 33 22 11 00 8c 01 2a 3d 00 00 34 01 ..^.......*=..4.
c3 40 01 00
Is that some other data that thermometer is sending?

As a side note, gatttool is deprecated and the current supported tool for doing this is bluetoothctl.
GATT UUID's with the format 0000xxxx-0000-1000-8000-00805f9b34fb mean they have been adopted by the Bluetooth SIG and you can look up what they represent in the 16-bit UUID Numbers Document
There are also generic Bluetooth Low Energy scanning and exploration tools such as nRF connect that can be helpful exploring a device.
From the GATT information you posted, I could only see generic content that needs to be included and not anything specific about temperature.
The advertising data is including Manufacturer Data which can (as maybe the name suggests) be anything that the manufacturer wants. From the Core Specification Supplement
This means you need to get the information from the manufacturer or work backwards from what you think the data is saying. As you have not shared any information about the device broadcasting, it seems like you are heading in the right direction.
Most Bluetooth data is little endian so having to swap the bytes around is not unexpected. Beacon formats like iBeacon and Eddystone tend to be big endian but they are the exception rather than the rule.
You will probably want to use the D-Bus API if you want to get the data into some kind of code. There are D-Bus bindings for most languages and the BlueZ API you will need is documented at:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt

Bluez blotoothctl scan vs hcitool scan

I'm running bluez 5.50 on a Raspberry Pi (both Buster and Stretch). I have a ble sensor device that advertises data only when a button on the sensor device is pressed. So advertisements are asynchronous and there are no periodic advertisements in between (and all packets are unique, no duplicates). I'm having an issue with Bluez though where once a packet is received, Bluez seems to not report any additional packets from the device for the next approximately 11 seconds (very occasionally the interval is shorter). This is with the bluetoothctl line command tool as well as my own c++ application (based off the bluez client/main.c example). In both cases before starting a scan I clear the scan filter, set transport to le, and set duplicate-data reporting on. Conversely, when running hcitool scan I see all the packets from the sensor (it even seems to be reporting all 3 copies broadcast on the different advertisement channels). So my question is, is there a way to get those missing advertisements through the dbus api, possibly some additional setting somewhere? If not, is the hci api okay to use from c++ and should it do the trick? Any help appreciated, thanks!
Edited per Alex's questions -
Have you tried downloading the latest bluez (5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git ?
Not yet, just wanted to check and see if this might be something known beforehand.
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
hcitool lescan (under root), and yes, the hardware is a Pi Zero/W and a P3 so BLE 4.x controllers (I assume)
Have you tried running sudo btmon to see all of the HCI communication during scanning?
I have but can't remember exactly what I saw other than it didn't contradict anything else, i.e. missing packets w/ dbus api vs hci
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
always exactly as you've noted...
Could you also provide the results of hciconfig -a
--- Results (P Zero) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:79:2E:3F ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:55476 acl:126 sco:0 events:2012 errors:0
TX bytes:6956 acl:114 sco:0 commands:444 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi01'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
--- Results (P3) -
hci0: Type: Primary Bus: UART
BD Address: B8:27:EB:2B:A2:A3 ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:10995 acl:0 sco:0 events:390 errors:0
TX bytes:2145 acl:0 sco:0 commands:91 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HubPi02'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7) Revision: 0x168
LMP Version: 4.1 (0x7) Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)
Below is a scan covering about 20 seconds (editing out all unrelated packets),
where I'm pressing down the button on the sensor about every 2 seconds and then
holding it down for another 2 seconds before letting it up. The first chunk
is from bluetoothctl, the second from "hcidump --raw" (on a second raspberry pi). The first four bytes
in the bluetoothctl packet data is a little endian packet seq number
incremented by the sensor for each new packet. The next byte indicates a
button up/down action. You can see bluetoothctl reported packets numbered 05df,
05e5, 05e9. In the raw dump the seq number is at the end of the top line. There
you can see all packets are in order, reported 1 to 3 times (I assume it is
reporting all advertising channels it catches). All packets are present 05df to
05e9 in the hcidump scan. Lastly is the output from "hcitool lescan --duplicates",
which I'm not really sure how it maps...
------ bluetoothctl
.
[NEW] Device E2:15:00:01:73:96 E2-15-00-01-73-96
[CHG] Device E2:15:00:01:73:96 RSSI: -46
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
df 05 00 00 10 a1 ac 8a b4 .........
[CHG] Device E2:15:00:01:73:96 RSSI: -45
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e5 05 00 00 10 e7 4f 67 6e ......Ogn
.
[CHG] Device E2:15:00:01:73:96 RSSI: -65
[CHG] Device E2:15:00:01:73:96 ManufacturerData Key: 0x03da
[CHG] Device E2:15:00:01:73:96 ManufacturerData Value:
e9 05 00 00 10 f4 f9 f8 7d ........}
---------- hcidump --raw
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 C3
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 DF 05
00 00 10 A1 AC 8A B4 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E0 05
00 00 11 11 0F 3E 24 B6
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 CF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E1 05
00 00 10 F7 68 07 50 BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A BF
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E2 05
00 00 11 1D 18 A8 2A B8
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E3 05
00 00 10 E2 29 C7 F7 BB
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E4 05
00 00 11 57 F0 5C 76 C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E5 05
00 00 10 E7 4F 67 6E CA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE C0
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BA
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E6 05
00 00 11 77 63 92 CE BE
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E7 05
00 00 10 2D 52 48 C2 BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D BD
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E8 05
00 00 11 EE 32 20 9D C1
> 04 3E 19 02 01 03 01 96 73 01 00 15 E2 0D 0C FF DA 03 E9 05
00 00 10 F4 F9 F8 7D BC
------- hcitool lescan --duplicates
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)
E2:15:00:01:73:96 (unknown)

Have you tried downloading the latest bluez (5.53) https://git.kernel.org/pub/scm/bluetooth/bluez.git ?
Are you using hcitool scan or sudo hcitool lescan? If you are running hcitool scan, you are picking up bluetooth classic (not low energy packets). hcitool is a deprecated tool. I've found that sudo hcitool lescan only works with BLE 4.x controllers. The function fails on 5.x controller.
Have you tried running sudo btmon to see all of the HCI communication during scanning?
Can you provide code for your use of bluetoothctl, ie:
$bluetoothctl
[bluetooth]# menu scan
[bluetooth]# clear
[bluetooth]# transport le
[bluetooth]# duplicated-data on
[bluetooth]# back
[bluetooth]# scan on
Could you also provide the results of hciconfig -a

Handling of duplicate advertising data with the BlueZ D-Bus API is an on-going saga that is complicated by the fact that both the kernel and user-space are involved. The following thread over on the BlueZ developer mailing list probably gives the best insight: https://marc.info/?l=linux-bluetooth&m=158225950522806&w=2
The workaround I have been using with the D-Bus API, when scanning for beacons, is to remove the device once I have the data from it. I don't appear to miss data this way. As I don't connect to the beacons, I don't need to worry about losing the paring data for that device.
As a side note, tools like hciconfig, hcitool, and hcidump were deprecated back in 2017

Weird behaviour of a counter in process() method of Javacard

I use a static short field named counter in the process() method of my Java Card applet to count the number of this method firings!
Well, the program is really simple and looks like this:
package testPack;
import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISOException;
public class Test extends Applet {
public static short counter = 0x0000;
public static void install(byte[] bArray, short bOffset, byte bLength) {
new Test().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
}
public void process(APDU apdu) {
if (selectingApplet()) {
return;
}
counter = (short) (counter + 1);
ISOException.throwIt(counter);
}
}
When I install this applet in the regular way, it works fine:
Regular Installing:
GlobalPlatformPro:> gp -list
AID: A000000151000000 (|....Q...|)
ISD OP_READY: Security Domain, Card lock, Card terminate, Default selected,
AID: A0000001515350 (|....QSP|)
ExM LOADED: (none)
A000000151535041 (|....QSPA|)
GlobalPlatformPro:> gp -install d:\test.cap
GlobalPlatformPro:> gp -list
AID: A000000151000000 (|....Q...|)
ISD OP_READY: Security Domain, Card lock, Card terminate, Default selected,
AID: 010203040501020304 (|.........|)
App SELECTABLE: (none)
AID: A0000001515350 (|....QSP|)
ExM LOADED: (none)
A000000151535041 (|....QSPA|)
AID: 010203040501 (|......|)
ExM LOADED: (none)
010203040501020304 (|.........|)
Regular installing, applet output:
OpenSCTool:> OSC.exe -s 00A4040009010203040501020304 -s 00000000
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 09 01 02 03 04 05 01 02 03 04
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x01)
OpenSCTool:> OSC.exe -s 00A4040009010203040501020304 -s 00000000 -s 0000000
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 09 01 02 03 04 05 01 02 03 04
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x02)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x03)
But when I install it as default selected applet, the counter works different:
installing as Default selected applet:
GlobalPlatformPro:> gp -list
AID: A000000151000000 (|....Q...|)
ISD OP_READY: Security Domain, Card lock, Card terminate, Default selected,
AID: A0000001515350 (|....QSP|)
ExM LOADED: (none)
A000000151535041 (|....QSPA|)
GlobalPlatformPro:> gp -install d:\test.cap -default
GlobalPlatformPro:> gp -list
AID: A000000151000000 (|....Q...|)
ISD OP_READY: Security Domain, Card lock, Card terminate, CVM (PIN) managem
AID: 010203040501020304 (|.........|)
App SELECTABLE: Default selected
AID: A0000001515350 (|....QSP|)
ExM LOADED: (none)
A000000151535041 (|....QSPA|)
AID: 010203040501 (|......|)
ExM LOADED: (none)
010203040501020304 (|.........|)
Default selected, applet output:
OpenSCTool:> OSC.exe -s 00A4040009010203040501020304 -s 00000000
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 09 01 02 03 04 05 01 02 03 04
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x06)
OpenSCTool:> OSC.exe -s 00A4040009010203040501020304 -s 00000000 -s 0000000
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 09 01 02 03 04 05 01 02 03 04
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x0C)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x0D)
As you see above, when I installed the applet as Default Selected, the counters increases by 6 with each command (instead of increasing by 1)!
What is happening on the background?
Update 1:
Based on dear #Vojta's comment, I changed the program in way to increase the counter value for APDU commands with CLA = 0x80 only:
public void process(APDU apdu) {
if (selectingApplet()) {
return;
}
byte[] buffer = apdu.getBuffer();
if ((buffer[ISO7816.CLA_ISO7816] & 0x00FF) == 0x80 ) {
counter = (short) (counter + 1);
}
ISOException.throwIt(counter);
}
This is the output (for Default selected case):
OpenSCTool:> OSC.exe -s 00A4040009010203040501020304 -s 00000000 -s 8000000
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 09 01 02 03 04 05 01 02 03 04
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x00)
Sending: 80 00 00 00
Received (SW1=0x00, SW2=0x01)
OpenSCTool:> OSC.exe -s 00A4040009010203040501020304 -s 00000000 -s 80000000
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 09 01 02 03 04 05 01 02 03 04
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x01)
Sending: 80 00 00 00
Received (SW1=0x00, SW2=0x02)
OpenSCTool:> OSC.exe -s 00A4040009010203040501020304 -s 00000000 -s 8000000
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 09 01 02 03 04 05 01 02 03 04
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 00 00
Received (SW1=0x00, SW2=0x02)
Sending: 80 00 00 00
Received (SW1=0x00, SW2=0x03)

Random data generator applet returns `0x6F00`

I wrote the below program to generate random numbers of different lengths, using two different algorithms (ALG_SECURE_RANDOM and ALG_PSEUDO_RANDOM).
P1 and P2 in the APDU command specify the algorithm and the random length in order.
P1 = 0X01 : ALG_SECURE_RANDOM
P1 = 0X02 : ALG_PSEUDO_RANDOM
P2 = Random number length
public class RandGen extends Applet {
byte[] generatedArray;
byte[] generatedRandom;
RandomData randomDataSecure = RandomData
.getInstance(RandomData.ALG_SECURE_RANDOM);
RandomData randomDataPseudo = RandomData
.getInstance(RandomData.ALG_PSEUDO_RANDOM);
private RandGen() {
}
public static void install(byte bArray[], short bOffset, byte bLength)
throws ISOException {
new RandGen().register();
}
public void process(APDU apdu) throws ISOException {
if (selectingApplet()) {
return;
}
byte[] buffer = apdu.getBuffer();
generatedArray = JCSystem.makeTransientByteArray(
(short) buffer[ISO7816.OFFSET_P2], JCSystem.CLEAR_ON_DESELECT);
switch (buffer[ISO7816.OFFSET_P1]) {
case (0x01):
generatedRandom = secureRandomGenerator(apdu);
break;
case (0x02):
generatedRandom = pseudoRandomGenerator(apdu);
break;
default:
return;
}
Util.arrayCopyNonAtomic(generatedRandom, (short) 0, buffer, (short) 0,
(short) ISO7816.OFFSET_P2);
apdu.setOutgoingAndSend((short) 0, (short) ISO7816.OFFSET_P2);
}
public byte[] secureRandomGenerator(APDU apdu) {
byte[] buffer = apdu.getBuffer();
randomDataSecure.generateData(generatedArray, (short) 0,
(short) buffer[ISO7816.OFFSET_P2]);
return generatedArray;
}
public byte[] pseudoRandomGenerator(APDU apdu) {
byte[] buffer = apdu.getBuffer();
randomDataPseudo.generateData(generatedArray, (short) 0,
(short) buffer[ISO7816.OFFSET_P2]);
return generatedArray;
}
}
The CAP file generated and uploaded on the card successfully, but when I send APDU commands to the card, I receive the 0X6F00 status word :
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000202
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 02 02
Received (SW1=0x90, SW2=0x00)
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000102
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 01 02
Received (SW1=0x6F, SW2=0x00)
Is there something wrong in my applet?
Update:
Based on dear #Vojta's answer, I replace
Util.arrayCopyNonAtomic(generatedRandom, (short) 0, buffer, (short) 0,
(short) ISO7816.OFFSET_P2);
apdu.setOutgoingAndSend((short) 0, (short) ISO7816.OFFSET_P2);
With following lines in process() method :
Util.arrayCopyNonAtomic(generatedRandom, (short) 0, buffer, (short) 0,
(short) buffer[ISO7816.OFFSET_P2]);
apdu.setOutgoingAndSend((short) 0, (short) buffer[ISO7816.OFFSET_P2]);
Now I have a weird output in OpenSC-Tool output :
Secure random generator :
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000110
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 01 10
Received (SW1=0x90, SW2=0x00):
B8 1F 80 25 A2 8E 25 30 F8 22 F8 40 0F AE B0 6C ...%..%0.".#...l
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 .....
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000110
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 01 10
Received (SW1=0x6F, SW2=0x00)
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000110
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 01 10
Received (SW1=0x90, SW2=0x00):
F6 45 A9 0C 0C 3B 3A 5A 5F DC A8 36 .E...;:Z_..6
Pseudo random generator :
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000210
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 02 10
Received (SW1=0x90, SW2=0x00):
37 FD FC 67 EB 9E 21 00 6B E9 44 A7 21 3F 31 9A 7..g..!.k.D.!?1.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 .......
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000210
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 02 10
Received (SW1=0x6F, SW2=0x00)
OSC: opensc-tool.exe -s 00a404000b0102030405060708090000 -s 00000210
Using reader with a card: ACS CCID USB Reader 0
Sending: 00 A4 04 00 0B 01 02 03 04 05 06 07 08 09 00 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 00 02 10
Received (SW1=0x90, SW2=0x00):
72 FE 48 1B 9A A0 BD 2D DF F9 E7 F8 58 CF B7 C0 r.H....-....X...
00 00 00 00 00 00 00 00 00 00 00 ...........
Why I have different output for a single command?

There is a little bug in your code. You want
Util.arrayCopyNonAtomic(generatedRandom, (short) 0, buffer, (short) 0,
(short) buffer[ISO7816.OFFSET_P2]);
instead of
Util.arrayCopyNonAtomic(generatedRandom, (short) 0, buffer, (short) 0,
(short) ISO7816.OFFSET_P2);
General rule: ALWAYS surround the content of your process method with a try-catch block and set status words according to the type and reason of the exception. Otherwise you get only 6F00 and you do not know what really happened. If you followed this rule, you would know that ArrayIndexOutOfBoundsException was thrown.
Answer to update:
Weird output is caused by the fact, that
Util.arrayCopyNonAtomic(generatedRandom, (short) 0, buffer, (short) 0,
(short) buffer[ISO7816.OFFSET_P2]);
apdu.setOutgoingAndSend((short) 0, (short) buffer[ISO7816.OFFSET_P2]);
overwrites the buffer[ISO7816.OFFSET_P2] with some random value and then this value is used on the next line. You should store buffer[ISO7816.OFFSET_P2] in RAM in the beginning of the process method:
final byte p2 = buffer[ISO7816.OFFSET_P2];
Answer to comment below:
You have troubles for P2 >= 0x80, because of casting byte to short. Unfortunately, JavaCard handles byte as signed, that is why your length for P2 >= 0x80 is negative. You could easily avoid this by:
final short outputLen = (short) (buffer[ISO7816.OFFSET_P2] & 0xFF);

command not supported
You have the wrong instruction joining together.

Develop Reference

node.js excel linux python-3.x azure haskell apache-spark rust .htaccess string