A sample TCP hexadecimal Wireshark capture shown below,
0000 6c 6a 77 8d 48 cf 96 38 a7 7d 02 de 08 00 45 28
0010 00 34 56 92 40 00 28 06 fa e9 a2 7d 13 09 c0 a8
0020 8a f1 01 bb df 84 20 00 27 8e e3 6f a9 7f 80 10
0030 00 7c 25 f3 00 00 01 01 08 0a 54 48 f8 cc 61 38
0040 eb 22
How to get to know TCP or UDP protocol from Wireshark pcap hexadecimal view ?.
Save the hex data, as shown, into a text file and then run text2pcap file.txt file.pcap. You can then load the file.pcap file into Wireshark. Run text2pcap -h for more help or refer to the text2pcap man page for more details about that tool.
0000 6c 6a 77 8d 48 cf 96 38 a7 7d 02 de 08 00 45 28
0010 00 34 56 92 40 00 28 06 fa e9 a2 7d 13 09 c0 a8
8th Byte in the second line we have to check. In here it's 06. So protocol number 06 is TCP. Like wise we can get to know the protocol number from hexadecimal view.
Related
I'm working with APDU commands and SmartCard. APDU command that I am sending to SmartCard is:
8813040000004A0000015D79403B6900000000000000000000003032313133313638320000000000000000000000415344333231363534000000000000249F000203000000000084AA0100000000024490 (Data converted to an array of bytes and printed as a hexadecimal string).
Response code is 9000(OK) and response data is:
0000015D79403B6900000000000000000000003032313133313638320000000000000000000000000000000000000000000000000000249F000000004D0000004D59984310375BFA315BD7D067A49535281665DBF0E76287A9A1D8E223AED0E2908DAE61A03B91FD965271B7980807E826174F33D3E65614191734C7FCBE5CF16652301905CC9E9364A42CCE2C59533C60420097D1725EAEECF883B51E4F9E17FED1F7D63B93C1B4D70D6A12275EA40F09C1321223BB760581DBAF7CA720C1EBA7A4016D66B02BFB1CD1902C46458EE22528D05564992D77E0DF2E1FC63093D45BB8BC493076E694C24C1FC1A29982C82674D27DB641510E07ADE48A586FC3CB05E28734A7ED7D86CA3D9E66EBBAE7B78EEDC7E8A567DB39A37D0B92C110540C20290055E2F90FC674FB4E39A34A76A5310ABC1C9CF5E48D499473EC0EAADF305F667E27987370E744153D3533FB6D93CE9835363DF2398677A96FE4A5CC0DAEFB344391F7F2A17C42E6CBE9E36254945A38A0EBD4B1D0A2167A8DD1D8B593F6EEC5C92D866D1423EC3ED89893F123D1923A3AD3E1AEDA424232D0C9B3A60C9E179B02BDF2DAFD00B810F35E608322619EF9D9D90B2512E3216B0EC4D3D36CE66505A1457767DA5D5542BEF57B2BB15B12A9F19495C74A9633395ADE2FD4A1639E1A53334BCE88D51937A786F002EDEEB96BA524C60D2623390D76437EC46F99C13BFA91A44FB348F72DCF8C020EE0F73607A7AFB1B568D09C059BA2B4361B02D1C46B1D31369D58488118BA20BBB99C3593A0775F9FAA4BA9241C6F5F6F4C4C84
SmardCard is supposed to sign and return data with signature (Certificate). It should be a string that I need for later but when I try to convert it back to string all I'm getting is vC~ÄoÁ;ú¤O³H÷-Ïà÷6§¯±µhТ´6ÑÄk16XHº »¹5 w_ªK©$o_oLL kind of a string that I can't actually use. Am I doing something wrong or missing any steps in between? How am I supposed to get that string from that hex response? Do I need to reverse bytes maybe (tried)?
Thanks in advance!
You are converting the returned data into a WideString (default string type in modern Delphi versions) but the returned data is actually in AnsiString format.
And if you want to view the returned data in a similar fashion that most browsers show digital certificate key value just add an empty space after every two characters.
For this you can use code like this:
//AStr is of AnsiString type
for I := Length(AStr)div 2 downto 1 do
begin
Insert(' ',AStr,I*2+1);
end;
The returned result will then be:
00 00 01 5D 79 40 3B 69 00 00 00 00 00 00 00 00 00 00 00 30 32 31 31 33 31 36 38 32 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 24 9F 00 00 00 00 4D 00 00 00 4D 59 98 43 10 37 5B FA 31 5B D7 D0 67 A4 95 35 28 16 65 DB F0 E7 62 87 A9 A1 D8 E2 23 AE D0 E2 90 8D AE 61 A0 3B 91 FD 96 52 71 B7 98 08 07 E8 26 17 4F 33 D3 E6 56 14 19 17 34 C7 FC BE 5C F1 66 52 30 19 05 CC 9E 93 64 A4 2C CE 2C 59 53 3C 60 42 00 97 D1 72 5E AE EC F8 83 B5 1E 4F 9E 17 FE D1 F7 D6 3B 93 C1 B4 D7 0D 6A 12 27 5E A4 0F 09 C1 32 12 23 BB 76 05 81 DB AF 7C A7 20 C1 EB A7 A4 01 6D 66 B0 2B FB 1C D1 90 2C 46 45 8E E2 25 28 D0 55 64 99 2D 77 E0 DF 2E 1F C6 30 93 D4 5B B8 BC 49 30 76 E6 94 C2 4C 1F C1 A2 99 82 C8 26 74 D2 7D B6 41 51 0E 07 AD E4 8A 58 6F C3 CB 05 E2 87 34 A7 ED 7D 86 CA 3D 9E 66 EB BA E7 B7 8E ED C7 E8 A5 67 DB 39 A3 7D 0B 92 C1 10 54 0C 20 29 00 55 E2 F9 0F C6 74 FB 4E 39 A3 4A 76 A5 31 0A BC 1C 9C F5 E4 8D 49 94 73 EC 0E AA DF 30 5F 66 7E 27 98 73 70 E7 44 15 3D 35 33 FB 6D 93 CE 98 35 36 3D F2 39 86 77 A9 6F E4 A5 CC 0D AE FB 34 43 91 F7 F2 A1 7C 42 E6 CB E9 E3 62 54 94 5A 38 A0 EB D4 B1 D0 A2 16 7A 8D D1 D8 B5 93 F6 EE C5 C9 2D 86 6D 14 23 EC 3E D8 98 93 F1 23 D1 92 3A 3A D3 E1 AE DA 42 42 32 D0 C9 B3 A6 0C 9E 17 9B 02 BD F2 DA FD 00 B8 10 F3 5E 60 83 22 61 9E F9 D9 D9 0B 25 12 E3 21 6B 0E C4 D3 D3 6C E6 65 05 A1 45 77 67 DA 5D 55 42 BE F5 7B 2B B1 5B 12 A9 F1 94 95 C7 4A 96 33 39 5A DE 2F D4 A1 63 9E 1A 53 33 4B CE 88 D5 19 37 A7 86 F0 02 ED EE B9 6B A5 24 C6 0D 26 23 39 0D 76 43 7E C4 6F 99 C1 3B FA 91 A4 4F B3 48 F7 2D CF 8C 02 0E E0 F7 36 07 A7 AF B1 B5 68 D0 9C 05 9B A2 B4 36 1B 02 D1 C4 6B 1D 31 36 9D 58 48 81 18 BA 20 BB B9 9C 35 93 A0 77 5F 9F AA 4B A9 24 1C 6F 5F 6F 4C 4C 84
Is this the result you are looking for?
We noticed our Jenkins build logs were being filled with 10 times more content than we expected. This greatly increases the amount of logs that slaves have to send back to the master, which in turn makes all builds take longer, which in turn makes builds fail with spurious timeouts.
On investigation, we find the lines all have a huge URL prepended.
ha:////{320 bytes of base64 junk} Log message
ha:////{320 bytes of base64 junk} [blank line]
ha:////{320 bytes of base64 junk} Next log message
I tried decoding the base64, but it doesn't produce any structure which I'm familiar with.
I didn't want to post ours because someone who knows how to decode it might find private info in there, but I tried searching for some of the content we were seeing, and noticed that someone else had posted the same sort of thing to pastebin:
https://pastebin.com/LM7mht8W
Taking one of those URLs:
ha:////4HTWhKVov8LrT80csqfIVuXrtfeJTJod3fz9PpkDu0UAAAAAzh+LCAAAAAAAAP9b85aBtbiIQSOjNKU4P0+vIKc0PTOvWK8kMze1uCQxtyC1SC8ExvbLL0llgABGJgYmLwaB3MycnMzi4My85FTXgvzkDB8G3tScxILi1BRfsEwJg4BPVmJZon5OYl66vk9+Xrp1RRGDFNSy5Py84vycVD1nCI1qPENFAZCOr07/fwfoPj6QKXogU/TApnQ/mXCmX/k+EwOjFwNrWWJOaSrQXAGEIr/S3KTUorY1U2W5pzzohprGwMDU+O4jAJgnACXyAAAA
And decoding it (including the ////):
00000000 ff ff ff e0 74 d6 84 a5 68 bf c2 eb 4f cd 1c b2 |....t...h...O...|
00000010 a7 c8 56 e5 eb b5 f7 89 4c 9a 1d dd fc fd 3e 99 |..V.....L.....>.|
00000020 03 bb 45 00 00 00 00 ce 1f 8b 08 00 00 00 00 00 |..E.............|
00000030 00 ff 5b f3 96 81 b5 b8 88 41 23 a3 34 a5 38 3f |..[......A#.4.8?|
00000040 4f af 20 a7 34 3d 33 af 58 af 24 33 37 b5 b8 24 |O. .4=3.X.$37..$|
00000050 31 b7 20 b5 48 2f 04 c6 f6 cb 2f 49 65 80 00 46 |1. .H/..../Ie..F|
00000060 26 06 26 2f 06 81 dc cc 9c 9c cc e2 e0 cc bc e4 |&.&/............|
00000070 54 d7 82 fc e4 0c 1f 06 de d4 9c c4 82 e2 d4 14 |T...............|
00000080 5f b0 4c 09 83 80 4f 56 62 59 a2 7e 4e 62 5e ba |_.L...OVbY.~Nb^.|
00000090 be 4f 7e 5e ba 75 45 11 83 14 d4 b2 e4 fc bc e2 |.O~^.uE.........|
000000a0 fc 9c 54 3d 67 08 8d 6a 3c 43 45 01 90 8e af 4e |..T=g..j<CE....N|
000000b0 ff 7f 07 e8 3e 3e 90 29 7a 20 53 f4 c0 a6 74 3f |....>>.)z S...t?|
000000c0 99 70 a6 5f f9 3e 13 03 a3 17 03 6b 59 62 4e 69 |.p._.>.....kYbNi|
000000d0 2a d0 5c 01 84 22 bf d2 dc a4 d4 a2 b6 35 53 65 |*.\..".......5Se|
000000e0 b9 a7 3c e8 86 9a c6 c0 c0 d4 f8 ee 23 00 98 27 |..<.........#..'|
000000f0 00 25 f2 00 00 00 |.%....|
000000f6
Noticing that 1f 8b 08 looked like a gzip header, I tried cutting the file at that point and decompressed it. This gave:
00000000 ac ed 00 05 73 72 00 28 68 75 64 73 6f 6e 2e 70 |....sr.(hudson.p|
00000010 6c 75 67 69 6e 73 2e 74 69 6d 65 73 74 61 6d 70 |lugins.timestamp|
00000020 65 72 2e 54 69 6d 65 73 74 61 6d 70 4e 6f 74 65 |er.TimestampNote|
00000030 00 00 00 00 00 00 00 01 02 00 02 4a 00 10 6d 69 |...........J..mi|
00000040 6c 6c 69 73 53 69 6e 63 65 45 70 6f 63 68 4c 00 |llisSinceEpochL.|
00000050 0d 65 6c 61 70 73 65 64 4d 69 6c 6c 69 73 74 00 |.elapsedMillist.|
00000060 10 4c 6a 61 76 61 2f 6c 61 6e 67 2f 4c 6f 6e 67 |.Ljava/lang/Long|
00000070 3b 78 72 00 1a 68 75 64 73 6f 6e 2e 63 6f 6e 73 |;xr..hudson.cons|
00000080 6f 6c 65 2e 43 6f 6e 73 6f 6c 65 4e 6f 74 65 00 |ole.ConsoleNote.|
00000090 00 00 00 00 00 00 01 02 00 00 78 70 00 00 01 5f |..........xp..._|
000000a0 7b 67 ff dc 73 72 00 0e 6a 61 76 61 2e 6c 61 6e |{g..sr..java.lan|
000000b0 67 2e 4c 6f 6e 67 3b 8b e4 90 cc 8f 23 df 02 00 |g.Long;.....#...|
000000c0 01 4a 00 05 76 61 6c 75 65 78 72 00 10 6a 61 76 |.J..valuexr..jav|
000000d0 61 2e 6c 61 6e 67 2e 4e 75 6d 62 65 72 86 ac 95 |a.lang.Number...|
000000e0 1d 0b 94 e0 8b 02 00 00 78 70 00 00 00 00 02 81 |........xp......|
000000f0 ee f1 |..|
000000f2
So it kind of seems like the timestamper plugin is somehow implicated in this nonsense, but when I go and read their code, I don't see anything about this stuff.
Which bit of Jenkins is actually doing this, and is there a way to avoid it?
Good detective work, #Trejkaz. Disabling the timestamper plugin did NOT fix things for me (I left the plugin installed; perhaps I should have removed it altogether or restarted Jenkins one more time to be sure).
My best answer (the one I'm using in practice) gets rid of all the escape sequences in the console AND in the context of this question, removes all of the 'ha:////' URLs as well so I get pretty close to unadorned, complete ASCII text in my processed console log. It's worth mentioning that our site's automation culture is to allow Jenkins builds to expire except those marked for keeping, so my workflow is to produce a postprocessed console log artifact to "keep" and not to archive the original log. It's not to create a smaller log in the first place, which I saw as more time- and resource-consuming for no discernible benefit.
Presuming the raw Jenkins console log lives in console-log.txt, it's:
ansi2txt < console-log.txt | col -b | sed 's;ha:////[[:print:]]*AAAA[=]*;;g'
This eliminates escape sequences meant to provide terminal display sugar without requiring build and installation of tool packages not found in any repo (in Ubuntu ansi2txt comes from colorized-logs and col comes from bsdmainutils), removes the mysterious 'ha:////' URLs regardless of their source, and turns a raw console log that looks like:
Started by user ESC[8mha:////4AqgegZw7qQ8DI1+KvWPDM7IJMwAv+ifWfXHqdHJJeCwAAAAlx+
LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihh
k0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUN
odHsLgAzWEgZu/dLi1CL9xJTczDwAj6GcLcAAAAA=ESC[0mAdmin
Checking out git ssh://git#github.com/SlipChip/PHX-Inst-App-SW.git into /var/tmp
/meta-talis/workspace/Firmware-Inst-App-SW#script to read Jenkinsfile
...
Commit message: "Add Jenkins console log as artifact console-log.txt."
> git rev-list --no-walk b70ac257fc5c87aa4a1fe55661b3523842f43412 # timeout=10
Running in Durability level: MAX_SURVIVABILITY
ESC[8mha:////4Ke8FKbo31T+wvpwDtO0m31cw6Dr9enqafGE6M9os2Y7AAAAoh+LCAAAAAAAAP9tjTEOwjAQBM8BClpKHuFItIiK1krDC0x8GCfWnbEdkooX8TX+gCESFVvtrLSa5wtWKcKBo5UdUu8otU4GP9jS5Mixv3geZcdn2TIl9igbHBs2eJyx4YwwR1SwULBGaj0nRzbDRnX6rmuvydanHMu2V1A5c4MHCFXMWcf8hSnC9jqYxPTz/BXAFEIGsfuclm8zQVqFvQAAAA==ESC[0m[Pipeline] Start of Pipeline
ESC[8mha:////4IgCbJC4forU2exyZEKrDUTKRV7HgFuwndWEBhDMO34wAAAApR+LCAAAAAAAAP9tjTEOwjAUQ3+KOrAycohUghExsUZZOEFIQkgb/d8mKe3EibgadyBQiQlLlmxL1nu+oE4RjhQdby12HpP2vA+jK4lPFLtroIm3dOGaMFGwXNpJkrGnpUrKFhaxClYC1hZ1oOTRZdiIVt1VExS65pxj2Q4CKm8GeAAThZxVzN8yR9jeRpMIf5y/AJj7DGxXvP/86jduZBmjwAAAAA==ESC[0m[Pipeline] node
...
into the considerably more palatable:
Started by user Admin
Checking out git ssh://git#github.com/SlipChip/PHX-Inst-App-SW.git into /var/tmp/meta-talis/workspace/Firmware-Inst-App-SW#script to read Jenkinsfile
...
Commit message: "Add Jenkins console log as artifact console-log.txt."
> git rev-list --no-walk b70ac257fc5c87aa4a1fe55661b3523842f43412 # timeout=10
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
which is the same as what I see in the Jenkins web interface when browsing the console log.
I hope this answer helps you in a practical sense (i.e. rather than making an O(n) walkthrough of all of your plugins searching for the 'ha:////' culprit).
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).
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.
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.