I have a Java Card with an applet installed on it that returns the following response when I send 00 40 00 00 to it:
Connect successful.
Send: 00 40 00 00
Recv: 61 32
Time used: 15.000 ms
Send: 00 C0 00 00 32
Recv: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 90 00
Time used: 15.000 ms
The tool that I use (PyAPDUTool), have an option labeled "Auto Get Response". When I check this option, I don't need to send Get Response command (00 c0 00 00 32) anymore:
Send: 00 40 00 00
Recv: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 90 00
Time used: 15.000 ms
Okay. Now I want to have the above behavior on another Java Card. So I wrote the following program:
package testPrjPack;
import javacard.framework.*;
public class TestPrj extends Applet
{
public static byte[] data = {(byte)0x01 ,(byte)0x02 ,(byte)0x03 ,(byte)0x04 ,(byte)0x05 ,(byte)0x06 ,(byte)0x07 ,(byte)0x08 ,(byte)0x09 ,(byte)0x0A ,(byte)0x0B ,(byte)0x0C ,(byte)0x0D ,(byte)0x0E ,(byte)0x0F ,(byte)0x10 ,(byte)0x11 ,(byte)0x12 ,(byte)0x13 ,(byte)0x14 ,(byte)0x15 ,(byte)0x16 ,(byte)0x17 ,(byte)0x18 ,(byte)0x19 ,(byte)0x1A ,(byte)0x1B ,(byte)0x1C ,(byte)0x1D ,(byte)0x1E ,(byte)0x1F ,(byte)0x20 ,(byte)0x21 ,(byte)0x22 ,(byte)0x23 ,(byte)0x24 ,(byte)0x25 ,(byte)0x26 ,(byte)0x27 ,(byte)0x28 ,(byte)0x29 ,(byte)0x2A ,(byte)0x2B ,(byte)0x2C ,(byte)0x2D ,(byte)0x2E ,(byte)0x2F ,(byte)0x30 ,(byte)0x31 ,(byte)0x32};
public static void install(byte[] bArray, short bOffset, byte bLength)
{
new TestPrj().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
}
public void process(APDU apdu)
{
if (selectingApplet())
{
return;
}
byte[] buf = apdu.getBuffer();
switch (buf[ISO7816.OFFSET_INS])
{
case (byte)0x40:
ISOException.throwIt((short)0x6132);
break;
case (byte)0xC0:
Util.arrayCopyNonAtomic(data,(short)0, buf, (short)0, (short)0x32);
apdu.setOutgoingAndSend((short)0,(short)0x32);
break;
default:
ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
}
}
}
After installing the .cap file on the new Java Card, I have the following response for both Auto Get Response option checked and unchecked:
As you see above, the Auto Get Response doesn't work anymore and I need to send Get Response command manually.
I'm curious to know what is wrong with this tool or my program? Is the issue related to the communication protocol? (The first card working with T=0 and the second one working with T=1).
Nothing is wrong. T=1 just doesn't use GET RESPONSE at all, so there is no reason for Python to handle it automatically.
Important: note that Java Card also handles the GET RESPONSE automatically, so you should never have to implement it explicitly.
Related
I want to modify icmp.unused value in scapy. But no matter what value I set for it, the value of icmp.unused is still 0. I know which byte in my packet is responsible for its value. So I want to modify the byte directly. hexstr and hexdump don't work. The end of the packet is messed up. How to do this?
hex_packet = scapy.hexstr(packet)
print(type(hex_packet))
list_packet = list(hex_packet)
list_packet[38] = '\x05'
list_packet[39] = '\x14'
hex_packet = ''.join(list_packet)
packet_hex = scapy.Ether(scapy.import_hexcap())
08 00 27 78 FE 4B 52 54 00 12 35 00 080 45 00 00 38 00 01 00 00 40 01 31 6D C0 A8 64 01 C0 A8 64 05 03 04 41 5E 00 00 05 14 45 00 00 1C 00 01 00 00 40 11 31 74 C0 A8 64 05 C0 A8 64 06 FC F1 00 35 00 08 B9 5A ..'x.KRT..5...E..8....#.1m..d...d...A^....E.......#.1t..d...d....5...Z
Does JCOP/J3A081 support int data type?
I am using latest eclipse JCOP tools for java card applet development. I need to store big integer values in a card so I have used the INTEGER data type (int) for balance in my applet. it is compiling without any error but getting error 6A80 on uploading the CAP file into JCOP J3A081 cards. I have tried all combinations of GP 2.1.1, GP 2.2.1, JDK 2.2.2, JDK 3.0.4 library but getting the same error.
Are int data type variables and JCint library supported by J3A/J2A series cards? if yes how to resolve the issue?
Applet source code:
Note: if I remove int data type variable and JCint references then no error comes.
- version
current version is 5.32.0.4 [1]
build timestamp is 27-01-2020 12:10:53
- /terminal
--Opening terminal
Session ID: 6527B91D44DD89CDE6AB60FCA590DF06
> /list-readers
----------------------
Name ( Type )
----------------------
> /card -v
Warning: Usage of /atr with no preceding of /reset is deprecated. /reset is invoked.
IOCTL().
ATR: 3B89800150565F4A334130383150
ATR:
Hist = PV_J3A081
T = 0
T = 1
=> 00 A4 04 00 00 .....
(12493 usec [SYS])
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 00 78 34 00 73 4A 06 07 2A ...n.G..x4.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
FCI Data:
Max. Block Length: 255
CPLC Data:
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
Security Domain Management Data:
Global Platform Version: 2.1.1
Secure Channel Protocol: 02 (option 15)
cm> /identify
FABKEY ID: 0x02
PATCH ID: 0x21
TARGET ID: 0x00 (null)
MASK ID: 0x34 (52)
CUSTOM MASK: 00000000
MASK NAME: NX011D
FUSE STATE: fused
ROM INFO: 58E957
COMBO NAME: null-m34.02.21-NX011D
cm> get-cplc -v
=> 80 CA 9F 7F 00 .....
(8475 usec [SYS])
<= 9F 7F 2A 47 90 51 68 47 91 00 78 34 00 31 30 04 ..*G.QhG..x4.10.
81 33 96 75 18 48 12 31 37 00 00 00 00 0F 20 38 .3.u.H.17..... 8
34 38 31 33 33 00 00 00 00 00 00 00 00 90 00 48133..........
Status: No Error
IC Fabricator : 4790
IC Type : 5168
Operating System ID : 4791
Operating System release date : 0078 (18.3.20X0)
Operating System release level : 3400
IC Fabrication Date : 3130 (10.5.2003)
IC Serial Number : 04813396
IC Batch Identifier : 7518
IC Module Fabricator : 4812
IC Module Packaging Date : 3137 (17.5.2003)
ICC Manufacturer : 0000
IC Embedding Date : 0000
IC Pre-Personalizer : 0F20
IC Pre-Perso. Equipment Date : 3834
IC Pre-Perso. Equipment ID : 38313333
IC Personalizer : 0000
IC Personalization Date : 0000
IC Perso. Equipment ID : 00000000
cm> /cap-info "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
CAP file name : C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap
CAP file version : 2.2
Java package name : com.pryogika.jc
Internal pkg. name : com/pryogika/jc
CAP file components :
Header.cap (38 Bytes)
Directory.cap (36 Bytes)
Import.cap (36 Bytes)
Applet.cap (22 Bytes)
Class.cap (17 Bytes)
Method.cap (82 Bytes)
StaticField.cap (13 Bytes)
ConstantPool.cap (41 Bytes)
RefLocation.cap (16 Bytes)
Descriptor.cap (90 Bytes)
Debug.cap (500 Bytes)
Integer support : yes
Package version : 1.0
Package AID : "HelloJCOP"
Import AIDs :
A0000000620101 (javacard.framework) version 1.3
A00000006202080101 version 1.0
A0000000620001 (java.lang) version 1.0
Applet AIDs :
"HelloJCOPApplet"
Code size to load : 301 bytes
Code size on card :
pkgAID : 9
applet AIDs : 22
classes : 17
methods : 82
statics : 0
exports : 0
-------------------------------------
overall : 130 bytes
SHA-256 (Load File data): FD9E6BDB25A9C863B83C1ECE829F66DBEAA64B38BF5CD4EA953651B110AAD209
SHA-256 (Load File dbg) : 07F25D2E0A470C0AFECCADEF1387986D70C71606E33DD339ED89F4CE1CA84467
SHA-256 (Load File) : CE72441BF5B56BB36A4AEBE3F3A96725D0A36926697B9187C3873C3437CBEAA4
SHA-1 (Load File data): C5EFC5FAAE4FB711E327F5563C48888EA56F81D5
SHA-1 (Load File dbg) : 41264E6C8F21F1C46F2BE7EBCF70CAE00624A277
SHA-1 (Load File) : EB826D7E56AFF5AAF4C4CD3FC4FB5850DD81D91F
DAP block(s) : none
Load Token(s) : none
Install Token(s) : none
Delete Token(s) : none
cm> set-key 1/1/DES-ECB/404142434445464748494a4b4c4d4e4f 1/2/DES-ECB/404142434445464748494a4b4c4d4e4f 1/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update
=> 80 50 00 00 08 11 A9 0F 67 2B 22 B6 E1 00 .P......g+"...
(37691 usec [SYS])
<= 00 00 31 30 04 81 33 96 75 18 01 02 00 3E 60 17 ..10..3.u....>`.
08 B3 12 20 F1 76 A5 F1 D0 6D 12 BD 90 00 ... .v...m....
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 3F BE FC 67 E2 96 5E DF A7 85 B1 .....?..g..^....
9C CF C3 A4 F2 .....
(42458 usec [SYS])
<= 90 00 ..
Status: No Error
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(8862 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(7220 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8838 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
cm> upload -b 250 "C:\Users\pp\eclipse-workspace\testJCOP\bin\com\pryogika\jc\javacard\jc.cap"
=> 80 E6 02 00 16 09 48 65 6C 6C 6F 4A 43 4F 50 08 ......HelloJCOP.
A0 00 00 00 03 00 00 00 00 00 00 00 ............
(13758 usec [SYS])
<= 00 90 00 ...
Status: No Error
=> 80 E8 00 00 FA C4 82 01 2D 01 00 23 DE CA FF ED ........-..#....
02 02 05 00 01 09 48 65 6C 6C 6F 4A 43 4F 50 0F ......HelloJCOP.
63 6F 6D 2F 70 72 79 6F 67 69 6B 61 2F 6A 63 02 com/pryogika/jc.
00 21 00 23 00 21 00 13 00 21 00 26 00 0E 00 4F .!.#.!...!.&...O
00 0A 00 0D 00 00 00 57 00 00 00 00 00 00 00 00 .......W........
03 01 00 04 00 21 03 03 01 07 A0 00 00 00 62 01 .....!........b.
01 00 01 09 A0 00 00 00 62 02 08 01 01 00 01 07 ........b.......
A0 00 00 00 62 00 01 03 00 13 01 0F 48 65 6C 6C ....b.......Hell
6F 4A 43 4F 50 41 70 70 6C 65 74 00 08 06 00 0E oJCOPApplet.....
00 00 00 80 03 00 FF 00 07 01 00 00 00 1C 07 00 ................
4F 00 01 10 18 8C 00 00 7A 05 30 8F 00 01 3D 8C O.......z.0...=.
00 02 18 1D 04 41 18 1D 25 8B 00 03 7A 04 23 18 .....A..%...z.#.
8B 00 04 60 03 7A 19 8B 00 05 2D 1A 04 25 73 00 ...`.z....-..%s.
1B 00 00 00 00 00 09 12 0A 36 1A 08 23 8D 00 06 .........6..#...
3B 19 08 07 8B 00 07 70 08 11 6D 00 8D 00 08 7A ;......p..m....z
08 00 0A 00 00 00 00 00 00 00 00 00 00 05 00 00 ................
(25820 usec [SYS])
<= 6A 80 j.
Status: Wrong data
jcshell: Error code: 6a80 (Wrong data)
jcshell: Wrong response APDU: 6A80
cm> /list-v
Global:____________________________________________
SESSION.ID=0FA5DF09FC02F2276D5A113D1591EE7C
cap.applet.aids=48656C6C6F4A434F504170706C6574
cap.package.aid=48656C6C6F4A434F50
exec.dir=C:\Users\pp\Desktop
jcop.v242=false
last.apdu.executiontime=25.717
last.apdu.executiontime.unit=msec
last.executiontime=52.0
last.executiontime.unit=msec
last.response.status=6a80
logfile.list=
cm> card-info
=> 80 F2 80 00 02 4F 00 00 .....O..
(17196 usec [SYS])
<= 08 A0 00 00 00 03 00 00 00 07 9E 90 00 .............
Status: No Error
=> 80 F2 40 00 02 4F 00 00 ..#..O..
(20679 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
=> 80 F2 10 00 02 4F 00 00 .....O..
(8299 usec [SYS])
<= 6A 88 j.
Status: Reference data not found
Card Manager AID : A000000003000000
Card Manager state : INITIALIZED
No, these cards have not supported the int type. For full certainty simply ask for the data sheet or user's manual from NXP, and if it is not in there, ask them directly.
If you want to support bigger data types then this is of course possible, but you'll have to program it yourself. In that case the fact that objects are stored in persistent memory will of course not be of any help, but it can be done.
Otherwise: it depends on what kind of integer support you require. Just addition or subtraction is very easy to implement yourself on a byte-by-byte base. For cryptographic purposes you may need to look a lot deeper. Sometimes you can also use existing API's such as DH key agreement to perform e.g. modular exponentiation. There are for instance libraries to perform Elliptic Curve calculations (which require big integer).
I'm trying to interpret a HEX message that is transmitted in network byte order (big endian), how should I proceed to achieve conversion to ASCII?
server.on('message', function (message, remote) {
//I receive message via UDP in HEX.
});
The message comes in this format:
2B 41 43 4B 19 EF 24 10 01 02 03 02 56 50 22 00 0A 02 3B 01 00 00 4E 07 DD 02 17 11 21 20 46 AD 4E 1E 0D 0A
With that being said, each byte has a parameter attached, let's say I have 4 bytes to parameter1, 2 bytes to parameter2 and 8 bytes to parameter 3, how would I interpret it?
For example: How would one decode the following ethernet frame?
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00 05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8 01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10 00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00 01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
I know that the first 6 bytes are the MAC destination address : 00 26 b9 e8 7e f1 The next 6 bytes are the source MAC address : 00 12 f2 21 da 00 The next 2 bytes show the ethernet type : 08 00 The next 4 bytes are : 45 00... Ipv4... "5" the number of bytes in the header.. and "00" means there are no differentiated services.
What I don't know is what anything after that is or how to read it.
Anyone help?
Rearranging a bit your packet, we have:
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00
05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8
01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10
00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00
01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
If you know that the first 6 octets form the destination mac address, that means that it is an Ethernet layer 2 packet.
According to IEEE 802.3, $3.1.1:
First 6 octets are the destination mac address (00 26 b9 e8 7e f1)
Next 6 octets are the source mac address (00 12 f2 21 da 00)
Next 4 octets are, optionally the 802.1Q tag (present, 08 00 45 00)
Next 2 octets are either:
Maximum payload size - aka MTU (if <= 1500, which is the case, 05 dc is 1500)
Ethernet 2 frame (if >= 1536)
Next is the payload ranging from 46 octets (if the 802.1Q tag is absent) or 42 octets (if the 802.1Q tag is present) to up to 1500 octets (starts at e3 cd 20 10 ..., ends either at 20 12 18 19 or at 03 06 00 00, depends on the 7th item)
Last 4 octets form the CRC32 code (either 01 98 64 34 or 04 85 80 00, depending on the 7th item)
There is also 12 octets used for padding (random - not so random - bytes), that may or may not be inserted in this packet. (if inserted, the padding is e8 90 84 98 20 12 18 19 04 85 80 00)
I use node-canvas;
....
var content = canvas.toBuffer();
var length=content.length;
console.log(content);
result:
<SlowBuffer 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 00 30 00 00 00 30 08 06 00 00 00 57 02 f9 87 00 00 00 06 62 4b 47 44 00 ff 00 ff 00 ff a0 bd a7 93 ...>
And
var buf=new SlowBuffer(length);
buf.write(content.toString());
console.log(buf);
result:
<Buffer ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 28 00 28 00 00 ff db 00 43 00 08 06 06 07 06 05 08 07 07 07 09 09 08 0a 0c 14 0d 0c 0b 0b 0c 19 12 13 0f 14 ...>
They are not equal:( ,so when I store it into redis ,I can't get it back;
Depending on the format you want, you can use the following methods:
buf.toJSON() // Straight to JSON format
buf.toString('utf8') ; // UTF8 format
Read on for more alternatives: https://nodejs.org/api/buffer.html#buffer_buf_tostring_encoding_start_end
You can't just call Buffer.toString and assume that everything will be all right, since the default encoding is utf8. If you want to encode binary data, you need base64 encoding.