Protected: Flare-On 7 – Task 10 [coming soon]

This content is password protected. To view it please enter your password below:

Posted in Uncategorized | Enter your password to view comments.

Flare-On 7 – Task 9

This year’s FlareOn was very interesting. I managed to finish it with 87th place. In this small series I will describe my favorite tasks, and how I solved them. I hope to provide some educational value for others, so this post is intended to be beginner-friendly.


In this task we are provided with the following package (password: flare). It contains a 64 bit PE (crackinstaller.exe), and a description that says:

What kind of crackme doesn't even ask for the password? We need to work on our COMmunication skills.

By the name and the description we can guess that it is going to be an installer for some other components, and also that some knowledge about COM (Component Object Model) is going to be required.


Before we go into details of the solution, lets see the roadmap of the elements that we are going to discover.

The following diagram presents the loading order of particular components involved in this task:

The elements with solid borders are loaded from files. The elements with dash line borders are loaded in-memory only. Yellow – executes only in a usermode, blue – only in a kernelmode, gray – part in usermode and part in kernel mode.


The crackme runs silently, without displaying any UI. In order to see what is happening during execution, we can use some methods of tracing the activities (i.e. ProcMon). I wanted to see what exactly are the APIs called from the main application, so started by running it via Tiny Tracer. In order to get the complete trace, it must be run as an Administrator.

This is the trace log that I obtained:

It gives a pretty good overview what is going on at what points of the code. Let’s go through the log first, and see how much can we discover by reading the order of APIs called.

The first fragment that triggered my interest is the following:


By reading it we can find that the crackinstaller:

  1. drops some file (CreateFileW, CreateFileMappingW, MapViewOfFile, CloseHandle)
  2. installs it as a service (OpenSCManager, OpenServiceW, StartService)
  3. sends an IOCTL (DeviceIoControl) – most likely the receiver is this newly installed service, that is a driver
  4. uninstalls the created service (OpenServiceW, DeleteService)

Another interesting fragment of the log follows the previous one:


In this fragment we can see that some file is being dropped (CreateFileW, WriteFile). Then it is registered as a COM server.

So, at this point we can expect two elements are going to be installed: a driver (which is uninstalled right after use) and the COM component. In order to find them we must see what are the files that are being dropped. We can load the generated .tag into x64dbg, and set breakpoints on the interesting functions.

The dropped components

First I set breakpoints at CreateFileW to see what are the paths to the dropped components. We can collect them from those paths once they are saved.

As we observed before, there are two elements dropped:

  1. The driver: da6ca1fb539f825ca0f012ed6976baf57ef9c70143b7a1e88b4650bf7a925e24
    • dropped in: C:\Windows\System32\cfs.dll
  2. The COM server: 4d5bf57a7874dcd97b19570b8bad0fa748698671d67593744df08d104e6bd763
    • dropped in: C:\Users\[username]\AppData\Local\Microsoft\Credentials\credHelper.dll

The first element executed is the driver, so this is where I started the analysis.

The dropped driver (cfs.dll)

As we could find out by reading the comments on Virus Total, this is a legitimate, but vulnerable Capcom driver, that was a part of the Street Fighter V game (more about it you can read here and here). Due to the vulnerable design, this signed driver allows for execution of an arbitrary code in kernel mode. By sending a particular IOCTL we can pass it a buffer that will be executed (it is possible since the driver disabled SMEP as well). This vulnerability makes it a perfect vector to install untrusted kernelmode code on the machine – that feature is used by the current crackme.

First, the driver is dropped from the crackinstaller into:


And installed as a service. Its path is:


Then, the aforementioned IOCTL is being called. Below you can see an example of the parameters that were passed to the IOCTL (DeviceIoControl function), along with their explanation:

1: rcx 00000000000001E4 ; driver
2: rdx 00000000AA013044 ; IOCTL
3: r8 0000007B3EAFF6C8 ; input buffer
4: r9 0000000000000008 ; input buffer size
5: [rsp+28] 0000007B3EAFF6C0 ; output buffer

The input buffer turns out to be the following small stub, written in additionally allocated executable memory page:

025E86BD0008 | sti
025E86BD0009 | mov rdx,25E86AF2080 ; address of: driver.sys
025E86BD0013 | mov r8d,5800 ; size of the driver
025E86BD0019 | mov r9d,3170 ; address of DriverBootstrap function
025E86BD001F | jmp qword ptr ds:[25E86BD0025] ; function inside crackinstaller.exe

The stub sets parameters, that are going to be used by the next function. Then it leads the execution back to the crackinstaller.exe – to another function (at RVA 0x2A10). Although the dropper is a userland application, this part of the code will be called in a kernel mode – because the execution to this function is redirected via the kernelmode component.

This function is responsible for loading yet another driver (driver.sys) that is also passed as one of the parameters.

By looking at the loading function, we can see that this driver is going to be mapped manually into the kernel-mode memory. The “DriverBootstrap” function exported by driver.sys is a kernel-mode Reflective Loader variant (similar to this one).

After this installation, the first driver (cfs.dll) gets unloaded and uninstalled – however, the second one: driver.sys – persists in the memory (in contrast to usermode applications, the memory allocated by a driver is not freed automatically when the driver is unloaded).

What I initially did, was dumping this driver.sys in a user mode (before the IOCTL was executed), and analyzed it statically. Then, I tried to load it as a standalone driver. However, it was a mistake. This driver has a buffer that is supposed to be overwritten on load, in kernel mode. At this stage, it is not filled with the proper content yet. This buffer is crucial for decoding a password. Since I overlooked the part that was overwriting it, although I understood the full logic of the driver, the output that I was getting was a garbage. After consulting it with other researchers, confirmed that the output was supposed to be a valid ASCII – so I realized that I missed something on the way, and I shouldn’t have been making shortcuts and dumping the driver in the userland. I then decided to walk through the full way of loading the driver in the kernel mode, and dumped it again in kernel mode, just before its execution.

The driver.sys

Before we move further to the dynamic analysis, let’s have a look at the driver.sys in IDA. As I mentioned earlier, dumping this driver in userland is not a perfect option (some important buffer is filled on load in kernel mode). However, for now, this version is good enough for the static analysis of the driver’s logic.

As always the execution starts in DriverEntry.

In our case, this function redirects execution to another one, which I labeled as “driver_main”.

Click to enlarge

Some interesting strings inside the driver are obfuscated – they are dynamically decoded just before use. There are various ways to retrieve them – I have chosen to write a simple wrapper in libPeConv that allowed me to call the decoding function without analyzing it, and apply it on the chosen buffers.

This module (driver.sys) is a filter driver with an altitude of 360000, which means “FSFilter Activity Monitor”.

The main function is pretty simple: its role is to initialize the device, and to set the callback that will be used for event filtering. The function CmRegisterCallback sets the callback that will be triggered each time an operation on Windows Registry is executed.

The routine that is registered to handle the callback (DispatchCallback) must follow the prototype of EX_CALLBACK_FUNCTION.

The second argument (denoted as Arg1) is of type REG_NOTIFY_CLASS – it informs about what type of the operation triggered the callback. In our case the event is processed further only in the case if the value of the REG_NOTIFY_CLASS is 26 (RegNtKeyHandleClose ?). The next argument (Arg2) holds a pointer to the structure of different types, depending on the value of the previous one (Arg1). In our case, Arg2 holds the pointer to the UNICODE_STRING with the name of the operated Registry Key.

