How to prevent easy language from being cracked, and how to prevent easy language writing programs?

Agree with the upstairs statement that shelling is a good way to do it. As for this tool, you can take a look, but you need to know that it is very likely to be killed and poisoned after packing. It's not very difficult to add shelling, some of them are foolish, just do it all at once or get some sinister tricks, I'll give you an idea.

Suppose the Launch window. The title ≠ self-specified title" then run ("Something, can be a virus, let the cracker have a lesson") or automatically end your program.

1、The insertion of flower instructions,Of course, it is necessary,Some people say that it is useless to add flower instructions,The current decompilation software basically has the function of removing flower instructions,But the difficulty it can go I don't add,It's good to add a little trouble to the cracker!

2. Shelling, many shells now have automatic shelling tools, so is this shell added or not? Same reason as the first point above, plus! Be sure to add, you don't want your program to become a beginner cracker to practice it.

3. The choice of registration method, as far as the most commonly used registration is concerned, it has to be in the form of hardware code + registration code, and other dongles, network verification and other methods still cannot be popularized!

4. The choice of encryption algorithm, don't write your own encryption algorithm, such as disassembling the hardware code, displacement, calculation, and finally getting the registration code, you can tell you very clearly, if you do this, the keygen will appear sooner or later.

5. Choose some relatively mature algorithms, such as RSA and the like, and we will learn the use of RSA in the next section.

6. How to verify the registration code in the program, don't come to a judgment to determine whether it is equal, in that case, the blasting will appear, with some relatively complex methods, which is clearly explained in the tutorial written by a master "spicy teacher" in the easy language forum, and it is highly recommended that you take a look.

7. The use of dark piles, there are many places to verify registration, verify the same from time to time in the process of program running, find that it is cracked and ignore it, automatically exit after a few minutes of operation, and the time is still random!

8. Isn't the front padded shell? After the shelling of the program becomes smaller, then you can judge how big the program file is at the beginning, and find that it is larger than the size after compression, which means that it has been shelled, and it will automatically exit after the same as above.

9. A more advanced dark pile, establish a parameter, judge whether it is cracked at a critical time, if not, of course, there is no problem, if so, change the data of the operation to be carried out, and this parameter will work, so that the result of the final operation of the cracked version is a bunch of garbage data.

10. What to do if there is a crack, this is actually normal, don't go to the heart, hehe, upgrade your program, upgrade every day or every two days, every time you have to verify the relevant ** of the registration code, it turns out to be judged, you change it to if, and then change it to if it is true, it turns out that the registration is successful and pops up the information, and now it is a failure to pop up the information, in short, don't make it very easy for people to locate, and then change the position of the original dark pile, and add the dark pile to some places where there was no dark pile, It's not hard for you to change these, but the cracker is very tired, hehe!

11. One more thing to add, if necessary, encrypt the hardware code, such as MD5 or the like, so that people don't know what hardware code you are taking.

Shell it, but some soft kills will be killed as viruses. However, the anti-cracking is only temporary, and today's masters have made it a network verification. Every time you start it you get some data from the server that the program needs to run.

You can do some self-verification, set up dark piles, detect debuggers and other things.

1. ** reduces the occurrence of plaintext strings, which can be encrypted, including constants, etc., to reduce the text information that may exist in memory after running.

2. Start a thread to clock detect some key information in the program, and exit if it is modified.

3. Use the external web, etc., to store the key information in the program, such as the MD5 code of the program's exe, and first go to the network to obtain the MD5 of this version after the program runs, if it is inconsistent, it has been modified.

4. There are anti-OD modules, etc., anti-cracking modules. For example, if you use an anti-OD module, you can terminate the operation when running on a computer with OD cracking software.

5. Use less if, if true. Instead, you can use "Judgment ()" to add more invalid judgment branches to the judgment, which increases the difficulty of cracking the entry point.

6. And so on.

I have, I just happened to be working on this stuff in the past two days, privately.