Description

For some time I have wanted to get better at reverse engineering. After recently solving some shellcoding and buffer overflow binaries on Windows I thought the time was finally right to get started.
The binary in this blog post was fetched from crackmes.one. The challenge is called pixel (challenge file called: lazy.exe) and was written by Boozy. The difficulty rating is 2.0 and the quality rating is 4.0.

Tools

To solve this crackme I used the following tools:

  • IDA Free (static analysis)
  • x64dbg (dynamic analysis)

Writeup

First off, open the program in Ida. Then go to the main function. In there you will see the following:

The above image describes how the program is using FindFirstFileA to find an image file with the exteion ‘.jpeg’. But there are also 3 ‘?’ before the ‘.jpeg’ file extension. These question mark characters are wildcards, according to the Windows docs. To sum up, the program is looking for a ‘.jpeg’ file in the current folder, which has a name of the characters before the file extension.

After seeing this, we create a file called: “AAA.jpeg” (which was actually a cat image I downloaded but I don’t know if that makes a difference :-) ).
Also, I discovered that the program would try and use fopen to open a file. This prompted me to inspect the binary with the dynamic debugger to get a better understanding before proceeding with the static analysis.
The picture below is a screenshot from Ida that displays how the program is using fopen:

After setting a breakpoint on fopen it was possible to inspect the registers before and after the function call.
Before:

After:

In the 2nd picture above, you can see that the fopen call returns null, indicating an error. After stepping a little further, I discovered that the program did not terminate after this.
In the x64dbg view I noticed that there was some comparison loop going on, by noticing that the registers kept changing between different char values. Also, the assembly showed that there was comparison operations going on.
The picture below shows the loop in x64dbg:

The picture below shows the loop in Ida:

And looking a little further down in the Ida graph viewer, I noticed that there was a comparison with ‘~’ - hmmm, this seemed interesting.

Moving back to the pseudocode in Ida, it was possible to see the final check where the binary would either print “umm….try again” or the winning message: “dayummm”. I went back into x64dbg and stepped further in the code. I also put a breakpoint on the final comparison to see what was going on:

The binary was checking if our image was named ‘~.jpeg’!
After realizing this I renamed the picture and ran the program again in x64dbg just to confirm - it was correct!
Below you can see the terminal output of the program after renaming the picture to ‘~.jpeg’.