The name of the key is copied into additionally allocated memory with a tag “FLAR”. It is compared further with a dynamically decoded string:

Only if the name of the key matches the hardcoded one, the next, more interesting part of the code is executed. If we checked the changes in the registry made during the execution of crackinstaller, we will notice, that this registry key is created on the installation on the COM server. So, this is how those components are tangled together.

The next part of the driver’s code decrypts some mysterious buffer. We can recognize the involved algorithms by their typical constants. First, SHA256 hash is calculated from a buffer hardcoded in the driver (denoted as “start_val”). Then, the hash is used as a key for the next algorithm, that is probably Salsa20 (eventually it may be a similar cipher, ChaCha).

Click to enlarge

At this point we can guess that our next goal is to get this decoded buffer.

In order to get the valid solution, we need to first get the overwritten version of the above driver, so, the one that is loaded in the kernel mode.

Notes on kernel mode debugging

Before we can start kernel mode debugging, we need to have an environment set up. The setup that I used is almost identical to this one. Yet, there are few differences that I am going to mention in this part.

First of all, we need a 64 bit version of Windows – I used Windows 10 64 bit VM on VirtualBox (linked clones for Debugee and Debugger).

As always, the usermode analysis tools (i.e. x64 dbg) as well as the crackme itself, are going to be run on the Debugee VM. The kernel mode debugger (WinDbg) will be run on the Debugger VM, connected to the Debugee.

Configuring the Debugee VM

There are few more steps (in addition to the ones described here) that we have to take in order to configure the Debugee VM. In case of Windows 10, explicitly setting the debug interface is necessary (by default, even if we enable debugging on the machine, it is going to be set in a local mode, and we will not be able to connect the Debugger VM). Since we are going to establish a debug session over a serial port, the following settings apply:

bcdedit /dbgsettings serial debugport:1 baudrate:115200

We can test if the proper options are applied by deploying the command dbgsettings without parameters:

bcdedit /dbgsettings

Expected result:

DbgSettings after

We need to remember that on 64 bit Windows a driver must be signed in order to be loaded. This is not gonna be an issue if we want to load the first driver: cfs.dll – because this is a legitimate, signed driver. However the second one: driver.sys – which is more important to the task – is not signed. It loads just fine as long as the first, signed driver is used as a loader. But for the sake of the convenience, at some point we are going to load the driver.sys as a standalone module. To be able to do so, we must change an option in bcdedit, in order to allow unsigned drivers to be loaded. It can be done running this command on the Debugee machine:

bcdedit /set TESTSIGNING ON

After changing the settings, the system must be rebooted.

We also have to disable Windows Defender, otherwise the crackme will be mistaken as a malware and removed.

Dumping driver.sys in kernel mode

In order to understand what exactly is going on, and not to miss anything, I decided to walk through the full flow since the IOCTL is executed inside cfs.sys, till the driver.sys is loaded in memory.

To start following it in kernel mode, we need to locate the address of the function inside cfs.dll that is going to be triggered when the IOCTL is sent. Let’s open cfs.dll in IDA, and see the function registered to handle IOCTLs:

Inside we can see the IOCTLs numbers being checked, and then the function to execute the passed buffer is being called:

In the next function (that I labeled “to_call_shellcode”) we can see the operations of disabling SMEP, calling the passed buffer, and then enabling the SMEP again:

The function disabling SMEP :

So, we need to set the breakpoint at the address just after the function disabling SMEP returns, because in this line there is a call passing execution to the shellcode. This happens at VA = 0x10573 (RVA = 0x573):

If we step into that call in WinDbg, we will be able to follow the passed shellcode executed in kernel mode.

Before we will go to set the breakpoint in kernel mode, we need to load the crackinstaller into a userland debugger (such as x64dbg) and set the breakpoint before the DeviceIoControl function is called.

Then, on the Debugger machine (connected to the Debugee where the crackme runs) we deploy WinDbg and connect to the Debugee.

We can set a breakpoint on load of the cfs.dll in WinDbg by:

sxe ld cfs

After that, we run the crackme. The breakpoint should hit and the Debugee freezes. With the help of the following command:


We can see the list of all the loaded modules, and find the module of our interest on the list:

If we want to view this list from the Debugee perspective, we can also use Driver List by Daniel Pistelli.

Now, let’s set a breakpoint on the offset inside the driver, that executes the shellcode:

bp cfs + 0x573

And we resume the Debugee. Lets step over the breakpoint at DeviceIoControl in x64dbg. Now, in the Debugger VM, we can see again that the breakpoint has been hit.

Opening the Disassembly window allows us to see this line in the original context:

Click to enlarge

As we can see, it is the same code fragment that we observed in IDA before, analyzing the relevant fragment of cfs.dll.

Using the command:


We can step into the call. And what do we see? The very same shellcode that we observed being passed to the DeviceIoControl!

The address moved to RDX is the address of the buffer holding driver.sys.

Now as we know from the previous analysis, the execution should be redirected back to crackme.exe, but the execution will take place in a kernel mode. We can set the breakpoint at the first jump which will do the redirection

bp [address]

After setting the breakpoint, we can resume the execution (“g”) and once the breakpoint is hit, step in again (“t”):

This is where we end up:

…and it is exactly the function at 0x2A10 in crackinstaller.exe, that we found before. As we know, this function will do the modifications in the driver, and then redirect execution to there, inside the DriverBootstrap function (RVA = 0x3D70 , raw = 0x3170).

By analyzing the flow of the corresponding function in crackinstaller, we can guess that the redirection happens at RVA = 0x2c26

inside crackistaller.exe

Let’s set a breakpoint there, and resume the execution.

At this point we can see the function PSCreateSystemThread is being called. The start routine is going to be the DriverBootstrap function.

The address of the bootstrap function is stored in RAX register:

At this point the driver is in the raw format, so we know that the raw address of the bootstrap function was used: 0x3170. By subtracting it from the whole address, we can get the driver’s base. By looking up this address in the Memory window we can see that indeed this is where the driver has been loaded:

Now it’s time to dump the driver. We can do it with the help of command .writemem. We need to supply it the path where we want to save the dump, and the range to be dumped. The size of the driver was supplied to the shellcode, and it is 0x5800. So, we can dump the range in the following way:

The new version dumped as “mydriver.sys”

After having the driver dumped, we can see what was patched. The comparison done via PE-bear:

Comparison – the original vs the modified

The patched content is the buffer that was used to derive the Salsa20 key (the “start_val” is filled with a string “BBACABA”).

Extracting the password in kernel mode

After the driver.sys is loaded in the memory, the crackinstaller.exe installs the COM server. On installation, the COM server creates the Registry key with the server GUID: “{CEEACC6E-CCB2-4C4F-BCF6-D2176037A9A7}\Config”. Creation of this key triggers the filter function inside the driver.sys to decrypt the hardcoded password. Our next goal is to fetch this password from the memory while it is being decoded.

Finding of this password can be achieved easily – all we need to do is to set a breakpoint in WinDbg, that will be triggered after the password is decoded, and then dump the output from the memory.

Yet, setting the breakpoint on the function of the reflectively loaded driver would be very inconvenient. Reflectively loaded driver will not be listed among the loaded modules, so we cannot reference it by its name. We also don’t know the base at which it was loaded. So, this is the point where it comes very handy to load the driver.sys independently.

For this part, we are going to use the patched version of the driver.sys – the one that was dumped as mydriver.sys in the previous part.

