Flare-On 8 – Task 6

Flare-On is an annual “reverse engineering marathon” organized by Mandiant (formerly by FireEye). You can see more information here. It is a Capture-The-Flag type of a contest, where you are given a set of crackmes with growing difficulity. This year we were provided with 10 tasks. I finished as 125. In this series of writeups I will present my solutions to the selected challenges, and guide you through the task, all the way till the final flag.


The description of the challenge 6:

Download: 06_PetTheKitty.7z (password: flare)

In this task we are given a PCAP file.

I opened it in a Wireshark and followed the TCP steams.

There are two streams, first of them consists of a request, followed by a longer response, containing a PNG:

Another contains many shorter packets, requests and responses:

We can see the keyword “ME0W”, but also “PA30” repeating…

PA30 is a patch format, introduced by Windows Vista, and called Intra-Package Delta (IPD). More information about it we can find in the following blog. We will find there also a python script delta_patch.py that can be used for applying the patches.

First I extracted the components from the first stream. As we saw at the first sight, the response contains a PNG. At the end of the PNG we can see an ASCII art:

A PA30 patch follows after.

In order to separate them correctly, we need to understand the headers of the “ME0W” packet:

4d 45 30 57  d0 24 0a 00  d0 24 0a 00 | ME0W .$.. .$..

The header contains the magic number “ME0W” followed by two DWORDs, denoting the size of the data repeated twice, and then the data buffer.

After extracting the data buffers, we get two elements listed below (along with their MD5 hashes):

2c691262493ceaaa5de974adab36ed69  cat.png
440c49962f81e3d828ddcc3354c879c9  patch.p30

The PNG:

The image looks valid and looks very innocent, but after applying the patch it will change completely…

I guessed that the patch from this stream must be used along with the given PNG. I applied it with the help of the following command:

delta_patch.py -i cat.png -o out.bin patch.p30

The output turned out to be a DLL:

By looking closer at the code we realize that this is the “malware” responsible for generating the further communication. It connects to the URL that was referenced in the PCAP:

In order to understand how to decode the rest of the PCAP, we need to check how the the received data is processed. The relevant fragment of the code:

It turns out to be fairly simple. First the data is decoded by being applied as a patch on an empty buffer. Then, the output is XORed with a hardcoded key “meoow”.

Applying of the patch is done by the same function as was used before (to decode the DLL from the picture) – ApplyDeltaB:

Now we can decrypt the rest of the traffic following this pattern. First we need to apply the patch on a buffer filled with 0s, and then XOR the output with the key.

We can see the decrypted traffic contains some exfiltrated data from a victim machine. Among this data there is a listing containing the flag:

1m_H3rE_Liv3_1m_n0t_a_C4t@flare-on.com

About hasherezade

Programmer and researcher, interested in InfoSec.
This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

1 Response to Flare-On 8 – Task 6

  1. the author says:

    This is out of my league, to say the least. But the bit on self-modifying code reminds me of tracing a Z80 program In the late 1970s that read in a floppy disk sector just ahead of itself, such that the code picked up at the boundary. Tricky for the time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s