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
Related
I'm going to delete an existent key from my card's ISD. To do so I sent a DELETE Key APDU command with corresponding KeyID and KeyVersion to the ISD after a successful Mutual Authentication as below:
--> 00 A4 04 00 08 A0 00 00 01 51 00 00 00
<-- 6F 5B 84 08 A0 00 00 01 51 00 00 00 A5 4F 73 49 06 07 2A 86 48 86 FC 6B 01 60 0B 06 09 2A 86 48 86 FC 6B 02 02 02 63 09 06 07 2A 86 48 86 FC 6B 03 64 0B 06 09 2A 86 48 86 FC 6B 04 02 55 65 0B 06 09 2A 86 48 86 FC 6B 02 01 03 66 0C 06 0A 2B 06 01 04 01 2A 02 6E 01 03 9F 65 01 FF 90 00
--> 80 50 00 00 08 79 71 01 3C 63 9D 72 A3
<-- 00 00 90 30 09 0A 90 72 3D A3 01 02 00 00 60 AD 80 68 C2 A1 79 AE B9 E4 4A 4D B7 99 90 00
--> 84 82 00 00 10 AB E9 10 5B 60 7C DE C6 9C DC 15 E0 DA 9B 81 44
<-- 90 00
--> 80 E4 00 00 06 D0 01 01 D2 01 71
<-- 6A 80
As you see above, I received 6A80 status word which means Wrong Data. I've have tried the same command and data with a different card and it successfully returned 90 00 status words.
So
What is wrong with this card and how I can delete this key?
Is there anyway to list all existent keys on the card? As far as I know, GET DATA APDU command with Tag 66 (Key Information Template) does not return list of all available keys.
Some card are simply not supporting it. As alternative you can rotate the keys to a random value.
The tag for key templates is 00E0. You can use this with GET DATA. E.g. GPShell provides the command get_key_information_templates -keyTemplate index. Use 0 as index. This output returns a more readable list.
I'm wanting to make a PCap Analyzer script where it can detect what traffic is what from a pcap file.
The general idea is: HTTP(x10), DNS(x5), HTTPS(x20)
Now as you can see the majority of traffic is HTTPS based I want to be able to pull that from the pcap packet data to pass to another section of my analyzer script.
I don't have a clue nor any idea of what NPMs or anything that I can use, I have looked into pcap-parser which is a 9+ Yr old NPM this package , and only provides packet.data, packet.header.
I'm just completely losing all hope on making this script as I've tried ever potential resource even went into researching a potential API system to upload the pcap and bring the info I wish to obtain with no avail.
Example of packet.header
{
timestampSeconds: 1606145597,
timestampMicroseconds: 444357,
capturedLength: 60,
originalLength: 60
}
Example of packet.data (Buffer)
<Buffer 01 00 5e 7f ff fa 34 29 8f 99 09 70 08 00 45 00 00 a5 a4 76 00 00 04 11 10 f3 0a c8 06 1d ef ff ff fa ed 0c 07 6c 00 91 17 56 4d 2d 53 45 41 52 43 48 ... 129 more bytes>
<Buffer ff ff ff ff ff ff 34 29 8f 99 09 6e 08 06 00 01 08 00 06 04 00 01 34 29 8f 99 09 6e 0a c8 06 e6 00 00 00 00 00 00 0a c8 06 de 00 00 00 00 00 00 00 00 ... 10 more bytes>
<Buffer e0 55 3d 5e 95 a0 40 ec 99 d3 06 fd 08 00 45 00 05 6b a7 ed 40 00 80 06 00 00 0a 91 a6 ce 34 ef cf 64 e9 9f 01 bb a2 30 72 ed d9 06 6d cc 80 18 02 00 ... 1351 more bytes>
<Buffer 40 ec 99 d3 06 fd e0 55 3d 5e 95 a0 08 00 45 00 00 34 72 2d 40 00 70 06 e2 e3 34 ef cf 64 0a 91 a6 ce 01 bb e9 9f d9 06 6d cc a2 30 14 19 80 10 1b 25 ... 16 more bytes>
<Buffer e0 55 3d 5e 95 a0 40 ec 99 d3 06 fd 08 00 45 00 00 34 05 b4 40 00 80 06 00 00 0a 91 a6 ce 17 d9 8a 6c e9 a8 01 bb f0 0d cc ed 00 00 00 00 80 02 fa f0 ... 16 more bytes>
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).
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.