Rating:
# Emotional Roller Coaster (Misc 350)
## Problem
Are you a good listener? Expect us!
_This time you're the target. :-)_
## Solution
Credit: [@emedvedev](https://github.com/emedvedev)
It's a great forensics challenge and also a lot of fun. Although not particuarly hard, it's very creative and nicely layered.  Let's begin!
#### 1. The query
"A good listener" and "this time you're the target" in the description, along with the fact that nothing else is given, points us in the direction of traffic capture: somebody will probably try to attack your machine or send requests to it.  DCTF has a VPN network for challenges, so it's safe to assume that this one will involve our VPN connection. Let's fire up Wireshark, capture all VPN traffic and see whatever it is we're the "target" of. 
Here it is. We really are good listeners, aren't we? 
#### 2. The response
The request is an MX (mail) query to a DNS server: it asks our machine to resolve `dctfu2126.1337.def`. Let's fire up a DNS server and actually resolve the query; DNSmasq does this job quite well and it's incredibly easy to set up. 
```
$ dnsmasq --address=/dctfu2126.1337.def/10.20.8.95 --mx-host=dctfu2126.1337.def --mx-target=10.20.8.95
```
That's it, now your machine is a DNS server. 
#### 3. The message
Let's see what happens after we send the response:
Logically enough, since we answered that our machine is a mail server, we're seeing an SMTP request to port 25 now. Let's fire up a catch-all SMTP server, and capture whatever the message is.  I'm using `MockSMTP` on OS X (you have to start it with `sudo` to make it listen on port 25), but if you're running another OS, I bet you can find a lot of software if you just google "mock SMTP" or "catch-all SMTP". Here we go:
"Almost there," they said. Don't trust the guys. 
#### 4. The attachment
Attached to the e-mail is a packet capture file, [ftps.pcap](ftps.pcap). Let's fire up Wireshark again:
Is it a bird? Is it a plane? It's an SMB session!  We'll use Wireshark's convenient SMB object extraction to see what's in there:
Now we have an archive, [emotions.zip](emotions.zip). Is the flag there? Well, not quite yet. 
#### 5. The emotions
We have 96 amazing animated emoticons in the archive, which is a reward good enough by itself, of course, because emoticons are just like glitter: they're awesome and everybody loves them. I even took the liberty of sprinkling some across this whole write-up , as you might have noticed (or not—I was being very subtle).
There's a `flag.gif` in the archive, so let's take a look:
Aside from being awesome, the image is completely uneventful. Opening it in hex editor doesn't show much except it's an ordinary gif (duh ) with metadata `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA`.
This metadata bit looks interesting, so we'll take a look at other files, too. Let's use `exiftool` on some random emoticons:
```
$ exiftool thumbsdown.gif
ExifTool Version Number : 10.00
File Name : thumbsdown.gif
Directory : .
File Size : 6.9 kB
File Modification Date/Time : 2015:10:03 03:11:14+06:00
File Access Date/Time : 2015:10:04 15:27:04+06:00
File Inode Change Date/Time : 2015:10:04 06:00:23+06:00
File Permissions : rwxrwxrwx
File Type : GIF
File Type Extension : gif
MIME Type : image/gif
GIF Version : 89a
Image Width : 28
Image Height : 18
Has Color Map : Yes
Color Resolution Depth : 6
Bits Per Pixel : 6
Background Color : 63
Animation Iterations : Infinite
XMP Toolkit : Image::ExifTool 9.46
Camera Model Name : zyy7mY2/Rx1LP5jYtGa3G2j8y9mM7w9i3eGf012vsdc3fcyqRr9w+8ZyGds4uMwAA
Frame Count : 20
Duration : 4.95 s
Image Size : 28x18
Megapixels : 0.000504
```
Notice the "Camera Model Name" field: if you're reading this, chances are you know Base64 when you see it. 
#### 6. The flag
Decode a few Base64 messages, and you'll see they all appear to be parts of some binary file.  Let's just concat all the emoticons into one big file and see what happens:
```
$ exiftool *.gif | grep Camera | cut -c 35- > misc350.base
$ cat misc350.base | base64 -D > misc350.bin
```
We're definitely on the right track with this: notice the `PK..` (`50 4B 01 02`): it's a clear indicator of a ZIP archive. However, the order in which we concatenated Base64 strings (it's the filename by default) is clearly wrong beause the file is scrambled. Hmmm, what might be the correct sorting method? 
Let's take a look at our decoded `misc350.base`: one line clearly stands out. Meet Billy:
Unlike all his emoticon friends with 65-byte Base64-encoded strings in their metadata, Billy only has 29 bytes (don't worry, Billy, size doesn't matter ), so this truncated string should be in the end of our file. Let's sort files and look for the sorting method where Billy comes last. 
After some trial-and-error the method turns out to be modification date: do `ls -tlr` and you'll see that `billy.gif` is the last one on the list. Now let's recreate the archive:
```
$ exiftool `ls -tr` | grep Camera | cut -c 35- | base64 -D > misc350.zip
```
And here's the flag, waiting patiently for you in `sol/flag`, wanting so desperately to be found:
```
DCTF{e4045481e906132b24c173c5ee52cd1e}
```
Congratulations! It was a great run.
