How does the reference assembly is verfied to check whether it is tampered?

This question is about verifying the assembly to check whether it is tampered for malicious activity. When an assembly is created, metadata is generated. Metadata includes tables like type definition tables, type reference tables and manifest tables. Reference tables contain an entry for each assembly reference and the entry includes referenced assembly, its public key and a hash value. The manifest includes details of assembly referenced for each assembly and it includes the assembly name, 开发者_StackOverflow中文版its public key and Hashing algorithm. I also understand that during runtime when the assembly is loaded, it generates digital signature of the assembly with the public key embedded in the manifest and compares it with the digital signature already embedded in the assembly. If the digital signature matches then it loads. My questions are below.

1. The Assembly Reference metadata table include a HASH. It is also mentioned that it is not used. Then what is its purpose?
2. Does this assembly verification happen every time the assembly loads?
3. What happens if it is not strongly typed?

1. Good question.

Actually,

"The common language runtime also performs a hash verification; the assembly manifest contains a list of all files that make up the assembly, including a hash of each file as it existed when the manifest was built. As each file is loaded, its contents are hashed and compared with the hash value stored in the manifest. If the two hashes do not match, the assembly fails to load." http://msdn.microsoft.com/en-us/library/ab4eace3.aspx

but...

"Each entry (of AssemblyRef Metadata table) also contains some flags and a hash value . This hash value was intended to be a checksum of the referenced assembly’s bits. The CLR completely ignores this hash value and will probably continue to do so in the future." Jeffrey Richter "CLR via C#" 3rd Edition.

And per my private investigations on .Net 4.0 assemblies - hash sums are really ignored on Assembly Binding stage, even if assembly was signed by crypto-key and so has a strong name.

After a while I've realized that strong-name bypass feature causes this behavior. So you need to "create a DWORD entry with a value of 0 named AllowStrongNameBypass under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework key" in order to enable strong name (+hashsum) validation.

1: No, it's used. Ecma-335, partition II, chapter 6.2.3 on the .file directive:

The bytes after the .hash specify a hash value computed for the file. The VES shall recompute this hash value prior to accessing this file and shall generate an exception if it does not match. The algorithm used to calculate this hash value is specified with .hash algorithm (see clause 6.2.1.1).

2: Only if strong name validation is enabled. Note that this is off by default since .NET 3.5 SP1 in full trust scenarios. You'd have to explicitly enable it with caspol.exe

3: assuming "strongly named", then no validation is possible.