Easy language anti-cracking tutorial says that using a custom window for an information box is to create a new window by yourself. How can the new window achieve the effect of program waiting or syste

Easy language anti-cracking tutorial says that using a custom window for an information box is to create a new window by yourself. How can the new window achieve the effect of program waiting or system waiting? 4. Random verification

Random verification is very important, for example, one of your verifications always exists, so traitors can easily trace underground breakpoints. Therefore, in addition to a normal verification when the software is started, it is best to verify it randomly in other cases, with a probability of one in 30 or one in 50, so that traitors will keep trying where your software has been verified, so the cracking time will be quite long.

Encryption theorem 14: enough random verification is enough to kill the cracker.

Random verification includes randomly entering different verification subroutines.

Or the maximum number of random numbers is larger, and there is only a 30-in-30 chance of verification.

Or put some picture boxes with the same color as the base map in the window, so that the traitor may not click here, but a user's click will trigger verification.

We assume that all software can be cracked, including easy language, so if his cracking speed can't keep up with the speed at which you release new software, then he will always be exhausted by cracking the latest version. Or it takes him more time to crack than it takes you to write a software, so it is better to write the software directly.

One of the tasks of anti-cracking is to make traitors exhausted or waste their lives.

You can also use the following methods: after reading the registration code, public key and registration file to be verified, you can define the 10000 array, and store the same contents for later inspection, which wastes at most some memory. When verifying, randomly use one of them for verification. Because the traitor doesn't know which array you use for comparison, and it's random, and the value of each verification is different, so it's strange not to let the traitor vomit blood.

Counting loop head (10000, counting)

Array [count] = "123456"' Copy 10000 public registration codes or public keys, and it doesn't matter if the cracker knows it.

Tail of counting period

Array [take random number (1, 10000)]

Don't look up the registration code immediately, 10000 copies. You just need to find one copy casually in the future. The cracker doesn't know which one you are using. At the same time, you can make it up in advance and constantly use some fake calls to read the registration code array to interfere with the cracker. This method has little effect on the performance of the program, but it wastes a little memory. Because Debug limits the memory breakpoint, in this case, he wants to break the breakpoint, and the exhausted person is the one who cracks it.

5. Different permissions verification

It is very necessary to conduct a verification at startup to let the traitor know that it has indeed been verified and let him relax his vigilance, and this verification is only a part of the verification, not a complete verification.

It is also suggested that the registration information should not be verified after being read in at startup, and it is uncertain where to verify it. Personally, I think this will make the cracker more vigilant and think that the software author is very experienced. It is also important to paralyze the enemy.

For example, it is enough to pass the verification once when starting, strengthen the verification level by one level, and then verify it elsewhere.

The following code is to confirm a level.

Count loop head (to value (verify 1),)

Registered = 1

Count cycle tail ()

……

……

Re-verify the level in another trigger subroutine:

Count loop header (registered)

Count loop head (to value (verification 2),)

Registered = 2

Jump out of the loop ()

Count cycle tail ()

Jump out of the loop ()

Count cycle tail ()

In other trigger subroutines, revalidate at this level:

Count loop header (registered)

Count loop head (to value (verification 3),)

Registered =3

Jump out of the loop ()

Count cycle tail ()

Jump out of the loop ()

Count cycle tail ()

Sometimes the level can be lowered, and how to lower it is of course directly verified regardless of the level:

6. Fudge GHOFFICE filter word verification code

I have already talked about the principle of flower instruction, and it is also a good idea to artificially put some GHOFFICE filter words in the program to fool the traitors. GHOFFICE filter word codes are some fake verification codes, which are basically plaintext. There are hundreds of such codes, which is enough to exhaust the traitors.

In fact, there is a way to deal with those experts who "blast according to the jump instruction", which is enough to make them have a headache. That is, you did not obviously add sentences related to judging whether it is genuine or not in the program, and did not give any hints, so as not to let them follow the trace, but jumped to another seemingly reasonable branch after judging it as piracy, and that branch is similar to the genuine branch code, only slightly moved in the calculation formula or other algorithms, making its operation result incorrect. So they can't tell which is right and which is wrong at the machine code level. Even if they think the crack is successful, they actually run it, and the result is full of mistakes and they are not interested. Hehe, calculate the loss! ! !

Encryption theorem 15: Although it is helpless to add a large number of GHOFFICE filter words, it is very useful.

Homework 1: Make a constant * * * *

Requirements: Make an automatic generator of constant code. Hundreds of easy language source code forms can be randomly generated and directly copied into easy language to become constants. Variables can also be made like this.

After writing such a program, the code of GHOFFICE filter words can be automatically generated, and then copied and pasted into the constant table of Easy Language. As shown in the figure below:

