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)
Related
When inserting an UICC in an iPhone SE2 and recording the APDU messages between the modem and the UICC I see a sequence opening a logical channel and trying to select an application. I could not find any reference to this application. What is it?
01 a4 04 0c 10 a0 00 00 00 09 02 03 ff ff ff ff 89 01 00 00 ff
The RID a0 00 00 00 09 is registered for the ETSI.
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 ?
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
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.
I am running this (http://www.linux-usb.org/gadget/usb.c) Gadget FS user mode driver on an embedded device.
When I connect it to Windows, these are the GET_DESCRIPTOR setup requests I receive:
80 06 03 03 09 04 ff 00
80 06 00 03 00 00 ff 00
80 06 02 03 09 04 ff 00
80 06 03 03 09 04 ff 00
80 06 00 03 00 00 ff 00
80 06 02 03 09 04 ff 00
`bmRequestType`: 0x80 Device-to-host transfer direction
`bRequest`: 0x06 GET_DESCRIPTOR
`wValueH` : 0x03 Descriptor Type 'String'
`wValueL` : Descriptor Index
`wIndex` : 0x04 0x09 Language ID "US-English" for Descriptor Types "String", 0x00 for others
`wLength` : Length of the requested descriptor
These are the setup requests coming from the Linux host when i connect the device.
80 06 00 03 00 00 ff 00
80 06 02 03 09 04 ff 00
80 06 01 03 09 04 ff 00
80 06 03 03 09 04 ff 00
80 06 ee 03 00 00 00 04
The last one makes my GadgetFS implementation STALL. The Descriptor Type is 3, meaning a Descriptor of type "String" is requested but in wIndex no Language ID is provided (0x00 0x00). Also, the Descriptor Index is 0xEE, but why would you have 238 String Descriptors for a device?
Notice also the length of the requested descriptor: 0x0400 (1024).
This is a code excerpt from the driver implementation I use (linux-usb.org) that handles the setup requests:
case USB_REQ_GET_DESCRIPTOR: //0x06
if (setup->bRequestType != USB_DIR_IN) //USB_DIR_IN = 0x80
goto stall;
switch (value >> 8) // wValueH: Descriptor Type
{
case USB_DT_STRING: // 0x03 Type = "String"
{
tmp = value & 0x0ff; // wValueL : Descriptor Index
struct usb_gadget_strings strings = {
0x0409, /* "en-us" */
m_aUsbStringtab
};
index = 0x0409
if (tmp != 0 && index != strings.language) //This makes it STALL when connected to a linux
goto stall;
I'd really appreciate it, if someone could help me!
So appearently on linux, the setup request with a descriptor index of 0xEE and a length of 1024 is not sent by libusb on linux but by mtp-probe (part of libmtp, media transfer protocol).