. Net dll protection measures (non-obfuscation encryption shelling),. net details

. Net dll protection measures (non-obfuscation encryption shelling),. net details

I won't say much about why we want to protect the DLL. Each person has his/her own reasons. In general, we do not want to expose the core logic or crack the authorization verification.

 

First, let me introduce the risks faced by the released DLL:

1. Direct reference

Ii. Decompilation

Iii. Reflection

If the DLL does not take any action at all, any of the above methods can achieve the purpose of cracking.

 

Then, the following protection methods can be found on the Internet, but it is of little use. Of course, it is more difficult for the hacker.

I. obfuscation tools (such as Dotfuscator, but it can be decompiled through ILSpy, Reflector, and so on, and can be run by directly copying the code)

2. encryption tools (such as MaxToCode, corresponding cracking tutorials on the Internet)

Iii. Shell tools (for example, Sixxpack, corresponding cracking tutorials on the Internet)

4. Strong signature (the signature only prevents a DLL from being tampered with in the project and does not prevent decompilation or reflection)

 

Having said so much, isn't there a relatively reliable way?

Finally, let's go to the topic

The purpose of the above tools comes down to two goals: one is not visible, and the other is not adjustable. Of course, we also achieve these two goals, but the means are different.

I. Cannot read :. net dll can contain hosted heap Code (which can be decompiled) and non-hosted heap Code (which cannot be decompiled. decompiled is a higher level and is out of discussion scope ), we place the core logic code in the non-heap code, and the managed heap Code provides interfaces for external calls. When called, the unmanaged code passes through. NET Dynamic compilation feature returns the execution result after compilation. In this way, you can't see it.

Ii. Call failure: we add the caller source verification function in the unmanaged code, determine whether the caller's HASH value is the same as the HASH value agreed in the unmanaged code (the HASH value of the reference must be generated in advance during release and stored in the unmanaged code, finally, the DLL that generates the unmanaged code is stored in the installation package.) If they are consistent, the returned result is executed. If they are inconsistent, the returned result is null. In this way, the issue of non-legal sources cannot be adjusted.

 

Note: problems arising therefrom

I. performance problems: dynamic compilation of each call will definitely affect the performance, but we can solve this problem through caching. During the first call, the compiled objects will be stored in the cache.

Ii. Platform Problems: unmanaged code cannot generate ANYCPU type DLL, so two versions (X86/64) need to be released to generate the corresponding version DLL, the installation package determines the target platform attributes and then outputs the corresponding DLL.

Iii. Release problem: during each release, the HASH value of the dependent project must be accumulated in the unmanaged code and then generated in the installation package. The steps are a little complicated, but for security, this should be acceptable.

 

----------------------------------------------------------------------------

To all the students who are still suffering this problem, the above only provides ideas. I already have solutions for the above ideas. Because it takes a lot of effort and energy, if you still cannot solve the problem by thinking about your ideas, you can ask me (6458450), and I can provide paid services.