Variables can also be generated in this way, but the generated variables can be copied as global variables, assembly variables or local variables at will. The name at the time of production can be a Chinese name, and the Chinese name with the same name will not be found in the EXE file after direct compilation. Therefore, you can safely define these names as "g officefilterword constant 1" and "g officefilterword variable 1" to show the difference from ordinary codes.

Homework 2: Make a code obfuscator

The nature of this assignment is the same as above, which is to automatically generate some useless GHOFFICE filter words in easy language to confuse the traitor's cracking and let him find all GHOFFICE filter words, thus greatly prolonging the cracking time.

By directly copying and pasting the contents of the edit box into your code, you can automatically complete this task, as shown in the following figure:

The above figure generates some code of g officefilterword with plaintext encryption. Let traitors study these GHOFFICE filters.

It's best to call the subroutine name above sometimes, because it won't really work anyway, so it's best to call it with multiple threads.

Or you usually pay attention to collect more subroutines that others use to encrypt, copy them into a useful program and save them. This kind of code is put in your useful program as GHOFFICE filter word code, which increases the size of some programs, but the security is greatly improved. And basically does not sacrifice software performance and stability.

7. Pseudo-verification technology

Let me give you an example first. Before the 10.0 version of the electronic watch, a large number of registration machines were found, so the author of the electronic watch later changed the encryption method. After the launch of E-Watch 10.0, there is still a registration machine, and the software registered by this registration machine can be used. So some users used the registration code obtained by the registration machine. After a period of time, when pirated users were storing important data in the easy table, suddenly one day the database was locked, so they had to register the easy table and let the author unlock the database.

From this, it can be basically judged that the new version of E-Watch adopts pseudo-verification technology, that is, it provides first-level verification in more obvious places. This verification method has not been encrypted too much, but the second-level verification is triggered under certain conditions, and this condition is to check whether the user has entered important data, or a lot of data, or used it more times.

The basic principle is that the registration file consists of two registration codes. Generally, only the first registration code will be verified, and the second registration code will be verified when conditions are ripe.

This is a win-win strategy. The author of the change form will receive the registration fee, and the payer will apologize and thank the author of the change form. Haha, everyone should learn this trick.

However, this method is most suitable for database applications and large amounts of data, but it is ineffective for some users who have not generated data.

When you release the software, you release your registered machine and get a fake cracked version. People who want to crack may not come. Even if there is a crack, who will write a fake crack for themselves? Maybe the fake cracked version is only half cracked. When users use the data, they will lock it and let them register to unlock it. Thank you for paying, haha, this trick is not good, but it works!

Cryptography Theorem 16: Pseudo-verification can confuse ordinary crackers and even publish a pseudo-registry.

8. Time series verification, delay verification and customer data set cumulative verification.

Verify after a period of time. If you release a software in June 5438 +2005 10, the verification opportunity will be triggered after June 2005.

Or your software is a database product, then you can set in the program to verify whether the database is larger than 5MB, and you'd better make sure that these data are not repeated and intentionally added.

For example, a fake authentication is set in an electronic watch, and then a new registration machine appears on the market. When the user uses this registration machine, the prompt is successful registration. But one day after the user entered important data, the database suddenly couldn't be opened, and the user was very anxious. Because he thinks it's cracked successfully, he can only take money to register with the author of E-Watch by inputting important information. I appreciate it, and I regret that I shouldn't have cracked it. Haha, kill two birds with one stone.

This method is a good method for database application software.

Homework: Make an algorithm program and put it in your database software. This subroutine can count whether the user inputs copied things or normal data when your database software is used. Trigger verification when statistics reach 1000. The idea of the method is: you can check whether the user used the shortcut key of copy and paste, or sort the data. If there is a lot of duplication, it means that the traitor is copying data and cracking it. Otherwise, it is an important data for normal use, just compare it.

This method has excellent control effect for users who have information to crack. By combining the pseudo-authentication technology in Article 6 with this technology, we can know whether it is a genuine user, lock the database, and unlock it after he registers.

Encryption theorem 17: the result of encryption should be win-win, and pseudo-verification is the best policy.

9. Technology combining verification with professional knowledge.

Combining verification with professional knowledge makes it necessary for rebels to learn professional knowledge before they can really crack it, which is higher than the cost of writing a software by themselves, and some professional knowledge is unknown to experts, so it is a better encryption method.

In the previous code, "to value (verification 1 ())" returns a number between 0 and 1, which can be mixed by multiplication, for example:

Volume = playback position x to value (verification 1 ())

Returns 1 when the verification is correct, otherwise returns 0, and the result is 0, which is an error.

Such code can be mixed into your professional knowledge. For example, fortune-telling software can carry out such calculations in heavenly stems and earthly branches, Birthday and other places, calculation software can combine some special calculation processes, and drawing software can add some algorithms in drawing to such calculations, such as sound design software and machine tool design software.

