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:
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
hasherezade's 1001 nights 
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.