A study of the defense of the game Limbo. Keygen

Hello. Many people know about this wonderful game - LIMBO ! You even probably bought it in Steam , or downloaded it from torrents ...
I also bought it once ( which I advise you too ! ), And went through). But, as always, this was not enough for me, and, out of sports interest, I decided to study its protection. So there was a keygen to the game LIMBO .

In this article I will tell and show you how I did it.

Before you begin, remember: all the actions you perform at your own peril and risk. Respect the work of game developers.

Stage One: Examination of the Patient

The full installer of the game can be downloaded here . After installing the game, first of all, as usual, we find out what the main executable file is written on. I will use for this ExeInfo PE .



We see: Visual Studio 2008 . IDA Pro does a great job of it, so we'll send it there. I will use a bunch of IDA Pro + HexRays , i.e. with a decompiler - to speed up the work.

Stage Two: What Are We Looking For?

First of all, let's give Idea to analyze limbo.exe - the main executable file of the game.

Next, you need to determine what exactly we, in fact, want to find here. Run the game:



We see the magic inscription " UNLOCK FULL GAME ". Click on it. Next, we are expected by an unexpected person (at least, when I first selected this menu item, I expected to see the input field on the graphic engine of the game, or something like that, but it turned out to be much simpler ...):



Yes Yes! It is an ordinary window! It’s easier for us. Let's try to enter something, and press Unlock . Something like this:



Well , let's look at the text in the IDA so that we can build on it and find a place to check. And then a bummer was waiting for me ...
According to the text of the message in the error window, Ida did not find anything for me! Content search through Total Commander told me the same thing . The message may be encrypted. You can try to find a window call based on a MessageBoxA / W call . But, I went the other way, which, for some reason, is described in few articles.

Stage Three: Click Me

We will proceed as follows. We’ll open any resource editor that is convenient for you, drag an exe-worker into it, find the key input dialog box, and in it the Unlock button . No sooner said than done:



On the screen, I highlighted the ID of our button. By it we will search exactly where the click is processed. Open Ida , press Alt + I ( Search -> immediate value ...), enter the number 203 (without 0x , because decimal), and see what happens. And this was found:



See those lines that Ida marked as ; nIDDlgItem ? We’ll start with them. Double-click on the first of these results:



With a green arrow, I designated the place that Ida pointed to , and a little lower ( habit: scroll above / below the desired location ) - the arrow indicates the place of calling one interesting API function: GetDlgItemTextA . Judging by the name according to MSDN , this function receives the text of the specified window element in the buffer.

Why didn’t I immediately search by input field ID ? Of course, it was possible to do so. But, you never know what happens after the button is pressed, even before the text is subtracted from the field.

So, let’s track where the received serial goes. We scroll through the listing to see the whole place the API function was called:



My “ soapy ” look tells me that the received buffer ( Ida designated it as var_134 ) is passed directly to the function following the call to GetDlgItemTextA , which returns a zero or non-zero value in al (similar to the result of checking the key). Let's check the guess ...

Stage Four: Decompilation

We go into the function. We see there a jump to another address - go to it. We see the normal code, so feel free to click F5 there (call HexRays Decompiler ).


Now you can try to bring this code to a more adequate one.

First of all, we notice that the input parameter is of type int , which is not entirely true. Let's designate it as " char * ". To do this, stand in the name of the function and press the Y ( Set item type ) key there . We fix the type and name of the input parameter (I called it as key ).

Next ... We see the line:

  if ( strlen(key) != 37 || key[5] != 45 || key[11] != 45 || key[17] != 45 || key[23] != 45 || key[30] != 45 )

Because our input parameter is a string, let's fix it in the places where the characters of the key are compared with numbers, and compare them with the characters. To do this, on each of these numbers, press R ( Char ). Already better:

  if ( strlen(key) != 37 || key[5] != '-' || key[11] != '-' || key[17] != '-' || key[23] != '-' || key[30] != '-' )

Now the loop:


For clarity, we give v3 the name i , because It looks like it is being used as an iterator. Rename by pressing the name key N ( Name ).

