. Net encryption principle, implementation of method body encryption information ing (1)

In per method DOTNET encryption, the primary solution is the method body correspondence, that is, how to determine the encryption information corresponding to the method body to be decrypted in the runtime encryption shell.

Currently, most encryption shells use the metadata of DOTNET to store this relationship. We know that each method in the metadata corresponds to an RVA value, the encrypted shell can directly record this relationship at the RVA address. During framework running, the data at RVA is directly transmitted as a "method body" in the processing process. The encryption shell intercepts functions in the framework processing process, to distribute the "method body. That is to say, first determine whether the data at RVA is "method body encryption corresponding information". If it is to enter the internal processing of the encrypted shell Runtime Library, It is not processed according to the original framework process.
For this "method body encryption information", the simplest way is to record a pointer information and point it to another data block. The four-byte space is enough. However, in order to distinguish it from normal unencrypted method bodies, in addition to this, you also need to add some unique identifiers so that the runtime database can be safely distinguished.
You can use ue to open the encryptedProgramSet to see the data at the RVA of a method body. It is easy to identify the recorded "method body encryption information ".
For this reason, the encryption shells of dnguard V1.0 and similar processing methods cannot encrypt method bodies smaller than a specified number of bytes.
Because the size of the "method body encryption information" exceeds the size of the method body space, the data written will overwrite the subsequent method body information. This is actually caused by laziness. This problem can be solved by rearranging the method body. Of course, it is a lot of trouble.

In this mode, a virtual table is saved in the metadata to implement the corresponding records of methodtoken => "method body encryption corresponding information. This table is public.

In dnguard 2007, I did not choose to solve this problem by means of weight sorting. Instead, I chose another method to record a virtual table implementation by myself: methodtoken => the corresponding record of "method body encryption information.
The advantage is that the virtual table can be encrypted and saved. In addition, there is no need to add identifiers in the "method body encryption information" to distinguish them from common unencrypted method bodies.

No real encryption is used in the dnguard 2007 trial.AlgorithmTo encrypt the Assembly, but the"CodeThe "decryption" Operation of the running database is only an operation that is directly read from another location.

A friend previously analyzed that there was a dnguard trial version.The virtual table records methodrid => ilcode. This is the virtual table: methodtoken => "method body encryption information" in the trial versionDegraded Model.

In addition, because the method body is only moved to another location, it is still in the Assembly file, loaded into the memory, and also in the memory space of the assembly module. Instead of entering the Il code back into the memory after decryption of the running library that the friend said.

The trial version is only provided to verify whether dnguard is suitable for your software project and system release environment. Do not use the trial version to encrypt the Assembly and distribute it directly.