We began with no hint, and the file ‘cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2’. The command file tells us that it is compressed data.
$ file cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2 cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2: xz compressed data
We attempt an extraction using 7-Zip.
$ 7z e cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2 7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=utf8,Utf16=on,HugeFiles=on,8 CPUs) Processing archive: cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2 Extracting cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2~ Everything is Ok Size: 2063504 Compressed: 29312
What’s this new file? We try file again:
$ file cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2~ cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2~: data
No help this time, so we try strings:
$ strings cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2~ | head
Linux 3.2.0-4-686-pae
Dumpcap 1.8.2
eth0
Linux 3.2.0-4-686-pae
wikipedia
wikipedia
wikipedia
;{xUQ
wikipedia
4X @
So in the strings, we notice that this might be a file produced by dumpcap.
$ mv cloudfs-31c938df3531611b82fddf0685784a2b67373305ec689015f193a555b756beb2~ cloudFS.pcap
Yes, it’s a PCAP file. It opens in Wireshark 1.99; Wireshark tells us that it is specifically a PCAP-NG format file. In the packet listing, we see there are lots of pings, and we notice there is apparently a covert data channel (for those familiar with ICMP tunnels). We’d like to extract all of those ICMP → data → data fields for analysis, but with 3000+ packets, copy/pasting is not going to work.
Most PCAP analysis is done with BPF filters. Wireshark uses BPF for its display filters feature, and ngrep uses them at the command line to search for packets. But filtering in this way only results in a subset of the packets that match the filter. We don’t want that, we want only the ICMP data from those packets. Another approach might be to try using tcpxtract to detect file header signatures in a PCAP dump and extract them, but since it didn’t easily build from source on our system, we went with our own approach.
Enter dpkt for Python.
$ sudo pip install dpkt
Password:
Downloading/unpacking dpkt
Downloading dpkt-1.8.6.tar.gz (77Kb): 77Kb downloaded
Running setup.py egg_info for package dpkt
Installing collected packages: dpkt
Running setup.py install for dpkt
Successfully installed dpkt
Cleaning up...
Before working with dpkt though, we had to use Wireshark to ‘Save As…’ the PCAP-NG format capture to an old-format tcpdump-compatible PCAP file.
import dpkt
input=file("cloudfs.pcap", "rb")
# We are going to extract all ICMP payloads and concatenate them in one file,
# and see what happens:
output=open("output.bin", "w")
pcap=dpkt.pcap.Reader(input)
for ts, buf in pcap:
eth=dpkt.ethernet.Ethernet(buf)
if (eth.type != 2048): # 2048 is the code for IPv4
continue
ip=eth.data
icmp=ip.data
# The parsed packets in the dpkt.pcap.Reader contains two members: "ts" and "buf".
# The member "ts" is just the timestamp which lived in the packet when captured
# by Wireshark; it is the clock when captured this packet. The member "buf" holds
# the real packet data captured by capture tool, it's the raw traffic data.
if (ip.p==dpkt.ip.IP_PROTO_ICMP) and len(icmp.data.data)>0:
try:
#print icmp.data.data
output.write(icmp.data.data)
except:
print 'Error extracting ICMP payload data from this packet.'
continue
input.close()
output.close()extract.py
$ python extract.py
This results in an output.bin file containing all of the ICMP data data fields, concatenated, from both requests and replies. We probably only wanted the ICMP echo requests (echo replies are probably just copies of the requests), but this will do for now.
$ file output.bin output.bin: data
We suspect there might be some embedded files in the data, so let’s run another Python tool called binwalk, which we already have installed. If we were a Windows user, we might have tried an alternative, Luigi Auriemma’s signsearch.
$ binwalk -e output.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 37742 0x936E bzip2 compressed data, block size = 900k 38766 0x976E bzip2 compressed data, block size = 900k 39790 0x9B6E bzip2 compressed data, block size = 900k
[Output truncated here for brevity]
This is promising. We poke around and find that we’ve extracted some files. Let’s look.
$ rm _output.bin.extracted/*.bz2
$ ls _output.bin.extracted/
1476E 2876E 2E76E 81F32 BE33A C14AA C9042 E030A
$ file _output.bin.extracted/1476E
_output.bin.extracted/1476E: POSIX tar archive (GNU)
$ cd _output.bin.extracted/
$ tar -xvf 1476E
x key
x ping/ping.py
$ cat key
key{WhyWouldYouEverUseThis}
And that was the solution! The other file, ping/ping.py, was what was used to create the challenge.