How to extract raw data from TCP packets using Wireshark - networking

Completely new to Wireshark and wondering how to extract the data from the TCP packets which I receive on wireshark.
I am currently using a raspberry pi with grove sensors and getting the values of pressure and temperature. I am sending these values to a server in cloud and it is working. I am using wireshark to trace the packets.
Now I want to extract the data (i.e the pressure value and temperature value) from the packets and store them in a file for further implementation. Is there a way to do it? If yes, then can anyone please explain? It will be helpful.
Thanks.

Most convenient way is saving whole TCP stream into file. Right click on any TCP packet of desired stream, choose "Follow -> TCP stream" and you will see window for managing stream data. You can choose, which data to save (one-direction, or both), which format will be used for output and so on. Check pict below:
The other way is saving data from any packet individually. Since you aren't interested in whole packet, you can select only payload part. Check picture below, where I selected HTTP part of the packet (I marked field with red arrow for clearance). In your case, it will be some field with raw data. Once highlighted the right field, right click on it, choose "copy" and select desired format. Data will be placed into buffer, so you need to paste it into some application. If raw binary is chosen for format, you need application capable of pasting binary data. I use frhed for this task.

Related

How to reverse engineer buffer data received from a serial port

I am trying to decode some buffer data that I have received from a serial port. To me the data seems to make no sense - I am not even sure if I am splitting the messages up correctly.
The data comes from a concrete crusher and while the concrete is being crushed we get an almost continuous stream of data. I get about 10 "messages" a second (but this might be multiple messages included in each message) and I am splitting them up by waiting 50 ms after each message. The data looks like this:
[0,0,0,224,0,224,0,0,224,0,0,224,0,0,0,0,0,0,0,224,0,0,0,0,224,0,0,0,224,0,224,0,0,224,0,0,0,224,0,0,0,0,0,0,0,224,0,0,0,224,0,0,224,0,0,224,0,224,0,0,224,0,0,0,0,0,0,0,0,224,224,0]
[0,0,0,224,0,224,0,0,224,0,0,224,0,0,0,0,0,0,0,224,0,0,0,0,0,0,0,224,0,224,0,0,0,0,0,0,0,0,0,0,0,0,0,224,0,0,0,224,0,0,224,0,0,224,0,0,0,0,224,0,0,0,0,0,0,0,0,224,224,0]
[0,0,0,224,0,224,0,0,224,0,0,224,0,0,0,0,0,0,0,224,0,224,0,0,224,0,0,0,224,0,224,224,224,0,0,0,224,0,0,0,0,0,0,0,0,224,0,0,0,224,0,224,224,224,0,0,224,0,0,0,224,0,0,0,224,0,0,0,0,0,224,224,0]
as you can see there are no values at all other than 0 and 224...
The last message is:
[0,0,0,0,0,0,224,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,224,0,0,224,0,0,0,0,0,0,0,0,0,0,0,0,0,0,224,0,0,0,0,224,224,0,0,224,0,0,224,0,0,0,224,0,0,0,0,0,0,0,0,0,0,0,224,0,0,0,0,0,224,0,224,224,0,0,224,0,0,0,224,224,0]
the value displayed on the machine was 427.681kN but I can't see any way that this data can produce that.
Each message ends with 224,224,0 so I am wondering if that is the split sequence?
I am getting this data with node-red and this is the format that I can copy it from the debug panel in.
I am very lost so any guidance or directions that I can look in would be much appreciated.

How to manage multi-packet sends with gsocket?

I got a question regarding tcp/ip socket networking. Basically it is there: are there any parts of tcp/ip that I can leverage to help manage multi-packet sends. For example, I want to send a 100 mb binary file which would take something like 70-80 tcp packets. Meanwhile I have a relatively fast polling receive on the other side. Would my receive have to receive each packet it individually and "stitch" together the data packet by packet, looking for some size to be reached(it can look at the opcode and determine size) or is there some way to tell tcp to say "hey I'm sending 100 mb here, let them know when it is finished."
I am using glib's low level socket library (gsocket).
When using a binary encoding like, say protocol buffers, you would wrap the actual payload by inserting a header that would include the information necessary to decode the payload on the other end.
Say appending 8 bytes where the first 4 signify the type of the encoded message and the second four indicate the length of the entire message.
On the receiving side you are then reading this header, that's part of the payload, to determine the message type and length of the message. This lets you combine multiple messages in one payload or split messages across packets and reliably recombine them.

64/66b encoding