Encryption theorem 18: You know the professional knowledge, but the cracker may not know it. Let's combine expertise with verification.

10. Camouflage and write your own support library in easy language.

You can change the extension of DLL file to the extension of FNE file, which is the support library file of Yi language, so that it can be mixed with other FNE files after compilation, or even you can write a support library of Yi language and take a part as the verification part.

The FNE file of the Easy Language Support Library is actually a DLL file, but the extension has been changed. The method of writing support library in easy language has already sent a post, which has been explained. Please search golden eye's post on Yi Language Forum to find it.

Homework: Find golden eye's post about writing a support library in Yi language, and write a support library yourself.

1 1. The wonderful setting of hidden piles.

There are many hidden piles that should be thought of in code. Here are some special hidden piles for traitors to taste.

You can put some hidden stakes in some inconspicuous places, such as random verification when the window is minimized, such as verification when the component mouse moves.

Sometimes it is necessary to put data integrity verification in a higher level of verification, and don't check whether the file has been modified as soon as it comes up.

The same verification can be used many times, so that the traitor thinks that you have already verified it, and there is no need to verify it again. On the contrary, verification is generated at this time, which makes the traitor hard to prevent. For example, when the program starts, check the integrity immediately, and if there is any change, quit the program immediately. Such verification is also randomly placed in some subroutines.

More hidden piles are best designed by yourself.

Encryption Theorem 19: Encryption is very important to the setting of hidden piles, and incomplete cracking is invalid cracking.

12. Release the incomplete version.

Some software authors release incomplete versions of shareware and provide more data after registration. It's ok to do this, but it's a little more troublesome. If there is graphics production software, the picture resources will be packaged separately, and the user will give a full version of the picture after registration.

Some also cleared the verification part of the DLL file, and provided the real registered DLL file and registration code after registration. Others put the key file directly in the DLL file and provide it separately.

The 20th Law of Encryption: Do not release the full version for static braking.

13. Encryption technology combining program and data

Put the resources needed for the program to run into the database file, and set the password for the database. The password is the result of the data summary transformation of the main program. When the program runs, you need to verify whether it is registered or not. If registered, it will take the data summary of the running program itself (take the execution file name ()), form a string after many transformations with its own designed algorithm, and use this string as the password of the database to open the database file. If opening the database fails, it means that the main program has been modified and the program can be terminated. It is impossible to stop, and the program can't find the resources it needs to run. )

In addition, design a program to calculate the database password with the same algorithm, and then encrypt the database.

A large number of support libraries are recommended for cryptographic algorithms. However, if the assembler writes the registry with an assembler, it will directly copy all the disassembly codes supporting the library. The question is whether they have time to do it.

14. Custom algorithm

As mentioned above, the method of intersection calculation between RSA and numerical calculation support library is its own algorithm, and it would be better if advanced functions such as matrix and Fourier transform in numerical calculation support library can be used.

Multiple RSA cross scrambling: You can also use more RSA keys, such as five, 10, which doesn't matter. The important thing is to disrupt all these registration codes and let the traitor cry to death. The way to disrupt is your own original method.

More self-owned algorithms will depend on everyone to study. Good luck to everyone.

Encryption Theorem No.21:Encryption does not oppose eccentric and abnormal methods, and it is encouraged.

15. Encryption block diagram

This is a block diagram of encryption design. You can change the encryption policy according to your actual situation:

In the figure, the periphery of the main program has been compiled and protected by adding a common shell. It doesn't matter if you are bombarded, because there are hidden piles and random inspections.

The picture shows that after the main program runs, the regular registration code is verified for the first time to see if there is a registration file. If this is cracked, the registration code should be a short RSA, and the real registration code is the superposition of three RSA. It doesn't matter if a fake registrar is created.

In the main program, the window title and copyright information are verified in the form of hidden heap, considering that if it is verified as soon as it is started, it will be easily seen by traitors and will jump over. Therefore, some random, hierarchical or conditional methods are used to obtain unfixed verification.

In the main program, the integrity of the main program is checked by hiding the pile. Don't put this into routine verification, otherwise it will be easily skipped. You can check the file length, whether it is MD5 or CRC32 or above.

Anti-debugging module is added in the main program by hiding the heap.

The main program is full of GHOFFICE filter word verification codes. And the source code has comments, which can't be wrong.

The main program randomly performs second-level verification under certain conditions, and takes the second piece of data from the registration code. If the registration code is not long enough to get the second data, it means that a fake registration machine is used, locking the user's database and waiting for him to pay for registration.

The main program reactivates the verification under one condition and obtains the third piece of data from the registration code file. If the registration code is not long enough to get the third data, it means that a fake registration machine is used, locking the user's database and waiting for him to pay for registration.

In the programming, we also pay attention to the scrambling and storage of encrypted strings, encrypt important data with Wu's encryption command, add the algorithm of numerical calculation support library, add some punishment methods and add some own algorithms.

