When you analyze a file, the first thing is probably to understand the type of the file. If you are familiar with Windows, I believe you can recognize the file type of the first challenge just by looking at its icon:
Yes, it looks very much like a Windows Installer. That is to say, this file is a Windows Portable Executable file. And this can be easily confirmed by opening the file with a text/hex editor and find the magic strings “MZ” and “PE”:
After knowing the file type, we may look at more file attributes with the help of a file format analyzer. For Windows PE files, I prefer the CFF Explorer, because it has a good support for .NET file format.
From the PE header of this file, one important thing I observed is that this file is a 64 bit Windows Portable Executable file:
This means that the file only can be executed on a 64 bit Windows system. If we have a 64 bit Windows system, that’s good, we can just run it and see what will happen (I suggest to run all the unknown files in a Virtual Machine because it can be a malware). But what if we don’t have one?
For installers, it usually embeds or compresses the target files into its resource section or its append data. Keep this principal in mind, you may easily find an unusual resource inside this file:
As the picture shows, this resource is actually a Cabinet file (according to the magic string “MSCF” at the beginning of the resource) which contains a suspicious executable named:
You can extract the resource with any resource editor you like, and here I use the Resource Hacker to do this. Once we extracted the Cabinet file, we can decompress the file inside with a decompression tool like 7-zip. Finally, we can get the following file:
File Name: i_am_happy_you_are_to_playing_the_flareon_challenge.exe
Size: 641 bytes
File i_am_happy_you_are_to_playing_the_flareon_challenge.exe is also a Windows Portable Executable file, but not like the previous one, this one is a 32 bit program probably written in Assembly Language.
When you execute this file, it will ask for a password. And if a wrong password is provided, it will print out “You are failure” and exit:
So it is time to look at the disassembly code in IDA:
This part of the code dose the follow works:
1. Retrieves a handle of standard input and standard output by calling API GetStdHandle().
2. Prints out following string to the output device:
Let's start out easy
Enter the password>
3. Read from the input device for at most 0x32 bytes.
The second part of the code looks like below:
There is a magic jump located at 0x0040105B which determines whether we success or fail. To make it not to jump to the failure branch, we should make sure the first 24 bytes of the input XOR 0x7D equals to a sequence located at 0x00402140:
So we can do a simple reverse calculation by XORing each bytes from 0x00402140 with 0x7D to get the correct password, here is an IDA python script that can help:
from idaapi import * addr = 0x00402140 length = 24 out = '' for i in range(0, length): out += chr(Byte(addr) ^ 0x7D) addr += 1 print out
And the output of this script is:
Obviously, there is a bug in this program because it allows us to enter more than 24 bytes data but only verify the first 24 bytes, here is a proof of concept: