Yet another kaspersky crackme
This time, LK has released six kryakmi, two of which were written in human language C. Let's start the analysis. Link , archive , sample from the article .
SHADOW
In the description of the task is written:
Oke, everything is clean. We look at the import:
')
At this stage, without digging up dysasm listing (it is small, see offset 00402310), you can understand the logic of the application:
Obviously, we need to hook the driver. We load the r3 archetype debugger “Olya”, set a bryak on CreateServiceA, DeviceIoControl and click F9 (there is no anti-debugging). The breakpoint on CreateServiceA is immediately triggered, the stack looks like this:
We notice the path to our driver, copy it somewhere. Klatsay F9, catch another stop at the same function:
It may seem to you that this is the same driver, but take a closer look: the names are a little different. We will keep it too. Klatsay F9, in front of us there is a console with a request to enter some data:
Enter random send. Immediately triggered on DeviceIoControl:
Here we can contemplate our bundle of meyl: the series, which is transmitted by the third and fifth parameters, respectively. The fourth and sixth argument is the size of the buffers (including zero). We trace in the debugger to ret, then before one. As a result, we will see the following picture:
In other words, if DeviceIoControl returned a non-zero value, the crack is resolved. Well, let's move on to learning the first driver. DriverEntry:
DeviceIoControl Handler:
Cherished Validate:
To reverse this feature is not difficult. However, let us remember that we have a second driver, about which we do not yet know anything. Its driverentry:
An interesting movie! It looks like a real driver filter. We look at the handler:
What we see here:
Thus, taking into account all the checks, you can jot down something like this:
The GetMD5 function is the most standard one taken from here . Compile, run:
Solved. I say goodbye to this.
SHADOW
In the description of the task is written:
“Ollydbg will not save you, researchers! The game will be played in the dark corners of the operating system kernel. Do you have the courage to know the hidden places of virtual reality? Shadow is waiting for you, find him! ”The hint is clear. We make a couple of runs with our sample analyzers:
Removed under spoiler
Oke, everything is clean. We look at the import:
')
Removed under spoiler
At this stage, without digging up dysasm listing (it is small, see offset 00402310), you can understand the logic of the application:
- Driver is loading (CreateService)
- Some parameters are passed to it (DeviceIoControl)
- Driver is doing something
- ???
Obviously, we need to hook the driver. We load the r3 archetype debugger “Olya”, set a bryak on CreateServiceA, DeviceIoControl and click F9 (there is no anti-debugging). The breakpoint on CreateServiceA is immediately triggered, the stack looks like this:
Removed under spoiler
We notice the path to our driver, copy it somewhere. Klatsay F9, catch another stop at the same function:
Removed under spoiler
It may seem to you that this is the same driver, but take a closer look: the names are a little different. We will keep it too. Klatsay F9, in front of us there is a console with a request to enter some data:
Removed under spoiler
Enter random send. Immediately triggered on DeviceIoControl:
Removed under spoiler
Here we can contemplate our bundle of meyl: the series, which is transmitted by the third and fifth parameters, respectively. The fourth and sixth argument is the size of the buffers (including zero). We trace in the debugger to ret, then before one. As a result, we will see the following picture:
Removed under spoiler
In other words, if DeviceIoControl returned a non-zero value, the crack is resolved. Well, let's move on to learning the first driver. DriverEntry:
Removed under spoiler
DeviceIoControl Handler:
Removed under spoiler
Cherished Validate:
Removed under spoiler
To reverse this feature is not difficult. However, let us remember that we have a second driver, about which we do not yet know anything. Its driverentry:
Removed under spoiler
An interesting movie! It looks like a real driver filter. We look at the handler:
Removed under spoiler
What we see here:
- The ValidateStr function is responsible for the additional validation of our primary data: only the characters A..Z + a..z + 0..9 + '.' + '@'. I would have torn off my hands to the person who added such a check - personally, my meil does not pass it, it contains the symbol '-'
- The ModifyMail function changes our file as follows:Removed under spoiler
- IofCallDriver transfers control to the main driver with already changed data
Thus, taking into account all the checks, you can jot down something like this:
Removed under spoiler
#include "main.h" char mail[257]; char hashes[32][33]; void main() { for (;;) { printf_s("Enter your name (1 chars min and 256 chars max, only A..Z + a..z + '.' + '@'):\n"); fgets(mail, 257, stdin); int ln = strlen(mail) - 1; if (mail[ln] == '\n') mail[ln] = '\x00'; else ln++; if (ln < 1) continue; for (int i = 0; i < ln; i++) { if ((mail[i] < '0' || mail[i] > '9') && mail[i] != '.' && mail[i] != '@') { if (i & 1) mail[i] &= 0xDF; else mail[i] |= 0x20; } } //change chars case GetMD5(mail, ln, mail); for (int i = 0; i < 32; i++) { if (mail[i] < '0' || mail[i] > '9') { mail[i] &= 0xDF; GetMD5(mail, 32, hashes[i]); mail[i] |= 0x20; } else GetMD5(mail, 32, hashes[i]); } for (int i = 0; i < 32; i++) mail[i] = hashes[i][i]; printf("%s\n", mail); } } The GetMD5 function is the most standard one taken from here . Compile, run:
Removed under spoiler
Solved. I say goodbye to this.
Source: https://habr.com/ru/post/343342/
All Articles