. NET core code protection policy-hide core assembly

After the storm of moral criticism, I haven't written a blog for a while. Of course, it's not that I have been so guilty that I haven't written it for so long. It's just a common problem for programmers .. I wanted to write a long story about how to be lazy. Think about it or forget it. It is estimated that it will lead to a new wave of offensive. It has no practical significance. It will affect the ethos and make everyone feel uncomfortable. This writing has practical significance, tell me how I protect my code, my personal experience. If anything is wrong, please forgive me.

We all know that. NET code is easily decompiled. From the perspective of the attacker, cracking a software can be divided into several types:

1. Modify the registration verification code to bypass registration;

2. Crack the registration core algorithm and write the registration machine;

3. Completely copy the code into a project that can be compiled and modified;

In terms of harm, the third type is the most serious. If your software is copied by more powerful competitors, it would be a devastating blow, theoretically. NET does not have any software to crack and copy. As long as a master is dead and wants to break your software, it is meaningless to protect it. At that time, he can only accept his fate, of course, General experts are also eager to crack meaningless things. Although we cannot fully protect the code, we can increase the difficulty of cracking and prevent experts. At least we need to defend against common programmers like me, it is an insult to the programmer's IQ that we cannot touch our code at all times.

Generally, several important processes of protecting software are as follows:

1. design the machine code;

2. Generate a registration code based on the machine code;

3. Verify the registration code (local + remote verification );

4. Enhance Assembly naming;

5. obfuscation of the assembly code;

Of course, these steps cannot be completed at one time. At present, I will mainly talk about how to hide my core assembly, that is, the. DLL dynamic library. When we write a project, there will certainly be a variety of dynamic libraries. When we compile a project, there will be *. DLL dynamic library appears, DLL contains a lot of metadata, Which is easy for people to decompile software to see the code in, so it is very important to hide the assembly, the idea is: save the assembly to the memory and use it only when it is used. In this way, the decompilation software cannot easily see our code, but it is a relatively large project, it is unrealistic to store all the Assembly into the memory. We can only hide several core assembly sets, such as the registration and verification process, login process, and core algorithm process, because you have hidden some important assemblies, even if some people get your other code, it still takes a lot of time to correctly run the software. By Zengg

It took a little time to write a DEMO that hides the Assembly, such:

 

　　

　　

　　

The main functions of this DEMO are:

1. Open a DLL from the outside and list the classes in the DLL;

2. List the number of executable public methods in a class;

3. When a method is executed, the returned result of the execution is displayed, provided that the method has a return value;

4. Convert the DLL opened from the outside into C # available code, so that everyone can store it in the memory;

5. Read the Assembly that has been saved into the memory from the memory and execute a class method of it;

Let's take a look at the VS structure of the project:

　　

Let's assume that the class library AssemblyTest is the place where we register for verification. AssemblyWPFDemo is our main program. Generally, if we want to use the function of the AssemblyTest class library, the main program must first reference the class library before using the function of this class library. There is a problem here. As long as the class library is referenced, the corresponding DLL of this class library will be generated locally, this exposes our code. The following process is to explain how to use the function of this class library without reference. By Zengg

AssemblyTest Class Library:

There are two test classes and a WPF form.

AssemblyTest1AssemblyTest2

WPF form Preview

This form is the window popped up by the DEMO Pipeline Above.

Let's take a look at how the main code is implemented. Before that, you may have to understand the application of C # Assembly. In this example, I only write some simple comments. Let's take a look:

Core code:

[] GetAssemblyToByte ([] assemblySource === ByteConverToString (memberNmae, strAssemblySource = + memberNmae + (B + = B. toString () + = strAssemblySource. substring (, strAssemblySource. length-+ = Assembly GetAssemblyBySource (= (assembly = NullReferenceException (assembly = (type = InvokeMember (MemberInfo menberInfo, | BindingFlags. public | BindingFlags. instance, obj, InvokeMemberHaveResult (MemberInfo menberInfo, obj. getType (). invokeMember (menberInfo. name, BindingFlags. invokeMethod | BindingFlags. public | BindingFlags. instance, obj,AssemblyControl

The AssemblyTestSource class in AssemblyWPFDemo stores the binary stream of our AssemblyTest class library. The binary stream is converted through the demo I wrote, there is a "conversion code" button in it. After you open a DLL, you can convert it to C # code. By loading this data stream, you can get the AssemblyTest assembly, with the assembly, you can use the functions in the Assembly. Due to the large number of AssemblyTestSource codes, pasting will affect the layout. You can download the DEMO on your own.

The others are some simple logic processing. I am only playing a leading role here, but it is rough to write. You should note that, the binary stream of the Assembly must be concealed and artistic. Otherwise, others can still extract the binary stream and save it to the file. This will become a DLL, if you are interested in the research, you can study the encryption of these binary data, and try to increase the difficulty of decompilation.

Here, I want to talk about the relationship between the cracker and the software developer. We write software protection to be a brave process with the cracker. These two are benign competitions, if you lose, it means that your skills are not as good as you do. If you go back to the furnace and try again, your technical skills cannot be improved, you must understand how the hacker thinks to design better protection methods. I believe that a good hacker must also be a brilliant software developer, there is no clear line between the two relationships... I also wish you a happy National Day in advance... The next blog does not know when it will come out... I may write several articles in the future around the topic of protection ..

Source code: http://pan.baidu.com/s/1xc9aW

If you have read this blog and think it is helpful to you, click [recommendation] in the lower right corner.

If you want to repost this blog, please indicate the source

If you have any comments or suggestions for this article, please leave a message.

Thank you for reading this article. Please follow my blog Zengg.

Author: Zengg Source: http://www.cnblogs.com/01codeworld/ this article copyright belong to the author and blog park a total, welcome to reprint, but without the author's consent must retain this paragraph of the statement, and in the Article Page clearly given the original connection, otherwise, you are entitled to pursue legal liability.