It will be retrieved later, at offset 0x There is a comparison of the output of both functions at offset 0x and if they match, the code jumps to the good boy. This function computes the hexadecimal value of the serial and XORs it with 0x The final check compares the output of both previous functions and jumps to the good boy if they match:.
This crackme has the same structure has for the 1st crackme. So we will directly jump to the interesting code in the WndProc function. As we will detail later, this function is actually encrypting the password.
At offset 0xF , the counter cl is checked and if it is zero, the code jumps to the good boy. This function sets the provided password to upper case and ensures that all characters are only letters [a-zA-Z].
This function counts how many characters of the encrypted password are correct by decrementing a counter cl , initially set to the length of the password. If all characters are correct, cl should be equal to zero.
As explained in the previous function, cl should be equal to zero if the encrypted password. This crackme is a bit different than the 2 previous ones. KEY at offset 0xD. If the file doesn't exist, the program exits. Then, the code reads 18 bytes from the file. KEY file contains less than 18 bytes. We will see later that this function XORs the serial and computes a checksum.
This latest is XORed with 0x at offset 0x I have noticed several usual patterns in this CrackMe that are interesting to know. First of all, this is a Win32 PE executable. That is still pretty common, though we are starting to see every day more and more x64 software out there. On Windows, everything is a window yes, even the buttons and the inputs.
They communicate with each other by sending messages that are processed in what is called the message loop. This message loops many times goes as you can see in the diagram. What can be seen on the graphic are Win32 API calls.
Understanding this is key in order to know how the program detects when we have pushed each of the menu items. As you can see on IDA, one of the parameters that are passed to the GetMessage function is a pointer to the place where the message is going to be stored. Such message contains several fields, but we are going to focus on two of them which are used to determine which element of the GUI is actuated on this crackme. When creating the main window with CreateWindowEx, one of the parameters is the WndProc, or window procedure, which is the procedure which will manage the messages for the main window, by clicking on its address, we will see that there is one parameter called Msg, which points to the message that is going to be processed.
Then we can see that there is a waterfall of jumps that check different things. Every time that there is a message dispatched to the window is processed by this procedure.
We can assume that what is there is an instance of an MSG Windows structure. First, the type of message is checked, and then the WParam, which gives additional information of a specific type of message.
This is a very common pattern in many crackmes and thus deserves its own analysis. As you know, internally, strings are a succession of bytes encoded using ASCII in this case, though it can also be Unicode that ends with the null byte. This fact is exploited in order to go through such strings char by char. The loops usually look this way there can be variations in the used registers or the registers that return values, but the pattern remains.
In the program, two checksums are calculated using this technique.
0コメント