We notice that in the loop, each character is taken from the key, and transferred to a function that is still unknown to us. I propose to find out what this function is. Double click on it. We see there a call to another function, go there. And, here it is - processing a single character! ( There is a lot of work for the R key here , but I will only show the result of processing immediately ).


Perfectly! Now we go back with the Esc key to the main function. We notice that the IDA itself redefined for us the type of result returned by the symbol processing function. We name it further, designate types, and get the following loop code:


If you notice, then there is one interesting decompiler bug. We see that the variable designated by me as itr is not incremented at all. To find out what actually happens, click RMB -> Copy to assembly , and see where our itr is used . We find out: it is incremented directly in this cycle (which was to be expected), and before the cycle it is reset. We will take this into account when writing keygen.

Now the second part of the key verification function ... We still have one unexplored function, which, by the way, is very similar to the CRC32 counting function . The result of processing (albeit in a hurry, but readable):


Remaining piece (converted):

    crc32 = j_calc_crc32(my_key, 32);
    sprintf(crc32_, "%08x", crc32);
    result = strcmp(crc32_, &my_key[32]) == 0;

Stage five: writing keygen

Objective: to determine what exactly happened with the key in order to write the inverse function. I will write, contrary to common sense and issuing HexRays , in Delphi , and you can write in a language that is easier for you.

By debugging, we find out what happened:

1. The game needs a 32- character key without hyphens ( 37 with hyphens ).
2. Taken over the four symbols of the key (not counted hyphens). Each of them is passed through the convert_char function and summed by the formula: sum + = new_c << 5 * (3 - itr) ;
3. Each such amount is converted to a lower-case hex string ( 5 characters ) and glued to the existing one (total 40 characters );
4. Taken CRC32 from the first 32 -x symbols and the resulting string is compared with the remaining eight symbols received in the previous paragraph line;
5. If the lines do not match, our key is incorrect.

Reverse Thinking:

1. Write a function that converts the 40- character hash back to the key;
2. Generate a 32- character hash;
3. Count from it 8 - character CRC32;
4. Glue the lines obtained in steps ( 2 ) and ( 3 );
5. Pass to function ( 1 ) - we get the desired key.

Thoughts on transformative function:

1. Because the input hash was obtained from eight 5- character hash chunks, we will process it the same way, according to the " fives ";
2. Each " five " was obtained from four key characters ;
3. Because during each calculation of the " five ", it shifted 5 bits to the left , it turns out that for each character of the key there is 5 bits ;
4. A careful examination of the convert_char function code leads us to the idea that the character set of the key is limited only to the characters of the set " 0123456789ABCDEFGHJKMNPQRSTVWXYZ ";
5. Total: 32 hash characters are generated from the " fives ". 32% 5 = 24 integer characters and 2 in the remainder - i.e. two characters we just have to regenerate.

Next, consider the CRC32 from the hash:

var
  key, hash, crc32: string;
begin
  hash := GenHash(24);
  crc32 := Crc32b(hash); // нашел первый попавшийся модуль, реализующий данный хэш-алгоритм

Transformer function code:


And finally, the resulting license key retrieval:

  key := Hash2Code(hash + crc32);
  lic_code := Format('%s-%s-%s-%s-%s-%s', [Copy(key, 1, 5),
                                              Copy(key, 6, 5),
                                              Copy(key, 11, 5),
                                              Copy(key, 16, 5),
                                              Copy(key, 21, 6),
                                              Copy(key, 27, 6)
                                              ]);

We check, and ... Entering the generated key activated the game, the activation point disappeared!

Summary

The main thing when writing keygen is to be able to think back. Those. be able to write such an algorithm that will be the reverse of the one you have. This is not an easy task, but it can be solved in most cases.

PS

Perhaps the article was too messy, I don’t know. The main idea that I wanted to convey: keygen is not such a difficult thing, if you have brains, and desire along with perseverance.

PPS

In the next article I will describe how I wrote keygen to another game - Unepic .