The following are excerpts from some people's programming experience, and the content has remained basically unchanged. Thank you here!

Appendix 1 encryption has formed cryptography.

I quote the author of Applied Cryptography:

There are two kinds of passwords in the world: one is to prevent my little sister from reading your files; The other is to prevent traitors from reading your documents.

If you lock a letter in a safe, hide it somewhere in new york ... and tell you to read it. This is not safety, it is hiding. On the contrary, if you lock a letter in a safe, I will give you this safe, its design instructions and many similar safes, so that you and the best experts in the world can study this lock device. And you still can't open the safe to read this letter. It's safe.

This means that the security of cryptographic system lies only in the confidentiality of key, not in the confidentiality of algorithm.

The encryption of pure data is also true. For those who don't want him to see the data (the clear text of the data), use a reliable encryption algorithm. As long as the cracker doesn't know the password of the encrypted data, he can't read the data.

But software encryption is different from data encryption and can only be "hidden". Whether you want him (a legitimate user or a cracker) to see these data (the plaintext of the software) or not, the software will eventually run on the machine, and for the machine, it must be plaintext. Since the machine can "see" these plaintext, the cracker can also see these plaintext through some technologies.

So in theory, any software encryption technology can be cracked. It's just that the difficulty is different. Some people have to keep the smartest cracker busy for months, and some people may be able to crack it as easily as blowing off dust.

Therefore, the task of anti-piracy (technical anti-piracy, not administrative anti-piracy) is to increase the difficulty of cracking. The cost for them to crack the software is higher than the profit for him to crack the software. So Cracker's cracking becomes meaningless-who will spend more money on pirated software instead of genuine software?

However, how easy is it to "crack"? Sony used to be known as the super anti-piracy version (Key 2 audio music CD anti-piracy version), which used very cutting-edge technology, but it was recently cracked by a marker and became a joke after dinner!

So many technologies that look good may be really easy to crack. Like maginot line, Cracker doesn't start from your line, but "detours". In this way, your anti-piracy technology will be cracked in places you never dreamed of.

Why is this happening? In the final analysis, it is because the software runs on the machine and the software and the machine are separated-this is the key. If software and hardware are completely bound and inseparable, an almost unbreakable system like IDEA can be realized. This point will be explained in detail when we talk about traditional software protection technology later.

For my solution, I can't guarantee that the cracking experts can crack it in a few days. I can only say, "in this software, I try my best to block the possible gap between the methods commonly used by the current crackers and the" I want ". "But I believe that the anti-piracy software I have devoted three months to is by no means a toy anti-piracy software.

Appendix 2 "How to Prevent Cracking by Simple Methods"

Arctic anomaly

In the debugging manual, we can see the limitations of debugging tools: the first limitation is that you can only download breakpoints in four memory areas, and each breakpoint cannot control more than two bytes, so memory breakpoints cannot control areas exceeding 16 bytes; The second limitation is that multiple threads can only trace one thread at a time.

Suppose your registration part has 300 lines, you can divide it into 30 subroutine calls or repeat func 1 (), func2()...func30 (). Feel free to put it in all parts of the program, and never put it together (just find it yourself). Do not use common system calls such as Memcpy to copy the registration code. Try to write it yourself. Memcpy is easy to write, and performance is almost irrelevant. After compilation, the inline function is extended, and the registration part is mixed with other codes. Writing a registration machine is like looking for a needle in a haystack, finding useful registration parts from hundreds of thousands or even millions of assembly codes.

The first limitation of using Debug is that registration codes cannot be put together. Assuming that your registration code is 12 bits, you should not put the registration code in the array of 12 bits. You can define 12 global character variables in different positions of the program, one for each variable, so that the registration code will be discontinuous in the memory. It's best to encrypt it again (simple XOR is enough) and decrypt it when verifying it. Do not use contiguous memory to store variables for validation. Try to define temporary variables for verification in different parts of the program, and then pass some values to other variables continuously during the verification process, which will be more effective for violence and Loader.

There is no need to use complex encryption algorithm, and it is easier to be the target of tracking. As long as you hide the registration part well enough and there are no loopholes, it will take you 1 day to write the encryption algorithm, and it may take the cracker 100- 1000 times to crack it. Most people will give up.

You put the registration together, just like putting your treasure in a modern safe. Although it is very strong and difficult to decrypt, it can be opened in two minutes for a locksmith.

The method used by ancient pirates was to bury the treasure on the island, so there was no treasure map, and there was only one way for all masters and subordinates. It may take a lifetime to dig with a crowbar. There is so much code in the program that it may exceed a million lines after decompilation. If you hide the registered part in it, it's like burying a treasure on an island. Those so-called Crackme are just modern safes for experts to play with, and the same effect can be achieved by the original method.