There are a few things I don't understand about 64/66bit encoding, and failed to find the answers to on the web. Any help/links would be greatly appreciated:
i) how is the start of a frame recognised? I don't think it can be by the initial 10/01 bits called the preamble on wikipedia because you cannot tell them apart (if an idle link is 0, then 0000 10 and 000 01 0 look rather similar). I expect the end of a frame is indicated by a control word, with the rest of the bits perhaps used for the CRC?
ii) how do the scramblers synchronise, and how do they avoid scrambling the same packet the same way? Or to put this another way, why is not possible for a malicious user to induce substantial packet loss by carefully choosing a bad message?
iii) this might have been answered in ii), but if a packet is sent to a switch, and then onto another host, is it scrambled the same way both times?
Once again, many thanks in advance
Layers
First of all the OSI model needs to be clear.
The ethernet frame is a data link layer, while the 64b/66b encoding is part of the physical layer (More precisely the PCS of the physical layer)
The physical layer doesn't know anything about the start of a frame. It sees only data. (The start of an ethernet frame are data bytes which contain the preamble.)
64b/66b encoding
Now let's assume that the link is up and running.
In this case the idle link is not full of '0'-s. (In that case the link wouldn't be self-synchronous) Idle messages (idle characters and/or synchronization blocks ie control information) are sent over the idle link. (The control information encoded with 0b10 preamble) (This is why the emitted spectrum and power dissipation don't depend on if the link is in idle state or not)
So a start of a new frame acts like following:
The link sends idle information. (with 0b10 preamble)
Upper layer (data link layer) sends the frame (in 64bit chunks of data) to physical layer.
The physical layer sends the data (with 0b01 preamble) over the link.
(Note that physical layer frequently inserts control (sync) symbols into the raw frame even during a data burst)
Synchronization
Before data transmission 64b/66b encoded lane must be initialized. This initialization includes the lane initialization which the block synchronization. Xilinx's Aurora's specification (P34) is an example of link initialization.
Briefly receiver tries to match the sync character in different bit-position, and when it match multiple times it reports link-up.
Note, that the 64b/66b encoding uses self-synchronous scrambler. This is why the scrambler (itself) doesn't need to know anything about where we are in the data stream. If you run a self-synchronous (de-)scrambler long enough, it produces the decoded bit stream.
Maliciousness
Note, that 64b/66b encoding is not an encryption. This scrambling won't protect you from eavesdropping/tamper. (Encryption should placed at higher level of the OSI model)
Same packet multiple times
Because the scrambler is in different state/seed when you sending the same packet second time, the two encoded packet will differ. (Theoretically we can creates packets, which sets back the shift register of the scramble, but we need to consider the control symbols, so practically this is impossible.)

How can I use the Packet Structure from an RFC and apply it to my socket program?

Here's an example 'Packet Structure' image: http://freesoft.org/CIE/Course/Section3/7.htm
Lets say I had a small Python program that listened on X port and captured that packet and saved it to the variable 'data'.
How would I pull out the packet information from data? For example, say I wanted to read the 'version', is it just:
print data[0:4] ?
How would I get the Source IP Address?
I've been doing more socket coding lately and have ran into quite a few of these 'packet structure' images. I'm yet to figure out how to apply them to my code :/
Note that your example shows an IP header - if you are simply using sockets, you will not see this information (its already been digested by the system IP and TCP stacks).
If you want to capture raw data, look into using libpcap, which will allow raw packets. You can also use tcpdump to produce a file with raw packets.
As for structures, you can read the first 4 bytes if your data was a string with your command. You would likely want to encode the string as "hex" (or integers for the normal representation) or you will see "garbage" characters instead.
For more powerful unpacking, use the struct module which comes with python.

Is there a way to save a reassembled TCP in Wireshark

I am trying so sniff a multi-part POST request using Wireshark. When viewing the capture I can select "Reassembled TCP" which looks to contain the header and all the data in the transmission. However I can't seem to select the entire thing to save it. If I go back to the frame view i can select the frame, which usually selects the entire transmission, but it will only end up saving the post data.
How can I save the entire Reassembled TCP?
Use the "Follow TCP stream" option:
http://linuxonly.nl/docs/38/117_Wireshark.html
Ok, really simple one. There is a heading after "Transmission Control Protocol (TCP)" and "Hypertext Transfer Protocol" called "[Reassembled TCP Segments]" Selecting that allows you to save the Reassembled TCP Segments. Note to self to widen my focus a little.
Works for HTTP, DICOM or SMB streams only but there is a "Export Objects" option now.
You can access it from File -> Export Objects -> HTTP.

Resources