Flare-On 2015 #5

First we’ll check the PCAP to see what’s going on. We can see that there are a couple of HTTP packets so let’s filter for http:

We can see that the last 4 bytes of each packet must be some sort of key. If we concatenate all the 4byte values of each packet we’ll get the following string:

This must be a base64 string but if we’re trying to decode it, we’ll just get some strange binary stuff. So let’s have a look on IDA. Since we know that this binary is sending HTTP requests, we’re searching for specific function calls e.g. InternetOpen, HttpSendRequest, or HttpOpenRequest in the Import tab of IDA:

Let’s track back the function and we’ll see that most of these functions will be called in the function sub_401000. Checking the cross reference, we’ll find out that there is only one call of sub_4010000:

So we need to check what’s going on before this function call. The first interesting function call is “ReadFile”. If we scroll up a little bit higher, we’ll find out that this binary is trying to read a file “key.txt”. The function at 4011A0 (renamed to checkKey in the screenshot) is reading the content of “key.txt” and just adding each byte of the input to the respective byte of the string “flarebearstare”:

The encoding routine can be found at 4011E7 (renamed to obfuscation, that was my first thought ;-)). I did not get it that this was just a Base64 encoding algorithm with a different alphabet so I wrote a dirty-ass python script to reverse the whole stuff (omg!):

Anyways, it worked quite good. The output is:

If any python pro will ever read this blog. Please forgive me!

This entry was posted in Reverse Engineering and tagged . Bookmark the permalink.