Charm Solitaire game defense study

About 7-8 years ago, I accidentally came across a CharmSolitaire game, copied along with other games from another screw in the process of sharing information. This is not an ordinary card solitaire. In the unregistered version, the game has one hour, and only half of the levels are open. In that copy, time is almost over. I did not have the money to buy, so most likely I would delete it. But at that time I was a little keen on burglary and decided to try to find the registration code. The experience was quite interesting. The article describes the main features of protection, as well as how security through obscurity can weaken it.







There is no key in the open form in the article, but whoever is interested can find it on his own.



All actions you perform at your own risk.

')

Protection research

We load the file into IDA, launch the game and press the “Key” button. Enter something, for example 123321, and look through ArtMoney.







We put hardware breakpoint on this address. Switch to the game window, skip the breakpoint trigger until the game window is active. Click OK, breakpoint works.



Press Ctrl + F7 (Run until return) until we get from the system dll to the process space. This will be the message handling procedure for Controls :: TWinControl :: DefaultHandler (). We continue to exit the functions until we get to the call Controls :: TControl :: GetText (void):



The variable [ebp + var_8] is a pointer to the line with the entered code. Further we see the sub_4C23A8 () function call and the conditional transition. In the strings _str_WKeyError and _str_WRegistrationThanks you can guess that sub_4C23A8 () is the key verification function.



From the instructions at address 004C2473 it can be seen that the length of the string should be 18h, that is, 24 characters. OK, we set breakpoint, we launch, we enter key 123456789012345678901234.



The sub_4924D0 procedure performs some string manipulations and translates the result into int64.



Pseudo code:

 mixed_str_14 = mix_symbols_492688(key); v64_4 = StrToInt64Def(mixed_str_14, 0); while (v64_4[i] & 0x7F > 0) (string)p_res_10 += (char)v64_4[i] & 0x7F, i++; 

The function mix_symbols_492688 works like this - the values ​​from the first half of the line become odd places (if we count from 0), from the second one to even ones. Our line turns into 314253647586970819203142.



In the StrToInt64Def function, another ValInt64 system function is called. It has one feature - if there are still characters left after processing, then the current position is returned to the output variable (code), otherwise 0. Processing ends if the current value exceeds 0x0CCCCCCCCCCCCCCC (because 0x0CCCCCCCCCCCC = 0x7FFFFFFFFFFFFFFFF / 0x0A; 0x0A is base number systems). In StrToInt64Def there is a check for this, and if non-0 returned to the code, the default value is returned instead of the result (in this case, 0).



314253647586970819203142 clearly exceeds this value. Take for example the code 0x0CCCCCCCCCCCCCCC. Translate into the decimal system and perform the actions inverse to the actions of the function mix_symbols_492688 - we write odd characters in the first half, even in the second:

 0x0CCCCCCCCCCCCCCC = 922337203685477580 000000922337203685477580 0 0 0 2 3 7 0 6 5 7 5 0 0 0 0 9 2 3 2 3 8 4 7 8 000237065750000923238478 

We start again, we enter a new code, we return to the function check_key_4C23A8.



First, take a look at the sub_492C94 function. The constants 20h, 09h, 0Dh, 0Ah, in the comparison instructions say that there is some kind of work with the text. A more detailed examination shows that this function checks whether the contents of mem_stream_decrypted_14 are text. Let's call it is_text_492C94.



The main work takes place in the sub_492B48 function. There, using the key, data from mem_stream_encrypted_10 is decrypted, into which the contents of the file CharmSolitaire.udf were uploaded. You can look at it in the HEX-editor. In the beginning there is a block, where every 8 bytes is 0x33. Interesting, but not very clear how to use it. Go ahead.





Pseudocode:

 bytes_read = mem_stream_encrypted->read(buf, 8); for (i = 0; i < 8; i++) buf ^= key[i]; if (bytes_read == 8) { sub_492A6C(buf, out decrypted_buf); for (i = 0; i < 8; i++) decrypted_buf ^= key[i]; mem_stream_decrypted->write(decrypted_buf, bytes_read); } else { mem_stream_decrypted->write(buf, bytes_read); } 

First, the XOR is done with the key

Then, if the number of bytes read is equal to 8, the sub_492A6C procedure is called, which in some way shuffles the bits of the result.

Then again the XOR is done with the key.

The result is written to the output buffer.

If not equal (the last bytes of the encrypted buffer), then nothing is called, and the second XOR is not done.



sub_492A6C is a nested function, passed to the ebp parent function. Pseudocode is quite large, easier to describe in words. It takes 8 bytes as input, it makes up the first byte of the result from the first bits, the second byte from the second bits, and so on.

 (   ) 11111111 10000000 00000000 10000000 00000000 10000000 00000000 -> 10000000 00000000 10000000 00000000 10000000 00000000 10000000 00000000 10000000 

It seems to me like this dialogue:

- Let's encrypt via XOR with a key.

- No, let's XOR, then here and there we turn, and again XOR. To completely was incomprehensible.