Loading the driver.sys as a standalone driver

Once we dumped the modified version of the driver, we can load it as an independent module. However, now the loader is not signed, so it won’t load in Windows unless we disable signature checking in the bcdedit (as mentioned before, reboot is required each time we change the settings):

bcdedit /set TESTSIGNING ON

We install it on the Debugee VM:

sc create [service name] type=kernel binpath=[driver path] 
sc start [service name] 

Let’s break the execution via Debugger VM (WinDbg : Debug -> Break) and see if the driver.sys is present on the list of the modules, using the command:


We should see it on the list, just like on the example above.

Dumping the password from the memory

Now we can set the breakpoint inside the filter function. As mentioned before, it is gonna be called each time when some registry key is read/written. Then the name of the key is going to be compared with the hard-coded one (which is dynamically decrypted). If the name matches, another buffer is decrypted with the help of Salsa20. So, the password decryption is executed immediately when the COM server creates this key.

We can set the breakpoint after the key name verification is passed (RVA = 0x48C9):

bp driver + 0x48C9

In order to trigger the event, we need to use the the credhelper.dll now, and run the DllRegisterServer function. It can be done just by running (on Debugee):

rundll32.exe credhelper.dll,DllRegisterServer

This will trigger the breakpoint that we can follow in WinDbg…

Let’s set a breakpoint at the address where the Salsa20 algorithm was executed (it happens at RVA = 0x49AC):

driver.sys – IDA view
bp driver + 0x49AC

After that we can resume the execution


…and the breakpoint will be hit:

At this point, the address of the output buffer is in the R8 register. So we need copy this address to the memory view. Now we can step over the function.

And the decryptet content got filled in the buffer that we previewed:

So this is the password: “H@n $h0t FiRst!”.

Now we need to learn how to use this password to decode the flag…

The COM component

The driver.sys is quite small, and there is nothing more in it to decode, so I guessed the next pieces of this puzzle are hidden somewhere in the COM component. Let’s take a look…

We aleady saw in the Pin tracer log. that one function from this DLL is being called:


If we open the credhelper.dll in IDA, we can see that this function is probably the one responsible for decoding the flag:

We can see the registry keys “Password” and “Flag” being referenced.

However, if we take a closer look, we will see that the function responsible for setting the Flag is not inside the DllRegisterServer.

There are two unreferenced functions that manipulate the same registry keys:

The first one, reads the value of the Password from the registry, and initializes some structure with its help (snippet here).

The other is responsible for decoding the Flag (snippet here).

I guessed that the “Password” must be the string decoded from the driver.sys. So, we need to fill it in the registry, and then call those functions in proper order – probably using the COM interface.

This should probably be the “right” way to solve this task. However, when I was taking a closer look at those functions, they started to remind me something familiar: the functions used by RC4 encryption algorithm, which is commonly used in malware.

So, my guess was:

  1. The function that I denoted as “get_password_value” was an RC4 password expansion function – it was initializing the context with the password (“H@n $h0t FiRst!”).
  2. The function that I denoted as “set_flag_value” was using this context, and decoding a hardcoded buffer by the RC4 decryption algorithm

I dumped the hardcoded buffer, and decided to check those assumptions using CyberChef. It turned out correct!

So, the final flag was RC4 encrypted, with the password extracted from the driver.

Posted in CrackMe, KernelMode, Tutorial | Tagged , | 6 Comments

Flare-On 6 (tasks 10-12)

Flare-On 6

Flare-On Challenge is an annual competition organized by FireEye (the FLARE team). It is like a marathon of reverse engineering. Each year we get 12 crackmes of increasing difficulty to solve. You can download the tasks here.

This year I finished as 106.

In this post I will describe the last 3 tasks of the competition:

WARNING: Work in progress. I will be adding more details to this post.

Task 10 – “Mugatu”

[Mugatu.7z; password: flare]

In this task we get an EXE (Mugatu.exe) and two encrypted GIFs: best.gif.Mugatu, the_key_to_success_0000.gif.Mugatu.


The EXE is a ransomware, and the two GIFs are encrypted by it. We are supposed to decrypt one of those GIFs (best.gif.Mugatu) in order to get the flag.

The EXE is slightly obfuscated. For example, the Imports are replaced at runtime by some other imports. So, analyzing it statically we may get confused. In order to analyze it statically with a valid result, we should recover its real imports first. In order to do this, we can just dump it from memory once it is run by any dumper that can reconstruct the imports. In my opinion, the best for this task is Scylla. Once we have the main exe dumped with proper imports reconstructed, it becomes much more readable.

Inside the main executable there is a payload, that is the core of the ransomware. It is manually loaded by the main EXE. We can unpack this DLL statically in the following way:

  • in the resources of the main EXE there are 2 bitmaps on the same size.
  • We need to XOR one with another. (I did it using: )
  • As a result, we will get an executable (with some padding at the beginning).
  • We need to remove the padding, and that’s how we’ve got the resulting DLL, named Derelicte.dll.dll_name

However, it is not that simple. If we extracted the DLL statically, we will find that its imports don’t make much sense. It is because the main EXE replaces them on load. So, we need to find the valid imports for this DLL.

We can see the fragment of EXE’s code where the DLL is manually loaded.

The imports are loaded in an obfuscated way, that makes them quite difficult to reconstruct. They are not filled directly to the thunks, but into a proxy list, that looks in the following way:

Due to the used import obfuscation, the previous simple trick of running it and dumping won’t work again. We could try to deobfuscate them from the memory, but the better approach is to patch the loader, and just prevent the obfuscation from being applied.

Let’s take a look at the function that do the import loading. Just after the Import address is fetched, it is obfuscated:

It is being filled in the chunk of the emitted code:

In order to prevent the obfuscation, I applied some patches in the loader:

1) do not obfuscate the import address


2) write the import address directly to the thunk, not to the proxy


Then I dumped it with PE-sieve with option imp 3 (complete Import Table reconstruction). As a result I got a valid DLL that I could easily analyze statically. The import table reconstructed by PE-sieve:

After the DLL is manually loaded within the main EXE, it’s Entry Point (the DllMain function) is being called:

Then, an exported function is being called, with a parameter “CrazyPills!!!”:


Once we follow this function in a DLL, we will see the logic responsible for encrypting files.

The function that does the encryption is not called directly, but via obfuscated callback:


This callback is deobfuscated by XOR with the argument supplied to the function:


By following it in the debugger to the place where the deobfuscation is done, we can see the address of the callback function:

The callback is the function at RVA = 0x16b9.

We can follow it in IDA:


If we analyze it closer, we will find that it is an XTEA algorithm, but with few modifications. First we need to write a decrypting function for it.

I found this implementation very helpful to base my decryptor upon. The few things that are changed comparing to this implementation are: the delta, and the key buffer type (in the original implementation the key is an array of DWORDs). The second modification makes the strength of the crypto significantly lower: the key has only  4 BYTEs, not 4 DWORDs as in the valid implementation, so it is easy to be bruteforced.

The solution to this task:


Task 11 – “vv_max”

[vv_max.7z; password: flare]

In this task we are facing a Virtual Machine, using AVX2 instructions. That’s why it will not work on some older processors which have no AVX2 support. If we try to run it on such processor we get the following message: “Your processor/OS is ‘too old'”.


If the machine supports AVX2, it passes the verification, and prints “Nope!” in case of a wrong input.

