How to validate CRC-32 calculation of Zip file - checksum

I want to validate that my ZIP file has a correct CRC-32 checksum.
I read that in a ZIP file the CRC-32 data is in bytes 14 to 17:
Offset Bytes Description[30]
0 4 Local file header signature = 0x04034b50 (read as a little-endian number)
4 2 Version needed to extract (minimum)
6 2 General purpose bit flag
8 2 Compression method
10 2 File last modification time
12 2 File last modification date
14 4 CRC-32 of uncompressed data
18 4 Compressed size
22 4 Uncompressed size
26 2 File name length (n)
28 2 Extra field length (m)
30 n File name
30+n m Extra field
I wanted to validate a CRC-32 checksum of a simple ZIP file I created:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
-----------------------------------------------
50 4B 03 04 14 00 00 00 00 00 38 81 1C 51 4C 18 | PK........8..QL.
C7 8C 02 00 00 00 02 00 00 00 07 00 00 00 31 32 | nj............12
33 2E 64 61 74 73 73 50 4B 01 02 14 00 14 00 00 | 3.datssPK.......
00 00 00 38 81 1C 51 4C 18 C7 8C 02 00 00 00 02 | ...8..QL.nj.....
00 00 00 07 00 00 00 00 00 00 00 01 00 20 00 00 | ............. ..
00 00 00 00 00 31 32 33 2E 64 61 74 50 4B 05 06 | .....123.datPK..
00 00 00 00 01 00 01 00 35 00 00 00 27 00 00 00 | ........5...'...
00 00 | ..
The CRC-32 is: 0x4C18C78C
I went to this CRC-32 online calculator and added the following un-compressed row from the file:
50 4B 03 04 14 00 00 00 00 00 38 81 1C 51
This is the result:
Algorithm Result Check Poly Init RefIn RefOut XorOut
CRC-32 0x6A858174 0xCBF43926 0x04C11DB7 0xFFFFFFFF true true 0xFFFFFFFF
CRC-32/BZIP2 0xE3FA1205 0xFC891918 0x04C11DB7 0xFFFFFFFF false false 0xFFFFFFFF
CRC-32C 0xB578110E 0xE3069283 0x1EDC6F41 0xFFFFFFFF true true 0xFFFFFFFF
CRC-32D 0xAFE2EEA4 0x87315576 0xA833982B 0xFFFFFFFF true true 0xFFFFFFFF
CRC-32/MPEG-2 0x1C05EDFA 0x0376E6E7 0x04C11DB7 0xFFFFFFFF false false 0x00000000
CRC-32/POSIX 0xFF9B3071 0x765E7680 0x04C11DB7 0x00000000 false false 0xFFFFFFFF
CRC-32Q 0x79334F11 0x3010BF7F 0x814141AB 0x00000000 false false 0x00000000
CRC-32/JAMCRC 0x957A7E8B 0x340BC6D9 0x04C11DB7 0xFFFFFFFF true true 0x00000000
CRC-32/XFER 0xA7F36A3F 0xBD0BE338 0x000000AF 0x00000000 false false 0x00000000
But none of them equal to: 0x4C18C78C.
What am I doing wrong? The CRC-32 of the ZIP is the calculation of all the bytes (0-13) before, no?

The byte sequence you are running against the online CRC calculator are not uncompressed bytes.
50 4B 03 04 14 00 00 00 00 00 38 81 1C 51
Those bytes are the first few bytes of the zip file. The CRC32 value in a zip is calculated by running the CRC32 algorithm against the complete uncompressed payload. In your case the payload is the two byte sequence "ss".
To work that out, I converted your hex dump back into a zip file, tmp.zip. It contains a single member 123.dat
$ unzip -lv tmp.zip
Archive: tmp.zip
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
2 Stored 2 0% 2020-08-28 16:09 8cc7184c 123.dat
-------- ------- --- -------
2 2 0% 1 file
When I extract that member to stdout & pipe though hexdump, we find it contains the two bytes string "ss" (hex 73 73)
$ unzip -p tmp.zip | hexdump -C
00000000 73 73 |ss|
Finally, as already mentioned in another comment, you can check that the CRC value is correct by running unzip -t
$ unzip -t tmp.zip
Archive: tmp.zip
testing: 123.dat OK
No errors detected in compressed data of tmp.zip.

