Tools used: exeinfo, IDA Pro, OllyDbg
Codes & Binaries: https://github.com/jmprsp/labyrenth/tree/master/Window-Challenge-7
Description: This challenge is written in C++. A PCAP file given. Decrypt the message that is hidden in the traffic to get the flag.
The above figure tells us a lot of stuff.
- It is likely that it is not packed
- It is probably attempting to connect to an IP (172.16.95.1)
- There are some sort of debug messages
- uses socket to send data out
Let’s try to get the flag!
x-referencing from the import list we will see the above figure. Looks like the challenge is attempting to connect to 172.16.95.1:8080. It seems to only send 1 character at a time… Now, I want to know what is being send over the network. Tracing who calls this function bring us to the figure below.
The figure above shows that the challenge reads content from file.txt, encrypt the content, encode the encrypted content and send it out.
Let’s take a look at 0x00412359. How did I derive that it is a base64 encoding function? Take a look at 0x00411840 and you will see some tell tale signs as shown in the figure below. Most importantly I see “=” sign being appended near the end of the function.
Here is a piece of code i grabbed from online of a base64 implementation.
Notice there are some similarities between the code and the assembly codes. However the basis_64 variable seems to be different. Custom base64 encoding??? That is my guess. Now is there anyway to prove it? Let’s get our hands dirty with ollydbg! First create a file “file.txt” and placed it together with the challenge executable’s location. Put some contents in it… for my case I entered “AAAABBBBCCCCDDDDEEEEFFFF” into file.txt
We shall set breakpoint at
- 0x0412345 – call to suspected encryption routine
- 0x041234A – after encryption routine (or use F4 to break @ here)
- 0x0412359 – call to suspected base64 routine
- 0x041235E – after encoding routine (or use F4 to break @ here)
In the above figure, we can see that the string “AAAABBBBCCCCDDDDEEEEFFFF” and its length 0x18 (decimal 24) is passed into the subroutine @ 0x00411127.
After the routine, we can see that the value in the memory has changed. It seems like the encrypted data has the same length as the plain text.
@0x0412359 we can see that the encrypted data is passed into the routine @004111B3 (our suspected base64)… Let’s do a quick check here. We shall change the encrypted contents to “PIKACHU THUNDERBOLT NOW!”
Run to the next breakpoint @0x041235E (after the encoding routine).
We can see from the memory address pointed by eax that there are some garblish data in it… “GYc4QGlypBtGBKpz/YpBQ9UfpgtzsPVC”
Now we shall use an online tool for a quick check… (https://www.malwaretracker.com/decoder_base64.php) using “qtgJYKa8y5L4flzMQ/BsGpSkHIjhVrm3NCAi9cbeXvuwDx+R6dO7ZPEno21T0UFW” as the custom key.
As shown from the above figure, we indeed decoded the encoded data back to our pikachu text! Now we need to figure out how the encryption is done and we are almost there. Sadly i don’t have a lazy/simple solution here. I reversed the encryption algo into php code and did a algo reversal to get the plain text from the encrypted data. You may find the encryption code and decryption code in the github link provided.
Back in figure 2, we mentioned that only 1 byte is sent at a time to 172.16.95.1. Using scapy we can extract the data out from the pcap (as shown below).
Analyzing the encryption routine, you will see that “AWildKeyAppears!” is being used as a key to encrypt the data.
The following is a php code of the encryption routine found in the challenge.
The following is the codes to reverse the encryption process. Basically it undo what an encryption routine does.
Running the extracted data with the codes I had reversed earlier…