我过去认为，已签名和/或强命名的 .net 程序集在加载时由 CLR 验证，这意味着某人不可能编辑 IL 并仍然拥有有效的程序集。然后我听this great Herding Code podcast Jon McCoy 说这并没有真正发生(播客中大约 12:47)——也就是说，任何人都可以编辑 IL 并弄乱你的程序集，而 CLR 不会关心。我知道这听起来很奇怪，但他似乎知道他在说什么，所以也许只是我不知道他指的是什么场景。
有人可以解释 CLR 是否以及何时会实际验证程序集的全部内容以确保有人没有篡改 IL 吗？如果“签名”或“强命名”不起作用，您需要什么过程才能使 CLR 正确检查程序集？
一些其他引用资料(我还没有完全清楚 - 可能我有点慢):
谈论编辑 IL 和绕过强名称签名 Validating .NET Framework Assemblies (我不知道这是否是 Jon 提到的同一种攻击)。
说攻击者可以用他自己的 key 辞职，但不能完整保留您的签名: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
最佳答案
我是乔恩·麦考伊 :) 是的，可以绕过强名称签名。 为什么/如何-> 运行时仅检查强名称签名 key /证书，但不散列 DLL/EXE 以匹配 key 。如果操作系统 (Windows) 将 .NET Framework 设置为打开强名称签名检查，那么它会打开，但默认情况下关闭。
修复思路: 关闭旁路的链接:http://msdn.microsoft.com/en-us/library/cc713694%28v=vs.110%29.aspx
还有一些保护系统会有一个已知的散列来检查，但这可以被删除。
您可以将其作为一项 IT 政策并在 Windows 中执行。
是的:我的工具 GrayWolf(在 http://www.DigitalBodyGuard.com 上免费)更改了 IL 并将 key 从旧的复制到新的更改副本， key 将与它们所在的 DLL/EXE 的哈希值不匹配，但没有人检查:)
附言检查哈希会减慢启动时间
关于.net - 已签名的 .net 程序集在加载时是否经过全面验证，以检查它们是否未被修改？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20105103/