August 26, 2016 at 04:04Reverse engineering test crackme from Kaspersky Lab v2.0
In continuation of my previous analysis, “Reverse engineering test crackme from Kaspersky Lab . ” I found another crackme option from Kaspersky Lab on the Internet . The author applied brute force to solve it. This crude "cracker" method will not suit us here. We are interested in parsing the license key verification algorithm. You can, of course, make a huge selection of the right keys and try to find a pattern, but it seems to me that it’s better to reverse it a bit. So, let's begin. The beginning of crackme is the same as in the previous article: the key must contain 19 characters, each 5th character must be a “-” and all characters must be numbers. Let's move on to the interesting. We use 1234-5678-9012-3456 as a trial key.
The selected section of code contains an algorithm for checking key blocks. We will analyze it in detail.
On this section of the code, the operation of summing the hexadecimal codes of the block characters in this order is performed - the first three characters of the key block are added (or rather, their hexadecimal codes) and the code of the last block symbol is added three times to this sum (for example, if our first key block is 1234, then this amount will look like this 31h + 32h + 33h + 34h + 34h + 34h = 132h) and then this number is entered into the battery (RAX). Next is the key line of code:
This line stores the result of the following operation in ECX: the code of the last character of the block is stored in RCX and the value stored in RAX is added to this code, and as we remember, the result of the operation from the previous step is stored there. After, 150h is deducted from this amount. In our example, it will look like this: 34h + 132h-150h = 16h. Then this value is pushed onto the stack with the following line:
And the program performs such an operation with each block of the key, simultaneously summing up the results pushed onto the data stack in the r10 register. After all the results are pushed onto the stack and their sum is pushed to the r10 register, the program will divide the contents of the r10 register into 4 (shr r10d, 2) and check for equality each pushed value on the stack with the result obtained from division. If the values are equal, then the verification is carried out further, if not, then the program will say that the key is incorrect. According to the results of this analysis, we have the following - the calculation results, according to the algorithm at 140001091, for each block should be equal to each other . If we try the key 1234-1234-1234-1234, then the verification will pass this step and the last stage of the verification will begin:
This section of code controls that the arrangement of characters in each subsequent block of the key does not coincide with the arrangement of characters in the previous block. We will generate a key, according to the conclusions made. Let's try 9870-5781-1872-7503
Excellent!
The selected section of code contains an algorithm for checking key blocks. We will analyze it in detail.
000000014000106E | movsx eax,byte ptr ds:[r9]
0000000140001072 | add al,byte ptr ds:[r9+1]
0000000140001076 | add al,byte ptr ds:[r9+2]
000000014000107A | movsx ecx,byte ptr ds:[r9+3]
000000014000107F | add eax,ecx
0000000140001081 | add eax,ecx
0000000140001083 | add eax,ecxOn this section of the code, the operation of summing the hexadecimal codes of the block characters in this order is performed - the first three characters of the key block are added (or rather, their hexadecimal codes) and the code of the last block symbol is added three times to this sum (for example, if our first key block is 1234, then this amount will look like this 31h + 32h + 33h + 34h + 34h + 34h = 132h) and then this number is entered into the battery (RAX). Next is the key line of code:
0000000140001091 | lea ecx,dword ptr ds:[rcx+rax-150]This line stores the result of the following operation in ECX: the code of the last character of the block is stored in RCX and the value stored in RAX is added to this code, and as we remember, the result of the operation from the previous step is stored there. After, 150h is deducted from this amount. In our example, it will look like this: 34h + 132h-150h = 16h. Then this value is pushed onto the stack with the following line:
0000000140001098 | mov dword ptr ds:[rbx-4],ecxAnd the program performs such an operation with each block of the key, simultaneously summing up the results pushed onto the data stack in the r10 register. After all the results are pushed onto the stack and their sum is pushed to the r10 register, the program will divide the contents of the r10 register into 4 (shr r10d, 2) and check for equality each pushed value on the stack with the result obtained from division. If the values are equal, then the verification is carried out further, if not, then the program will say that the key is incorrect. According to the results of this analysis, we have the following - the calculation results, according to the algorithm at 140001091, for each block should be equal to each other . If we try the key 1234-1234-1234-1234, then the verification will pass this step and the last stage of the verification will begin:
This section of code controls that the arrangement of characters in each subsequent block of the key does not coincide with the arrangement of characters in the previous block. We will generate a key, according to the conclusions made. Let's try 9870-5781-1872-7503
Excellent!
