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
Linux 3.2.0-4-686-pae
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
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")


for ts, buf in pcap:
if (eth.type != 2048): # 2048 is the code for IPv4


# 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:
        #print icmp.data.data
        print 'Error extracting ICMP payload data from this packet.'



$ 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 

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

And that was the solution!  The other file, ping/ping.py, was what was used to create the challenge.