Overview of the main function responsible for verifying the arguments.

The function that I renamed to “vm_process_bytecode” is responsible for calculating some “hash” from the input. Then in the function “vm_check_flag” this “hash” is being compared to a hardcoded one.

Inside this function “vm_check_flag”:

At this moment we know that the crackme expects 2 commandline arguments. The first one must be “FLARE2019”, the second: a 32 bit long string. The second argument is processed by a function implemented by the VM, and the result is compared with a hardcoded “hash” that is 24 bytes long.

The fragment of code responsible for making the comparison:

The valid “hash”:

70 70 B2 AC 01 D2 5E 61 0A A7 2A A8 08 1C 86 1A E8 45 C8 29 B2 F3 A1 1E

Rather than analyzing the functionality in the details, I decided to treat the VM as a black-box, and make some tests, checking how the output changes depending on the given input.

I noticed that the input is processed in chunks. A single chunk of 4 bytes gives 3 bytes of the output. Also, I understood that it is not a hash, but rather some encoding, because a change in a single byte of the the chunk content was not fully changing the output content.

At this moment I decided that I  will try to brutforce the solution, by finding appropriate chunk of the input for each chunk of the output. Yet, I wanted to avoid re-implementing the full VM, so I decided to go for some sort of instrumentation of the original code.

After trying various options, I decided to use the patched version of the original sample. I patched in this way that the returned value (DWORD) will contain the selected bytes of the output.

The modified version of the  “vm_check_flag” function:

I removed the part responsible for comparing the “hash” calculated from the input with the hardcoded one. Instead, we will just copy its chunk into EAX register. Then, we need to NOP out the code that sets the EAX register to 0.

Let’s test the prepared sample using one of the saved input-output sets. We will be checking the output chunk with the help of a command:

echo %errorlevel%


Input: "01111111111111111111111111111119"
Output: D3 5D 75 D7 5D 75 D7 5D 75 D7 5D 75 D7 5D 75 D7 5D 75 D7 5D 75 D7 5D 7D

DWORD=-680174125 -> D7755DD3 (little endian) -> D3 5D 75 D7

As we can see, the returned value is valid.

Now we just need to write a brutforcing application that will integrate the patched module, and crack the full value, chunk by chunk. After each iteration we need to patch the app again and change the ECX value, in order to advance to the next chunk. So, in the first round ECX = 0.

Since each output chunk is 3 bytes long, we will use only 3 bytes from the returned DWORD. Also, the value of the ECX will be advancing in the increments of 3.

During the tests with the brutforcer I noticed, that rather than trying to crack the 4 byte long input chunk as a whole, I should crack it by finding:

  1. 1-st byte of the input that gives the 1-st byte of the output
  2. 4-th (last) byte of the output hat gives the 3-rd (last) byte of the output
  3. two middle values of the input (2nd and 3rd) that gives middle (3rd) value of the output

Finding this was able to speed up the cracking time a lot. I also automated the process of patching the ECX in the modified vv_max executable.

This is the complete solution:

During the process of cracking I started to notice that the output looks like something familiar… Yes, it is Base64! I noticed it too late – but from the other hand side it was so much fun to write this crazy bruteforcer for it!

Task 12 – “help”

In this task we receive a memory dump: help.dmp, along with a pcap: help.pcap. Both have been captured on the infected system. Our task is to analyze the infection.

I started by using volatility. First, I found what was the profile appropriate to analyze the given OS. For some reason volatility detected it as Windows 10 64 bit. However, loading the dump with this profile resulted in errors. Most of the volatility functions were not working. It turned the OS is just detected wrongly. If we open the same dump in WinDbg, we see that in reality it is Windows 7 SP1 64bit. We needed to manually find the appropriate volatility profile. The one that turned out to be valid is:


Finally, after this change, we could see a significant improvement, and volatility started to work as it was supposed to.

I poked around, listing processes, network connections, drivers… One thing that drawn my attention was a driver man.sys, with a path containing “Flare On 2019” keywords.

volatility -f help.dmp --profile=Win7SP1x64_23418 modules

Volatility Foundation Volatility Framework 2.6
Offset(V)          Name                 Base                             Size File
------------------ -------------------- ------------------ ------------------ ----
0xfffffa800183e890 ntoskrnl.exe         0xfffff80002a49000           0x5e7000 \SystemRoot\system32\ntoskrnl.exe
0xfffffa800183e7a0 hal.dll              0xfffff80002a00000            0x49000 \SystemRoot\system32\hal.dll
0xfffffa800183e6c0 kdcom.dll            0xfffff80000bac000            0x2a000 \SystemRoot\system32\kdcom.dll
0xfffffa80039c4630 bthpan.sys           0xfffff880032c8000            0x20000 \SystemRoot\system32\DRIVERS\bthpan.sys
0xfffffa800428ff30 man.sys              0xfffff880033bc000             0xf000 \??\C:\Users\FLARE ON 2019\Desktop\man.sys

Unfortunately we cannot dump it by volatility, because its header is erased. So, I loaded the same dump to WinDbg and dumped it using .writemem:

.writemem C:\dumps\man1.bin fffff880`033bc000 fffff880`033cb000

Since the driver has no header, we need to reconstruct it manually. We don’t need to get all the sections right – we need just basic things to make it suitable for static analysis. The most important is to get the imports right.
First, I copied the PE-header from another driver – I used it as a base on which I started to rebuild. Then, I reviewed the file in a hexeditor, in search for familiar patterns. I could distinguish two sections, so I added their headers:
I noticed where the list of the imported DLLs is located, and tried to find the beginning of the structure, in order to fill it in the Data Directory.
My final version of Data Directory has the following form:
Now we can open the file in IDA, just like any other PE. We still need to find the Entry Point (DriverEntry), and fill it in the header. I found some unreferenced function it at RVA 0x5110 – it is very likely to be the Entry Point:


The full reconstructed Optional Header:

Let’s open the driver in IDA again, and analyze what is going on in DriverEntry. We can see that the driver injected something in the process 876:

Let’s dump this full process using volatility, so that we can see what was injected there:

volatility -f help.dmp --profile=Win7SP1x64_23418 memdump -p 876 -D mem_dumps/

Indeed – this element contains other pieces of the “malware”. I carved them out using a hexeditor.


Most of the strings used in the “malware” are encrypted with RC4 – each using a different, hardcoded key. The same obfuscation method is used in each module. So, it is useful to make a decoder that would be able to statically deobfuscate it.

We are also given a PCAP file. So, we need to somehow make sense out of the network traffic, and what is its relationship with the found “malware”. The volatility will also be helpful in seeing which process was responsible for what part of the traffic. We can see it using the command:

volatility -f help.dmp --profile=Win7SP1x64_23418 netscan

