Technology for hacking defenses based on a key comparison

Once again, the vast majority of the protections used in practice are based precisely on a key comparison. In fact, both non-standard formatting parameters and other key disk parameters, as well as passwords, registration numbers (codes), and the number of program launches, and the time of free use of the software, and the counter of installed copies, and many other characteristics are essentially the key to protection. And being entered by the user, they are necessarily subject to comparison with the stored reference value, that is, they are calculated for a key comparison.

To crack, the violator first of all needs to study the code of the protected program and understand the logic of the protective mechanism. Therefore, the first step of a hacker is disassembling the program.

Note that there is a widespread misconception among inexperienced programmers that analyzing the protection algorithm is a very time-consuming job, because the disassembler, as a result of its work, issues huge listings that are almost impossible to understand. Authors who adhere to this point of view often even cite for comparison the dependence of the number of lines (tens and hundreds of thousands, millions) obtained by disassembling the program on the number of lines of the program itself.

This is a serious misconception. Yes, indeed, hacking reliable protection is generally a laborious job that requires high qualifications. But to study the logic of the security mechanism, very often a hacker does not need to understand all the disassembled code. Powerful interactive disassemblers that exist today[1] (IDA - Interactive DisAssembler is considered the best of them today) allow you to quickly find protective mechanisms among a huge number of function calls, many transitions and other program commands.

The idea of the way to find a security mechanism is to search for strings associated with the output requests and messages to the user. For example, in the case of password protection, such as "Enter password", "Password OK", "Password incorrect", etc. It is obvious that since the message strings themselves are in the data segment, it is necessary to look for links to such strings. In the vast majority of cases, the security mechanism that compares the entered password with the reference one is located in the vicinity of such links. And the interactive disassembler provides the hacker with enough tools to quickly and easily find these links.

The second step of the hacker is to search for a command to compare the key and conditional transition branches.

For example, in the case of password protection, the following code is expected:

call CheckPassword ; calling the password verification procedure

or ax,ax

jz PasswordOk ; if the password is correct

; switching to the PasswordOk label

. . . ; commands executed in the case of

; invalid password

PasswordOk : . . . ; the main part of the program

It is enough to replace the conditional transition JZ with an unconditional JMP in order for the program to begin to perceive any password as correct. This is the famous hacking technique of replacing just one (!) byte.

Surprisingly, it is widely believed among programmers that password hashing enhances protection. Apparently, this misconception is due to the fact that, firstly, complex mathematical calculations make it difficult to analyze the program code, and, secondly, it is not possible to find an explicitly missing password by looking at the code. In fact, in this case, the hacker again does not need to painstakingly understand the entire protective mechanism, and even more so in mathematical calculations, it is enough to find the "cherished" comparison command and replace the conditional transition with an unconditional one (still only one byte). The only difference in the implementation of such protection is that now the program does not compare the entered password with the original one, but the results of hashing the original password and the entered one. By the way, the same can be said about widespread implementations of password encryption protection. Obviously, in any implementation of password encryption protection, there will necessarily be a comparison command: either the entered password is encrypted and compared with the encrypted standard, or the encrypted standard is decrypted and compared with the user's password.

Note that modern versions of interactive disassemblers allow for contextual search. For an experienced hacker, it is enough to correctly select and specify the mask for the search in order to immediately localize the protective mechanism of the program. For example, hackers use a mask that includes the signature of a known sequence of commands

call ? ; or ax,ax; j?

plus offsets (links) to message lines like "The password is incorrect". In addition, the query language of modern versions of disassemblers for contextual search, along with the notation "arbitrary character" and "any number of arbitrary characters", contains the notation "any number of arbitrary commands" (for example, "; ;" in HIEW), which obviously facilitates the work of the hacker.

!

From all that has been said, it follows that in order to strengthen protection, it is necessary

1) make it difficult to search among the protection mechanism program codes;

2) if possible, avoid direct comparison of the parameter with the reference using comparison commands.

There are many ways to make it difficult to find a protective mechanism. Let's list some recommendations.

* Message strings such as "Correct password", "Enter registration number", which an attacker will first look for, it is better to generate dynamically or encrypt.

* The protective mechanism should not be designed as a separate module, procedure, or function. Accessing such a mechanism from the main program will be easy for a hacker to find. Experts recommend spreading the code of the protection mechanism throughout the program, accessing various procedures, and using undocumented functions. Another tip is to actively use global variables.

* You can control the integrity of critical program fragments by calculating checksums, and do this not once, but from different places in the program.

* When implemented correctly, encryption of the security mechanism has a good effect.

* And although anti-debugging techniques are powerless against modern debuggers, it is desirable to complicate the hacking of the program using anti-debugging techniques. In any case, the hacker will need time to "remove" them.

* Simply increasing the code also makes it more difficult to find a defense mechanism. To confuse the hacker (inexperienced), you can supplement the program with sections of code that are never controlled. At the same time, it is desirable to include "interesting" confusing commands and messages in these sections, that is, to complicate the work of the hacker as much as possible.

* Some protection authors use interrupt address substitution. For example, they copy some vector into any other (less interesting for a hacker), and then access the new address.

There are other ways to complicate the analysis of the program, We emphasize that all of them, as a rule, are associated with the use of original programming techniques.

You can abandon direct comparison commands and explicit conditional transitions:

· using the values obtained from the key in calculations;

· using hidden transitions or

· using transitions to addresses calculated as some functions of the original parameter (you can consider the parameter as an index in the transition table);

· You can try to trick the hacker by using "hidden" comparisons along with explicit comparisons. Explicit comparisons are expected to be revealed initially.

It is also possible to complicate the search for a protective mechanism by using a non-standard implementation of commands or by replacing commands with equivalent ones.
!
It is necessary to pay attention to the fact that all the recommended methods only complicate the hacking of the program or increase the time required to "remove" protection, that is, increase the labor costs of the hacker (depending on the degree of his qualifications).