I was able to create a zip file that matches the one in the question. The header shows that the compression type == 0, which means no compression, the uncompressed size == 2, the data == {73 73}. CRC32 uses reflected input and output, and the CRC is stored in little endian format, so the CRC == 0x8CC7184C.
I get a match using CRC32 on data of {73 73} using this online CRC calculator:
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

Related

weird pcap packet length

I am working with pcap in C and comparing the lengths of EAPOL handshakes with those get in wireshark, and the EAPOL packets captured with pcap are longer. The strange thing is that the added length is variable, some days it adds a header of 26 bytes and a footer of 4, making a 185 bytes packet (instead of the 155 byte in wireshark for the first message of the handshake). Some days it adds a 18 byte header with no footer, making a 173 byte packet. When it captures a packet of a certain length, it keeps that format for the whole day and the next day it switches to the other one.
I have read this Libpcap File Format but the lengths of those headers don't fill the gap, and wireshark doesn't show Radiotap Headers so I guess I don't have any. The captured packet comes always between the same devices and wireshark returns always the same length.
Anyone knows what is going on here? Thanks in advance guys!
As requested, I add some examples of the packets captured. For the sake of clarity I will paste only the first message of the handshake, and only for the 185 byte case, as it is the length I get today:
As captured by pcap (185 bytes). Extra bytes in bold:
00 00 1a 00 2f 48 00 00 f3 7c 7b 00 00 00 00 00 10 02 85 09 a0 00 db 01 00 0088 02 3a 01 85 74 13 51 b4 a8 d8 b7 b8 17 92 81 d8 b7 b8 17 92 81 00 00 00 00 aa aa 03 00 00 00 88 8e 02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 03 ed 35 bb b6 7d d9 0a 43 ba aa 09 23 f1 f6 6e c9 25 f3 13 c3 91 1c cd ae f5 47 98 0e 6b 15 7a fe 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 16 dd 14 00 0f ac 04 c2 8c 80 68 37 d8 87 fa 37 ab bd 07 1f c3 96 eecb f9 0b 91
The EAPOL packet as shown in Wireshark (155 bytes):
88 02 3a 01 85 74 13 51 b4 a8 d8 b7 b8 17 92 81 d8 b7 b8 17 92 81 00 00 00 00 aa aa 03 00 00 00 88 8e 02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 03 ed 35 bb b6 7d d9 0a 43 ba aa 09 23 f1 f6 6e c9 25 f3 13 c3 91 1c cd ae f5 47 98 0e 6b 15 7a fe 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 16 dd 14 00 0f ac 04 c2 8c 80 68 37 d8 87 fa 37 ab bd 07 1f c3 96 ee

Trying to decipher captured wireshark packets

I have a saved wireshark capture and I've applied a filter to the results to only show communications for one particular device.
I have decryption enabled, and the decryption key is stored as wpa-pwd in the format key:SSID.
I don't fully understand how to interpret the results that I have available to me. I've searched extensively here on S/O, and on Google.
I imagine that the packets that would be "of interest" to me from the results would be the packets coming from the source device, outgoing to the router, all marked with the 802.11 protocol.
I currently have the filtered results ordered by destination, there's
3 "request-to-send" results
followed by a "802.11 Block Ack",
8 "request-to-send" results,
followed by another "802.11 Block Ack"
3 "request-to-send" results.
I'll place the results here in this order, but I'm only including the summary for the first of the request-to-send, and the two 802.11 block ack packets, since the summary for the request-to-send packets are all essentially identical.
As a question, is there any way I can directly interpret these results to understand what these packets contained/were for?
Packet 1 (Request-to-send) Summary
5131 27.713095 Apple_88:85:55 (TA) Actionte_30:f4:b6 (18:1b:eb:30:f4:b6) (RA) 802.11 45 Request-to-send, Flags=...P....C
Packet 1 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 57 11 bb 47 00 00 00 00 ....o...W..G....
0010 12 30 85 09 80 04 c3 a0 00 b4 10 9e 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 a4 ff c8 cc 0..,....U....
Packet 2 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 c1 b7 77 48 00 00 00 00 ....o.....wH....
0010 12 30 85 09 80 04 c6 9e 00 b4 00 a6 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 69 3a 25 10 0..,....Ui:%.
Packet 3 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 de 05 78 48 00 00 00 00 ....o.....xH....
0010 12 30 85 09 80 04 c5 9e 00 b4 00 a2 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 72 b5 89 09 0..,....Ur...
Packet 4, 802.11 Block Ack Summary
6829 40.120666 Apple_88:85:55 (TA) Actionte_30:f4:b6 (18:1b:eb:30:f4:b6) (RA) 802.11 57 802.11 Block Ack, Flags=........C
Packet 4 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 53 65 78 48 00 00 00 00 ....o...SexH....
0010 12 30 85 09 80 04 c6 9e 00 94 00 00 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 05 00 b0 3c 01 00 00 0..,....U...<...
0030 00 00 00 00 00 5d c0 d4 c7 .....]...
Packet 5 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 02 6f 78 48 00 00 00 00 ....o....oxH....
0010 12 30 85 09 80 04 c5 9e 00 b4 00 a2 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 72 b5 89 09 0..,....Ur...
Packet 6 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 ea 77 78 48 00 00 00 00 ....o....wxH....
0010 12 30 85 09 80 04 c5 9e 00 b4 00 be 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 33 18 ce 45 0..,....U3..E
Packet 7 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 c3 ca 78 48 00 00 00 00 ....o.....xH....
0010 12 30 85 09 80 04 c5 9e 00 b4 00 a2 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 72 b5 89 09 0..,....Ur...
Packet 8 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 f8 d4 78 48 00 00 00 00 ....o.....xH....
0010 12 30 85 09 80 04 c5 9e 00 b4 00 ce 01 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 f3 72 37 72 0..,....U.r7r
Packet 9 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 24 68 7a 48 00 00 00 00 ....o...$hzH....
0010 12 30 85 09 80 04 c6 9e 00 b4 00 a2 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 72 b5 89 09 0..,....Ur...
Packet 10 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 7e ed 7b 48 00 00 00 00 ....o...~.{H....
0010 12 30 85 09 80 04 c6 9e 00 b4 00 a6 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 69 3a 25 10 0..,....Ui:%.
Packet 11 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 e3 3c 7c 48 00 00 00 00 ....o....<|H....
0010 12 30 85 09 80 04 c6 9e 00 b4 00 a2 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 72 b5 89 09 0..,....Ur...
Packet 12 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 3c 52 7c 48 00 00 00 00 ....o...<R|H....
0010 12 30 85 09 80 04 c6 9e 00 b4 00 0e 01 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 e0 6a fd b0 0..,....U.j..
Packet 13 (Block Ack) Summary
6978 40.406195 Apple_88:85:55 (TA) Actionte_30:f4:b6 (18:1b:eb:30:f4:b6) (RA) 802.11 57 802.11 Block Ack, Flags=........C
Packet 13 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 94 bf 7c 48 00 00 00 00 ....o.....|H....
0010 12 30 85 09 80 04 c6 9e 00 94 00 00 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 05 00 40 3d 03 00 00 0..,....U..#=...
0030 00 00 00 00 00 fa 5f c6 82 ......_..
Packet 14 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 54 cd 7c 48 00 00 00 00 ....o...T.|H....
0010 12 30 85 09 80 04 c6 9e 00 b4 00 a2 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 72 b5 89 09 0..,....Ur...
Packet 15 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 1a f7 7c 48 00 00 00 00 ....o.....|H....
0010 12 30 85 09 80 04 c2 9e 00 b4 00 be 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 33 18 ce 45 0..,....U3..E
Packet 16 Hex + ASCII
0000 00 00 19 00 6f 08 00 00 6f 4a 7d 48 00 00 00 00 ....o...oJ}H....
0010 12 30 85 09 80 04 c6 9e 00 b4 00 a2 00 18 1b eb .0..............
0020 30 f4 b6 2c f0 a2 88 85 55 72 b5 89 09 0..,....Ur...
So, I'm looking for an explanation how to interpret these and future results, kind of like "catch the first fish and then show me how to do it."
I know I've read something about right-clicking on the packet and going to "follow" and "stream", but this option isn't available in a saved capture, if anyone wants to mention what that specific feature does, it'd also be appreciated.
According to Wikipedia (https://en.wikipedia.org/wiki/IEEE_802.11_RTS/CTS), these messages are intended to avoid transmission collisions. They mean something like "I would like to send something over WiFi, can I or is there somebody else planning to send data?".
Some more explanation: instead of just "yelling out" the bulk of data the WiFi card can first asks "can I?" and if nobody complains the bulk of data follows (and nobody else tries to send data as you asked to speak first). Without asking first, there is the potential of everybody yelling out loud and nobody can understand anybody.
As the "can I?" message is way shorter than the bulk of data, there will be less concurrent transmissions (which result in collision --> data needs to be resend).

How to copy hex data of captured packet form wireshark

here is the example
this is the captured packet data
00000000 00 6e 0b 00 .n..
00000004 4d 5a e8 00 00 00 00 5b 52 45 55 89 e5 81 c3 81 MZ.....[ REU.....
00000014 12 00 00 ff d3 89 c3 57 68 04 00 00 00 50 ff d0 .......W h....P..
00000024 68 f0 b5 a2 56 68 05 00 00 00 50 ff d3 00 00 00 h...Vh.. ..P.....
00000034 00 00 00 00 00 00 00 00 00 00 00 00 e0 00 00 00 ........ ........
00000044 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........ !..L.!Th
00000054 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is progr am canno
00000064 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t be run in DOS
00000074 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode.... $.......
and i want only the hex part like this
00 6e 0b 00
4d 5a e8 00 00 00 00 5b 52 45 55 89 e5 81 c3 81
12 00 00 ff d3 89 c3 57 68 04 00 00 00 50 ff d0
I try right click on the packet and select copy -> bytes ->hex stream
but the hex data I got doesn't look like the above data at all
so How Can I copy hex data of captured packet form wireshark ?
thanks for reading
On the Wireshark "packet list" panel, right click the packet you want and:
1) if you select Copy->Bytes->Hex stream, you'll get the hex digits as one long string without white spaces
39cb08004528053f000000006f1105faac11745dac11740c039......
2) if you select Copy->Bytes->Offset Hex, you'll get the hex digits as displayed on the GUI , including the offset of each line starting byte (frame offset)
0010 05 3f 00 00 00 00 6f 11 05 fa ac 11 74 5d ac 11
0020 74 0c 03 9e 03 9d 05 2b 00 00 07 e0 8f ee 8f 1c
0030 ff 00 00 00 00 00 09 0f 00 58 39 cb 60 00 00 00
0040 11 80 08 00 73 00 02 44 00 00 00 00 03 dd de de
You can use TShark.
TShark is shipped with Wireshark.
Use command:
tshark -x -r dns.pcapng frame.number == 10
Output:
D:\Wireshark>tshark -r dns.pcapng frame.number == 10 -x
0000 00 25 9c ca 94 fe 90 e6 ba 71 70 03 08 00 45 00 .%.......qp...E.
0010 00 3f 6d 61 00 00 80 11 7d dc 0a 01 01 0a 11 22 .?ma....}......"
0020 33 44 f0 1d 00 35 00 2b be 3e 71 dd 01 00 00 01 3D...5.+.>q.....
0030 00 00 00 00 00 00 0d 73 74 61 63 6b 6f 76 65 72 .......stackover
0040 66 6c 6f 77 03 63 6f 6d 00 00 ff 00 01 flow.com.....
Copy and paste the hex part.
Hope this helps
If there are several packets you're interested in, you can export them to a file.
mark those packets (right click on each packet then Mark Packet (toggle) or Ctrl + M)
choose File > Export > File.... Make sure you select Marked packets.
if you're only interested in the hex data, make sure only Packet Bytes is checked in Packet Format
Note that when exporting you also have the choice with First to last marked as well as Range, if the interesting packets are next to each other.

