Reverse engineering test crackme from Kaspersky Lab
Greetings to the community! A long time ago, in 2013, the post “Reverse engineering at the interview: how we hire” was published on Habré. It offered a test crackme for applicants for the position of virus analyst. After making sure that there is no complete analysis of the test file on the Internet, I decided to write my own analysis. So let's get started. Crackme 64-bit. Run it in IDA Pro.
We see three functions on the left of the list of functions: start is the function with which program execution begins, DialogFunc — this function communicates with us and some function sub_140001000. Consider the dialogue function. We decompile it with Hex Rays.
The branching of conditions is striking, according to which, if some function sub_140001000 returns TRUE, a message will appear informing us of a job well done, otherwise it is not true. Let us analyze our cherished function sub_140001000. If we pass it through a decompiler, we will see that a pointer of just one value is passed as an argument. Probably, this value is taken from the dialog box and is an input key. Now consider the assembler listing. There is a first verification of the condition of accuracy of the entered data. If the condition is satisfied, the program is executed further; if not, then the return is from the subroutine.
')
Run our crackme under the debugger. Let's use x64dbg . We set breakpoint at our first check. As the input key, use the set of numbers 1234567.
As you can see, the edx register value and the number 13h are checked (in decimal system it is 19). This is probably a check on the number of entered key characters (we have 7 and the number in the edx number is 7). Let's try to enter a different number of characters. Run the debugger again. We introduce 9 numbers 123456789.
It seems that the way it is. So our key must contain 19 characters. Enter 19 characters 1234567890123456789 and proceed to the next stage of verification.
At this step, every fifth key symbol is checked for equality to the value 2Dh. The fact is that the number 2Dh is a hexadecimal character code "-". Those. our key should be xxxx-xxxx-xxxx-xxxx. We use 1234-5678-9012-3456 as a key and proceed to the next step.
And in the next step, characters are checked for numerical identity. The verification procedure is as follows: a character is taken from the key (every fifth character of the key is not counted) and the number -30 is added to its hexadecimal code and the result is compared with the number 9. If less, then the next key character is taken for verification, if A message is displayed that the key is incorrect. Go ahead.
At this step, it is verified that the sums of the numbers in the blocks are equal. The figure above highlights the block of code that counts the sum of numbers and the stack area where these sums are added. In parallel, the sums of the blocks are summed up among themselves and entered into the register r10. Then the result is divided in the register r10 by 4 (shr r10d, 2 - the shift by 2 bits is equivalent to division by 4) and the comparison of the value from the register r10 with the previously entered values in the stack. Fine. We make so that the sums of digits of each key block are equal (for example 1122-0123-2112-0006) and move on to the next verification step.
The code section highlighted in the figure above checks that the location of the characters in each subsequent key block does not match the previous one . As a result, our key looks like 1478-7814-1478-7814. We are checking.
Great job!
We see three functions on the left of the list of functions: start is the function with which program execution begins, DialogFunc — this function communicates with us and some function sub_140001000. Consider the dialogue function. We decompile it with Hex Rays.
The branching of conditions is striking, according to which, if some function sub_140001000 returns TRUE, a message will appear informing us of a job well done, otherwise it is not true. Let us analyze our cherished function sub_140001000. If we pass it through a decompiler, we will see that a pointer of just one value is passed as an argument. Probably, this value is taken from the dialog box and is an input key. Now consider the assembler listing. There is a first verification of the condition of accuracy of the entered data. If the condition is satisfied, the program is executed further; if not, then the return is from the subroutine.
')
Run our crackme under the debugger. Let's use x64dbg . We set breakpoint at our first check. As the input key, use the set of numbers 1234567.
As you can see, the edx register value and the number 13h are checked (in decimal system it is 19). This is probably a check on the number of entered key characters (we have 7 and the number in the edx number is 7). Let's try to enter a different number of characters. Run the debugger again. We introduce 9 numbers 123456789.
It seems that the way it is. So our key must contain 19 characters. Enter 19 characters 1234567890123456789 and proceed to the next stage of verification.
At this step, every fifth key symbol is checked for equality to the value 2Dh. The fact is that the number 2Dh is a hexadecimal character code "-". Those. our key should be xxxx-xxxx-xxxx-xxxx. We use 1234-5678-9012-3456 as a key and proceed to the next step.
And in the next step, characters are checked for numerical identity. The verification procedure is as follows: a character is taken from the key (every fifth character of the key is not counted) and the number -30 is added to its hexadecimal code and the result is compared with the number 9. If less, then the next key character is taken for verification, if A message is displayed that the key is incorrect. Go ahead.
At this step, it is verified that the sums of the numbers in the blocks are equal. The figure above highlights the block of code that counts the sum of numbers and the stack area where these sums are added. In parallel, the sums of the blocks are summed up among themselves and entered into the register r10. Then the result is divided in the register r10 by 4 (shr r10d, 2 - the shift by 2 bits is equivalent to division by 4) and the comparison of the value from the register r10 with the previously entered values in the stack. Fine. We make so that the sums of digits of each key block are equal (for example 1122-0123-2112-0006) and move on to the next verification step.
The code section highlighted in the figure above checks that the location of the characters in each subsequent key block does not match the previous one . As a result, our key looks like 1478-7814-1478-7814. We are checking.
Great job!
Source: https://habr.com/ru/post/308548/
All Articles