Telecharger Crackme.exe

[Paulette Dzurilla]

Atthis moment we can confirm that this EXE is in reality a wrapper for a Python script. There are several applications that allows to achieve it. Depending on which application produced the wrapping, the output has a bit different format and requires a different decompiler.

Unpacking the EXE is easy with the appropriate tool. In this case I used PyInstallerExtractor, written in Python.

python pyinstxtractor.py pycrackme.exe

This is the output:

[*] Processing pycrackme.exe

[*] Pyinstaller version: 2.1+

[*] Python version: 27

[*] Length of package: 2604972 bytes

[*] Found 20 files in CArchive

[*] Beginning extraction...please standby

[+] Possible entry point: pyiboot01_bootstrap

[+] Possible entry point: black_box

[*] Found 196 files in PYZ archive

[*] Successfully extracted pyinstaller archive: pycrackme.exe

You can now use a python decompiler on the pyc files within the extracted directory

The script directly hints, that the next step will be to use a Pyhon decompiler and turn the obtained pyc files into Python scripts.

It also hints about the possible entry point of the application. This information helps us to find where the code of our interest is located.

To understand it better what happens here, we should dump the content after the deobfuscation, rather than executing it. In order to do so, I slightly modified the script. I removed the code responsible for executing the second stage, and substituted it with the function that writes the decompressed result into a file. This is my modified version:

-black_box_patched-py

This crackme can be solved very easily if we know the few tricks. The most important was to find what are the proper tools to be applied. Once we got them, we could easily decompile the code and read the answer.

Hello sir,

i have successfully decompiled the main entry file. e.g. black_box file in this example. Now i want to create exe file so that it can contain files from PYZ-00.pyz_extracted folder into exe itself.

However, this is not a full and comprehensive analysis of the protector code or the code virtualization feature. When solving crackmes, I prefer to choose the simplest solution that gets the job done. This is also reason why I did not use ready-made tools like VMAttack, Detours, FRIDA and the like...

The crackme is an x64 binary that uses a custom protector. If you open crackme.exe in your favorite hex editor, you'll notice that .code section appears to be encrypted. OK, maybe you will not notice that. ?

Just check the entropy of each PE section with a tool like DiE:

So, our first step would be to unpack the file.

To unpack the crackme properly, we'd need to run it under debugger, find OEP and dump the process memory. However, when you try to run the crackme under x64dbg, you'll see that it throws breakpoint exception and terminates:

You also cannot attach to a running process, as it will terminate immediately.

Dumped file is surprisingly readable in IDA. We can soon find a suspicious part in .code section:

Following the jump, we see a combination of push constant+call followed by data which is very typical for a VM startup:

Following that, we see some code that looks like an obfuscated spaghetti code:

So, it looks like we have located our VM but the code is obfuscated. We'll need to take care of that first.

First, a carry flag is set to a know value using clc or stc instruction. Then a conditional jump is used to confuse IDA's analysis. Jump distance is usually very short - 2,3 or 4 bytes. Just like before, we can use regex to replace replace clc+jump+junk code with nops.

Once the simple jumps are replaced, you'll notice a much larger obfuscation pattern:

The pattern begins with pushfq, followed by call and 2 jumps and ends with the popfq. This example uses RAX, but it can be also RDX or some other register.

It's easy to find the end of the pattern just by looking for next popfq instruction.

And finally, there's a more complicated pattern. It's so large that I had to use graphic editor to stitch it all together for you. Notice that all nops, jumps and junk code are removed from the image!

As with the previous pattern, it's easy to find the end of it, just look for combination of pop rcx, pop eax and popfq.

I chose to hook VM dispatcher between "add rax, 0F8h" and "mov eax,[eax]" instructions. Since I didn't have any decent x64 hooking library for Delphi XE2, I made my own "hooking" code. It's ugly and you definitely shouldn't do that in production code. But for the crackme it's fine!

So far it doesn't look like much, does it? But by examining the instruction pointer PC values, we can see that opcode 0x13 can change PC significantly. So opcode 0x13 is probably a (conditional) jump instruction.

Specifically, on 2nd line we can see RAX=31. That's ASCII code of "1", the first character of fake serial that I entered. In RCX we see value 0x43. Could it be the correct first character of serial and this is "goodboy/badboy" jump?

3a8082e126