Vraytap autumn crackme from Kaspersky Lab

Hello. The name speaks for itself. The event was poorly lit and I somehow miraculously managed to participate in it. As a result, he managed to grab eleventh place and get the right to the promised dividends. Let's get down to business.

Quacks . Or here (hello from 2k17 if the link got stuck)

Tools: IDA, HxD, CFF Explorer, DbgView, PEChecksum , KmdManager
The last three tools are quite specific, many crackers have already understood what the whole point of the crack is.

After downloading the file, it turned out that it does not have an extension. Dirty thoughts about the fact that this is another ctf rubbish a la find how to use me began to creep into my head. Hex listing brought me back to ataraxia:
')

Mark Zbikowski’s cherished signatures were in place, we continue the analysis:


This is a turnaround driver. Feel free to rename cracks in crackme.sys . This time a well-grounded question came into my head: where is the loader? Where is the graph (user interface, don't think anything bad)? They are not. Literally. I think this is the second most important (hehe, we'll get to the first one), the illogical nature of the quacks: this does not happen. We continue the analysis.

This is what the ImageBase driver looks like:


And this is the real driverEntry:


Here you should remember the name of the device and pay attention to the fact that our driver kindly handles the user DeviceIoControl .

This is how the handler looks like before manual adjustment:


And so after comparing with asm listing:


What's going on here? The function receives a buffer at the input (I’m not able to figure out how to transfer it to DeviceIoControl , write in the comments) and a control code. The buffer, depending on the ControlCode , is copied to the mail or serial field (cool emulation, what to say). After filling in these fields, we have to send a ControlCode for the third time and as a result, a certain Validate function will be launched, on the basis of which a message will be displayed.

An experienced crack would patch this case and launch it into release, only we need to find the serial number to our email. Prepare for the worst and go to the cherished function Validate :


Asm listing of her most intimate moment:


After validating the received parameters, it calculates a hash from a certain constant string, a hash from the input buf1 (our mail, this is obvious) and a common hash from these two strings.

What does the func1 function look like? Scary and terrible (actually not very) . Inside it, there are also functions 4, which do something with the incoming line: fill, copy, modify, and so on.

It is worth remembering that in func1 we don’t transfer anything related to buf2 (obviously, this is our serial). And what does a cracker do when it sees a certain hash function from the mail, to which nothing connected with the serial is transferred, and right after this a charming combination:

 xor eax, eax repe cmpsb setz al ret 

Of course! It flies like a Kama bullet goes to breakpoint after calling this function, the return string is our serial (the biggest problem of any crackers is the banal strcmp). But there is a couple but:

1. We need to correctly initialize the call to the function Validate through a series of calls to the driver (well, or use the handles to call + patch the memory)
2. The usual debugger of the “Olya” archetype for ring0 is not suitable - you need to use more powerful tools

No matter how hard I tried, but my VirtualBox with the xp sp3 knurled on top refused to accept Syser / SoftICE / WinDbg. An idea appeared: why not make the driver kindly tell us the serial? How can I do that?

To begin with, patch checks for validity of incoming data inside Validate :


Just overwrite them with nop`ami.

Then you need to manually fill the buffer with soap (it is dynamically allocated); we do this, let's say, at the very beginning of the Validate function. It was like this:


It became so:


Those was a dynamic calculation of the length of the mail and everything related to buf2 .

Now we patch the very end of the function and instead of repe cmpsb execution of the repe cmpsb stuff the DbgPrint call:


After patching, it is necessary to recalculate the CheckSum driver field - for this we use the PEChecksum utility. Then we load the driver using KmdManager (to download the x32 driver, you must have a x32 system, preferably xp), open DebugView. Then it remains to write a small program to call the driver:

 char tmp[0x100]; HANDLE handle = CreateFile(L"\\\\.\\crackme", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); DeviceIoControl(handle, 0x222408, 0, 0, &tmp, 0x100, &tmp, 0); CloseHandle(handle); 

Compile, run:


The first line is the desired serial. I say goodbye to this.

NOTE: The decision was published immediately after the assignment completed the first fifteen participants in the competition. Fair competition must be respected.