In the first chapter, I talked about the security overview. There is nothing specific about it. I have recorded a little bit about trust, some of which can be passed. Security is not perfect for software.
I hate abstract things and cannot understand them;
Starting from Chapter 2
* Single fileProgramSet: includes assembly data, type metadata, msil, and resource set;
* Strong name: it consists of the Assembly name, version, and many other things. The digital signature is related to the hash code generated by the Assembly content and the randomly generated key pair, so who said it was almost the only one. At this time, if we identify the strong names when referencing the program, we can see whether the source file has been decompiled. nnd is the first step of the general reverse engineering cainiao card;
... A lot of commands and things. Let's talk about them later...
* Fuzzy processing: In the end, renaming and other methods are used to combat decompilation. However, it is a pity that it can only be delayed for a while, but it is useless;
* Local Compilation: it is used to make the local compilation different from the. NET output. The principle is very vague. It is not mature yet. I don't know what it is like now;
Chapter 3
* Application domain: it is used to isolate programs. Just like the relationship between processes, it can only communicate through other means;
* From large to small: Process> CLR> domain (default domain is generated when CLR is loaded, and other additional domains are determined by the host)> assembly (after loading, it can only be uninstalled by writing it in the application domain );