我以前认为已经签名和/或强名称的.net程序集在加载时由CLR验证，这意味着某人无法编辑IL并且仍然拥有有效的程序集。然后我听了this great Herding Code podcast Jon McCoy所说的并没有真正发生（播客中大约12:47） - 也就是说，任何人都可以编辑IL并弄乱你的程序集，CLR也不会关心。我知道这听起来很奇怪，但他似乎知道他在说什么，所以也许只是因为我不确切地知道他所指的是什么情景。
有人可以解释一下＆amp;当CLR实际验证程序集的全部内容以确保某人没有篡改IL时？如果“签名”或“强命名”不能执行此操作，您需要使用什么过程使CLR正确检查程序集？
其他一些参考文献（对我来说还没有完全清楚 - 可能我只是有点慢）：
谈论编辑IL并绕过强名称签名Validating .NET Framework Assemblies（我不知道这是否与Jon提到的那种攻击相同）。
攻击者可以使用自己的密钥辞职，但不能完整保留您的签名：Can strong naming an assembly be used to verify the assembly author?（即不是Jon提到的同一攻击）
从.net 3.5说起CLR不会在完全信任下验证程序集：Why does .NET not verify the BCL/CLR?（也许这就是Jon的意思？）
如何验证程序集：How to programmatically verify an assembly is signed with a specific Certificate?
Grey Wolf（由Jon McCoy撰写） - 用于复制强化名称在程序集上的签名！ https://www.digitalbodyguard.com/graywolf.html
答案 0 :(得分：5)
这是Jon McCoy :) 是的，可以绕过强名称签名。 WHY /如何 - ＆GT;运行时仅检查强名称签名密钥/证书，但不会散列DLL / EXE以匹配密钥。如果操作系统（Windows）将.NET Framework设置为打开强名称签名，那么它将会默认关闭。
FIX创意： 关闭旁路的链接：http://msdn.microsoft.com/en-us/library/cc713694%28v=vs.110%29.aspx
另外一些保护系统会有一个已知的哈希来检查，但这可以删除。
您可以将其强制执行为IT策略并在Windows中执行。
是：我的工具GrayWolf（在http://www.DigitalBodyGuard.com上免费）更改IL并将密钥从旧密钥移动到新更改的副本，密钥与它们所在的DLL / EXE的HASH不匹配但是没有人检查:)）
P.S。它会减慢启动时间以检查哈希