java card upload error [duplicate]

This question already has answers here:
jcop applet upload error
(3 answers)
Closed 9 years ago.
i am new to java card development.i have jcop 31(36k) card and scl010 reader.i have install jcop plugin for eclipse.when i run my helloworld java applet in simulater(using jcop shell) it works fine.now i want to upload .cap file in to my card.i thought the way is uploading .cap file in to card run the applet in reader.(i don't know it is the best way i have attached the process i followed). when i load cap file it gives this error
**upload -b 250 "C:\Projects\Javacard\MytestThree\bin\hms\javacard\testthree\javacard\testthree.cap"
=> 80 E6 02 00 15 08 6D 79 61 70 70 6C 65 74 08 A0 ......myapplet..
00 00 00 03 00 00 00 00 00 00 00 ...........
(26209 usec)
<= 00 90 00 ...
Status: No Error
=> 80 E8 00 00 FA C4 82 01 65 01 00 29 DE CA FF ED ........e..)....
02 02 04 00 01 08 6D 79 61 70 70 6C 65 74 16 68 ......myapplet.h
6D 73 2F 6A 61 76 61 63 61 72 64 2F 74 65 73 74 ms/javacard/test
74 68 72 65 65 02 00 21 00 29 00 21 00 10 00 0B three..!.).!....
00 2E 00 0E 00 7F 00 18 00 12 00 00 00 71 02 F0 .............q..
00 02 00 01 00 0B 01 01 00 04 00 0B 01 02 01 07 ................
A0 00 00 00 62 01 01 03 00 10 01 0C 6D 79 61 70 ....b.......myap
70 6C 65 74 2E 61 70 70 00 08 06 00 0E 00 00 00 plet.app........
80 03 00 FF 00 07 01 00 00 00 1C 07 00 7F 00 01 ................
10 18 8C 00 03 7A 05 30 8F 00 09 3D 8C 00 06 18 .....z.0...=....
1D 04 41 18 1D 25 8B 00 02 7A 02 23 18 8B 00 01 ..A..%...z.#....
60 03 7A 19 8B 00 05 2D 1A 03 25 11 00 FF 53 5B `.z....-..%...S[
32 1A 04 25 11 00 FF 53 5B 29 04 1F 10 80 6A 08 2..%...S[)....j.
11 6E 00 8D 00 00 16 04 73 00 10 FF 80 FF 80 00 .n......s.......
09 18 19 8C 00 07 70 08 11 6D 00 8D 00 00 7A 05 ......p..m....z.
22 19 8B 00 05 2D 7B 00 0A 92 32 7B 00 0A 03 00 "....-{...2{....
(779869 usec)
<= 6A 80 j.
Status: Wrong data
jcshell: Error code: 6a80 (Wrong data)
jcshell: Wrong response APDU: 6A80
Unexpected error; aborting execution**
can anyone tell me what is wrong and it is help to give me some reference!
Try with -b 230 instead. -b 250 could work if the Global Platform channel was fully plain, but if it contains a 8 byte MAC over the command data then you would get a total command data size of 250 + 8 = 258, which is over the maximum of 255 bytes that is supported.
Note that 6A80 wrong data can mean a whole lot of things. You can get the same message if you have compiled/converted against the wrong target platform, for instance. ISO 7816-4 status words are not very helpful in that regard. They may show some syntax errors, but normally semantic errors are shoe-horned into these syntax errors as well.

is there any actionscript bytecode debugger?

is there any known tool for debugging action script bytecode
just like debugging x86 binary code with IDA or olly debugger??
I have no source code. and I want to debug the ABC bytecode line by line.
SWFWire does not support this, neither FireBug.
I want to debug such ActionScript bytecode.
push "a"
96 03 00 00 01 00
getVariable
1C
push 248
96 05 00 07 F8 00 00 00
equals
0E
not
12
if true goto #159
9D 02 00 1D 00
push "a"
96 03 00 00 01 00
push "a"
96 03 00 00 01 00
getVariable
1C
push 476
96 05 00 07 DC 01 00 00
add
0A
setVariable
1D
getVariable
1C
jump #20
99 02 00 E0 FD
I want to set a breakpoint somewhere I want and follow the execution path
line by line.
I've googled for a while and there is no software which supports this.
thank you in advance.

Resources