We can correlate the traffic generated by the svchost (PID 876) with the traffic recorded in the PCAP. Let’s dump the packages and try to decode them. There is a huge amount of the traffic on the port 7777. When we dump those packages, we can see inside some repeating patterns. I visualized one of the dumps (using to get an idea what can possibly be hidden inside. This is the result:

Looking at the visualization we can guess, that it is not a PE file encoded, but rather a bitmap. (If it was a PE the patterns inside would look very different: in that image there is a lot of content that looks to be filled by the same characters – and in PE we would not have so much padding between the sections.)

After finding the proper XOR key (thanks to Mark Lechtik), I got the decoded content, that was indeed a series of bitmaps. As it turned out: screenshots from the infected system.

The screenshots give some very important hints on how is the flag stored. As we can see, it is in the KeyPass database. The masterkey is covered, but we know that it is typed on the screen, so we can suspect that the keylogger component should have caught it. It will probably be sent in some other part of the traffic.

I decided to find the KeyPass database first. I needed to check what exactly was the version of KeyPass. In order to do this, I dumped the KeyPass process. It turned out to be KeyPass 1.37. I installed the same version and checked what is the header for this format. Then, I carved out the valid file with this header.


The next step is to find the password! I confirmed that crypto.dll is the layer that decrypts that part of the traffic (thanks to Alex Polyakov and Alex Skalozub for answering my questions and confirming that this is the good direction to follow). I analyzed the crypto.dll and made a decryptor for the packets.

The traffic at the port 8888 contained the keylogged content (captured by keylog.dll), and the traffic on the port 6666 – the stolen files (fetched by filedll.dll). It turned out that the uploded file was keys.kdb – the same file that I carved out from the disk – so it was another way of retrieving this piece. I found that the hashes of both match, so I confirmed that I have the valid kdb. I found also something that looked like the key to the database: “th1sisth33nd111”.


Yet, this key didn’t work!

At this point I wasn’t sure if I went in a good direction, so I asked Alex Polyakov for the hint. He confirmed that this is indeed the key captured by the keylogger, but it is in a bit different form than the key that was typed… I tried to find something similar but yet different recorded in the memory, by grepping through the strings of the main dump (help.dmp). After many failed attempts, I got an idea that the number ‘1’ at the end can be in reality ‘!’. And I tried the following command:

cat help_strings.txt | grep -i 3nd!

I found the following string:


Still, it didn’t work… But I noticed that the first characters are missing, so I tried:


And finally it worked, I got the kdb unlocked and the flag has shown up!

That’s all! I hope you enjoyed my writeup. Sourcodes of all my Flare-On solutions are available here:

Thanks to the Flare team for the great contest!


FlareOn6 Write-Up of Write-Ups – aggregator and summary of varorious solutions
View at

Posted in CrackMe | Tagged , | 1 Comment

Application shimming vs Import Table recovery

In this post I am sharing a case that I investigated recently, during the tests of my application, PE-sieve. It demonstrates how the shims applied by the operating system can disrupt Imports recovery.

Tested features

Recently I had a new release of PE-sieve. One of the added features was a complete Import Table recovery. From now, if you run the PE-sieve with an option /imp 3 it will collect all the addresses that the scanned module imported from the DLLs in the memory, and construct a new Import Table out of them. It is a very useful feature that many PE dumpers have. It helps i.e. to deal with packed applications. Let’s take an example of UPX: it may compress the Import Table of the payload, and load it dynamically during unpacking.

PE-sieve offers also another, “milder” mode of the recovery (/imp 2). In this case PE-sieve bases on the existing import table, and only reconstruct the erased elements. It can be used i.e. in the following case, when the Thunks were overwritten by the functions addresses during the imports loading:


PE-sieve is able to recognize the exports that are at those addresses, and fills their names back into the table:


Test cases

I decided to test my application on some ready-made and well-known examples. I selected Anthracene’s unpacking series, available here.

The first sample (1dbfd12ad3ee39930578b949c6899d0a) looks pretty straight-forward. It is a simple application showing a MessageBox, packed with the help of UPX.


I run this example on one of my Virtual Machines (Windows 8 64 bit) and the imports got recovered flawlessly (video).

Later, I tried to do the same on a different machine, with another set of patches installed. For some reason, I could not reproduce the valid results. Import recovery “magically” stopped working – the received results were incomplete. When I tried to dump the payload with PE-sieve, using the option /imp 2 , all the functions imported from Kernel32.dll got recovered, but the function from User32: MessageBoxA did not.

First I assumed that it must be a bug in PE-sieve, but it turned out that other applications i.e. Scylla have the same problem: they cannot map this address to any of the exported functions.

I investigated the mentioned address under the debugger, and this is what I saw. The call to a MessageBoxA was proxied via apphelp:

The function used from the apphelp was not present in the export table, so it is logical that the applications recovering imports could not recognize it. So, it is not really a bug in the application – but a problem caused by some peculiar way in which this import was loaded.


Of course I wanted to understand what is the reason of such behavior. I suspected that there must be some shimming going on, but why did it happen? I checked other applications importing MessageBoxA, but each of them used this function directly from User32.dll, and apphelp.dll was not used as a proxy.

I started thinking that it may be related with the fact that my test case is a very old application.

The OS Version in the PE header is set to 4 (Win 95):

I made an experiment and”upgraded it”, just by changing the version number:

And it worked! After this simple change, the shim was no longer applied. The application used the import directly, and, as a result PE-sieve (and other applications) were able to properly recognize the function.

So, it turned out that the operating system applies this shim automatically for the backward compatibility with old applications.

Now when I think of it, it looks pretty obvious, but it was not so intuitive when I saw it for the first time, that’s why I decided to document this case. So, just a small heads-up: when the import recovery is not going right, first check if shims are not the reason! I hope you enjoyed my small writeup.


Posted in Programming, Uncategorized | Tagged , , , , , , | Leave a comment

PE-bear – version 0.3.9 available

[UPDATE] This release introduced some stability issues, fixed in

Hello! Several months have passed since I released PE-bear 0.3.8. Since it was my old, abandoned project, I did not plan to start developing it again. Initially, I got convinced to be adding only bugfixes, treating it rather as a legacy app. However, it started doing pretty good for a “dead” project. It got 15K+ new downloads, has been mentioned in some cool presentations, featured on OALabs, and added to FlareVM. It all made me reconsider my decision. Also, I started getting messages from users requesting new features. Finally, I decided to break what I said before, and prepare another release.

The current one (0.3.9) comes with some new features. You can download it from the main site of the project:

1. Added Rich Header (viewing and editing), with calculated checksum. Preview:


New PE-bear displays all the fields of RichHeader, and allows for their editing. It automatically calculates and verifies the Checksum, so it can help spotting the cases when the Rich Header was forged.

2. Added support for the new fields in Load Config Directory. Preview:


Since PE-bear is a pretty old project, it was not able to parse the full Load Config Directory, but only its basic form, ending on SEHHandlerCount. Now it supports the extensions introduced in Windows 8.1 and Windows 10.

3. In Debug Directory: parse and display RSDSI Table (including PDB path etc):


In the old version, Debug Directory was displayed, but without parsing the structure nested inside. Now, one of the most popular types, including PDB path, is also parsed: you can view the project path, and also edit it.

In addition, project underwent some internal refactoring, and I added some other tiny improvements.

I must say I started enjoying working on PE-bear again, and already got several new ideas that I am planning to implement. So, this release is not gonna be the last.

Big thanks to all of you who motivated me to “resurrect” this project. I hope you will enjoy the new version, and the PE-bear’s comeback. As always, I am open for any comments and suggestions.

Posted in PE-bear, Tools | 6 Comments

How to compile a PIN tool using Visual Studio 2017

UPDATE: the described problems in compiling the default PIN projects seems to be fixed in the new PIN release: 3.10.

PIN (of Intel) is a great platform for dynamic binary instrumentation. I use it on daily for tracing and deobfuscating malware, and I often recommend it to others. Unfortunately, figuring out how to set it up is not so straight-forward. If you want to compile the default projects that are distributed in the package, you may get multiple errors.

I never saw the full process of fixing them documented. I struggled with this myself, and from time to time people approach me asking for help. That’s why, I decided to make a walk-through, describing all the steps I did in order to get a tool compiled.

    • Used PIN package:
      • pin-3.7-97619-g0d0c92f4f-msvc-windows (link)
    • Environment:
      • Microsoft Visual Studio Community 2017 (Version 15.6.5)
      • Windows 8.1 64bit

Step 0 – I downloaded the PIN package and unpacked it into C:\pin\C_pin

I will be compiling MyPinTool, that is a part of the PIN Package:


Step 1 – I opened the single tool in Visual Studio and tried to compile it.


I got an error:


So, I searched the pin main directory, and I found where this file is. It was in “C:\pin\extras\xed-ia32\include\xed” (we need to pick a 32 bit version for a 32 bit build).


So, I included that folder:


[C/C++] -> [General] -> [Additional Include Directories]

Step 2 – I  tried to compile it again and got another error:


So, I went to disable SAFESEH. From:


[Linker] -> [Advanced] -> [Image Has Safe Exception Handlers]

I switched to:


[Linker] -> [Advanced] -> [Image Has Safe Exception Handlers] -> [No]

Step 3 – Another attempt of compilation, and another set of errors. This time at linking level:


I googled for those errors and I found this blog. Following the advice,  I solved it by adding “crtbeginS.obj” to additional dependencies:


[Linker] -> [Input] -> [Additional Dependencies] -> add: crtbeginS.obj

And finally! It compiled:


I can only say that it was the nastiest part of PIN, and now it should go much easier. There are various sample projects included in the package, very helpful in learning the functionality.

To make working with it even easier, I made some scripts that are adding PIN along with my favorite tracer to the context menu. Thanks to them, I can start tracing any EXE just by one click. You can find them here.



Posted in Tutorial | 6 Comments

PE-bear – version 0.3.8 available

It has been a long time since I abandoned PE-bear project (version 0.3.7 was released in 2014!). But due to the fact that it still has new downloads, and I keep getting messages from its users, I understood it would be a shame to leave it without any support. A tool is alive as long as someone wants to use it, so, here is an update for PE-bear.

As I wrote in the release notes, the latest release fixes several bugs . In this post I will elaborate on the most important changes and illustrate them with examples.

  1. Fixed bugs in parsing Delay Load Imports (64bit)

So, this is the old, incorrect version (example: winnet.dll, 64bit)


And in the new, corrected one:

delayed_imp_new2. Fixed bugs in parsing Load Config Directory (64bit)

This is the old, incorrect version:

load_config_old The fields ProcessHeapFlags and ProcessAffinityMask should be flipped, otherwise their sizes are incorrectly identified. It is fixed in the new release:


3. While adding a new section, the selected access rights were applied only if the section was loaded from the file. Also, in some alignments, there was a cave appearing between the previous section and the added one, that needed to be fixed manually in headers, or otherwise the application won’t run. This all is fixed in the current version.


Section test added by new version:


I fixed also some other, smaller bugs here and there. So if you like PE-bear, it’s time to update. And if you don’t know it yet, feel free to give it a try, because from now onward I am not gonna leave this app without support, and if you find any bug it will be fixed as soon as possible. However, I will do only minimalistic mantainance, so don’t ask me for some super cool new extra features. (Or maybe I get tempted for more… No, I won’t 😉)


Posted in PE-bear | 4 Comments

White Rabbit crackme!

UPDATE: We already got the three winners. Good job guys! However, we are waiting for the writeups to select the reward for the best one – so if you are still in between of doing the crackme, don’t give up!

UPDATE2: We got first writeups! All the upcoming ones will be linked under the section “Writeups”. The submission for the contest closes 20th February.

UPDATE3: Contest closed! The winner is @Eleemosynator with his writeup available here. Both writeups were very good and detailed, so we decided that the second one, by @pieceofsummer, also deserved a distinction and a bonus reward. Big thanks to both authors!

This time I would like to introduce a small contest organized by me and Grant Willcox. I wrote a small crackme and he volunteered to sponsor the rewards. The first 3 solutions will be rewarded by books chosen by the winners.

The crackme is a 32bit PE file. It shouldn’t be too difficult, but I didn’t want to make it boring either, so it has few tricks.


Disclaimer: I am not an author of the graphics used in the application, such as ASCII arts, icons and others. I don’t claim any rights to them.


You need to find the flag in format flag{...} and submit it ASAP to any of us as a DM on twitter (@hasherezade or @tekwizz123). After we announced that the contest is closed, we would like you to make a writeup explaining how did you solved it.

There will be an additional reward for the best writeup – so even if you was not the fastest, you still have a chance to get a book for free.

If you have any questions, you can write them as comments to this post and I will be answering them. I am not giving hints via private messages – I want the contest to be fair for everyone.

At the end I will publish my own writeup with a detailed explanation.

Download: (password: crackme)

Mind the fact, that the crackme contains some small obfuscation and malware-like tricks, so it may be flagged by some of the AV systems as malicious. False positives are very common when it comes to crackmes – it can’t be helped, sorry! I recommend you to run it on a Virtual Machine.


check_mark  Finished? You can rate it!


Posted in CrackMe | Tagged , | 9 Comments

Unpacking a malware with libPeConv (Pykspa case study)

In one of the recent episodes of “Open Analysis Live!” Sergei demonstrated how to statically unpack the Pykspa Malware using a Python script. If you haven’t seen this video yet, I recommend you to watch, it is available here – and the full series is really cool.

The video inspired me to use the same sample and demonstrate an alternative solution, applying my library, libPeConv . The advantage of using libPeConv is that you don’t have to spend time on understanding and rewriting the unpacking algorithm. Instead, you can import the original unpacking function from the original malware. It can speed up the work and be helpful also in the cases when the function of our interest is obfuscated.

Analyzed sample


Static analysis

The static analysis of this malware is already well demonstrated in the mentioned video. I will just recall the important points to which we are going to refer.

Function definition

The function that is responsible for unpacking is available at RVA 0x4520. It has the following prototype:


By analyzing how it is applied, we can find out what are the arguments that should be passed:


The first one is a blob of data (BYTE*), second – size of the blob (DWORD), next comes the name of the file where the output will be written, and last one is some magic char. This is how the function declaration should look:

int __cdecl *unpack_func(BYTE* blob, DWORD blob_size, LPCSTR lpFileName, char magic_val);

Function arguments

The function is applied twice, to decrypt two blobs of data (I call them blob1 and blob2). Important things to note are: the offsets of the blobs, their sizes and the passed magic values.

Decrypting blob1:


  • Blob1 RVA: 0xC030
  • Blob1 size: 0x11000

By following the code before the function call, we can find that the last argument (the magic char) must have the value ‘r’.


Decrypting blob2:


  • Blob2 RVA: 0x1D038
  • Blob2 size: 0x50000

Again, the magic value is ‘r’:


Now we have all the data to implement a static unpacker.

Writing a unpacker

Setting up the project

For this part you need to have Visual Studio, CMake and Git installed.

I already prepared a template that you can use to make a libPeConv-based project, so it is enough to fetch it from my Github:

git clone --recursive

Now use the CMake to generate a VisualStudio project:


The malware is 32bit, so it is important to generate a project for 32bit build, otherwise we will not be able to import the sample. Example:


Click “Finish” then  “Generate” and finally you can open the project in Visual Studio.

Unpacker’s code

Code of the full unpacker is very short:

#include <stdio.h>
#include <windows.h>
#include "peconv.h"
// for the sample: bd47776c0d1dae57c0c3e5e2832f13870a38d5fd
// from: "Unpacking Pykspa Malware With Python and IDA Pro – Subscriber Request Part 1"
int (__cdecl *unpack_func)(BYTE* blob, DWORD blob_size, LPCSTR lpFileName, char r_val) = nullptr;
int main(int argc, char *argv[])
if (argc < 2) {
std::cerr << "Args: <path to the malware>" << std::endl;
return 0;
DWORD blob1_offset = 0xC030;
DWORD blob1_size = 0x11000;
DWORD blob2_offset = 0x1D038;
DWORD blob2_size = 0x50000;
DWORD unpack_func_offset = 0x4520;
size_t v_size = 0;
LPCSTR mal_path = argv[1];
std::cout << "Reading module from: " << mal_path << std::endl;
BYTE *malware = peconv::load_pe_executable(mal_path, v_size);
if (!malware) {
std::cout << "Loaded" << std::endl;
ULONGLONG func_offset = (ULONGLONG)malware + unpack_func_offset;
unpack_func = (int (__cdecl *) (BYTE*, DWORD, LPCSTR, char)) func_offset;
DWORD res1 = unpack_func((BYTE*)((ULONGLONG) malware + blob1_offset), blob1_size, "blob1_unpack.bin", 'r');
std::cout << "Unpacked blob1, res:" << res1 << std::endl;
DWORD res2 = unpack_func((BYTE*)((ULONGLONG) malware + blob2_offset), blob2_size, "blob2_unpack.bin", 'r');
std::cout << "Unpacked blob2, res:" << res2 << std::endl;
peconv::free_pe_buffer(malware, v_size);
return 0;

view raw
hosted with ❤ by GitHub

Firstly, we load the original malware (by a function from peconv). We need it to be loaded with all the dependencies and ready to be executed. A function that allows to achieve it is load_pe_executable:

BYTE* peconv::load_pe_executable(LPCSTR path_to_pe, size_t &out_size);

This malware sample has no relocation table, so we not only need it loaded, but it must be loaded at it’s original base. This operation may fail on some runs, so we have to keep it in mind.

size_t v_size = 0;
BYTE *malware = peconv::load_pe_executable(mal_path, v_size);
if (!malware) return -1;

Then, using the known offset and the reconstructed declaration of the unpacking function, we are importing it from the loaded malware.

ULONGLONG func_offset = (ULONGLONG)malware + 0x4520;
unpack_func = (int (__cdecl *) (BYTE*, DWORD, LPCSTR, char)) func_offset;

We also use the known offsets of the blobs, and make pointers to the data. After we called the unpacking function with appropriate arguments, our payloads will be dumped to files with the supplied names.

DWORD res1 = unpack_func((BYTE*)((ULONGLONG) malware + blob1_offset), blob1_size, "blob1_unpack.bin", 'r');
std::cout << "Unpacked blob1, res:" << res1 << std::endl;

DWORD res2 = unpack_func((BYTE*)((ULONGLONG) malware + blob2_offset), blob2_size, "blob2_unpack.bin", 'r');
std::cout << "Unpacked blob2, res:" << res2 << std::endl;

At the end we can free the loaded malware:

peconv::free_pe_buffer(malware, v_size);

That’s all, the unpacker is ready. One last thing we can do is preparing a .bat file that will run the unpacker until the malware get loaded (remember the loading base issue caused by the missing relocation table).

Example of the batch script:

@echo off
peconv_project.exe malware.bin

The full package (except the malware) is available here:

Finally, let’s see it in action:

Posted in Malware, Programming, Tutorial | Tagged | Leave a comment

Solving a PyInstaller-compiled crackme

I got this crackme from one of my readers, who asked me for the help in understanding how to solve it. As he wrote in the e-mail, it comes “from last year competition by the CheckPoint company”. I promised to make a writeup, so here it is :). I hope it will benefit others also.

The crackme is for the beginners, so don’t expect any fireworks ;). But it was relaxing and fun to solve.

The crackme can be found here (password: crackme), also available at HA: 8ee7382cfdf632c29df5f2d9d3286614


This is how the application looks:


When we run in, it asks for a username:


And when we give an invalid one, it responds with a text:

“Go away, you are not me”

The first important step in solving the crackme, is noticing how exactly was it made and what tools are to be applied. As the icon hints, it seems to be an application written in Python and converted into EXE. But let’s confirm it by looking inside. The main process runs another instance of itself:

Let’s attach the debugger to the child process and see the loaded modules:

We can find that indeed Python2.7 is loaded to interpret the code (the module is marked red on the picture).

At this 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.

The popular converters of Python scripts into EXE format, are, i.e. Py2Exe and PyInstaller. This time, PyInstaller was applied.

Tools required

Step 1 – Unwrapping the exe

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

python 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.

Step 2 – Decompiling the pyc

The produced output is stored in the directory corresponding to the name of the input executable. We can see there multiple modules extracted, but the interesting one seems to be the file called “black_box”:


The black_box is a pyc file with a magic number removed, so we can just copy this part  from some other pyc file that we found in the extracted set, i.e.


Let’s paste it at the beginning of the black_box:


After this step we are ready to save it as black_box.pyc and decompile:


And here is the result:

# File: b (Python 2.7)
from time import sleep
from random import sample, getrandbits, randrange
from string import ascii_letters, digits
import sys
import random
import string
import hashlib
import base64
import zlib
import locale
import binascii
import socket
from hashlib import sha256
f = 'kukuriku'
k = 'elvis presley'
c = '789p8594po76n34n0p457s8947p85n0p0q31506093s02nn06654912r30p563o50q367p7q0o3o9qo6q37q6s061r182471246q1qq2o9138q8p3rpssp9rqnn246o638315o9s4oq3580n7o3oso71rr915o8p54n4o2o87s4s6q2pq8661868664pnp0o3853s443n1606907rsqro3oq670np348643s8o65778o5r248r0r7or5350r34p40714601snqps985255so43n278q69s582sq27n92554q919682n941rs05034r241pnqs1nrn40q44p147s73popp45268qqrns2o3os206q6s22ps6p441024r136n9373n32q965ss128p507sqpp78qo63orp2s9017p0379235ps8so96ns2n12169prn9nq7745snq47o71rs2173p39163pp45nn49p844o559p37sq390998267qn5n2712416qp7nq4n591s6867p8n5p9ro1062498678q88n1934s3788q8o7o8rrnr656ps162q72s0423277pp618roopr5q4np71q98p93o645qp6pp093n2sqn546s9171rqs59543rr9ns7n0p575r86p54n5626928320855139r672rrp449o601sn0ro69qpq5p8soppoorq6184590rn071303s6n32s82r857qn1n612q4or4pp8p40orpppn18nqr20279p90r30o12191nq4ns50oq11p8p271883srn3n655sn4177816pr659n3pqs6673so31qo5n985n4rnp0q7s1015q850s71psn99s3npsp01snps6516s4n8p16369r319oq2427628onrp882ooopr019r63q3pq4spnq559po661r2r250969r91rq57q4s6656n5op0n4q681qr3r8sn495555r40nqp27p98p199o5622ppq4q9q022s81p04r067op9151q38o6r65o7r399436r76ro6rsq87poo8557r89opq08s213rrqqsn3sn26q652412ss5r9s6308q612r8471r68po780roo2o22o9661q964824o754750s305sr0rr52oqss6367q7oo32o9rp05770p5ps9813r6324so7575068q4on9r833o1s4nr4ps1p2r6662p6pspo4pr9464or0487p0qs6289475o2o8r5rsnoosn5s751o15537q15343568nors5084sr8npq3o57r4r9s15rn3n0p0p803n35s668q55s00pr8sq6ro715r2sqs70ppqro6qs953nr9p44696n0o55sp9s04o8s9s496p6o23349op863838qrp5p5o1r4rs32297492p6s277r6r6sp303o673sp2or47qnr203qp411s61p308o76104pp5soqp08o9n87s9rs3n5sq016orn986o3o7s5qsp04q865q1o0nn8q1908877ro9pqqo979r460q60rr0210oopssopo32s3r023p9q79r994q32r2555nr8613nor196o3o0272o1sn95s95o698686q0pp0r04p324o2rr0o689s9p483p880592627780s376r1pn8120n98610571po9n7ooo593195r03s2495no223q037361p3qn950op4qq0s4so9q77orq05ss66r7ossqrp1n77rs63qs316nso13o1s19sso07060349qs86s1ss31r8poo9r2nss11530q17ss6688o656525078s784s75q95557nsoo4p54395qrs8no43ns8483sn0os39npn1s7nn38qs6op347n63po2s6p55o33q6rn23993sor0q77009679n44n39q09n0sos00070p6111'
exec base64.b64decode(zlib.decompress(binascii.unhexlify(c.decode('rot13'))))
g = 'lsdjfiownv9037la1sdf10'
p = 'byebye'

view raw
hosted with ❤ by GitHub

The file got decompiled properly, and at this point we can rename it to py and run like any other Python script. We can see the same prompt as it was in the EXE:


Looking at the code we can see that is is mildly obfuscated. The important part is hidden in the variable “c” that is obfuscated by ROT13 and compressed by ZLIB:

c = '789p8594po76n34n0p457s8947p85n0p0q31506093s02nn06654912r30p563o50q367p7q0o3o9qo6q37q6s061r182471246q1qq2o9138q8p3rpssp9rqnn246o638315o9s4oq3580n7o3oso71rr915o8p54n4o2o87s4s6q2pq8661868664pnp0o3853s443n1606907rsqro3oq670np348643s8o65778o5r248r0r7or5350r34p40714601snqps985255so43n278q69s582sq27n92554q919682n941rs05034r241pnqs1nrn40q44p147s73popp45268qqrns2o3os206q6s22ps6p441024r136n9373n32q965ss128p507sqpp78qo63orp2s9017p0379235ps8so96ns2n12169prn9nq7745snq47o71rs2173p39163pp45nn49p844o559p37sq390998267qn5n2712416qp7nq4n591s6867p8n5p9ro1062498678q88n1934s3788q8o7o8rrnr656ps162q72s0423277pp618roopr5q4np71q98p93o645qp6pp093n2sqn546s9171rqs59543rr9ns7n0p575r86p54n5626928320855139r672rrp449o601sn0ro69qpq5p8soppoorq6184590rn071303s6n32s82r857qn1n612q4or4pp8p40orpppn18nqr20279p90r30o12191nq4ns50oq11p8p271883srn3n655sn4177816pr659n3pqs6673so31qo5n985n4rnp0q7s1015q850s71psn99s3npsp01snps6516s4n8p16369r319oq2427628onrp882ooopr019r63q3pq4spnq559po661r2r250969r91rq57q4s6656n5op0n4q681qr3r8sn495555r40nqp27p98p199o5622ppq4q9q022s81p04r067op9151q38o6r65o7r399436r76ro6rsq87poo8557r89opq08s213rrqqsn3sn26q652412ss5r9s6308q612r8471r68po780roo2o22o9661q964824o754750s305sr0rr52oqss6367q7oo32o9rp05770p5ps9813r6324so7575068q4on9r833o1s4nr4ps1p2r6662p6pspo4pr9464or0487p0qs6289475o2o8r5rsnoosn5s751o15537q15343568nors5084sr8npq3o57r4r9s15rn3n0p0p803n35s668q55s00pr8sq6ro715r2sqs70ppqro6qs953nr9p44696n0o55sp9s04o8s9s496p6o23349op863838qrp5p5o1r4rs32297492p6s277r6r6sp303o673sp2or47qnr203qp411s61p308o76104pp5soqp08o9n87s9rs3n5sq016orn986o3o7s5qsp04q865q1o0nn8q1908877ro9pqqo979r460q60rr0210oopssopo32s3r023p9q79r994q32r2555nr8613nor196o3o0272o1sn95s95o698686q0pp0r04p324o2rr0o689s9p483p880592627780s376r1pn8120n98610571po9n7ooo593195r03s2495no223q037361p3qn950op4qq0s4so9q77orq05ss66r7ossqrp1n77rs63qs316nso13o1s19sso07060349qs86s1ss31r8poo9r2nss11530q17ss6688o656525078s784s75q95557nsoo4p54395qrs8no43ns8483sn0os39npn1s7nn38qs6op347n63po2s6p55o33q6rn23993sor0q77009679n44n39q09n0sos00070p6111'
exec base64.b64decode(zlib.decompress(binascii.unhexlify(c.decode('rot13'))))

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:

Now, once we execute this script, we get the next stage dumped. And this is how it looks:

from hashlib import sha256
from time import sleep
import socket, sys

PASSWORD = "36949"
HASH = sha256(PASSWORD).hexdigest()
USER = 'Nigel'
CODE = "807290"

PORT = 587

def login():
    print ""
    username = raw_input("Enter First Name: ")
    if username.rstrip(' \n\t') != USER:
        print "Go away! You are not me..."

    print "Hello %s, Good to see you!" % USER
    while True:
        password_guess = raw_input("Enter 5-digit password: ")
        print "[DEBUG]: calculating sha-256 hash"
        print "[DEBUG]: comparing with %s's hash: %s"  % (USER, HASH)
        print "[DEBUG]: performing anti-brute-force delay..."
        if sha256(password_guess).hexdigest() == HASH:
            print "Password OK!"
            print "Wrong password!"

    while True:
        s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, 0)
        s.connect((IPADDR, PORT))

        print "%s, two-factor authentication is required. A one-time code was sent to your email address" % USER
        code_guess = raw_input("Enter code: ")
        if code_guess == CODE:
            print "Success! The code is what you're looking for :)"
            print "Wrong code!"


The script is not further obfuscated.
Once we read it, it’s pretty straight-forward what to do next. So, the username was Nigel. Then, we have to give his password that is 36949 and finaly his code: 807290. This was my final conversation with the crackme confirming that the code is valid.



Enter First Name: Nigel
Hello Nigel, Good to see you!
Enter 5-digit password: 36949
[DEBUG]: calculating sha-256 hash
[DEBUG]: comparing with Nigel's hash: 6912863904dab1ddc332a928bf6df7f365bf1131906f3424aa931c6c85595c34
[DEBUG]: performing anti-brute-force delay...
Password OK!
Nigel, two-factor authentication is required. A one-time code was sent to your email address
Enter code: 807290
Success! The code is what you're looking for :

Exactly the same results we get when we talk with the original EXE:
So, the final answer is 807290.


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.


Posted in CrackMe, Tutorial | Tagged , | 6 Comments