mirror of https://github.com/dirtbags/moth.git
93 lines
3.2 KiB
Markdown
93 lines
3.2 KiB
Markdown
PCAP files
|
||
==========
|
||
|
||
When packets are captured off of a network, they are typically written
|
||
to PCAP (Packet CAPture) files. These files contain some information
|
||
about the device used to do the capture, and a list of packets that were
|
||
captured along with what precise time they were captured.
|
||
|
||
PCAP files are invaluable in network reverse engineering. Without
|
||
packet capture, all you can usually do is speculate. It's like the
|
||
difference between looking at clues at the scene of the crime, and
|
||
having a videotape from cameras providing video at every angle.
|
||
|
||
With full packet capture (capture of all inbound and outbound traffic to
|
||
a network), it is sometimes even possible to write *protocol decoders*,
|
||
which can be used to show exactly what information went back and forth,
|
||
at what times. This ability is of extremely high value in any sort of
|
||
forensic investigation.
|
||
|
||
|
||
Wireshark
|
||
---------
|
||
|
||
Wireshark is a graphical PCAP viewing tool for Unix, Windows, or MacOS.
|
||
It features built-in protocol decoders for many standard protocols,
|
||
powerful filters for examining captures, statistical tools, and much
|
||
more. It is capable of capturing packets on its own, and reading and
|
||
writing PCAP files.
|
||
|
||
Let’s load up Wireshark.
|
||
|
||
![Wireshark’s Startup](ws-start.png)
|
||
|
||
We can now open [an example pcap file](example1.pcap) with “File ->
|
||
Open”. After loading, we will see Wireshark’s 3-panel display:
|
||
|
||
![Loaded file](ws-opened.png)
|
||
|
||
The top panel shows a list of frames (packets). The middle panel shows
|
||
information about the currently-selected frame, and the bottom panel
|
||
shows a hex dump of the frame. We can click on one of the white
|
||
triangles to expand information about an aspect of the frame, and by
|
||
highlighting any line in the second panel, the third panel will
|
||
highlight that part of the hex dump:
|
||
|
||
![Examining a frame](ws-examine.png)
|
||
|
||
We can also right-click on a frame in the top panel for a drop-down menu
|
||
of options. We will focus on the “follow TCP stream” option.
|
||
|
||
![Follow a stream](ws-follow.png)
|
||
|
||
This opens up a new window in which both sides of the TCP stream are
|
||
reassembled from the individual frames:
|
||
|
||
![Followed stream](ws-stream.png)
|
||
|
||
This text can be copied and pasted into a text editor or a binary
|
||
editor as a means to quickly extract payloads like attachments or
|
||
transferred files.
|
||
|
||
|
||
Wireshark’s weakness, and `tcpflow`
|
||
-----------------------------------
|
||
|
||
Wireshark’s TCP reassembly routines have bugs. Sometimes, stream
|
||
reassembly is incomplete, even though all the frames are present.
|
||
|
||
Under Unix (or Cygwin in Windows), a program called `tcpflow` can do
|
||
much more reliable--not to mention quick--reassembly of TCP sessions:
|
||
|
||
$ ls
|
||
example1.pcap
|
||
$ tcpflow -r example1.pcap
|
||
$ ls
|
||
106.086.094.175.06063-239.201.176.004.65167
|
||
239.201.176.004.65167-106.086.094.175.06063
|
||
example1.pcap
|
||
$
|
||
|
||
`tcpflow` reassembles each side of a connection, which is usually all
|
||
you want anyway. This has reassembled into the “106.86.94.175 side” and
|
||
the “239.201.176.4 side”; each file contains what the left IP sent to
|
||
the right IP.
|
||
|
||
|
||
Question
|
||
========
|
||
|
||
Use Wireshark or `tcpflow` to extract the TCP stream from [this packet
|
||
capture](key.pcap). Then, using techniques from previous sections,
|
||
decode the payload. View it to find the key for this page.
|