- Right, come on.



In other words, an 8x8-bit matrix is ​​drawn around the main diagonal (transposed), after which a repeated XOR is made with the key. Therein lies the mistake.

Breaking into

What are we doing? We xorim a 8x8 bit block with key bytes, reverse this matrix, and xorim again with the same key. It turns out that the bits on the main diagonal are not encrypted at all. The remaining bits have a dependency:

 C[x][y] ^ K[x][y] ^ K[y][x] = D[y][x] C[y][x] ^ K[y][x] ^ K[x][y] = D[x][y]  C -  , D -  , K - , x  y -    . 

The elements K [x] [y] ^ K [y] [x] form a symmetric matrix T [x] [y]:

 T[x][y] = T[y][x] C[x][y] ^ T[x][y] = D[y][x] C[y][x] ^ T[x][y] = D[x][y] 

This means that we do not need to search for all the original bits of the key. It can be assumed that the upper triangle of the matrix of the key is zero. Then the upper and lower triangles of the matrix T will be equal to the lower triangle of the key.



This allows you to reduce the number of options for busting more than 2 times - half of the matrix + diagonal. The number of unknown bits: (7 + 6 + 5 + 4 + 3 + 2 + 1) = 28. Total 2 ^ 28 options, and after decrypting the matrix should get the text.



Search method:

- we read the encrypted block of 8 bytes

- we place the current value of the counter in the lower triangle of the key

- we do XOR with the ciphered block

- we turn the received matrix

- doing XOR again

- repeat

- after decryption we check for text; if the text did not work, then the key is wrong

- to speed up the search, you can check each decrypted block



Types of bits in the matrix (low bit on the left):

 #define FIXED_0 0 #define FIXED_1 1 #define UNKNOWN 2 const unsigned char bitTypes[8][8] = { {0, 0, 0, 0, 0, 0, 0, 0}, {2, 0, 0, 0, 0, 0, 0, 0}, {2, 2, 0, 0, 0, 0, 0, 0}, {2, 2, 2, 0, 0, 0, 0, 0}, {2, 2, 2, 2, 0, 0, 0, 0}, {2, 2, 2, 2, 2, 0, 0, 0}, {2, 2, 2, 2, 2, 2, 0, 0}, {2, 2, 2, 2, 2, 2, 2, 0} }; 

The current value of the brute force counter is distributed over the UNKNOWN bits (there is a code at the end of the article).



There is also a curious feature. Making XOR parts that are on the same side of the '=' sign, we get:

 C[x][y] ^ K[x][y] ^ K[y][x] ^ C[y][x] ^ K[y][x] ^ K[x][y] = D[y][x] ^ D[x][y] C[x][y] ^ C[y][x] ^ (K[x][y] ^ K[x][y]) ^ (K[y][x] ^ K[y][x]) = D[y][x] ^ D[x][y] C[x][y] ^ C[y][x] = D[y][x] ^ D[x][y] 

The XOR of two symmetric ciphertext bits is equal to the XOR of these decrypted text bits. Perhaps this could be useful in some cases, but here it is not important.

Not so simple

1. After the search is completed, 65 text variants will be obtained.



On my system, it took about 15-20 minutes. You can view them all manually and select the appropriate one. But we have a hint - every 8th byte at the beginning of the file is 0x33. Now we know how it appears - it is (high bits of a block of 8 characters) XOR (8th byte of matrix T). If we assume that the text is in Latin, then the high-order bits are everywhere 0, and 0x33 is the 8th byte of the matrix in open form.



Then you can sort out 256 times less options, that is, 2 ^ 20:

 #define FIXED_0 0 #define FIXED_1 1 #define UNKNOWN 2 const unsigned char bitTypes[8][8] = { {0, 0, 0, 0, 0, 0, 0, 0}, {2, 0, 0, 0, 0, 0, 0, 0}, {2, 2, 0, 0, 0, 0, 0, 0}, {2, 2, 2, 0, 0, 0, 0, 0}, {2, 2, 2, 2, 0, 0, 0, 0}, {2, 2, 2, 2, 2, 0, 0, 0}, {2, 2, 2, 2, 2, 2, 0, 0}, {1, 1, 0, 0, 1, 1, 0, 0} }; 

After starting the search, we find the only option. This will be the intended key. But in this form it does not fit.



2. If the number of bytes in the file is not a multiple of 8, then the remainder is obtained by encrypted plain byte XOR with the key.



Here you need to check only manually - look at the decrypted text, assume what the last bytes can be, and on the basis of them restore the matrix.



Levels after the 30th are also encrypted. Level is an XML file. If the key is inaccurate, then there may be different problems - from artifacts in graphics to an exception with a message about incorrect XML markup. Based on the CharmSolitaire.udf file, you can find 3 lower bytes of the real key and complete it with level 39 with this key. Its length is 0x246F, that is, you can find all 7 unknown bytes.

Result

8 bytes of the key:

Bre6Vqd3



Latin text at the beginning of the file:

Some years ago, she lived there.



Program Code: