签名的.net程序集在加载时是否经过全面验证,以检查它们是否已被修改? [英] Are signed .net assemblies ever fully verified when loaded, to check they haven't been modified?

查看:120
本文介绍了签名的.net程序集在加载时是否经过全面验证,以检查它们是否已被修改?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我以前认为签名和/或强名的.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):

  • 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?(也许这是wh在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?)

如何验证程序集:

How to verify an assembly: How to programmatically verify an assembly is signed with a specific Certificate?

Grey Wolf(由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以匹配密钥。如果OS(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.

FIX想法:
链接以关闭旁路: 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:)

PS这样会降低启动时间来检查哈希值

P.S. it would slow the boot time to check the Hash

这篇关于签名的.net程序集在加载时是否经过全面验证,以检查它们是否已被修改?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