已签名的 .net 程序集在加载时是否经过完全验证，以检查它们是否未被修改? [英] Are signed .net assemblies ever fully verified when loaded, to check they haven't been modified?
问题描述
我曾经认为已签名和/或强命名的 .net 程序集在加载时由 CLR 验证，这意味着某人不可能编辑 IL 并且仍然拥有有效的程序集.然后我听了这个很棒的牧群代码播客Jon McCoy 说这并没有真正发生(在播客中大约 12:47) - 即任何人都可以编辑 IL 并弄乱您的程序集，而 CLR 不会关心.我知道这听起来很奇怪，但他似乎知道他在说什么，所以也许只是我不知道他指的是什么场景.
I used to think that .net assemblies that were signed and/or strong-named were verified by the CLR when loaded, meaning that it wasn't possible for someone to edit the IL and still have a valid assembly. Then I listened to this great Herding Code podcast where Jon McCoy said that doesn't really happen (approx 12:47 in the podcast) - i.e. anyone can edit the IL and mess with your assembly and the CLR will not care. I know this sounds weird, but he seems to know what he's talking about, so perhaps it's just that I don't know exactly what scenarios he's referring to.
有人可以解释一下如果 &CLR 何时会真正验证程序集的全部内容以确保没有人篡改 IL?如果签名"或强命名"不这样做，您需要什么过程才能让 CLR 正确检查程序集?
Can someone explain if & when the CLR will actually verify the full contents of an assembly to ensure that someone hasn't tampered with the IL? If 'signing' or 'strong naming' doesn't do it, what process do you need to make the CLR check an assembly properly?
其他一些参考文献(我还没有完全清楚 - 可能我只是有点慢):
Some other references (that haven't made it entirely clear to me - probably I'm just a bit slow):
讨论编辑 IL 和绕过强名称签名验证 .NET Framework 程序集(我不知道这是不是 Jon 提到的那种攻击).
Talks about editing the IL and bypassing the strong name signing Validating .NET Framework Assemblies (I don't know if this is the same sort of attack referred to by Jon).
说攻击者可以用他自己的密钥辞职，但不能让你的签名完好无损:可以使用强命名程序集来验证程序集作者吗?(即与 Jon 提到的攻击不同)
Says attacker can resign with his own key but can't leave your signature intact : Can strong naming an assembly be used to verify the assembly author? (i.e. not the same attack referred to by Jon)
从 .net 3.5 CLR 说起在完全信任的情况下不会验证程序集:为什么 .NET 不验证 BCL/CLR?(也许这就是 Jon 的意思?)
Saying from .net 3.5 CLR doesn't verify assemblies under full trust: Why does .NET not verify the BCL/CLR? (maybe this is what Jon means?)
如何验证程序集:如何以编程方式验证程序集是否使用特定证书签名?
Grey Wolf (by Jon McCoy) - 用于在程序集上复制强名称签名！?https://www.digitalbodyguard.com/graywolf.html
Grey Wolf (by Jon McCoy) - for copying strong name signing on assemblies !? https://www.digitalbodyguard.com/graywolf.html
推荐答案
这是 Jon McCoy :)是的，可以绕过强名称签名.为什么/如何-> 运行时只检查强名称签名密钥/证书，但不会散列 DLL/EXE 以匹配密钥.如果操作系统(Windows)将 .NET Framework 设置为打开强名称签名检查，那么它会但默认情况下关闭.
This is Jon McCoy :) Yes the strong name signing can be bypassed. WHY/HOW-> The Runtime only checks the strong name signing key/cert but does not Hash the DLL/EXE to match the key. If the OS(Windows) has the .NET Framework set to turn Strong name Sign checking on then it will but this is off by default.
修正想法:关闭绕过的链接:http://msdn.microsoft.com/en-us/library/cc713694%28v=vs.110%29.aspx
FIX Ideas: Link to turn the bypass off: http://msdn.microsoft.com/en-us/library/cc713694%28v=vs.110%29.aspx
还有一些保护系统会有一个已知的哈希值需要检查，但可以删除.
Also some protection systems will have a known hash to check but this can be removed.
您可以将其作为 IT 策略并在 Windows 中强制执行.
You could enforce it as an IT policy and in windows.
是:我的工具 GrayWolf(在 http://www.DigitalBodyGuard.com 上免费)更改了 IL 和将旧密钥移动到新的更改副本，密钥将与它们所在的 DLL/EXE 的哈希不匹配，但没有人检查:)
Yes: My Tool GrayWolf(free on http://www.DigitalBodyGuard.com) changes the IL and moves the Keys from the old one to the new changed copy, the keys would not match the HASH of the DLL/EXE they are on but no one checks:)
附言检查哈希值会减慢启动时间
P.S. it would slow the boot time to check the Hash
这篇关于已签名的 .net 程序集在加载时是否经过完全验证，以检查它们是否未被修改?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
