Protect sharing software from brute force cracking

In the software cracking method, "brute-force cracking" (also known as "brute-force cracking") is the most popular and effective method. All functions of the software that has been "cracked" are available only in the authorized version. I am also a software developer. I am so disgusted with the theft of "intellectual property rights" that I have shared my personal experience in preventing "brute-force" attacks, and shared my experience with you.

I. Understanding the "brute-force" means

First, we will discuss how to crack the organization. No matter how skilled the Organization is, they will follow the basic steps below to complete the "brute-force ".

1. Determine whether the software is shelled ".

2. Run the brute-force tool to display the source program of the software.

3. Analyze the software source program and find the registration information statement.

4. Modify the registration information source program so that the registration function does not take effect or the registration code is displayed.

From the above steps, it is not difficult to see that the reason why the software is easily cracked is mainly because of the carelessness of the developer or the imperfect compilation technology, which leads to the existence of many vulnerabilities in the source program. As long as developers set up multiple levels of obstacles when writing source programs, they can prevent "cracking" to some extent (I dare not boast "Haikou ", to say that your method can completely eliminate "brute-force cracking", but at least it can enhance the registration protection performance of the software ).

Ii. methods to prevent brute-force cracking

"Shelling" software and adding anti-tracking code

1. Before the software is released, the executable program must be shelled so that others cannot directly modify the source program. "Shelling" can take advantage of many excellent "Shelling" tools, and it is best to use more than two tools to "shell" the program ". In addition, the anti-tracking feature provided by these tools should be used whenever possible.

TIPS:

It is best for developers to design their own "Shelling" methods. If ready-made tools are used, we recommend that you do not select popular tools because these tools have been widely studied and have a general "Shelling" approach.

2. In addition to shell processing, it is best to embed anti-tracking code during software development to prevent "brute-force" tools from finding software registration vulnerabilities.

There are many anti-tracking methods for the software. Common examples are the random change of the memory address of key code using the spending command. The following is an example.

The initial source code of the program is as follows:

Start _:
Xor eax, 1
Add eax, 2
Jmp label1
Label1: xor eax, 3
Add eax, 4
Xor eax, 5
End start _
 

Compile the source program first, and then use W32Dasm for disassembly. The result of the disassembly is the same as that of the source code. Next we will make the following changes to the above source code:

Start _:
Xor eax, 1
Add eax, 2
Jnz label1 \ note that the following two-sentence conditional jump is used instead: jmp label1
Jz label1
Db 0E8h \ pay attention to the difference between this useless byte and the source program
Label1: xor eax, 3
Add eax, 4
Xor eax, 5
End start _
 

Compile the source program and then use W32Dasm for disassembly. The following result is obtained: the results of the W32Dasm disassembly are different from those of the prepared Assembly command. The program's "real" function cannot be understood from the results of the disassembly. This is because the above changes have made "error guidance" in the disassembly work of W32Dasm, so that it can make mistakes.

Increases the difficulty of registering an authentication algorithm

The source program of registration and authentication is a breakthrough in cracking organizations. The difficulty of registering authentication algorithms directly affects the chances of software being cracked. To increase the difficulty of registering an authentication algorithm, you can start from the following aspects.

1. Select a relatively complex algorithm for registration and Development (RSA can be selected in the current encryption algorithm ). Of course, the best way is to write your own algorithms. If some common cryptographic algorithms are used, this is not much different from the introduction. After all, these common algorithms have been thoroughly studied by the "brute-force" experts and there is still security, however, using self-designed algorithms is different, and human thinking is different, which greatly increases the difficulty of cracking.

2. Check that the registration information code is better and better. If you write the registration module together, it is like placing the treasure in the safe, although it is very strong and difficult to open, but for the unlocking experts, once you open it, the treasure inside is lost. The specific operation method is: when the software is registered, do not let it call the same function or determine the same global flag.

3. Insert a large amount of useless computing code when checking registration information. This is intended to mislead the decryptor and make them think they have found a real method of cracking, but they find it ineffective after trying it. It's like soldiers on the battlefield disguise themselves with "camouflage servers" and straw. It's hard for the enemy to find out where they are.

Add Registration Information

After increasing the difficulty of registering an authentication algorithm, you also need to work hard on the registration information step to consolidate the anti-cracking walls.

1. Excellent random number algorithms can be used to make software registration methods random. For example, in addition to checking the registration code at startup, you can also randomly check the registration code at a certain period of time when the software is running.

2. One machine and one code protection are adopted. After this design, the registration code on one computer cannot be used on another computer, just as many software generates registration codes based on machine codes.

3. Delete the function code of the trial version. If the trial version is different from the official version. In the trial version, do not just lock the relevant menu, but completely delete the relevant function code.

Enhances the integrity of the software's source program.

In the process of developing shared software, in addition to strengthening the local registration code, you must also consider the integrity of the software program. The following aspects can be improved.

1. Added integrity checks for the software itself. This includes checking disk files and memory images to prevent unauthorized program modification for the purpose of cracking.

2. Hide the registration information code. Do not use common registration code names such as "IsLicensedVersion ()" and "key. dat. In addition, all software protection-related strings should not be stored in executable files in plain text, preferably dynamic generation.

3. Give the user as little information as possible, because these clues may cause the decrypted to go directly to the protected kernel. The software can be designed to mark somewhere in the system and automatically stop working after a period of time without prompting the user immediately after detecting a cracking attempt.

4. Do not rely on common functions such as "GetLocalTime ()" and "GetSystemTime ()" to obtain the system time. You can obtain the system time information by reading the modification time of key system files.

5. if the keyfile protection method is used, the size of the keyfile should not be too small. The structure can be designed to be complex, perform complex operations and checks on different parts of the keyfile in different places in the program.

TIPS:

Some of the information statements mentioned above are the most basic Breakthrough points of "violent organization". If these prompts are clearly displayed during the software development process, no doubt they will commit suicide. For these "brute-force" experts, with these tips, the software will surely have a devastating blow. Therefore, developers must be careful not to make such low-level mistakes.

It is indeed a complex and arduous task to prevent the "brute-force" Attack of shared software. We need to carefully study the thinking model of the "brute-force" person. First, let us assume that the attacker may adopt the "brute-force cracking" method, and then take the right remedy to strengthen some weak links. It can be said that "brute-force cracking" and "brute-force cracking" are an intellectual game, just like "cat and mouse". Although "brute-force cracking" is pervasive, however, developers can leave them away as long as they adopt the "riot" method properly.