. Net Assembly signing tool sn.exe key pair SNK file basic usage, sn.exe snk

. Net Assembly signing tool sn.exe key pair SNK file basic usage, sn.exe snk

Before discussing the concept of a signature tool, let me talk about it as follows:

1. It is not a tool used to encrypt an assembly. It has nothing to do with preventing Reflector or ILSpy from decompiling the assembly.

2. It is annoying for people to associate it with encryption.

Let me talk about what it is:

1. Start with a big name

Sn is the scaling of strong name. The positive name. The purpose of sn.exe is to give the Assembly a unique name (Hash + name + version + culture), that is, signature, ensure that two different DLL names will not be duplicated (the same as the ID card cannot be duplicated)

2. Let the caller identify whether the called DLL has been tampered

This is what I want to talk about. Let's assume a scenario first. A hacker is using a Client client program to Transfer funds to an account. After a reverse compilation, bank.exe calls the TransferMoney method of Transfer. dll to Transfer funds. Naturally, he thought that if I modified the TransferMoney method, multiplied the amount parameter by 10, and then re-compiled it into Transfer. dll to overwrite the original Transfer. dll, he would be the richest man in the universe!

The security question that we need to solve is that bank.exe has the ability to know whether the Transfer. dll it calls has been tampered with by others. We will naturally think of using the information digest algorithm ~ (The 128-Bit String extracted from different contents is absolutely different.)

Yes! The snpicking information of this big name, we can save it in the reference information of bank.exe. I should call Transfer. the dll digest value OriHash, so that we can digest the current Transfer before calling. dll to get the CurHash, and then compare the OriHash and CurHash! The process is as follows:

　　　　　　　　

This seems to be the correct answer,...

In this case, there is a problem about the abstract value you saved in advance, OriHash. There are two aspects:

Aspect 1. Once I update Transfer. dll normally, the final point will also be changed, and you need to notify bank.exe to update OriHash.

Aspect 2. Security issues caused by Question 1.

On the other hand, I think it is the most important reason, and transfer.dllis updated. to compete, bank.exe needs to update OriHash and update Transfer 100 times. dll, you need to update OriHash for 100 times. This is too bad. Of course, this is only a problem at the level of trouble. What's more serious is that, we can imagine the security problems caused by frequent OriHash updates.

The project file (such as Bank. csproj) to which the ingress belongs. At this time, OriHash has more risks of being hacked, which is a security problem!

So based on the above two points,. Net has come up with an asymmetric encryption algorithm! (Next, asymmetric encryption generates a pair of keys-private key and public key. The plaintext is encrypted by the private key and can only be decrypted using the public key. Otherwise, the private key must be kept confidential, public key can be assigned to anyone)

Encrypt OriHash with the private key as CodedHash and store it in Transfer. dll. In bank.exe, save this one-time storage to call Transfer. dll public key, but be sure to realize that Transfer. dll has no private key. The private key is only contained in myPair. in the snk file, you are the only one who holds the file, and the security guards with the gun are vowed to protect them from being taken away by others.

The new verification process is as follows:

A.m. first, bank.exe contains the public key and Transfer. dll contains CodedHash.

B .Bank.exe use the public key to decrypt CodedHash

C1. if the decryption succeeds, it proves that the CodedHash is encrypted with the private key paired with my public key.

C11. digest Transfer. dll to get CurHash and compare it with the decrypted Hash. If the same, it proves that Transfer. dll is safe and complete. Load it. If they are different, it turns out that the Transfer. dll has been tampered with by someone else. At this time, the Transfer. dll cannot be loaded.

C2. if decryption fails, it indicates that the CodedHash is encrypted with another private key, that is, the hacker. At this time, it also refuses to load Transfer. dll.

For example:

　　　　　　

The hacker only needs to use the public key to decrypt the CodedHash to know who sent the message, and compares the decrypted Hash with the real-time calculated Transfer. dll Hash. Here we have a logic assumption that the public key in bank.exe in order to call Transfer. dll is true. If you say this is a black hole, then I can only say that he can modify the public key information in bank.exe. Then he wants to change something, so you can put it together. In addition, if you say that you are afraid to give the orihashmap of bank.exe, are you afraid that the public key sent to bank.exe is false? I can only say that your logic is clear. Indeed, we cannot guarantee it, but what I want to say is that after all, the Public Key is transmitted only once, and OriHash may need to be transmitted multiple times, with different risk probabilities, if we assume that Transfer. dll will never change, that is, OriHash will only be uploaded once. Then I can say that you use the same non-asymmetric encryption algorithm, this is because OriHash for the first time is true and the Public Key for the first time is true, and the risk coefficients are the same. I don't know if you can understand what I mean. It took a long time for me to go smoothly.

We can assume that the hacker may launch the attack again: (the hacker cannot use bank.exe or PubKey1)

Attack 1: modified and overwritten my Transfer. dll, but CodedHash is exactly the same

In this case, the Hash of the Transfer. dll digest is different from the Hash of the PubKey1 CodedHash decryption result!

Attack 2: modified and overwritten my Transfer. dll. The hacker generated a public key private key pair and encrypted the Hash of Transfer. dll into CodedHash with the private key.

In this case, when we use PubKey1 to decrypt CodedHash, since the public key PubKey1 is not in pair with the hacker's private key, the decryption cannot be solved!

Attack 3: modified and overwritten my Transfer. dll, and Transfer. dll was not compiled by signature at all.

In this case, the result is the same as the previous two!

Attack 4: The hacker cannot hold your private key, indicating that there is no other attack solution, T_T.

So far, the principle is finally explained. Next I will introduce how to use sn.exe to handle these issues.

I'm so disgusted that mshas packaged so many important tasks in sn.exe. First, we have two projects, Bank. csproj and Transfer. csproj. What we need to do is the implementation process.

1.use sn.exe to generate the private key pair file myPair. snk. For example: (You have to swear to protect myPair. snk, because there is a private key, and this is the only place where the private key exists)

　　　　　　　　

2. In the Transfer project, fill in the path of myPair. snk to the AssemblyInfo. cs file, for example:

　　　　　　　　

3. Compile the Transfer project and generate Transfer. dll. At this point, the compiler instantly completes the Transfer. dll Hash, and use myPair. the private key in snk is encrypted into CodedHash and stored in Transfer. dll, and the public key information is stored in Transfer. dll (Note that there is absolutely no private key ).

4.in the Bank project, reintroduce the transfer.dll file and recompile bank.exe. during compilation, the compiler extracts the Public Key PubKey1 in Transfer. dll and writes it in the description of the referenced Dll. When we use the decompilation tool named bank.exe, we can view the following information:

// Transfer, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 3d5e0147c186af58

PublicKeyToken is what we call Public Key PubKey1.

The following information is thrown during the commit operation:

　　　　　　　　

 

This is the most basic application. I have also referred to many articles. The most important of them is.

Once again, sn.exe cannot encrypt the Assembly to prevent decompilation, but only let the caller know whether the called object is desired.

In addition, HTTPS also uses a similar scheme to determine whether the other party is its own. It only adds a symmetric encryption algorithm to encrypt data packets. The others are the same as this.

This is my first blog in the garden. It is not easy to write ~

Wish everyone progress together in the garden!