Unfortunately I'm not too familiar with Wireshark and in our recent homework we are supposed to create a pcap file which includes a specific number. In order to create that pcap file we are supposed to use the search function of Wireshark to find by string in packet bytes and export the result with the specified number in either the protocol header or the payload. How am I supposed to go about this?
Well, this was way easier than I thought. All I needed to do was to create a connection to a FTP server, listen to that connection in Wireshark and then transfer a textfile with the number in it/named after it, in plain FTP in ASCII mode.
Related
I'm working with Scapy to parse a set of .pcap files. I would like to understand what kind of payload those packets are carrying. If I have for example a pcap file with a lot of UDP packets which payloads has the same starting bytes I don't know what kind of encoding was used, and the first values keep repeating in other packets. Is there any program or python library that could allow me to figure out or try to guess what kind of encoding was used (if for example is an RTP payload or MPEG one and so on)?
UPDATE
I was able to use nDPI on those pcap files and it gave me satisfying results for all the flows except for a set of them that it was not able to recognize. I'm going to share with you the first part of the hex representation of the data:
f1d00404d1002d7c484830320000020080073804610d00007b09040000000000010f000000000000000000000000000000000000000000000000000121e002a22e537fcccb815afafce2361b
The first part f1d004 does not change between previous and successive packets. I have already tried to decode them with different protocols using wireshark's feature "Decode as". I have tried with RTP,RTCP,RTSP,JSON,MPEG. If can be useful, this is the capture related to a camera, that's why I tried the previous protocols.
For example, I have text log with sip messages.
I want to filter these messages such as I can to do this in wireshark display filter, for examples with next filter:
sip.Method ne REGISTER || sip.CSeq.method ne REGISTER
In output I want to make file without messages, that not accepted by filter.
Is it possible?
Wireshark is normally used with PCAP files but it can open a plethora of other formats. The section 5.2 of the manual has a list of some 30 different formats, notably ppd logs, juniper netscreen and apple packet logger. Just open the file File > Open.
Then you type your filter (you can use the keyword not in filters) and Apply the filter. Only the packets matched will be displayed. Now you shall save it with File > Export Specified Packets. In the dialog shown you shall click on Displayed and save the file as one of the several format available (although you should really be using the PCAP format for packets, it is widely supported).
A lot depends on the format of your log file. If you have the bytes from the UDP messages under SIP you likley used some tool to assemble this log. If the log has no info about the actual raw packets, you might as well use a simple grep.
So I am wondering how can we utilize Wireshark to see if a users has downloaded a txt file over the internet.
I tried this while running wireshark:
https://code.google.com/p/androidnetworktester/downloads/detail?name=1mb.txt
I followed the HTTP stream, and can see the URL and a bunch, but in the PCAP packet body, I can't find the 1mb.txt file anywhere. Just curious, if we are doing forensics works, how can we prove the person really downloaded this using this wireshark information? Is it because it's using SSL that all the text in the PCAP is scattered with random code?
Thanks a bunch
if we are doing forensics works, how can we prove the person really downloaded this using this wireshark information
You can't really prove it from the packet capture unless you are able to decode the content. In most cases this is not possible, but if you have access to the private key of the site (you usually don't because it is private) and if RSA key exchange was used then you can decode the traffic after capture.
What you can get from the packet capture is the target host of the request, but not the exact URL or even the content. But if the length of the packet capture matches about the length of the content (there is some overhead in transport) and if you know that this is the only file at the server of this size than you might have at least an indicator that the user might have downloaded this file. But is probably not enough as a real prove.
For more prove you might then have a look at this history of the browser.
Suppose I want to transfer just a portion of a file over FTP - is it possible using a standard FTP protocol?
In HTTP I could use a Range header in the request to specify the data range of the remote resource. If it's a 1mb file, I could ask for the bytes from 600k to 700k.
Is there anything like that in FTP? I am reading the FTP RFC, don't see anything, but want to make sure I'm not missing anything.
There's a Restart command in FTP - would that work?
Addendum
After getting Brian Bondy's answer below, I wrote a read-only Stream class that wraps FTP. It supports Seek() and Read() operations on a resource that is read via FTP, based on the REST verb.
Find it at http://cheeso.members.winisp.net/srcview.aspx?dir=streams&file=FtpReadStream.cs
It's pretty slow to Seek(), because setting up the data socket takes a long time. Best results come when you wrap that stream in a BufferedStream.
Yes you can use the REST command.
REST sets the point at which a subsequent file transfer should start. It is used usually for restarting interrupted transfers. The command must come right before a RETR or STOR and so come after a PORT or PASV.
From FTP's RFC 959:
RESTART (REST) The argument field
represents the server marker at which
file transfer is to be restarted. This
command does not cause file transfer
but skips over the file to the
specified data checkpoint. This
command shall be immediately followed
by the appropriate FTP service command
which shall cause file transfer to
resume.
Read more:
http://www.faqs.org/rfcs/rfc959.html#ixzz0jZp8azux
You should check out how GridFTP does parallel transfers. That's using the sort of techniques that you want (and might actually be code that it is better to borrow rather than implementing from scratch yourself).
I am writing an application in C, using libpcap. My program listens for new packets and parses them
according to a grammar. The payload actually is XML.
Sometimes one packet is not enough for an XML file, so the XML buffer is splitted into separate packets.
I want to add code logic in order to handle these cases. However I don't know in advance that a packet does not contain the whole data. How do I know that a packet has more data that will be send next? How to i recognize that a new packet contains the rest of the data?
Do I have to use the TH_FIN flag? Could you please explain it to me?
There's nothing in TCP that defines packets, that's up to the higher layers to define if they need to - TCP is just a stream.
If this is raw XML over a TCP stream, you actually need to parse the xml - you'll know when you have a whole xml document when you've received the end of the document element.
If it's XML packaged over HTTP , you might be able to parse out the Content-Length: header which should contain the length of the body.
Note, reassembling a TCP stream from captured packets is a very hard problem, there's a lot of corner cases, e.g. you'd need to handle retransmission , out of sequence tcp segments and many more. http://libnids.sourceforge.net/ might help you.
As Anon say use a higher level stream library.
But even then you need to know the chunk side before starting to handle it, as you will read from the stream in block's of n bytes.
Thus you want to first send in binary the number of bytes to be sent, then send x bytes, and repeat, thus when you are receiving the chucks via select/read to know went you have all of chunk one to pass to the processor.
If you're using TCP, use a TCP library that gives you the data as a stream instead of trying to handle the packets yourself.
Stream is good. Another option is to store the incoming data in a buffer (eg char*) and search for application messaging framing characters or in the case of Xml, the root end tag. Once you've found a complete xml message at the front of the buffer, pull it out and process.
The XMPP instant messaging protocol, used by Jabber, has means to move XML chunks over a TCP stream. I don't know how exactly it is done myself, but RFC 3290 is the protocol definition. You should be able to work it out from that.