It is recommended to develop 2-3 verification algorithms, for example, 1-2 digits should be divided by 3, and 3-7 superimposed by some algorithm on the user’s name should give a total of 4. These two checks are carried out in various places with a sufficiently large time difference – having hacked the first method, the hacker will not guess about the existence of several more that will manifest over time.
Tip _2. In any case, do not take any action after checking. For some unknown reason, most programs look something like this
In the example, a certain procedure checks the code and, if there is a discrepancy, takes active actions that literally shout “here it is where the protection is!!”. The best step is to wait a day or two (or at least 15 minutes). Moreover, all verification actions should be attributed as far as possible from the issuance of messages and other actions taken when an incorrect code is detected.
Tip _3 Distractions.
In addition to the actual code verification functions, it is very good to make a couple of fake ones – they will be called after entering the code, carry out active manipulations with the entered value, issue messages about the incorrectness of the entered code … – i.e. distract attention from the real check.
Tip _4. Do not store the test results in a variable and do not use it to explicitly restrict the functions of an unregistered program.
A classic example of a violation of this rule
Thus, elementary analysis shows that the LegalCopy variable stores the result of the check and by putting a breakpoint on it, you can catch the check itself. By editing these values in memory, you can temporarily make a copy of the “registered” one, and setting a breakpoint to change this variable will bring it to the place of its verification. And hacking boils down to the fact that the code verification function is reduced to two assembler commands:
Tip _5. (follows from 9) Do not store the results of the check on disk or in the registry.
A typical mistake is that they found out that the copy was registered and made a label somewhere. Catching it is quite simple (see the description of REGMON and FILEMON). The best way is to save the password and username in the form in which he entered them. Then, each time the program starts, check the correctness of this code, but do not forget the Advice _11. Do not check anything immediately when launching the application or immediately after reading the saved name or code. Remember that reading the code and entering it in the registration window are identical in terms of security measures – duplication in different memory areas, encryption…
Conclusions: we will arrange code verification in several places of the program, while applying several verification algorithms, we will not use the API.In addition, it is worth doing a few distracting maneuvers.