Let's talk about how petabytes of software can prevent cracking?

We have discussed this issue before:

Http://blog.csdn.net/chengg0769/archive/2009/02/28/3944575.aspx

 

However, this is a general idea. For Pb programs. It mainly deals with the infringement of the decompilation software.

Depb (version 1.0 depends on a lot of bugs, and a structure cannot be decompiled), pbkiller, and shudepb. Because Pb is executed by Vm, compilation and debugging are not a serious threat to Pb-written programs.

 

Roughly speaking, there are several protection methods at the end:

1. Compile a single EXE file using machine code.

In this decompilation software test, only the variable Declaration and the source code cannot be seen. If your program cannot be compiled into an EXE ), then you may wish to put the key part in an independent small executable file, such as registration code verification, and then this small Executable File generates an external file, for example, a K binary file. Immediately call the main program to run the entire program, and the main program will read this external K file into the Blob variable immediately, and then delete the external K file. Then, in the main program, we intentionally or unintentionally reference the values in this blob in many places to restrict the software. In general, unless the author decompile his own software, it is generally impossible for the attacker to decompile the software completely (or without the corresponding professional knowledge and patience. In this case, they can only get a glimpse of some code, but your code indicates that you want to limit the number of rows for a data query to 100, and there is no way for them. It should be impossible for him to decompile and then compile and package it! Right. We can prevent the code from being modified and re-packaged in the sense of [You can see the Code. Imagine if you have done something in 100 places, does he have the patience to get a tool and what effect does it achieve?

 

To sum up, put the key sensitive code into the single EXE compilation file of the machine cdoe, and try to confuse the hacker in the main program. He doesn't understand the program, so he is very difficult.

 

2. Compile sensitive code in pbni mode and convert it to PBD. Generally, The Decompilation software can only compile traditional PBD and DLL, but cannot decompress the PBD compiled by VC ++.

 

3. If a global object appears many times in a project, it will be searched in the Lib order, so this can also be used to confuse the hacker. For example, I generate multiple copy objects for several functions or even forms, put the test version in front, and use a single machine code program to verify the registration code. If the registration code is OK, then I can generate an encrypted file, which indicates the order of Lib. Set this order in the main program. Assume that the order is 10001.pbd 10002.pbd 10003.pbd. Of course, my ordered list is extracted from the encrypted file. Because he used shudepb to view the code, he could not debug it. After all, there were many errors after software decompilation. The error cannot be modified in days or nights, so we can think that he does not have debugging conditions. The specific order of your lib should be unclear.

 

You can dynamically create your real PBD from a file. It increases the difficulty of cracking.

You can parse all PBD or DLL files from a package and use an independent EXE file to execute this task. That is, multiple fake PBD files are generated under the main program, then, the PBD is generated in the window system directory or the directory pointed to by other paths. Then, the list is passed in through the parmlist of the main program, and the library path strength is set in the open event of the application of the main program. You can release hundreds of files at a time. Delete after use, and generate again next time. In this way, the file name can be named randomly and randomly. During static decompilation, PJ cannot confirm where your correct object is. It is useless for PJ to modify the PBD file.

 

Considering pbkiller and shudepb, it is best to create hundreds or even thousands of files at startup... Wait for PJ to study.

 

In short. Many compiled software can be easily cracked. The reason is that someone else tracked the Assembly commands like jxxp after ASM. And I think petabytes of programs are enough to fool the scammers. We can try to delay time and protect the software. Increasing the time cost and difficulty of cracking is a way to increase the magic. Imagine if a door is locked and you want to open it, you can quickly think of a way. The more violent way is to drop the lock or the door. However, if you adopt a method that is confusing enough, you may not know where the door is, or set a number of fake doors to delay his time and increase its frustration. I think it is also a good method. 4. For Network Authentication, place the authentication part on the network server. After Authentication, download an encrypted file. Use it to set some program parameters. Of course, some people will say that the hacker has a lot of technology. How can he do it! However, his workload is no less than the workload of re-developing 10 sets of software. What's his pain?