crackinstaller.exe was a complicated binary that installed the Capcom.sys driver, and then exploited it to load another driver into memory. It also dropped and installed another DLL, a credential helper. I used kernel debugging to see how the second driver is loaded, and eventually find a password, which I can feed into the credential helper to get the flag. I spent over two of the six weeks working crackinstaller.exe, and unfortunately, I stopped taking meaningful notes very early in that process, so this won’t be much of a writeup, but rather a high level overview.

## Challenge

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

• Bug Notice: Avoid a possible blue-screen by debugging this on a single core VM
root@kali# file ttt2.exe
ttt2.exe: PE32+ executable (GUI) x86-64, for MS Windows


## Running It

I happened to be on a fresh Windows VM when I started this challenge, and on trying to run this, Windows Defender blocked it. Looking at the logs, it is calling this HackTool:Win64/CapRoot.A:

It also calls out crackinstaller.exe as a containerfile, with the file in question being cfs.dll.

Once I disable defender, running it pops a blank terminal for a second, and then it disappears.

## General Notes

### crackinstaller.exe

This binary drops a bunch of things. It has an init function that runs pre-main that will drop the famous Capcom.sys driver.

Click for full size image

It then invokes the IOCTL call that basically loads user code into the kernel and runs it. I worked through both videos in this post and really learned a ton. Highly recommend.

For this binary, after installing the vulnerable driver, it uses it to load call code back in crackinstaller.exe:

FUN_140002a10(?, 22B00BA7E00h, 5800h, 3170h)


In this function, there’s a lot of kernel memory pools functions to put a new driver into memory and an array of kernel functions into a second pool. these are passed to PsCreateSystemThread:

PsCreateSystemThread(&hThread, GENERIC_ALL, 0x30, 0, 0, driver_in_memory.DriverBootloader, args[])


DriverBootloader basically does some memory re-arrangements and calls IoCreateDriver(NULL, entry).

After installing the driver, it continues in main, where it drops credhelper.dll to disk:

Click for full size image

Then it invokes the DllRegisterServer export.

### Unnamed Driver

I had to set up kernel debugging to see into the driver and what was happening. To do this, as I’m on a Linux host, I created two Windows VMs, and configured them according to this post.

The driver calls CmRegisterCallbackEx which will register a callback function that will be invoked when the kernel conducts registry operations. It took a bunch of documentation reading to understand the various structs passed to this function, but eventually I figured out where the function that was invoked would be.